"Это не баг, это фича" (С) Советы по эффективному маркетингу.
Версия 17.5.4 "main" и 17.0.32 "sale".
В дефолтном компоненте sale.order.ajax есть . Для тех, кто не открывает левые ссылки при чтении основной статьи: настройка "Когда рассчитывать доставки с внешними системами расчёта". Настройка имеет селект-поле выбора с 3 вариантами выбора:
высокотехнологичных методов d7. Это значит, что обработчик должен быть унаследован от базового класса Bitrix\Sale\Delivery\Services\Base и быть в пространстве имён Sale\Handlers\Delivery. Подробности в . Больше подробностей в классной .
Модуль же ipol.sdek, который на скриншоте у , написан в соответствии сВетхим Заветом старым положением вещей и ядра. Без использования неймспейсов вообще, что можно посмотреть в include.php модуля.
В новом варианте описания обработчиков есть метод isCalculatePriceImmediately():bool, который как раз и используется при отмеченной опции "Учитывать настройки доставки".
Ещё подробности для новой системы:
1) Если рассчитываемая внешними сервисами доставка стоит первой в списке, то в самом начале метод рассчёта (calculateConcrete()) будет вызван трижды: при initDelivery(), для recalculatePayment() и из calculateDeliveries(). Поэтому в дополнительных рекомендациях к у и есть непрозрачно-однозначный намёк на организацию кэширования. Также это повод переместить нерассчитываемые внешне службы, вроде самовывоза и статического рассчёта, в списке в самый верх.
2) Помимо написания непосредственно обработчика доставки можно написать к нему профили и дополнительные услуги. Как пример - СПСР. Комментариев в коде кот наплакал, но они уже есть!
3) Метод проверки совместимости isCompatible() вызывается до calculateConcrete(), что логично. Но если, например, нужно рассчитывать совместимость, исходя из полей ответа внешнего сервиса, то всегда можно вызвать в переопределяемом методе тот, что нужен. В некоторых случаях этим можно даже заменить ограничения служб доставки, связанные с внешними факторами.
Если есть возможность и время, то возможно Вам поможет .
Версия 17.5.4 "main" и 17.0.32 "sale".
В дефолтном компоненте sale.order.ajax есть . Для тех, кто не открывает левые ссылки при чтении основной статьи: настройка "Когда рассчитывать доставки с внешними системами расчёта". Настройка имеет селект-поле выбора с 3 вариантами выбора:
- Не рассчитывать (вариант "угадай сам")
- Учитывать настройки доставки
- Рассчитывать сразу
Модуль же ipol.sdek, который на скриншоте у , написан в соответствии с
В новом варианте описания обработчиков есть метод isCalculatePriceImmediately():bool, который как раз и используется при отмеченной опции "Учитывать настройки доставки".
Ещё подробности для новой системы:
1) Если рассчитываемая внешними сервисами доставка стоит первой в списке, то в самом начале метод рассчёта (calculateConcrete()) будет вызван трижды: при initDelivery(), для recalculatePayment() и из calculateDeliveries(). Поэтому в дополнительных рекомендациях к у и есть непрозрачно-однозначный намёк на организацию кэширования. Также это повод переместить нерассчитываемые внешне службы, вроде самовывоза и статического рассчёта, в списке в самый верх.
2) Помимо написания непосредственно обработчика доставки можно написать к нему профили и дополнительные услуги. Как пример - СПСР. Комментариев в коде кот наплакал, но они уже есть!
3) Метод проверки совместимости isCompatible() вызывается до calculateConcrete(), что логично. Но если, например, нужно рассчитывать совместимость, исходя из полей ответа внешнего сервиса, то всегда можно вызвать в переопределяемом методе тот, что нужен. В некоторых случаях этим можно даже заменить ограничения служб доставки, связанные с внешними факторами.
| Цитата |
|---|
| Алексей написал: На небольших ИМ эти бесполезные лишние запросы не критичны, а при высокой посещаемости, дают существенную нагрузку + выедают лимиты. |
Silence!
I kill you!!!
I kill you!!!
