Інтеграція 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.