Перейти к содержимому
BXWiki

Оформление заказа - настройка компонента и правка шаблона

Настраиваем форму оформления заказа, добавляем своё поле и разбираемся, почему доставка не выводится.

Решение

Ставим компонент оформления на страницу:

$APPLICATION->IncludeComponent('bitrix:sale.order.ajax', '', [
    'PERSON_TYPE'        => [1, 2],       // типы плательщика: физлицо, компания
    'ALLOW_AUTO_REGISTER' => 'Y',
    'DELIVERY_NO_AJAX'   => 'N',
    'PATH_TO_BASKET'     => '/personal/cart/',   // возврат в корзину из формы
    'PATH_TO_PAYMENT'    => '/personal/order/payment/',
    'DELIVERY_TO_PAYSYSTEM' => 'd2p',     // порядок выбора: доставка, потом оплата
    // шаблон компонента задают третьим аргументом: пустая строка берёт .default
]);

Компонент рисует все шаги сам и обменивается с сервером на каждое изменение формы. Отдельных страниц под шаги создавать не нужно, и попытка разложить их по страницам ломает пересчёт итогов.

Заводим своё свойство заказа:

use Bitrix\Sale\Internals\OrderPropsTable;


OrderPropsTable::add([
    'PERSON_TYPE_ID' => 1,            // свойство принадлежит типу плательщика
    'NAME'           => 'Код домофона',
    'TYPE'           => 'STRING',
    'CODE'           => 'DOOR_CODE',
    'REQUIRED'       => 'N',
    'UTIL'           => 'N',          // служебные свойства в форме не показываются
]);

Свойство привязано к типу плательщика, а не к заказу вообще. Заведённое для физлица поле не появится у компании, и это самая частая причина «поле есть в настройках, но не видно в форме».

Смотрим, какие доставки доступны заказу:

use Bitrix\Sale\Delivery\Services\Manager;


foreach (Manager::getActiveList() as $service) {
    printf("%-6s %-30s ограничений=%d\n",
        $service['ID'], $service['NAME'],
        count(Manager::getRestrictionsList($service['ID'])));
}

Каждая служба проверяется своими ограничениями: сумма, вес, местоположение, группа покупателя. Не прошедшая хотя бы одно из них служба в форму не попадает и никак об этом не сообщает.

Переопределяем шаблон формы:

Окно терминала
# копия в своём шаблоне сайта: обновления продукта её не тронут
cp -r bitrix/components/bitrix/sale.order.ajax/templates/bootstrap_v4 \
      local/templates/main/components/bitrix/sale.order.ajax/my_checkout

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

Значение свойства доезжает до заказа только через штатный механизм свойств. Поле, дописанное прямо в разметку шаблона, отправится вместе с формой, но модуль продаж его не примет: он сохраняет только известные ему свойства своего типа плательщика. Такие поля либо заводят свойствами, либо обрабатывают своим кодом в событии сохранения заказа.

Обязательность поля проверяется на сервере, а не в разметке. Убранный из шаблона блок с обязательным свойством не отменяет проверку: заказ не оформится, а сообщение об ошибке будет некуда вывести. Поэтому лишние поля отключают в настройках свойства, а не прячут стилями.

Типичные проблемы

Своё свойство не появляется в форме.

Оно привязано к другому типу плательщика либо помечено служебным. Форма показывает только свойства своего типа.

Служба доставки активна, но её нет в списке.

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

Заказ не оформляется, ошибок на экране нет.

Не заполнено обязательное свойство, спрятанное в шаблоне. Проверка идёт на сервере, а место для вывода ошибки в разметке потерялось.

После обновления модуля пропали правки формы.

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

Итоги не пересчитываются при смене доставки.

Форма разложена по своим страницам или сломан обмен с сервером. Компонент рассчитан на один шаг с обновлением по частям.

Частые вопросы

Можно ли сделать оформление в один шаг?

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

Как менять состав полей для юрлиц и физлиц?

Через типы плательщика: у каждого свой набор свойств заказа. Один и тот же компонент показывает разные поля в зависимости от выбранного типа.

Почему при смене оплаты меняется список доставок?

Ограничения служб учитывают выбранную оплату и наоборот. Совместимость доставки и оплаты настраивается ограничениями, а не порядком шагов.

Как добавить поле, которого нет среди типов свойств?

Через свойство с типом строки и своей обработкой в обработчике события сохранения заказа. Штатных полей произвольного вида в модуле продаж нет.

Смежное

Первоисточник