Проблема с переменной цены $item.price и операции с ней

Доброго времени суток, друзья!
Надеюсь Вы все живые и активные на форуме, давно не трогал инстантсмс, но по ряду причин решил вернуться и учить вторую ветку. Но пока с первой не домучаю, тяжело двигаться дальше.

Собственно, вопроса два:
1) в базу данных компонента универсальный каталог загнал цены товаров с 2 десятичными — типа 15000.20 копеек
При правке записи цена округляется и остается 15000 только. Куда копать, даже не знаю

2) Операции с ценой товара вообще кружат голову — {$item.price} выводит 15000, а вот {$item.price+$item.price/10} выводит 16.5
Откуда такая неразбериха?

Помогите пожалуйста, кто хорошо помнит старую добрую первую ветку и смарти

Евгений Фоменко, смотрите в моделях запросы в базу как бы там round не использовался.

Там есть запрос и в нем используется round — если его просто удалить, то цена не сохраняется, а своих знаний корректно удалить у меня мало. Но если Вы тоже думаете, что причина round — покопаю этот момент внимательнее!
Спасибо большое

Евгений Фоменко, обычно round(тут переменная какая-то), вот и берите переменную без round и скобок.
Далее посмотрите чтоб в настройках таблиц базы данных не было округление, а то если запись в базе уже округлена, то счастья не будет

Ок, спасибо — сейчас гляну в базу. Как в базе может стоять округление? Там просто стоит в структуре float и все.
Да и если товар редактировать — то в поле цена копейки ещё есть, а уже после сохранения исчезают. Очевидно это баг в системе, я большинство файлов поставил с дефолта.

Спасибо за помощь, буду копать

Евгений Фоменко, например dev.mysql.com/doc/refman/5.5/en/fixed-point-types.html кол. после запятой и т.п.

Вы правы — это таки округление
$item['price'] = round($price, 2); (строка 953)
Хотя по логике тут ошибок нет — округление до 2 десятичных должно было оставлять 200,07

По крайней мере можно мелкие товары забивать
СЕйчас попробую разобраться со второй частью вопроса