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