Мультипостачальникова логіка замовлень у 1С-Бітрікс

Уявіть: інтернет-магазин продає товари від 10 постачальників. Надходить замовлення з 5 позиціями від 3 різних постачальників. Без автоматизації менеджер вручну копіює рядки замовлення в Excel, формує три листи та відправляє. На це йде 15–20 хвилин на замовлення. При 50 замовленнях на день — більше 10 годин чистої рутини. Помилки неминучі: переплутана адреса, невірний артикул, зайвий товар.

Ми автоматизуємо цей процес під ключ. Налаштовуємо обробники подій, HL-блоки та агенти, щоб кожен постачальник отримував лише свої товари, а статуси відстежувалися в реальному часі. Сертифіковані спеціалісти з 10-річним досвідом реалізували понад 50 проєктів з мультипостачальниковою логікою.

Чому стандартні відвантаження Бітрікс не підходять для дропшипінгу?

Стандартна модель замовлень Бітрікс передбачає, що все замовлення обробляється одним магазином. При дропшипінгу товари фізично знаходяться у різних постачальників, і кожен має отримати повідомлення лише про свої позиції. Якщо використовувати одне замовлення з одним відвантаженням, постачальник побачить усі товари, в тому числі чужі, що порушує логістику та конфіденційність.

Як розбити замовлення за постачальниками?

Існує три підходи до розбивки. Перший — єдине замовлення з окремими сповіщеннями: замовлення залишається цілим, обробник OnSaleOrderSaved відправляє кожному постачальнику лист лише з його товарами. Це просто, але немає роздільного відстеження статусів відвантаження. Другий — єдине замовлення з кількома відвантаженнями: для кожного постачальника створюється об'єкт Shipment. Це нативний механізм Бітрікс, що дає повний контроль над відвантаженнями та роздільні статуси. Третій — розбивка на дочірні замовлення: батьківське замовлення та кілька дочірніх за кількістю постачальників. Це дає повну незалежність статусів, але складніше в реалізації та підтримці.

Для більшості проєктів ми рекомендуємо другий варіант: рішення з кількома відвантаженнями в 2 рази швидше в розробці, ніж з дочірніми замовленнями, і забезпечує рівний баланс функціональності та витрат. Нижче — зведення підходів:

Як ми реалізуємо мультипостачальникову логіку?

При збереженні замовлення визначаємо постачальників і створюємо відвантаження. Функція getSupplierByProductId() читає властивість SUPPLIER_ID з b_iblock_element_property.

AddEventHandler('sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $isNew = $event->getParameter('IS_NEW'); if (!$isNew) return; $basket = $order->getBasket(); $supplierItems = []; foreach ($basket->getOrderableItems() as $item) { $supplierId = getSupplierByProductId($item->getProductId()); if ($supplierId) { $supplierItems[$supplierId][] = $item; } } $shipmentCollection = $order->getShipmentCollection(); foreach ($supplierItems as $supplierId => $items) { $shipment = $shipmentCollection->createItem(); $shipment->setField('DELIVERY_ID', getSupplierDeliveryId($supplierId)); $shipment->setField('CUSTOM_PRICE_DELIVERY', 'N'); $shipmentItemCollection = $shipment->getShipmentItemCollection(); foreach ($items as $basketItem) { $shipmentItem = $shipmentItemCollection->createItem($basketItem); $shipmentItem->setQuantity($basketItem->getQuantity()); } } $order->save(); }); 

Докладніше про подію OnSaleOrderSaved — в документації.

Сповіщення постачальникам

Кожен постачальник отримує лист або повідомлення лише зі своїми товарами. Відправка через \Bitrix\Main\Mail\Event::send() з кастомним шаблоном:

foreach ($supplierItems as $supplierId => $items) { $supplierEmail = getUserEmail($supplierId); \Bitrix\Main\Mail\Event::send([ 'EVENT_NAME' => 'SUPPLIER_ORDER_NOTIFY', 'LID' => SITE_ID, 'C_FIELDS' => [ 'SUPPLIER_EMAIL' => $supplierEmail, 'ORDER_ID' => $order->getId(), 'ORDER_ITEMS' => formatItemsForEmail($items), 'BUYER_ADDRESS' => getOrderDeliveryAddress($order), ], ]); } 

Шаблон SUPPLIER_ORDER_NOTIFY створюється в «Поштові події» адміністративної частини. Передача даних через REST API постачальника прискорює обробку в 3 рази порівняно з email — особливо при 50+ замовленнях на день.

Відстеження статусів за постачальниками

HL-блок SupplierOrderStatus фіксує статус кожної частини замовлення:

• UF_ORDER_ID — ID замовлення Бітрікс
• UF_SUPPLIER_ID — постачальник
• UF_STATUS — new / confirmed / shipped
• UF_TRACKING_NUMBER — трек-номер

Агент перевіряє, чи всі постачальники встановили shipped, та змінює статус основного замовлення:

function checkAllSuppliersShippedAgent(): string { $connection = \Bitrix\Main\Application::getConnection(); $orders = $connection->query(" SELECT UF_ORDER_ID FROM b_hl_supplier_order_status GROUP BY UF_ORDER_ID HAVING COUNT(*) = SUM(CASE WHEN UF_STATUS = 'shipped' THEN 1 ELSE 0 END) AND UF_ORDER_ID IN ( SELECT ID FROM b_sale_order WHERE STATUS_ID NOT IN ('F','C') ) "); while ($row = $orders->fetch()) { $order = \Bitrix\Sale\Order::load($row['UF_ORDER_ID']); if ($order) { $order->setField('STATUS_ID', 'S'); $order->save(); } } return __FUNCTION__ . '();'; } 

Що входить у нашу роботу?

• Аналіз поточної структури каталогу та бізнес-процесів
• Проектування архітектури розбивки (вибір підходу, проектування HL-блоків, обробників, агентів)
• Реалізація коду: обробники подій, агенти, поштові шаблони, інтеграції з REST API постачальників
• Налаштування сповіщень та відстеження статусів через HL-блок
• Тестування на реальних замовленнях, виправлення помилок, оптимізація продуктивності
• Документація з підтримки та експлуатації рішення
• Гарантія безперебійної роботи після деплою

Процес роботи: етапи та результати

Строки та як ми працюємо

Налаштування займає від 2 до 5 днів залежно від складності. Ми працюємо за прозорим процесом: аналітика → проектування → реалізація → тестування → деплой. Гарантуємо безперебійну роботу рішення. Отримайте консультацію — оцінимо ваш проєкт безкоштовно та запропонуємо оптимальний підхід.

Наш досвід у розробці на Бітрікс — понад 10 років, реалізували понад 50 проєктів з мультипостачальниковою логікою. Зв'яжіться з нами — допоможемо автоматизувати дропшипінг.