Разработка кастомного оформления заказа 1С-Битрикс

Разработка кастомного оформления заказа 1С-Битрикс

Стандартный компонент bitrix:sale.order.ajax при всей гибкости настроек имеет жёсткие архитектурные ограничения: форма оформления — это серверный рендеринг с AJAX-обновлением отдельных блоков, а не реактивный интерфейс. Добавить сложную условную логику (например, калькулятор доставки в реальном времени или динамическую смену полей в зависимости от типа товара в корзине) без переписывания компонента практически невозможно. Поэтому кастомное оформление заказа — это либо глубокая доработка стандартного компонента, либо разработка нового с нуля поверх API модуля sale.

Архитектура кастомного checkout

Кастомное оформление заказа строится на двух уровнях:

Серверная часть — контроллер, который:

1. Принимает данные формы через AJAX
2. Валидирует их (тип плательщика, обязательные поля из b_sale_order_props_variant)
3. Создаёт заказ через \Bitrix\Sale\Order::create()
4. Рассчитывает доставку через \Bitrix\Sale\Delivery\Services\Manager::getById()
5. Применяет скидки и купоны через \Bitrix\Sale\DiscountCouponsManager
6. Возвращает JSON с результатом или ошибками

Клиентская часть — React/Vue компонент, который управляет состоянием формы, показывает/скрывает поля в зависимости от выборов пользователя, отображает актуальную стоимость доставки без перезагрузки.

Пример создания заказа программно:

$order = \Bitrix\Sale\Order::create('s1', $userId);
$order->setPersonTypeId($personTypeId);

$basket = \Bitrix\Sale\Basket::loadItemsForFUser(
    \Bitrix\Sale\Fuser::getId(), 's1'
);
$order->setBasket($basket);

$propertyCollection = $order->getPropertyCollection();
$propName = $propertyCollection->getItemByOrderPropertyCode('NAME');
$propName->setValue('Иван Иванов');

$shipmentCollection = $order->getShipmentCollection();
$shipment = $shipmentCollection->createItem();
$service = \Bitrix\Sale\Delivery\Services\Manager::getById($deliveryId);
$shipment->setFields([
    'DELIVERY_ID' => $deliveryId,
    'DELIVERY_NAME' => $service['NAME'],
    'CURRENCY' => 'RUB',
]);

$result = $order->save();

Условная логика полей

Кастомное оформление позволяет строить гибкую логику отображения полей. Примеры:

• При выборе «Юридическое лицо» — показывать поля ИНН, КПП, расчётный счёт
• При выборе доставки «Почта России» — скрыть поля адреса и показать список почтоматов через API СДЭК/Boxberry
• При наличии в корзине товаров категории «Крупногабарит» — автоматически убирать «Курьерскую доставку» из списка доступных способов

На сервере такие правила реализуются через обработчики событий модуля sale: OnSaleComponentOrderMakeOrder, OnSaleDeliveryServiceCalculate. На клиенте — через state-машину компонента.

Интеграция с API служб доставки в реальном времени

Стандартный компонент рассчитывает стоимость доставки при загрузке шага доставки. Для кастомного checkout можно реализовать расчёт на лету — при вводе адреса. Пример с DaData + CDEK:

1. При вводе адреса — запрос к DaData API для стандартизации адреса и получения координат
2. Координаты передаются в API СДЭК /v2/calculator/tariff с параметрами веса из корзины
3. Результат отображается пользователю до выбора доставки — он видит цену ещё на этапе ввода адреса

Это требует прокси-контроллера на стороне Битрикс (чтобы не светить API-ключи на клиенте) и корректного кеширования результатов по ключу {postal_code}_{weight_kg}.

Кейс: checkout с разделением заказа по поставщикам

Клиент — маркетплейс, где один заказ может содержать товары от разных поставщиков с разными условиями доставки. Стандартный checkout не поддерживает отгрузки от разных поставщиков в одном заказе.

Решение: разработан кастомный checkout, который при добавлении товаров анализирует PROPERTY_VENDOR_ID у каждой позиции корзины и группирует их по поставщику. Для каждой группы — отдельный блок выбора доставки. Итоговый заказ в Битрикс создаётся один, но с несколькими отгрузками (b_sale_shipment), каждая привязана к своему поставщику и службе доставки.

Сложность: расчёт итоговой суммы с учётом того, что разные поставщики могут иметь разные пороги бесплатной доставки. Реализовано через отдельный сервис расчёта с кешированием в Redis.

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

• Аудит бизнес-логики текущего оформления заказа и требований
• Разработка серверного API (контроллеры, валидация, создание заказа)
• Разработка фронтенд-компонента (React/Vue или vanilla JS)
• Интеграция с платёжными системами (ЮKassa, Сбербанк, Тинькофф)
• Интеграция с выбранными службами доставки
• Тестирование сценариев: анонимный пользователь, авторизованный, юрлицо, физлицо, разные комбинации доставки/оплаты

Сроки

Кастомное оформление заказа — от 10 рабочих дней до 2 месяцев в зависимости от количества типов плательщиков, служб доставки и платёжных систем, наличия нестандартной бизнес-логики. Базовый вариант (один тип плательщика, 2–3 службы доставки, 1–2 платёжные системы) — 2–3 недели.