Уявіть: магазин приймає замовлення, постачальник відвантажує напряму покупцеві. Логіка проста, але на стандартному Бітрікс немає вбудованої маршрутизації за постачальниками, синхронізації залишків у реальному часі та розподілу виплат. Без кастомної розробки кожне замовлення потребує ручної обробки — менеджер перевіряє наявність, узгоджує з постачальником, вносить дані. При 200 замовленнях на день це 4 години рутини, помилки та затримки. Ми вирішуємо цю проблему: наша компанія має понад 10 років досвіду в розробці на 1С-Бітрікс та виконала 50+ проєктів з дропшиппінгу — від дрібних інтернет-магазинів до федеральних маркетплейсів. Наприклад, для мережі магазинів електроніки впровадили систему з 15 постачальниками, яка обробляє 2000 замовлень на день. Результат: скорочення ручної праці на 70% (замовлення обробляються в 5 разів швидше, ніж раніше) та виключення помилок відвантаження. Наші інженери — сертифіковані спеціалісти 1С-Бітрікс, що гарантують прозорий процес впровадження.
Проблеми, які вирішує дропшиппінг на Бітрікс
Основний біль — ручна обробка замовлень. Без автоматизації менеджер витрачає до 5 хвилин на одне замовлення: перевірити залишки у постачальника, узгодити ціну, передати дані. При 500 замовленнях на день це понад 40 годин на тиждень. Друга проблема — розбіжність залишків. Постачальники оновлюють дані нерівномірно: хтось раз на годину, хтось раз на добу. В результаті магазин продає товар, якого немає на складі. Це призводить до скасувань замовлень і втрати довіри. Третя — розподіл виплат. Якщо постачальник вимагає оплату після відвантаження, а ви приймаєте гроші одразу, потрібна прозора система розрахунків. Ми вирішуємо всі три завдання через кастомну розробку: створюємо єдину систему управління постачальниками, синхронізацію залишків у реальному часі та гнучку маршрутизацію замовлень.
Як працює дропшиппінг на Бітрікс?
Мінімальна дропшиппінг-система тримається на трьох елементах:
- Прив'язка постачальників до товарів через HL-блок.
- Маршрутизація замовлень — при створенні замовлення визначаємо, яким постачальникам передавати позиції.
- Синхронізація залишків — постачальник передає актуальні дані через 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:
| Поле | Тип | Опис |
|---|---|---|
UF_PRODUCT_ID |
integer | ID товару |
UF_SUPPLIER_ID |
integer | ID постачальника |
UF_SUPPLIER_SKU |
string | Артикул постачальника |
UF_SUPPLIER_PRICE |
float | Закупівельна ціна |
UF_STORE_ID |
integer | Склад постачальника |
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__ . '();';
}
Завдяки такій схемі наші клієнти економлять до 150 000 грн на місяць на ручній обробці, а середня вигода за рік перевищує 1,2 млн грн. Для невеликого магазину економія може становити 30 000–50 000 грн на місяць. За даними 1С-Бітрікс, CommerceML — стандарт обміну даними між системою управління підприємством та інтернет-магазином. Якщо постачальники використовують CommerceML, ми інтегруємо обмін за цим протоколом — він стандартизує передачу залишків і цін. Для невеликих постачальників підходить вивантаження в CSV з наступним імпортом.
Як ми впроваджуємо дропшиппінг: покроковий план
- Аудит каталогу та постачальників. Визначаємо структуру товарів, формати даних постачальників (XML, JSON, CSV). Розраховуємо обсяг замовлень і необхідну швидкість синхронізації.
- Проєктування архітектури. Вибираємо HL-блоки для прив'язок, проєктуємо обробники подій, схему складів. Узгоджуємо формати повідомлень (email або вебхуки).
- Розробка модуля дропшиппінгу. Створюємо HL-блок
SupplierProduct, обробникOnSaleOrderSaved, інтеграцію синхронізації залишків (агент або вебхук). - Тестування та налагодження. Перевіряємо всі сценарії: створення замовлення, часткове відвантаження, повернення, розбіжність залишків. Використовуємо тестових постачальників.
- Запуск та моніторинг. Вмикаємо в бойовому режимі, відстежуємо логи перших 100 замовлень. Налаштовуємо сповіщення про помилки.
Що входить у налаштування дропшиппінгу
- Розробка модуля дропшиппінгу (HL-блоки, обробники, маршрутизація).
- Реалізація обробника
OnSaleOrderSavedз маршрутизацією. - Налаштування повідомлень: email або вебхуки (REST, JSON).
- Інтеграція складського обліку: створення складів для кожного постачальника, синхронізація залишків.
- Налаштування особистого кабінету постачальника: постачальник бачить свій кошик постачальника, статуси та залишки.
- Навчання співробітників роботі з системою та підтримка після запуску.
- Документація з адміністрування та типових помилок.
Строки реалізації
| Конфігурація | Склад | Строк |
|---|---|---|
| Базова (1 постачальник, email) | HL-блок + обробник + шаблон листа | 3–5 днів |
| Стандартна (кілька постачальників, вебхуки) | + особистий кабінет постачальника + API | 2–3 тижні |
| Повна (синхронізація в реальному часі, аналітика) | + фід залишків + звіти + розподіл виплат | 1–2 місяці |
Вартість розраховується індивідуально під ваш проєкт. Ми пропонуємо налаштування дропшиппінгу під ключ: від аналізу каталогу до запуску та підтримки. Запишіться на безкоштовний аудит вашого проєкту — ми проаналізуємо структуру ваших постачальників і запропонуємо оптимальне рішення. Отримайте комерційну пропозицію з точними строками. Досвід, сертифікати та прозорий процес — основа нашої роботи.