Округление цен, дробное количество товара Исправлено

6

Добрый день. Уже не раз поднимался вопрос дробного количества товара. Мы занимаемся продажей напольных покрытий (линолеум) - товар отрезной. Торгуем и мечтаем о вводе так необходимого нам функционала. Необходима возможность формирования заказа либо в метрах погонных (например 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 руб. Возможности отключить округление цен нет (галочка не снимается):

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

Заранее спасибо.





14 комментариев

  • +4
    CATAHA666 CATAHA666 28 ноября 2017 16:36 #

    такая же проблема, нужна возможность заказать дробное кол-во и проблема с округлением, перелопачивать двиг самому не выход, так как после обновления очередного слетит всё

  • +2
    CATAHA666 CATAHA666 30 ноября 2017 13:11 #

    для себя временно решил проблему, но после очередного обновления слетит в контроллере правка, нужно будет повторять, вроде нигде больше ничего не правил:

    /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

      Не норм , списание и перемещение со складов не доделали.

      • +1
        CATAHA666 CATAHA666 30 ноября 2017 17:10 #

        Если не секрет, то куда копать? Просто у меня остатки постоянно обновляются извне, с 1с, но всё равно хочется сделать по фен-шую

        Мне-то по сути это не нужно, я про списание со складов, а другим пригодится. Так понимаю ещё поля count нужно у продуктов и sku править, может ещё где в коде есть траблы?

        Не понимаю в чем трудность у разработчиков сделать это, просят люди не первый год.

        и да не double лучше, а decimal в типе поля

      • +2
        Cornet Cornet 31 января 2018 17:54 #

        для того, чтобы правки при обновлениях не слетали, рекомендую эту приблуду - https://github.com/MihanEntalpo/MonkeyPatching

        позволяет учитывать любые правки практически в любых файлах на лету.



      • +2
        Владислав Мозаика Владислав Мозаика 15 декабря 2017 18:19 #

        Кто-то может написать пошаговую инструкцию как ввести дробные? Не все отличаются умом и сообразительностью+ стоит сторонняя разработка и боюсь что все уедет ... или есть кто за деньги делает?

        Нужны дробные(они есть) но по итогу все округляется, можно отключить округление?


      • +2
        DAVIDhaker DAVIDhaker 26 апреля 2021 23:00 #

        Помимо проблемы в /wa-apps/shop/lib/actions/frontend/shopFrontendCartSave.controller.php, решение которой описал пользователь с оккультным ником есть ещё место, куда следует внести правки, чтобы округления не происходило.  

        Следующая правка актуальная для последней, на момент комментария, версии.

        В файле /wa-apps/shop/lib/classes/shopOrder.class.php следущие правки вносим:


        • 0

          Плохой совет. Скидки за штуку, налог, различные экспорты, синхронизации -- вы постоянно будете сталкиваться либо с некорректным расчётом, либо просто что-то перестанет работать.

          А даже если у вас лично, кажется, всё работает, то советовать это другим -- подстава: вы же не будете разбираться что и почему у ваших последователей вдруг заглючило. Это будут делать эксперты за очень дополнительные деньги.

          • +2
            DAVIDhaker DAVIDhaker 27 апреля 2021 03:16 #

            Это не совет, это людям подсказываю ещё одно место, на котором завязано округление. Тут все прекрасно понимают, что это костыль. А если и посоветовать - так это то, чтобы те, кто хочет попробовать этот движок - никогда не сделали эту ошибку, ибо потом будут долго жалеть. Это кривое решение, ужасное в исполнении, сложное в доработке, без соблюдения DRY, SOLID, с весьма сложным в освоении кодом, тесно связанными между собой зависимостями, на понимание всего уйдёт у вас уйма времени и сил не говоря уж о доработке. Скорее всего вы плюнете на самостоятельную разработку/доработку и наймёте Webasyst-разработчика, а через несколько подобных итераций перейдёте на более адекватное решение или самописное. Этот движок, пример того, как не стоит вести разработку. Сей пост и всё, что под ним, тому ясное подтверждение. И таких постов не один, постоянно вылазят какие-то глупые проблемы. Качество кода на уровне джунов, которые ещё месяц назад писали Hello Wold. Я, и мои коллеги удивляемся тому, как такой движок мог обрести популярность. И мы поражаемся тем, как сложно даются любые изменения в нём.

            Добавить комментарий

            Чтобы добавить комментарий, зарегистрируйтесь или войдите