Разработка схемы дропшиппинга с поставщиками 1С-Битрикс

При ручной обработке заказов с 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; } } 

Передача заказа поставщику

Три канала передачи, в порядке предпочтительности:

1. Вебхук (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; } 

2. Email с HTML-таблицей — когда поставщик не имеет API. Шаблон письма через CEvent::Send, событие DROPSHIPPING_ORDER_NEW. Таблица позиций, адрес доставки, сумма к перечислению.

3. Файловый обмен через FTP/SFTP — для поставщиков, работающих с 1С. Генерируем XML в формате CommerceML и кладём на FTP поставщика. Он забирает по расписанию.

Синхронизация остатков

Остатки устаревают быстро — проблема всей дропшиппинг-схемы. Три стратегии:

• 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 запускается агент, который уведомляет менеджера и, если есть альтернативный поставщик того же товара, автоматически перенаправляет заказ.

Пошаговая настройка дропшиппинга

Сроки реализации

Что входит в результат

• Модель данных (HL-блоки Supplier и SupplierProduct) с полями под ваших поставщиков.
• Маршрутизатор заказов с поддержкой N поставщиков и логикой выбора по приоритету.
• Интеграция с поставщиками: вебхуки, email или FTP — под каждого индивидуально.
• Синхронизация остатков в режиме, близком к реальному времени.
• Обработка отказов с автоматическим перенаправлением на альтернативного поставщика.
• Документация по архитектуре и инструкция по эксплуатации.
• Обучение менеджеров (2 часа) и техподдержка в течение 30 дней.

Свяжитесь с нами для бесплатной оценки вашей задачи. Мы проанализируем количество поставщиков, объёмы заказов и существующую инфраструктуру. Закажите разработку схемы дропшиппинга под ключ — получите надёжное решение, которое не сломается при росте бизнеса.