При ручній обробці замовлень з 10 постачальниками на день виникає до 15% помилок – втрачені замовлення, дублі, неправильні залишки. З ростом до 50 постачальників процес стає некерованим. Ми спроектували понад 30 схем дропшипінгу на 1С-Бітрікс, що обробляють до 5 000 замовлень на добу без ручного втручання. Ключова складність — синхронізація залишків у реальному часі та коректна маршрутизація при множинних постачальниках. Стандартні модулі не вирішують цих завдань. Неправильно спроектована схема ламається при додаванні другого постачальника або при зростанні обсягу до 100+ замовлень на день. Наш досвід — понад 7 років у Бітрікс-розробці та 30+ проєктів. Ми гарантуємо коректну маршрутизацію та своєчасну синхронізацію залишків. Зв'яжіться з нами для оцінки вашого проєкту — розберемо вашу поточну інфраструктуру та підготуємо рішення.
Чому стандартні модулі не підходять для дропшипінгу?
Готові модулі часто пропонують пряму підстановку постачальника, але не враховують складну маршрутизацію, множинні джерела залишків та автоматизацію відмов. Доводиться проектувати власну модель даних та обробники, адаптовані під будь-якого постачальника.
Модель даних для зв'язку товарів і постачальників
Центральне питання: як пов'язати товар з постачальником та зберігати дані для маршрутизації замовлень.
Інфоблок товарів (b_iblock_element, b_iblock_element_property) зберігає роздрібні дані: назву, опис, зображення, характеристики. Це не чіпаємо.
HL-блок Supplier — довідник постачальників:
b_uts_supplier (автогенерована таблиця HL-блоку)
- ID
- UF_NAME — назва постачальника
- UF_EMAIL — email для повідомлень
- UF_WEBHOOK_URL — URL для POST-повідомлень
- UF_API_KEY — ключ доступу до API постачальника
- UF_FEED_URL — URL фіду залишків (XML/CSV/JSON)
- UF_FEED_FORMAT — формат фіду
- UF_LEAD_TIME — строк обробки замовлення (днів)
- UF_ACTIVE — активність
HL-блок SupplierProduct — зв'язок товарів і постачальників:
b_uts_supplier_product
- ID
- UF_PRODUCT_ID — ID елемента інфоблоку (b_iblock_element.ID)
- UF_SUPPLIER_ID — ID постачальника (b_uts_supplier.ID)
- UF_SUPPLIER_SKU — артикул постачальника
- UF_PURCHASE_PRICE — закупівельна ціна
- UF_CURRENCY — валюта закупівлі
- UF_STORE_ID — склад постачальника (b_catalog_store.ID)
- UF_MIN_QUANTITY — мінімальна партія
- UF_IS_PRIMARY — основний постачальник (якщо кілька)
Склади (b_catalog_store) — по одному на кожного постачальника. Залишки — у b_catalog_store_product. Це стандартний механізм Бітрікс, не винаходимо велосипед.
Як спроектувати маршрутизацію замовлень?
Завдання маршрутизатора: при створенні замовлення розібрати корзину, згрупувати позиції по постачальниках, передати кожному постачальнику його частину. Ускладнення — один товар може мати кілька постачальників. Потрібна логіка вибору: за ціною, за наявністю, за пріоритетом. Реалізується через UF_IS_PRIMARY плюс перевірка поточного залишку.
namespace Local\Dropshipping;
use Bitrix\Highloadblock\HighloadBlockTable;
use Bitrix\Main\Application;
class SupplierResolver
{
/**
* Повертає найкращого постачальника для товару:
* спочатку основного з залишком > 0, інакше будь-якого з залишком
*/
public static function resolve(int $productId, int $quantity): ?array
{
$conn = Application::getConnection();
// Знаходимо постачальників, у яких достатньо залишку
$result = $conn->query("
SELECT sp.UF_SUPPLIER_ID, sp.UF_SUPPLIER_SKU, sp.UF_PURCHASE_PRICE,
sp.UF_IS_PRIMARY, csp.AMOUNT
FROM b_uts_supplier_product sp
JOIN b_catalog_store_product csp
ON csp.PRODUCT_ID = sp.UF_PRODUCT_ID
AND csp.STORE_ID = sp.UF_STORE_ID
WHERE sp.UF_PRODUCT_ID = {$productId}
AND csp.AMOUNT >= {$quantity}
ORDER BY sp.UF_IS_PRIMARY DESC, sp.UF_PURCHASE_PRICE ASC
LIMIT 1
");
return $result->fetch() ?: null;
}
}
Передача замовлення постачальнику
Три канали передачі, в порядку переваги:
- Вебхук (REST API постачальника) — найкращий варіант. Ми POST-имо JSON з даними замовлення на URL постачальника, він відповідає підтвердженням:
private static function sendWebhook(string $url, string $apiKey, array $payload): bool
{
$http = new \Bitrix\Main\Web\HttpClient();
$http->setHeader('Content-Type', 'application/json');
$http->setHeader('Authorization', 'Bearer ' . $apiKey);
$http->setTimeout(10);
$response = $http->post($url, json_encode($payload));
$status = $http->getStatus();
\Bitrix\Main\Diag\Debug::writeToFile(
['url' => $url, 'status' => $status, 'response' => $response],
'Dropshipping webhook',
'/local/logs/dropshipping.log'
);
return $status === 200;
}
-
Email з HTML-таблицею — коли постачальник не має API. Шаблон листа через CEvent::Send, подія DROPSHIPPING_ORDER_NEW. Таблиця позицій, адреса доставки, сума до перерахування.
-
Файловий обмін через FTP/SFTP — для постачальників, що працюють з 1С. Генеруємо XML у форматі CommerceML і кладемо на FTP постачальника. Він забирає за розкладом.
Синхронізація залишків
Залишки застарівають швидко — проблема всієї дропшиппінг-схеми. Три стратегії:
| Стратегія | Опис | Затримка | Вимоги до постачальника |
|---|---|---|---|
| Push від постачальника | Вебхук при зміні залишку | Хвилини | Наявність API з callback |
| Pull за розкладом | Агент кожні N хвилин завантажує фід | 15-30 хв | Надання фіду (XML/CSV/JSON) |
| Резервування | Зменшення залишку при замовленні | Миттєво | Немає |
- Push від постачальника — постачальник сам повідомляє про зміну залишку через вебхук. Реалізуємо ендпоінт з перевіркою API-ключа.
- Pull за розкладом — агент Бітрікс кожні 30 хвилин завантажує фід постачальника та оновлює залишки. Фіди бувають XML (1С-формат), CSV, JSON.
- Резервування — якщо pull неможливий, після створення замовлення одразу зменшуємо залишок на складі постачальника в b_catalog_store_product. Некорректно, але краще ніж нічого.
Розрахунок маржі
Закупівельна ціна зберігається в UF_PURCHASE_PRICE HL-блоку. Роздрібна ціна — в b_catalog_price. Різниця — маржа. Звіт по маржі запитується прямо до бази:
SELECT
be.NAME AS product_name,
cp.PRICE AS retail_price,
sp.UF_PURCHASE_PRICE AS purchase_price,
cp.PRICE - sp.UF_PURCHASE_PRICE AS margin_abs,
ROUND((cp.PRICE - sp.UF_PURCHASE_PRICE)
/ cp.PRICE * 100, 1) AS margin_pct
FROM b_iblock_element be
JOIN b_catalog_price cp ON cp.PRODUCT_ID = be.ID AND cp.CATALOG_GROUP_ID = 1
JOIN b_uts_supplier_product sp ON sp.UF_PRODUCT_ID = be.ID AND sp.UF_IS_PRIMARY = 1
WHERE be.IBLOCK_ID = :catalog_iblock_id
AND be.ACTIVE = 'Y'
ORDER BY margin_pct ASC;
Як обробляються відмови постачальника?
Постачальник може відхилити замовлення (немає в наявності, помилка адреси). Потрібен статусний HL-блок для відстеження:
b_uts_supplier_order
- UF_ORDER_ID — ID замовлення Бітрікс (b_sale_order.ID)
- UF_SUPPLIER_ID — ID постачальника
- UF_STATUS — pending / confirmed / rejected / shipped / delivered
- UF_SUPPLIER_ORDER — номер замовлення у постачальника
- UF_TRACKING — трек-номер відправлення
- UF_REJECT_REASON — причина відмови
- UF_DATE_UPDATE — дата останньої зміни
При статусі rejected запускається агент, який повідомляє менеджера і, якщо є альтернативний постачальник того ж товару, автоматично перенаправляє замовлення.
Покрокове налаштування дропшипінгу
Як впровадити схему за 5 кроків (розгорніть)
- Аудит — аналізуємо поточний каталог, інтеграції, кількість постачальників та обсяг замовлень (в середньому 500-1000 замовлень на день).
- Проектування моделі — створюємо HL-блоки Supplier та SupplierProduct, налаштовуємо склади для кожного постачальника.
- Розробка маршрутизатора — пишемо логіку вибору постачальника за пріоритетом та залишками.
- Інтеграція каналів передачі — вебхуки, email або FTP залежно від можливостей постачальника.
- Тестування та запуск — навантажувальне тестування на 1000+ замовлень, моніторинг протягом тижня.
Терміни реалізації
| Конфігурація | Склад | Термін |
|---|---|---|
| Один постачальник, email-повідомлення | HL-блоки + обробник + шаблон | 1–2 тижні |
| Кілька постачальників, вебхуки | + маршрутизатор + API синхронізації | 3–4 тижні |
| Повна схема з фідами, кабінетом та аналітикою | + pull фідів + ЛК постачальника + звіт по маржі | 6–8 тижнів |
Що входить у результат
- Модель даних (HL-блоки Supplier та SupplierProduct) з полями під ваших постачальників.
- Маршрутизатор замовлень з підтримкою N постачальників та логікою вибору за пріоритетом.
- Інтеграція з постачальниками: вебхуки, email або FTP — під кожного індивідуально.
- Синхронізація залишків у режимі, наближеному до реального часу.
- Обробка відмов з автоматичним перенаправленням на альтернативного постачальника.
- Документація з архітектури та інструкція з експлуатації.
- Навчання менеджерів (2 години) та техпідтримка протягом 30 днів.
Зв'яжіться з нами для безкоштовної оцінки вашого завдання. Ми проаналізуємо кількість постачальників, обсяги замовлень та існуючу інфраструктуру. Замовте розробку схеми дропшипінгу під ключ — отримайте надійне рішення, яке не зламається при зростанні бізнесу.