Автоматизація дропшиппінгу на 1С-Бітрікс: кейси, строки впровадження

Уявіть: магазин приймає замовлення, постачальник відвантажує напряму покупцеві. Логіка проста, але на стандартному Бітрікс немає вбудованої маршрутизації за постачальниками, синхронізації залишків у реальному часі та розподілу виплат. Без кастомної розробки кожне замовлення потребує ручної обробки — менеджер перевіряє наявність, узгоджує з постачальником, вносить дані. При 200 замовленнях на день це 4 години рутини, помилки та затримки. Ми вирішуємо цю проблему: наша компанія має понад 10 років досвіду в розробці на 1С-Бітрікс та виконала 50+ проєктів з дропшиппінгу — від дрібних інтернет-магазинів до федеральних маркетплейсів. Наприклад, для мережі магазинів електроніки впровадили систему з 15 постачальниками, яка обробляє 2000 замовлень на день. Результат: скорочення ручної праці на 70% (замовлення обробляються в 5 разів швидше, ніж раніше) та виключення помилок відвантаження. Наші інженери — сертифіковані спеціалісти 1С-Бітрікс, що гарантують прозорий процес впровадження.

Проблеми, які вирішує дропшиппінг на Бітрікс

Основний біль — ручна обробка замовлень. Без автоматизації менеджер витрачає до 5 хвилин на одне замовлення: перевірити залишки у постачальника, узгодити ціну, передати дані. При 500 замовленнях на день це понад 40 годин на тиждень. Друга проблема — розбіжність залишків. Постачальники оновлюють дані нерівномірно: хтось раз на годину, хтось раз на добу. В результаті магазин продає товар, якого немає на складі. Це призводить до скасувань замовлень і втрати довіри. Третя — розподіл виплат. Якщо постачальник вимагає оплату після відвантаження, а ви приймаєте гроші одразу, потрібна прозора система розрахунків. Ми вирішуємо всі три завдання через кастомну розробку: створюємо єдину систему управління постачальниками, синхронізацію залишків у реальному часі та гнучку маршрутизацію замовлень.

Як працює дропшиппінг на Бітрікс?

Мінімальна дропшиппінг-система тримається на трьох елементах:

1. Прив'язка постачальників до товарів через HL-блок.
2. Маршрутизація замовлень — при створенні замовлення визначаємо, яким постачальникам передавати позиції.
3. Синхронізація залишків — постачальник передає актуальні дані через API або через файл.

Кожен пункт потребує опрацювання: без правильної архітектури виникають помилки в замовленнях і розбіжності в залишках. Наприклад, якщо не налаштувати валідацію при зміні постачальника, можна відправити замовлення на товар, який вже знятий з виробництва.

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

При створенні замовлення обробник на подію OnSaleOrderSaved розбиває позиції за постачальниками і надсилає повідомлення. Цей підхід використовується в 90% проєктів.

// /local/php_interface/init.php AddEventHandler('sale', 'OnSaleOrderSaved', ['\Local\Dropshipping\OrderRouter', 'route']); 

// /local/lib/Dropshipping/OrderRouter.php namespace Local\Dropshipping; use Bitrix\Main\Application; class OrderRouter { public static function route(\Bitrix\Sale\Order $order): void { $supplierItems = []; foreach ($order->getBasket() as $item) { $productId = (int)$item->getProductId(); $supplierId = self::getSupplierByProduct($productId); if ($supplierId) { $supplierItems[$supplierId][] = [ 'product_id' => $productId, 'name' => $item->getField('NAME'), 'quantity' => $item->getQuantity(), 'price' => $item->getPrice(), 'sku' => self::getSupplierSku($productId, $supplierId), ]; } } foreach ($supplierItems as $supplierId => $items) { self::notifySupplier($order, $supplierId, $items); } } private static function notifySupplier(\Bitrix\Sale\Order $order, int $supplierId, array $items): void { $supplier = self::getSupplierData($supplierId); if (!empty($supplier['WEBHOOK_URL'])) { self::sendWebhook($supplier['WEBHOOK_URL'], $order, $items); } else { self::sendEmail($supplier['EMAIL'], $order, $items); } } } 

Важно: в обробнику потрібно враховувати часткове відвантаження та повернення. Ми додаємо статуси "Чекає постачальника" і "Передано постачальнику", щоб не дублювати повідомлення.

Чому HL-блоки кращі за властивості інфоблоку?

Для прив'язки товарів до постачальників використовуємо HL-блок SupplierProduct:

HL-блок зручніший: підтримує декілька постачальників на один товар, зберігає закупівельні ціни окремо від роздрібних, легко розширюється. Властивості інфоблоку швидко стають некерованими при десятках постачальників. Якщо у вас 50 постачальників і 10 000 товарів, то HL-блок з індексом по UF_PRODUCT_ID забезпечить швидку вибірку, а властивості інфоблоку призведуть до деградації продуктивності.

Як ми вирішуємо проблему синхронізації залишків?

Синхронізація залишків — ключова точка відмови. Якщо залишки не оновлюються вчасно, магазин продає те, чого немає у постачальника. Налаштовуємо два сценарії:

• Пул — агент за розкладом. Кожні 10 хвилин агент запитує залишки і оновлює кількість на складі. Підходить для 80% випадків.
• Пуш — вебхук від постачальника. Постачальник надсилає POST-запит з актуальними залишками. Обробляється в реальному часі, але потребує доопрацювання на стороні постачальника.

Кожен постачальник отримує окремий склад в b_catalog_store. Залишки зберігаються в b_catalog_store_product. Це дозволяє бачити не тільки загальний залишок, але й залишок конкретного постачальника. Типова помилка — плутати склади при синхронізації. Ми налаштовуємо маппінг supplier_id ↔ store_id, щоб дані потрапляли правильно.

// Агент, що запускається кожні 10 хвилин function syncSupplierStocks(): string { $suppliers = getSuppliers(); foreach ($suppliers as $supplierId) { $stocks = fetchSupplierStocks($supplierId); updateStocks($supplierId, $stocks); } return __FUNCTION__ . '();'; }