такая реализация? https://clip2net.com/s/4a8xXV6
что мы в конце doFinalAction дописываем свой обработчик
upd: Да там конечно там надо будет проверить все так как doFinalAction так же дергается при изменении заказа и в админке, но в целом это очень удобный способ дописать свою логику на изменения цены
здесь был неформатированный поток сознания... а без него - нет, я не стал бы так делать. вообще, от слова совсем. при причине того, что этот заказ потом еще в админке открывать и что-то с ним делать 1. потенциально я вижу тут зацикливание. Плюс нарушение логики (doFinalAction заказа может вызвать любая из подсущностей) 2. при вашем подходе нарушается условие целостности заказа: PRICE = BASKET_PRICE + DELIVERY_PRICE + DISCOUNT_VALUE + TAX сходу это вылезет в админке при просмотре заказа. где еще - просто не возьмусь искать (в голову приходит 1С). 3. ни один менеджер потом не сумеет понять - что это было (никакой информации о том, откуда такая разница в стоимости) 4. техподдержка сразу скажет, что заказа битый и ничего с ним делать не будет (при возникновении проблем) 5. любые действия в админке с заказом (галки применения скидок, манипуляции с товаром, добавление купонов) сносят ваши расчеты - сумма будет перезаписана варианты решения: если лень что-либо делать - выставлять поле DISCOUNT_VALUE заказа. Исправит все, кроме п.3 и обмена с 1С (не знаю, как там это сейчас обрабатывается) более сложное решение - добавлять купон на скидку при вводе телефонного номера. решает все, кроме существующих проблем вычисления фиксированной скидки на корзину.
@VirtualWhiskers Был поток и нет потока, сделал как всегда через купоны, а хотелось как то без создания скидки, купона. к слову, 1. да я по этому сюда и написал так как не знаю всех тонкостей 2.3.4.5 Всегда же дергается событие doFinalAction и мое событие срабатывало бы всегда. Конечно я бы вел записи о скидки отдельно в табличке или в свойствах заказа, и я бы всегда на них ссылался и мои расчеты не сносились бы, так как всегда бы повторялись.
Обсуждают сегодня