Інтеграція 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 і опис бізнес-процесів складу.