Округление цен, дробное количество товара Исправлено
Добрый день. Уже не раз поднимался вопрос дробного количества товара. Мы занимаемся продажей напольных покрытий (линолеум) - товар отрезной. Торгуем и мечтаем о вводе так необходимого нам функционала. Необходима возможность формирования заказа либо в метрах погонных (например 5,65 м.п. - 2 знака после запятой) либо в м2 (например 19,775 м2 с возможностью выставления кратности - 3 знака после запятой).
Мы из этой ситуации выкручивались, введя дополнительные артикулы - ширина линолеума с указанием цены за 1 см погонный. Клиенты тормозили жестко, но система худо бедно работала. Пример:
НО ПОСЛЕ ОБНОВЛЕНИЯ 08.11 С ОКРУГЛЕНИЕМ ЦЕН ВОЗНИКЛА ДРУГАЯ ПРОБЛЕМА:
Округлять начало цену, а не сумму по заказу. Так как мы были вынуждены указывать цену за 1 см.погонный, то цена артикула получалась в бэкенде такого вида 2,5м- 0,3925руб (Валюта белорусские рубли).Пример - заказ куска 2,5х5,65м по цене 15,7 руб/м2. До обновления клиент оформляя заказ видел после выбора ширины 0,39, но при оформлении заказа расчет производился корректно для нас 565х0,3925=221,7625 и работало округление до 221руб 76коп (что нас полностью удовлетворяло, т.к. приход товара и учет ведется в м2). После обновления округляться стали цены артикулов и сейчас при формировании аналогичного заказа мы получаем 565х0,39=220,35 руб. Возможности отключить округление цен нет (галочка не снимается):
Заранее спасибо.
14 комментариев
такая же проблема, нужна возможность заказать дробное кол-во и проблема с округлением, перелопачивать двиг самому не выход, так как после обновления очередного слетит всё
для себя временно решил проблему, но после очередного обновления слетит в контроллере правка, нужно будет повторять, вроде нигде больше ничего не правил:
/wa-apps/shop/lib/actions/frontend/shopFrontendCartSave.controller.php
13 строка поменять тип int на float
было if ($q = waRequest::post('quantity', 0, 'int')) {
стало if ($q = waRequest::post('quantity', 0, 'float')) {
таблицы
shop_order_items поменять тип поля quantity на double 10,3
shop_cart_items поменять тип поля quantity на double 10,3
посмотрю, как будет работать, пока что вроде норм
Не норм , списание и перемещение со складов не доделали.
Если не секрет, то куда копать? Просто у меня остатки постоянно обновляются извне, с 1с, но всё равно хочется сделать по фен-шую
Мне-то по сути это не нужно, я про списание со складов, а другим пригодится. Так понимаю ещё поля count нужно у продуктов и sku править, может ещё где в коде есть траблы?
Не понимаю в чем трудность у разработчиков сделать это, просят люди не первый год.
и да не double лучше, а decimal в типе поля
я сделал плагин дробного количества, но с учетом текущих привязок плагинов к целому получается жуть!
Подскажите пожалуйста, есть окончательное решение проблемы с мерными товарами?
нету и быть не может пока система еще не готова к такому, все заточено под целые числа
для того, чтобы правки при обновлениях не слетали, рекомендую эту приблуду - https://github.com/MihanEntalpo/MonkeyPatching
позволяет учитывать любые правки практически в любых файлах на лету.
Кто-то может написать пошаговую инструкцию как ввести дробные? Не все отличаются умом и сообразительностью+ стоит сторонняя разработка и боюсь что все уедет ... или есть кто за деньги делает?
Нужны дробные(они есть) но по итогу все округляется, можно отключить округление?
Есть плагин, но он не работает с другими плагинами, т.к. они привязаны к целочисленному количеству товаров...
Помимо проблемы в /wa-apps/shop/lib/actions/frontend/shopFrontendCartSave.controller.php, решение которой описал пользователь с оккультным ником есть ещё место, куда следует внести правки, чтобы округления не происходило.
Следующая правка актуальная для последней, на момент комментария, версии.
В файле /wa-apps/shop/lib/classes/shopOrder.class.php следущие правки вносим:
Плохой совет. Скидки за штуку, налог, различные экспорты, синхронизации -- вы постоянно будете сталкиваться либо с некорректным расчётом, либо просто что-то перестанет работать.
А даже если у вас лично, кажется, всё работает, то советовать это другим -- подстава: вы же не будете разбираться что и почему у ваших последователей вдруг заглючило. Это будут делать эксперты за очень дополнительные деньги.
Это не совет, это людям подсказываю ещё одно место, на котором завязано округление. Тут все прекрасно понимают, что это костыль. А если и посоветовать - так это то, чтобы те, кто хочет попробовать этот движок - никогда не сделали эту ошибку, ибо потом будут долго жалеть. Это кривое решение, ужасное в исполнении, сложное в доработке, без соблюдения DRY, SOLID, с весьма сложным в освоении кодом, тесно связанными между собой зависимостями, на понимание всего уйдёт у вас уйма времени и сил не говоря уж о доработке. Скорее всего вы плюнете на самостоятельную разработку/доработку и наймёте Webasyst-разработчика, а через несколько подобных итераций перейдёте на более адекватное решение или самописное. Этот движок, пример того, как не стоит вести разработку. Сей пост и всё, что под ним, тому ясное подтверждение. И таких постов не один, постоянно вылазят какие-то глупые проблемы. Качество кода на уровне джунов, которые ещё месяц назад писали Hello Wold. Я, и мои коллеги удивляемся тому, как такой движок мог обрести популярность. И мы поражаемся тем, как сложно даются любые изменения в нём.
Ты не представляешь как сложно было написать плагин дробных товаров)))