Кроссдокинг на Битрикс: автоматизация транзитной логистики
Когда интернет-магазин работает по модели дропшиппинга, каждый заказ требует мгновенной передачи поставщику?
Без автоматизации оператор вручную создаёт заказы, сверяет статусы и контролирует отгрузки. На стандартном Битриксе такой процесс превращается в узкое место: система не знает о поставщиках, не создаёт встречные заказы и не отслеживает транзитный склад. В результате — задержки, ошибки и потеря клиентов. Мы решаем эту задачу через кастомные статусы, события и интеграции. Наши специалисты имеют опыт работы с Битрикс более 5 лет и реализовали свыше 50 проектов с кроссдокингом.
Какие проблемы решаем
Первая проблема — отсутствие сквозной статусной модели. Стандартные статусы (NEW, PAID, ALLOW_DELIVERY) не отражают этапы работы с поставщиком. Вторая — ручное создание заказов поставщику. При 200 заказах в день оператор тратит до 4 часов на ввод данных. Третья — потеря контроля над транзитным складом: товар приходит, но система не инициирует отправку клиенту. Мы устраняем эти проблемы с помощью кастомных статусов, автоматизации и интеграций.
Как работает кроссдокинг в интернет-магазине на Битрикс?
Схема проста: клиент оформляет заказ, система автоматически создаёт заказ поставщику, поставщик отправляет товар на транзитный склад, откуда он сразу уходит клиенту. В Битрикс для этого используется кастомная цепочка статусов:
-
CROSS_WAITING— ожидает поставщика (ID: CW) -
CROSS_IN_TRANSIT— товар в пути (ID: CI) -
CROSS_ARRIVED— прибыл на транзитный склад (ID: CA) -
CROSS_SHIPPED— отправлен клиенту (ID: CS)
Отличие от обычного заказа — в промежуточных статусах ожидания и транзита. Это даёт прозрачность и контроль.
Почему стандартные статусы Битрикс не подходят?
Битрикс предоставляет предопределённые статусы (N, P, F, D), в которых нет понятия «ожидание поставщика» или «товар в пути». Используя штатные статусы, вы не сможете отличить заказ, ожидающий поставщика, от оплаченного. Мы создаём кастомные статусы через \Bitrix\Sale\OrderStatus::add() и связываем их с событиями.
Таблица кастомных статусов
| Статус | ID | Описание | Используется в кроссдокинге |
|---|---|---|---|
| NEW | N | Новый заказ | Нет |
| CROSS_WAITING | CW | Ожидает поставщика | Да |
| CROSS_IN_TRANSIT | CI | Товар в пути от поставщика | Да |
| CROSS_ARRIVED | CA | Прибыл на транзитный склад | Да |
| CROSS_SHIPPED | CS | Отправлен клиенту | Да |
| ALLOW_DELIVERY | D | Разрешена доставка | Нет (заменяется CS) |
Как автоматически создавать заказ поставщику?
При переходе заказа в статус CW срабатывает событие OnSaleStatusOrder. Мы добавляем обработчик, который загружает заказ и для каждой позиции определяет поставщика через кастомный класс SupplierCatalog. Затем SupplierOrderService создаёт заказ поставщику по API или EDI. Пример кода:
AddEventHandler('sale', 'OnSaleStatusOrder', function($orderId, $newStatus) { if ($newStatus === 'CW') { $order = \Bitrix\Sale\Order::load($orderId); $basket = $order->getBasket(); foreach ($basket as $item) { $productId = $item->getProductId(); $supplier = SupplierCatalog::getSupplierByProduct($productId); if ($supplier) { SupplierOrderService::create($supplier, [ 'PRODUCT_ID' => $productId, 'QUANTITY' => $item->getQuantity(), 'ORDER_REF' => $orderId, ]); } } } }); Документация Битрикс по событию OnSaleStatusOrder
Дополнительно: мониторинг транзитного склада
Для транзитного хранения создайте отдельный склад в b_catalog_store с типом «Транзитный». Приход от поставщика регистрируется через \Bitrix\Catalog\StoreDocumentTable с типом A (поступление). После увеличения остатка на транзитном складе агент немедленно создаёт отгрузку клиенту.
Что входит в настройку
Наши инженеры выполняют работы по этапам:
| Этап | Детали |
|---|---|
| Аналитика | Определение схемы кроссдокинга, список поставщиков, типы интеграций |
| Проектирование | Проектирование статусной модели, таблиц соответствия товаров поставщикам |
| Разработка | Кастомные статусы, обработчики событий, интеграция с поставщиками (API/EDI) |
| Тестирование | Проверка цепочек заказов, обработка ошибок, нагрузочное тестирование |
| Запуск | Настройка транзитного склада, обучение операторов, документация |
Сроки: от 5 до 15 рабочих дней, в зависимости от количества поставщиков и сложности интеграции. Стоимость рассчитывается индивидуально.
Как выбрать способ интеграции с поставщиком?
Для кроссдокинга критична скорость обмена данными. Лучшие варианты:
- API — прямая передача заказов в JSON/XML. Требует, чтобы поставщик предоставлял API.
- EDI — электронный обмен документами (заказ, подтверждение, инвойс). Подходит для крупных поставщиков.
- Email — отправка PDF-заказа письмом. Простой, но ненадёжный: возможны задержки.
Для магазинов с 2-3 поставщиками достаточно API. При 10 и более поставщиках лучше внедрить EDI-шлюз.
Типичные ошибки при настройке
- Не настроен агент для обработки прихода — заказ зависает в статусе «Прибыл».
- Отсутствует механизм отмены заказа поставщику — если клиент передумал, заказ уже создан.
- Не учитываются остатки поставщика — заказ может быть принят при отсутствии товара.
- Некорректная обработка частичной отгрузки — если поставщик отгружает частями.
Эти проблемы решаются на этапе проектирования. Наша команда имеет опыт интеграции с десятками поставщиков через разные протоколы. Получите консультацию по вашему проекту — мы оценим сложность и предложим оптимальное решение. Экономия на складских расходах достигает 40%, а время обработки заказа сокращается на 60%.