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