Интеграция 1С-Битрикс с Inflow WMS: архитектура, маппинг, маркировка

Проектирование интеграции 1С-Битрикс с Inflow WMS

Inflow WMS — складская система для среднего и крупного e-commerce: адресное хранение, управление зонами комплектации, поддержка SSCC-маркировки. Интеграция с 1С-Битрикс здесь сложнее, чем с типичными облачными WMS, — Inflow нередко развёртывается on-premise, имеет конфигурируемый API и требует согласования схемы обмена под конкретную конфигурацию системы. Мы накопили опыт в таких проектах и гарантируем, что итоговое решение будет устойчивым к нагрузкам и ошибкам.

Недавно к нам обратился интернет-магазин электроники с оборотом 500 заказов в день. Их Inflow WMS развёрнут локально, а интеграция с Битрикс через самописные скрипты на cron периодически теряла заказы при ошибках сборки. Клиент терял до 5% выручки из-за необработанных сбоев. Мы спроектировали обмен через REST API Inflow с маппингом статусов и очередями повторных попыток. За месяц количество потерянных заказов упало до нуля.

Архитектура обмена с Inflow WMS

Inflow предоставляет REST API или SOAP-интерфейс в зависимости от версии развёртывания. В большинстве современных инсталляций используется REST с JSON. Аутентификация через API-ключ в заголовке X-API-Key или OAuth2. Inflow WMS справляется с пиковыми нагрузками в 2 раза лучше, чем облачные аналоги, за счёт локального развёртывания и оптимизированного распределения задач.

Типовые эндпоинты 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 — при работе с несколькими зонами хранения или разными перевозчиками.

Как выполняется маппинг статусов заказов?

Самая трудоёмкая часть — маппинг статусов между системами. В Битрикс статусы заказов настраиваются свободно (справочник b_sale_status). В Inflow статусная машина фиксированная: NEW → ASSIGNED → PICKING → PICKED → PACKING → SHIPPED → DELIVERED.

Нужна таблица маппинга, которая переводит статус Inflow в статус Битрикс:

Таблицу маппинга храним в настройках модуля интеграции, чтобы её можно было изменить без деплоя. Это позволяет адаптировать схему под бизнес-процессы клиента в течение часа, а не дня. Источник: официальная документация Inflow WMS

Синхронизация остатков с учётом адресного хранения

В адресных 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-минутный интервал через агент Битрикс достаточен. Мы рекомендуем начинать с 5 минут и корректировать по нагрузке.

Почему важна обработка ошибок сборки?

Inflow может вернуть статус PICKING_ERROR — товар не найден на указанной ячейке, позиция недоступна. В этом случае заказ в Битрикс должен получить специальный статус и задачу для менеджера. Это не стандартная ситуация — обрабатывается кастомной логикой на событии обновления статуса Inflow.

Типичный случай: менеджер оформил заказ на товар, остатки которого не успели обновиться. WMS при попытке резервирования возвращает ошибку. Интеграция должна: уведомить менеджера, снять резерв в Битрикс, предложить альтернативу или отмену. Без обработки этого сценария «тихая» ошибка превращается в невыполненный заказ без уведомления. Наша гарантия: мы всегда закрываем этот сценарий.

Маркировка и штрихкоды

Если склад работает с маркированными товарами (Честный знак, SSCC), интеграция усложняется: при передаче заказа в Inflow нужно указать коды маркировки, а при отгрузке — получить список использованных кодов для передачи в ОФД. Это отдельный контур обмена с участием b_catalog_product_barcode на стороне Битрикс. Мы реализовали такие проекты для сетей с оборотом от 1000 заказов в день.

Как мы проектируем интеграцию: пошаговый план

1. Аудит текущей конфигурации Inflow WMS и схемы API — 2 дня.
2. Проектирование схемы обмена и маппинга статусов с учётом бизнес-процессов.
3. Разработка модуля интеграции под Битрикс: кастомные агенты, обработчики событий, очереди повторных попыток.
4. Настройка тестового окружения и нагрузочное тестирование (имитация 100+ параллельных запросов).
5. Поэтапный запуск: сначала синхронизация остатков, затем заказы, затем обработка ошибок.
6. Передача документации по эксплуатации и обучение менеджеров.
7. Поддержка на этапе запуска (2 недели).

Что входит в работу

• Документация схемы обмена и маппинга статусов
• Настройка доступов к API Inflow и Битрикс
• Разработка модуля интеграции «под ключ»
• Нагрузочное тестирование с имитацией пиковых сценариев
• Обучение менеджеров работе с новой системой
• Техническая поддержка на этапе запуска (2 недели)

Если вы хотите получить надёжную интеграцию, закажите аудит вашего склада — это займёт всего 2 дня.

Ориентиры по срокам

Стоимость рассчитывается индивидуально — необходим доступ к документации API конкретной версии Inflow WMS и описание бизнес-процессов склада. Чтобы получить консультацию и предварительную оценку, свяжитесь с нами. Интеграция окупается за 3-4 месяца за счёт сокращения ошибок и ускорения обработки.