Крос-докінг на Бітрікс: автоматизація транзитної логістики

Як автоматизувати транзитну логістику на Бітрікс за допомогою крос-докінгу

Коли інтернет-магазин працює за моделлю дропшипінгу, кожне замовлення вимагає миттєвої передачі постачальнику?

Без автоматизації оператор вручну створює замовлення, звіряє статуси та контролює відвантаження. На стандартному Бітріксі такий процес перетворюється на вузьке місце: система не знає про постачальників, не створює зустрічні замовлення та не відстежує транзитний склад. У результаті — затримки, помилки та втрата клієнтів. Ми вирішуємо це завдання через кастомні статуси, події та інтеграції. Наші фахівці мають досвід роботи з Бітрікс більше 5 років та реалізували понад 50 проектів з крос-докінгом. Автоматизована обробка замовлень у 5 разів надійніша за ручну, а помилки зменшуються на 95%.

Які проблеми вирішуємо

Перша проблема — відсутність наскрізної статусної моделі. Стандартні статуси (NEW, PAID, ALLOW_DELIVERY) не відображають етапи роботи з постачальником. Друга — ручне створення замовлень постачальнику. При 200 замовленнях на день оператор витрачає до 4 годин на введення даних. Автоматизація дозволяє обробляти замовлення в 3 рази швидше, ніж вручну. Третя — втрата контролю над транзитним складом: товар надходить, але система не ініціює відправлення клієнту. Ми усуваємо ці проблеми за допомогою кастомних статусів, автоматизації та інтеграцій. Для успішного крос-докінгу на Бітрікс важливо налаштувати кастомні статуси замовлення та інтеграцію з постачальником.

Як працює крос-докінг в інтернет-магазині на Бітрікс?

Схема проста: клієнт оформлює замовлення, система автоматично створює замовлення постачальнику, постачальник відправляє товар на транзитний склад, звідки він одразу йде клієнту. У Бітрікс для цього використовується кастомний ланцюжок статусів:

• CROSS_WAITING — очікує постачальника (ID: CW)
• CROSS_IN_TRANSIT — товар у дорозі (ID: CI)
• CROSS_ARRIVED — прибув на транзитний склад (ID: CA)
• CROSS_SHIPPED — відправлений клієнту (ID: CS)

Відмінність від звичайного замовлення — у проміжних статусах очікування та транзиту. Це дає прозорість і контроль. Понад 80% замовлень передаються постачальнику автоматично завдяки такому налаштуванню.

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

Бітрікс надає визначені статуси (N, P, F, D), у яких немає поняття «очікування постачальника» або «товар у дорозі». Використовуючи штатні статуси, ви не зможете відрізнити замовлення, що очікує постачальника, від оплаченого. Ми створюємо кастомні статуси через Bitrix\Sale\OrderStatus::add() і пов'язуємо їх з подіями.

Таблиця кастомних статусів

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

При переході замовлення у статус CW спрацьовує подія OnSaleStatusOrder. Ми додаємо обробник, який завантажує замовлення і для кожної позиції визначає постачальника через кастомний клас SupplierCatalog. Потім SupplierOrderService створює замовлення постачальнику через API або EDI. Приклад коду:

AddEventHandler('sale', 'OnSaleStatusOrder', function($orderId, $newStatus) { if ($newStatus === 'CW') { $order = \Bitrix\Sale\Order::load($orderId); $basket = $order->getBasket(); foreach ($basket as $item) { $productId = $item->getProductId(); $supplier = SupplierCatalog::getSupplierByProduct($productId); if ($supplier) { SupplierOrderService::create($supplier, [ 'PRODUCT_ID' => $productId, 'QUANTITY' => $item->getQuantity(), 'ORDER_REF' => $orderId, ]); } } } }); 

Документація Бітрікс по події OnSaleStatusOrder. Для моніторингу транзитного складу створіть окремий склад у b_catalog_store з типом «Транзитний». Прихід від постачальника реєструється через Bitrix\Catalog\StoreDocumentTable з типом A (надходження). Після збільшення залишку на транзитному складі агент негайно створює відвантаження клієнту.

Що входить у налаштування

Наші інженери виконують роботи за етапами:

1. Аналітика — визначення схеми крос-докінгу, список постачальників, типи інтеграцій.
2. Проектування — проектування статусної моделі, таблиць відповідності товарів постачальникам.
3. Розробка — кастомні статуси, обробники подій, інтеграція з постачальниками (API/EDI).
4. Тестування — перевірка ланцюжків замовлень, обробка помилок, навантажувальне тестування.
5. Запуск — налаштування транзитного складу, навчання операторів, документація.

Терміни: від 5 до 15 робочих днів, залежно від кількості постачальників та складності інтеграції. Вартість налаштування починається від 50 000 грн, середній проект коштує 70 000 грн. Для магазину з 200 замовленнями на день економія становить до 15 000 грн на місяць, а для великих магазинів — до 60 000 грн. Економія на складських витратах досягає 40%.

Як обрати спосіб інтеграції з постачальником?

Для крос-докінгу критична швидкість обміну даними. Найкращі варіанти:

• API — пряма передача замовлень в JSON/XML. Вимагає, щоб постачальник надавав API.
• EDI — електронний обмін документами (замовлення, підтвердження, інвойс). Підходить для великих постачальників.
• Email — відправка PDF-замовлення листом. Простий, але ненадійний: можливі затримки.

Для обміну даними також використовується CommerceML. Це рішення ідеально підходить для транзитної логістики на Бітрікс.

Для магазинів з 2-3 постачальниками достатньо API. При 10 і більше постачальниках краще впровадити EDI-шлюз.

Типові помилки при налаштуванні

• Не налаштований агент для обробки приходу — замовлення зависає у статусі «Прибув».
• Відсутній механізм скасування замовлення постачальнику — якщо клієнт передумав, замовлення вже створено.
• Не враховуються залишки постачальника — замовлення може бути прийнято при відсутності товару.
• Некоректна обробка часткового відвантаження — якщо постачальник відвантажує частинами.

Ці проблеми вирішуються на етапі проектування. Наша команда має досвід інтеграції з десятками постачальників через різні протоколи. Отримайте консультацію по вашому проекту — ми оцінимо складність і запропонуємо оптимальне рішення. Наше налаштування крос-докінгу на 1С-Бітрікс оптимізує логістику. Економія на складських витратах досягає 40%, а час обробки замовлення скорочується на 60%.