Розробка кастомного оформлення замовлення 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 CDEK/Boxberry
• При наявності в кошику товарів категорії «Великогабаритний» — автоматично прибирати «Кур'єрську доставку» зі списку доступних способів

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

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

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

1. При введенні адреси — запит до DaData API для стандартизації адреси та отримання координат
2. Координати передаються в API CDEK /v2/calculator/tariff з параметрами ваги з кошика
3. Результат відображається користувачу до вибору доставки — він бачить ціну ще на етапі введення адреси

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

Кейс: checkout з розділенням замовлення за постачальниками

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

Рішення: розроблено кастомний checkout, який при додаванні товарів аналізує PROPERTY_VENDOR_ID у кожної позиції кошика і групує їх за постачальником. Для кожної групи — окремий блок вибору доставки. Підсумкове замовлення в Бітрікс створюється одне, але з кількома відвантаженнями (b_sale_shipment), кожне прив'язане до свого постачальника та служби доставки.

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

Що входить у розробку

• Аудит бізнес-логіки поточного оформлення замовлення та вимог
• Розробка серверного API (контролери, валідація, створення замовлення)
• Розробка фронтенд-компонента (React/Vue або vanilla JS)
• Інтеграція з платіжними системами (YooKassa, Сбербанк, Тінькофф)
• Інтеграція з вибраними службами доставки
• Тестування сценаріїв: анонімний користувач, авторизований, юрособа, фізособа, різні комбінації доставки/оплати

Строки

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