Интеграция 1С-Битрикс с Inflow WMS
Inflow WMS — складская система, ориентированная на средний и крупный e-commerce: адресное хранение, управление зонами комплектации, поддержка SSCC-маркировки. Интеграция с 1С-Битрикс здесь сложнее, чем с типичными облачными WMS, — Inflow нередко развёртывается on-premise, имеет конфигурируемый API и требует согласования схемы обмена под конкретную конфигурацию системы.
Архитектура обмена с Inflow WMS
Inflow предоставляет REST API или SOAP-интерфейс в зависимости от версии развёртывания. В большинстве современных инсталляций используется REST с JSON. Аутентификация через API-ключ в заголовке X-API-Key или OAuth2.
Типовые эндпоинты Inflow:
-
GET /api/v1/stock— текущие остатки по складу/зонам -
POST /api/v1/orders— создание заказа на сборку -
GET /api/v1/orders/{id}/status— статус выполнения заказа -
PUT /api/v1/orders/{id}/cancel— отмена заказа на сборку
Принципиальное отличие от более простых WMS: Inflow разделяет понятия заказ на сборку (picking order) и заказ покупателя (customer order). Один заказ покупателя может порождать несколько picking orders — при работе с несколькими зонами хранения или разными перевозчиками.
Синхронизация остатков с учётом адресного хранения
В адресных WMS-системах «остаток» — это не просто число, а распределение по ячейкам. Для интернет-магазина важно только доступное к продаже количество: qty_on_hand - qty_reserved - qty_in_picking.
Запрашиваем через Inflow GET /api/v1/stock?warehouse=main&available_only=true. Получаем агрегированные остатки. Обновляем в Битрикс через \Bitrix\Catalog\ProductTable::update() с инвалидацией кэша.
Частота синхронизации остатков — отдельный предмет обсуждения с клиентом. Высокооборотистые склады (100+ отборов в час) требуют синхронизации каждые 2–5 минут или перехода на события. Для менее нагруженных — 15-минутный интервал через агент Битрикс достаточен.
Передача заказов: маппинг статусов
Самая трудоёмкая часть интеграции — маппинг статусов между системами. В Битрикс статусы заказов настраиваются свободно (справочник b_sale_status). В Inflow статусная машина фиксированная: NEW → ASSIGNED → PICKING → PICKED → PACKING → SHIPPED → DELIVERED.
Нужна таблица маппинга, которая переводит статус Inflow в статус Битрикс:
| Статус Inflow | Статус Битрикс |
|---|---|
NEW |
P (в обработке) |
PICKING |
Q (комплектуется) |
SHIPPED |
D (доставка) |
DELIVERED |
F (выполнен) |
CANCELLED |
Z (отменён) |
Таблицу маппинга храним в настройках модуля интеграции, чтобы её можно было изменить без деплоя.
Обработка ошибок сборки
Inflow может вернуть статус PICKING_ERROR — товар не найден на указанной ячейке, позиция недоступна. В этом случае заказ в Битрикс должен получить специальный статус и задачу для менеджера. Это не стандартная ситуация — обрабатывается кастомной логикой на событии обновления статуса Inflow.
Типичный случай: менеджер оформил заказ на товар, остатки которого не успели обновиться. WMS при попытке резервирования возвращает ошибку. Интеграция должна: уведомить менеджера, снять резерв в Битрикс, предложить альтернативу или отмену. Без обработки этого сценария «тихая» ошибка превращается в невыполненный заказ без уведомления.
Маркировка и штрихкоды
Если склад работает с маркированными товарами (Честный знак, SSCC), интеграция усложняется: при передаче заказа в Inflow нужно указать коды маркировки, а при отгрузке — получить список использованных кодов для передачи в ОФД. Это отдельный контур обмена с участием b_catalog_product_barcode на стороне Битрикс.
Ориентиры по срокам
| Сценарий | Срок |
|---|---|
| Базовая синхронизация остатков и заказов | 4–8 недель |
| Полная интеграция со статусами и обработкой ошибок | 2–3 месяца |
| Интеграция с поддержкой маркировки | 3–5 месяцев |
Стоимость рассчитывается индивидуально — необходим доступ к документации API конкретной версии Inflow WMS и описание бизнес-процессов склада.