Интеграция 1С-Битрикс с WMS-системами

Интеграция 1С-Битрикс с WMS-системами

Когда интернет-магазин переходит с ручного учёта на складскую систему управления (WMS), первая же проблема — рассинхрон остатков. Заказ оформлен на сайте, резерв выставлен в 1С-Битрикс, но WMS об этом ещё не знает. К моменту сборки оказывается, что товара нет на нужной ячейке. Интеграция решает именно эту петлю, а не просто «передаёт данные».

Что именно нужно синхронизировать

Стандартный обмен между 1С-Битрикс и WMS охватывает три потока данных:

Остатки и резервы. WMS — источник правды по физическому наличию. Битрикс получает остатки и обновляет b_catalog_product (поля QUANTITY, QUANTITY_RESERVED). Частота синхронизации критична: при обороте 200+ заказов в день задержка в 15 минут уже создаёт oversell.

Заказы. Новый заказ из Битрикс → WMS для резервирования и сборки. Статусы сборки из WMS → Битрикс для обновления статуса заказа покупателя. Здесь важна атомарность: заказ либо принят WMS, либо нет — «висящие» передачи недопустимы.

Товарный справочник. Номенклатура, штрихкоды, единицы измерения, упаковки. Обычно мастер-данные ведутся в ERP/1С, а WMS и Битрикс синхронизируются от него.

Архитектура интеграции

Прямой API-стыковки «Битрикс ↔ WMS» не существует — каждый WMS имеет собственный API или поддерживает форматы EDI/XML. Выбор архитектуры зависит от требований к надёжности и реальному времени:

Polling (опрос по расписанию). Агент в Битрикс каждые N минут запрашивает WMS API, получает изменения, обновляет остатки. Простая схема, но есть лаг = интервал опроса. Реализуется через обработчик в \Bitrix\Main\EventManager или собственный агент.

Webhook/очередь событий. WMS отправляет событие при каждом изменении остатка. Битрикс принимает через REST-эндпоинт (собственный контроллер или Bitrix REST API). Менее задержка, но нужна очередь (RabbitMQ, Redis Streams) чтобы не терять события при перегрузках.

Через брокер 1С. Если в цепочке есть 1С:Предприятие, обмен идёт через него: Битрикс ↔ 1С (стандартный CommerceML/REST) ↔ 1С ↔ WMS (через правила обмена или прямой API 1С WMS). Более тяжёлая схема, но контроль на стороне 1С.

Технические детали реализации на стороне Битрикс

Остатки обновляются через \Bitrix\Catalog\ProductTable::update() или низкоуровневый CCatalogProduct::Update(). При обновлении важно инвалидировать кэш: \Bitrix\Catalog\Catalog::clearProductCache($productId). Без этого сайт будет показывать старые остатки из кэша ещё 30–60 минут.

Резервирование при создании заказа: объект \Bitrix\Sale\Order при сохранении автоматически выставляет резерв через \Bitrix\Sale\Basket::setField('RESERVE_QUANTITY'). Если интеграция обновляет остатки напрямую в БД минуя API — резервы слетают. Всегда работаем через публичный API модуля sale.

Для передачи заказов в WMS вешаемся на событие OnSaleOrderSaved или OnSaleStatusOrderChange — в зависимости от того, по какому триггеру WMS должен начать сборку. Событие обрабатывается синхронно в рамках того же HTTP-запроса, поэтому долгие API-вызовы к WMS лучше выносить в очередь.

Частые проблемы

Дублирование заказов в WMS. Происходит, если сеть нестабильна и Битрикс повторяет запрос при таймауте. Решение: идемпотентные запросы с ORDER_ID Битрикс как внешним ключом в WMS — повторная передача обновляет существующую запись, не создаёт новую.

Расхождение единиц измерения. Битрикс хранит штуки, WMS работает с паллетами и коробками. Если таблица соответствия ед. изм. Битрикс → ед. изм. WMS не заполнена — остатки передаются некорректно. Решается справочником конвертации на стороне интеграционного слоя.

Тайм-аут при массовом обновлении остатков. WMS отдаёт 10 000 позиций одним запросом, Битрикс обрабатывает пакетно с set_time_limit() и \Bitrix\Main\Application::getInstance()->getDbConnection()->startTransaction().

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

Стоимость рассчитывается индивидуально — зависит от API конкретной WMS-системы, объёма номенклатуры и требований к реальному времени. Начинаем с аудита текущих процессов и технической документации WMS.