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

Представьте: магазин принимает заказы, поставщик отгружает напрямую покупателю. Логика простая, но на стандартном Битрикс нет встроенной маршрутизации по поставщикам, синхронизации остатков в реальном времени и разделения выплат. Без кастомной разработки каждый заказ требует ручной обработки — менеджер проверяет наличие, согласовывает с поставщиком, вносит данные. При 200 заказах в день это 4 часа рутины, ошибки и задержки. Мы решаем эту проблему: за 10 лет настроили дропшиппинг для 50+ проектов — от мелких интернет-магазинов до федеральных маркетплейсов. Например, для сети магазинов электроники внедрили систему с 15 поставщиками, обрабатывающую 2000 заказов в день. Результат: сокращение ручного труда на 70% и исключение ошибок отгрузки. Наши инженеры — сертифицированные специалисты 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__ . '();'; }