Почему возникает рассинхрон остатков при интеграции с WMS
Рассинхрон остатков между 1С-Битрикс и WMS — прямые финансовые потери. Заказ оформлен на сайте, резерв выставлен, но WMS не знает. К моменту сборки товара нет на ячейке — клиент получает отказ. Без правильной интеграции вы теряете до 3% выручки из-за oversell и задержек отгрузки. Потери могут достигать $4.5k–6.5k в год. Мы интегрируем 1С-Битрикс с любой WMS, гарантируя атомарность передачи и отсутствие «висящих» заказов. Работы ведутся сертифицированными специалистами с использованием проверенных паттернов. Свяжитесь с нами для оценки вашего проекта.
Что именно нужно синхронизировать
Остатки и резервы
WMS — источник правды по физическому наличию. Битрикс получает остатки и обновляет b_catalog_product (поля QUANTITY, QUANTITY_RESERVED). Частота синхронизации критична: при обороте 200+ заказов в день задержка в 15 минут уже создаёт oversell. Потери могут достигать $1.8k–2.6k в месяц.
Заказы
Новый заказ из Битрикс → WMS для резервирования и сборки. Статусы сборки из WMS → Битрикс для обновления статуса заказа покупателя. Здесь важна атомарность: заказ либо принят WMS, либо нет — «висящие» передачи недопустимы.
Товарный справочник
Номенклатура, штрихкоды, единицы измерения, упаковки. Обычно мастер-данные ведутся в ERP/1С, а WMS и Битрикс синхронизируются от него.
Какую архитектуру интеграции выбрать
Прямого API-стыковки «Битрикс ↔ WMS» не существует — каждый WMS имеет собственный API или поддерживает форматы EDI/XML. Выбор архитектуры зависит от требований к надёжности и задержкам. Webhook с очередью событий в 3–5 раз быстрее polling и обеспечивает задержку в секунды против минут. Сравним основные подходы:
| Подход | Задержка | Надёжность | Сложность |
|---|---|---|---|
| Polling (опрос по расписанию) | Интервал опроса (1-15 мин) | Средняя (потеря данных при сбое агента) | Низкая |
| Webhook + очередь событий | Секунды | Высокая (очередь буферизует) | Средняя |
| Через брокер 1С | Минуты | Очень высокая (контроль 1С) | Высокая |
Polling реализуется через обработчик в \Bitrix\Main\EventManager или собственный агент. Webhook/очередь событий: WMS отправляет событие при каждом изменении остатка. Битрикс принимает через REST-эндпоинт и очередь (RabbitMQ, Redis Streams). Через брокер 1С: если в цепочке есть 1С:Предприятие, обмен идёт через него: Битрикс ↔ 1С (стандартный CommerceML / REST) ↔ 1С ↔ WMS.
Как технически реализовать интеграцию на стороне Битрикс
Остатки обновляются через \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 — в зависимости от триггера. Событие обрабатывается синхронно, поэтому долгие API-вызовы выносим в очередь.
Как избежать дублирования заказов
Дублирование происходит, если сеть нестабильна и Битрикс повторяет запрос при таймауте. Решение: идемпотентные запросы с ORDER_ID Битрикс как внешним ключом в WMS — повторная передача обновляет существующую запись, не создаёт новую. Мы всегда реализуем этот механизм, чтобы исключить финансовые потери от задвоений.
Почему важна атомарность передачи
Представьте: заказ передан в WMS, но WMS не успел принять, а Битрикс уже пометил как «отправлен». Товар резервируется физически, но в системе остаётся висящим. Атомарность гарантирует, что заказ либо полностью передан и принят, либо нет. Достигается через транзакционные очереди и подтверждения от WMS. Это наш стандарт.
Какие типичные ошибки возникают
Прямое обновление базы данных минуя API модуля sale — резервы слетают. Игнорирование инвалидации кэша после обновления остатков. Отсутствие обработки таймаутов при массовых запросах. Расхождение единиц измерения (штуки vs паллеты) — без таблицы конвертации остатки некорректны. Решается справочником конвертации на стороне интеграционного слоя. При массовом обновлении остатков WMS отдаёт 10 000 позиций одним запросом, Битрикс обрабатывает пакетно с set_time_limit() и \Bitrix\Main\Application::getInstance()->getDbConnection()->startTransaction().
Сколько времени занимает интеграция
| Сценарий | Срок |
|---|---|
| Простая интеграция: остатки по расписанию | 2–4 недели |
| Двусторонний обмен заказами и остатками | 4–8 недель |
| Интеграция через 1С-брокер со сложной логикой | 2–4 месяца |
Стоимость рассчитывается индивидуально — зависит от API конкретной WMS-системы, объёма номенклатуры и требований к реальному времени. Начинаем с аудита текущих процессов и технической документации WMS. Свяжитесь с нами, чтобы получить точные сроки и коммерческое предложение.
Что входит в интеграцию
- Аудит текущих складских процессов и API WMS.
- Проектирование архитектуры интеграции (polling/webhook/1C-брокер).
- Разработка модулей обмена на стороне Битрикс.
- Реализация идемпотентности и атомарности.
- Настройка очередей (RabbitMQ/Redis при необходимости).
- Инвалидация кэша и тегированное кэширование.
- Тестирование на боевых нагрузках (oversell, таймауты).
- Документация, обучение команды, поддержка после запуска.
Закажите интеграцию под ключ — мы подготовим детальный план и сроки. Гарантия на работы — 12 месяцев.