Кастомизация оформления заказа (sale.order.ajax)

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

Этот материал — практическое how-to по кастомизации компонента sale.order.ajax в 1С-Битрикс: как устроен компонент, почему нельзя трогать ядро, как копировать шаблон, добавлять свойства заказа, ограничивать доставку и оплату и менять логику через события так, чтобы кастомизация пережила обновления. Если форма заказа сложная или тормозит, точечно её приводит в порядок аудит и оптимизация.

Зачем вообще трогать оформление заказа

Стандартная форма оформления заказа в 1С-Битрикс универсальна, а значит, никому не подходит идеально. Универсальность означает много полей и шагов «на все случаи», тогда как конкретному магазину нужен свой короткий и понятный путь. Каждое лишнее действие на кассе стоит части конверсии, поэтому форму подгоняют под реальный сценарий покупки.

Типовые причины кастомизации:

• Убрать лишнее. Скрыть поля и шаги, которые не нужны вашему сценарию, чтобы упростить оформление.
• Добавить нужное. Собрать специфические данные: комментарий к доставке, ИНН для юрлиц, желаемое время.
• Ограничить варианты. Показывать только релевантные способы доставки и оплаты под регион и тип клиента.
• Встроить логику. Подарки, скидки, проверки, интеграции с CRM и уведомлениями на этапе оформления.

Как устроен sale.order.ajax

Чтобы кастомизировать компонент грамотно, надо понимать его устройство. sale.order.ajax — это комплексный компонент, который отвечает за всю страницу оформления и работает через AJAX: при любом изменении (смена доставки, региона, количества) он пересчитывает заказ и обновляет форму без перезагрузки страницы.

Внутри он оперирует несколькими сущностями:

• Корзина (basket). Состав заказа, количества, цены с учётом скидок.
• Свойства заказа. Данные покупателя и заказа, привязанные к типу плательщика.
• Доставка (delivery). Доступные службы доставки с расчётом стоимости и ограничениями.
• Оплата (paysystem). Системы оплаты, доступные для выбранных условий.

Логика (component.php) собирает эти данные и отдаёт их в шаблон (template.php), а фронтенд обеспечивает AJAX-пересчёт. Понимание этого разделения — ключ к правильной кастомизации: верстку и вывод меняют в шаблоне, справочные данные — в настройках, а бизнес-логику — в событиях, не трогая саму логику компонента в ядре.

Главное правило: не править ядро

Самая дорогая ошибка — открыть файлы компонента в /bitrix/components/bitrix/sale.order.ajax/ и начать их править. Всё в этой папке принадлежит ядру и перезаписывается при обновлении. После ближайшего апдейта все правки бесследно исчезнут, а магазин может сломаться. Это правило не имеет исключений.

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

Копирование шаблона компонента

Кастомизация вывода начинается с копирования шаблона компонента из ядра в своё пространство. Порядок такой:

1. Скопируйте шаблон. Возьмите штатный шаблон компонента и перенесите его в свой шаблон сайта или в /local/templates/, не трогая оригинал в /bitrix/.
2. Правьте копию. Меняйте вывод, разметку и порядок блоков только в своей копии шаблона.
3. Держите структуру. Сохраняйте ожидаемые компонентом имена полей и точки AJAX, чтобы не сломать пересчёт.
4. Выносите стили и скрипты. CSS и JS формы держите в ассетах шаблона, а не вперемешку с логикой.

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

Свойства заказа вместо хардкода

Частая ошибка — добавлять новые поля прямо в шаблон формы как обычный HTML. Такое поле не сохранится в заказ, не уйдёт в 1С и не будет доступно в админке. Правильный путь — заводить дополнительные данные как свойства заказа в настройках торгового каталога.

• Заведите свойство. В настройках типов заказа и свойств создайте поле нужного типа (строка, список, флажок).
• Привяжите к плательщику. Свойство можно показывать только для нужного типа плательщика (физлицо / юрлицо).
• Настройте обязательность. Отметьте, обязательно ли поле, чтобы валидация работала штатно.
• Выведите в шаблоне. Разместите свойство в нужном месте формы, используя данные, которые компонент уже отдаёт.

Тогда значение автоматически сохраняется в заказ, отображается в админке и передаётся в 1С при обмене CommerceML. Это принципиально важно для сценариев, где данные заказа должны попасть в учётную систему, — например, реквизиты юрлица для B2B. Отдельные свойства покупателя корректно доедут до 1С только если заведены как свойства заказа, а не как поля в вёрстке.

Ограничения доставки и оплаты

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

В 1С-Битрикс для этого есть штатный механизм ограничений:

• По местоположению. Служба доставки доступна только в своих регионах и городах.
• По сумме и весу. Бесплатная доставка от суммы, курьер до определённого веса.
• По типу плательщика. Безналичная оплата — для юрлиц, наличные при получении — для физлиц.
• Пользовательские ограничения. Нестандартные правила реализуют как свои классы ограничений.

Держать эту логику на сервере критично: то, что спрятано только на фронтенде через JavaScript, легко обходится и не защищает от некорректных заказов. Серверные ограничения гарантируют, что недоступный способ не пройдёт, даже если клиент попробует его подставить. Для сложных интеграционных сценариев расчёт доставки иногда выносят во внешние сервисы через REST и вебхуки с учётом безопасности.

События заказа и обработчики

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

• OnSaleOrderBeforeSaved. Перед сохранением заказа — валидация, корректировка данных, проверки.
• OnSaleOrderSaved. После сохранения — отправка в CRM, уведомления, интеграции.
• События корзины и оплаты. Реакция на изменение состава, применение скидок, смену статуса оплаты.
• Размещение кода. Обработчики регистрируют в отдельном модуле или в init.php, а не в шаблоне.

Так бизнес-логика живёт вне ядра и вне верстки: она переживает обновления, легко тестируется и не смешивается с выводом. Это тот же подход к работе с данными и сущностями, что и в D7 ORM. Если логики много, её оформляют как собственный модуль на Битрикс с понятной структурой, а не как россыпь правок в init.php.

Одностраничное оформление и UX

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

• Одностраничное. Все шаги на одном экране с AJAX-пересчётом — обычно снижает число отвалов для розницы.
• Многошаговое. Разбивка на шаги оправдана для сложных B2B-заказов с юрлицами, договорами и согласованиями.
• Минимум обязательных полей. Спрашивайте только то, что реально нужно для выполнения заказа.
• Понятные ошибки. Валидация подсказывает, что именно исправить, а не показывает общий сбой.

Выбор делают по аудитории и сложности заказа, а не по моде, и обязательно проверяют на реальной конверсии. Красивая одностраничная форма, которая не собирает нужные для B2B данные, хуже, чем чуть более длинная, но рабочая.

Производительность формы заказа

Форма заказа пересчитывается при каждом изменении, поэтому её производительность заметна пользователю напрямую. Если каждый AJAX-пересчёт тянет тяжёлые запросы и грузит много скриптов, оформление ощутимо тормозит именно там, где клиент уже готов платить.

• Кэшируйте справочные данные. Списки регионов, служб доставки и прочие справочники не должны запрашиваться заново на каждый пересчёт.
• Минимизируйте запросы. Уберите лишние обращения к базе в шаблоне и обработчиках на горячем пути.
• Лёгкий фронтенд. Не подключайте на страницу заказа тяжёлые библиотеки, которые там не нужны.
• Профилируйте пересчёт. Замерьте, что именно тормозит при смене доставки или количества, и оптимизируйте это.

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

Тестирование и деплой кастомизации

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

1. Тестовый стенд. Все правки обкатывают на копии данных, а не на боевом магазине.
2. Проверка сценариев. Тестируют оформление для разных типов плательщиков, регионов, способов доставки и оплаты.
3. Проверка обмена. Убеждаются, что свойства заказа корректно уходят в 1С.
4. Контролируемый деплой. Выкладка через понятный процесс с бэкапом и возможностью отката.

Управляемая выкладка правок формы заказа — часть общей культуры CI/CD и деплоя на Битрикс. Кастомизацию, живущую в /local/ и в событиях, легко переносить между стендом и продом без ручного копирования файлов.

Частые ошибки кастомизации

• Правка файлов в /bitrix/. Всё исчезает при обновлении ядра.
• Поля хардкодят в шаблоне. Данные не сохраняются в заказ и не уходят в 1С.
• Логика в шаблоне вместо событий. Бизнес-правила смешаны с версткой и не переживают апдейт.
• Доставку прячут через JavaScript. Ограничение легко обходится, проходят некорректные заказы.
• Нет кэша справочников. Каждый AJAX-пересчёт грузит базу, форма тормозит.
• Перегруженная форма. Лишние обязательные поля роняют конверсию на кассе.
• Правки сразу на проде. Ошибка в оформлении стоит потерянных заказов.
• Свойства не доходят до 1С. Данные заказа собраны мимо штатных свойств.

Чек-лист доработки оформления

1. Шаблон скопирован. Кастомизация вывода — в своём шаблоне или /local/, ядро не тронуто.
2. Поля — свойства заказа. Доп. данные заведены как свойства, привязаны к плательщику, уходят в 1С.
3. Ограничения на сервере. Доставка и оплата ограничены штатным механизмом, а не JavaScript.
4. Логика в событиях. Вмешательство в заказ — через обработчики D7 в модуле или init.php.
5. UX выверен. Одно- или многошаговое оформление выбрано по аудитории, минимум обязательных полей.
6. Форма быстрая. Справочники кэшируются, лишние запросы и скрипты убраны.
7. Обмен проверен. Свойства заказа корректно доходят до 1С.
8. Деплой безопасен. Правки обкатаны на стенде, выложены с бэкапом и откатом.

Вывод

Кастомизация оформления заказа на 1С-Битрикс — это работа с последним и самым важным шагом воронки. Делать её нужно правильно: копировать шаблон в /local/, добавлять данные через свойства заказа, ограничивать доставку и оплату штатным механизмом на сервере и менять логику через события D7. Тогда доработка переживёт обновления, а не рассыплется при первом апдейте.

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