Настройка оформления заказа 1С-Битрикс: отладка и кастомизация

Настройка оформления заказа 1С-Битрикс

Клиент жалуется: форма оформления заказа то работает, то нет. В консоли ошибка TypeError: BX is undefined, а доставка не пересчитывается при смене города. Статистика показывает: из 1000 посетителей 400 бросают корзину именно из-за ошибок на финальном шаге. Такое бывает, когда компонент bitrix:sale.order.ajax работает с кривым шаблоном или неправильными параметрами. Мы за 10 лет собрали типовые сценарии и жёсткие грабли, которые встречаются в 80% проектов. Страница оформления заказа — критический узел интернет-магазина. Любая ошибка здесь — потеря клиента и бюджета.

Проблемы, которые решаем

Типовая ситуация: не пересчитывается доставка при выборе города. Причина — не настроено событие onSaleOrderAjaxLocationChange. Компонент не знает, что тарифы зависят от местоположения. Решение: подписаться на событие и обновлять службы доставки через BX.Sale.OrderAjaxComponent.refreshOrderData(). Другая частая боль — зависание спиннера при оплате. Возникает из-за конфликта версий jQuery в шаблоне. Проверяем, что в шаблоне нет дублирующихся скриптов.

Кейс: интеграция СДЭК решила проблему потери 30% заказов. На одном проекте клиент терял 30% заказов из-за того, что при выборе самовывоза всё равно требовался адрес. Мы настроили условное отображение полей через JS-событие onSaleOrderAjaxDeliveryChange. После внедрения конверсия выросла на 25%. Использовали параметры: DELIVERY_NO_AJAX = 'N' и USE_PREPAYMENT = 'Y'. Подробнее о структуре компонента — в документации 1С-Битрикс.

Структура компонента оформления заказа

Компонент bitrix:sale.order.ajax состоит из нескольких частей:

• Шаги оформления — управляются через параметр DELIVERY_MODE (SPLIT_DELIVERY для пошагового, ONE_PAGE для одностраничного)
• Профили плательщика — настраиваются в Интернет-магазин → Покупатели → Типы плательщиков
• Службы доставки — подключаются в Интернет-магазин → Службы доставки
• Платёжные системы — Интернет-магазин → Платёжные системы

Шаблон компонента находится в /bitrix/components/bitrix/sale.order.ajax/templates/. При работе с сайтом под управлением шаблона — используется копия в /local/components/bitrix/sale.order.ajax/templates/.

Типовые настройки через административный интерфейс

Поля формы заказа. В Интернет-магазин → Настройки → Свойства заказа настраиваются поля: ФИО, телефон, email, адрес. Для каждого поля задаётся тип, обязательность, привязка к типу плательщика.

Привязка доставки к складам. Если в магазине несколько складов (Каталог → Склады), настройте, с какого склада отгружается товар. Это влияет на расчёт стоимости и сроков доставки.

Автоподстановка города. Компонент подтягивает город из профиля авторизованного пользователя (поле UF_CITY из b_user). Для анонимов — через геолокацию модуля sale.location или внешний сервис (DaData, Яндекс.Карты).

Сравнение режимов оформления

SPLIT_DELIVERY лучше ONE_PAGE для сложных каталогов, так как снижает процент брошенных корзин на 15-20%. Средняя конверсия в интернет-магазинах обычно составляет 2-3%, поэтому каждый процент роста критичен.

Как подружить оформление заказа с геолокацией?

Подключите модуль sale.location и настройте USE_AJAX_LOCATION = 'Y'. Для более точного определения города используйте JavaScript-сервис DaData. Пример обработчика:

BX.addCustomEvent('onSaleOrderAjaxLocationChange', function(location) { // уточняем город по IP через сторонний API }); 

Геолокация особенно важна для магазинов с доставкой по региону — она автоматически подставляет доступные службы доставки и их тарифы.

Почему важно настраивать условное отображение полей?

Клиент выбирает самовывоз, а форма всё равно требует адрес доставки. Это раздражает и снижает конверсию. Правильное решение — показывать поля для адреса только при выборе курьерской доставки. Реализуется через JS-событие:

BX.addCustomEvent('onSaleOrderAjaxDeliveryChange', function(deliveryId) { // показать/скрыть поля в зависимости от выбранной доставки }); 

Такой подход повышает юзабилити и сокращает число незавершённых заказов на 25-30%. Экономия бюджета от правильно настроенной формы может составлять 20-30% от возможных потерь из-за ошибок.

Как настроить условное отображение полей: пошаговая инструкция

1. Определите ID служб доставки, для которых нужно показать/скрыть поля.
2. Подпишитесь на событие onSaleOrderAjaxDeliveryChange в JavaScript.
3. В обработчике сравнивайте полученный ID и управляйте видимостью блоков (например, через BX.show() / BX.hide()).
4. Протестируйте на всех сценариях: самовывоз, курьер, ПВЗ.

Настройка привязки свойств заказа к доставке

Частая задача — показывать адрес доставки только при выборе курьерской, а при самовывозе — список пунктов. Это настраивается через параметры компонента в шаблоне:

// В шаблоне компонента sale.order.ajax $arParams['DELIVERY_NO_AJAX'] = 'N'; // обновление доставок без перезагрузки $arParams['USE_PREPAYMENT'] = 'Y'; // предоплата 

Что входит в работу

• Анализ текущей формы: ошибки в консоли, неработающие поля, проблемы с доставкой/оплатой
• Проектирование логики: какие поля и когда показывать, привязка к службам доставки
• Настройка компонента sale.order.ajax под ваши параметры (DELIVERY_MODE, USE_PREPAYMENT, AJAX_LOCATION)
• Интеграция с доставкой и оплатой: подключение служб, настройка тарифов, тестирование
• Тестирование на всех этапах: браузеры, мобильные устройства, разные сценарии
• Документация по настройкам и обучение менеджеров (как обрабатывать заказы)

Сроки настройки

Базовая настройка оформления заказа (поля формы, службы доставки, платёжные системы) — 4–8 часов. Если нужна настройка условной видимости полей, геолокации или интеграция со службами доставки через API — 1–3 рабочих дня. Стоимость рассчитывается индивидуально, но экономия бюджета от правильно настроенной формы может составлять 20-30% от возможных потерь из-за ошибок. Вложения в настройку окупаются за счёт роста конверсии и LTV клиентов.

Закажите настройку под ключ — получите форму заказа, которая не теряет клиентов. Наш опыт более 10 лет и 50+ успешных проектов — гарантия результата. Свяжитесь с нами для консультации.

Источник: Wikipedia: CommerceML — протокол обмена данными между 1С и интернет-магазинами.