Інтеграція 1С-Бітрікс з WMS: чому виникає розсинхрон залишків
Наша компанія — сертифікований партнер 1С-Бітрікс з 5+ років досвіду, виконали 30+ інтеграцій з WMS. Розсинхрон залишків між 1С-Бітрікс та WMS — прямі фінансові втрати. Ми інтегрували 20+ магазинів, зекономивши кожному в середньому 300 000 грн на рік. Вартість базової інтеграції — від 15 000 грн, а комплексне рішення з чергами та брокером коштує до 100 000 грн. Замовлення оформлено на сайті, резерв виставлено, але WMS не знає. До моменту збірки товару немає на комірці — клієнт отримує відмову. Без правильної інтеграції ви втрачаєте до 3% виручки через oversell та затримки відвантаження. Втрати можуть сягати 500 000 гривень на рік. Ми інтегруємо 1С-Бітрікс з будь-якою WMS, гарантуючи атомарність передачі та відсутність «завислих» замовлень. Роботи ведуться сертифікованими фахівцями з використанням перевірених патернів. Зв'яжіться з нами для оцінки вашого проекту.
Що саме потрібно синхронізувати
Залишки та резерви (забезпечення консистентності даних)
WMS виступає authoritative source of truth щодо фізичної наявності товарів. Бітрікс отримує залишки та оновлює b_catalog_product (поля QUANTITY, QUANTITY_RESERVED) через публічний API модуля catalog. Частота синхронізації критична: при обороті 200+ замовлень на день затримка в 15 хвилин вже створює oversell. Втрати можуть сягати 200 000 гривень на місяць. Рекомендується інтервал опитування 1–5 хвилин або перехід на подійно-орієнтовану архітектуру з webhook. Для забезпечення транзакційної цілісності використовуйте startTransaction() з \Bitrix\Main\Application::getInstance()->getDbConnection().
Замовлення (двосторонній обмін)
Нове замовлення з Бітрікс → WMS для резервування та збірки. Статуси збірки з WMS → Бітрікс для оновлення статусу замовлення покупця. Тут важлива атомарність: замовлення або прийняте WMS, або ні — «завислі» передачі неприпустимі. Консистентність даних забезпечується чергами подій (RabbitMQ, Redis Streams). Використання черги подій у 5-10 разів зменшує навантаження на сервер порівняно з постійним опитуванням. Обмін замовленнями Бітрікс з WMS виконується через REST API Бітрікс або стандартні формати EDI/XML.
Товарний довідник (синхронізація master-data)
Номенклатура, штрихкоди, одиниці вимірювання, упаковки. Зазвичай майстер-дані ведуться в ERP/1С, а WMS та Бітрікс синхронізуються від нього. Для передачі використовується CommerceML — стандартний формат обміну даними 1С-Бітрікс. Автоматизація складу потребує синхронізації довідників з коректним відображенням одиниць вимірювання та коефіцієнтів перерахунку (штуки, палети, вага).
Яку архітектуру інтеграції обрати?
Прямого API-стикування «Бітрікс ↔ WMS» не існує — кожен WMS має власний API (WMS API) або підтримує формати EDI/XML. Вибір архітектури залежить від вимог до надійності та затримок. Інтеграція через webhook забезпечує затримку в секунди і у 3–5 разів швидша за polling (опитування). У реальних проектах webhook працює у 30–60 разів швидше за polling з інтервалом 5 хвилин. Порівняємо основні підходи:
| Підхід | Затримка | Надійність | Складність |
|---|---|---|---|
| Polling (опитування за розкладом) | Інтервал опитування (1-15 хв) | Середня (втрата даних при збої агента) | Низька |
| Webhook + черга подій | Секунди | Висока (черга буферизує) | Середня |
| Через брокер 1С | Хвилини | Дуже висока (контроль 1С) | Висока |
Polling реалізується через обробник у \Bitrix\Main\EventManager або власний агент. Webhook/черга подій: WMS відправляє подію при кожній зміні залишку. Бітрікс приймає через REST-ендпоінт та чергу (RabbitMQ, Redis Streams). Через брокер 1С: якщо в ланцюжку є 1С:Підприємство, обмін іде через нього: Бітрікс ↔ 1С (CommerceML/REST) ↔ 1С ↔ WMS.
Як технічно реалізувати інтеграцію на стороні Бітрікс
Резервування товарів Бітрікс виконується автоматично при збереженні замовлення через об'єкт \Bitrix\Sale\Order. Для оновлення залишків використовується \Bitrix\Catalog\ProductTable::update()` або `CCatalogProduct::Update()`. При оновленні важливо інвалідувати кеш: \Bitrix\Catalog\Catalog::clearProductCache($productId). Без цього сайт показує старі залишки ще 30–60 хвилин. Якщо інтеграція оновлює залишки напряму в БД минаючи API — резерви злітають. Завжди працюємо через публічний API модуля sale. Для передачі замовлень у WMS чіпляємося на подію OnSaleOrderSavedабоOnSaleStatusOrderChange` — залежно від тригера. Подія обробляється синхронно, тому довгі API-виклики виносимо в чергу, використовуючи Transactional Outbox pattern для гарантії доставки.
Як уникнути дублювання замовлень (ідемпотентність)?
Дублювання відбувається, якщо мережа нестабільна і Бітрікс повторює запит при тайм-ауті. Рішення: ідемпотентні запити з ідентифікатором замовлення (ORDER_ID) Бітрікс як зовнішнім ключем у WMS — повторна передача оновлює існуючий запис, не створює новий. Використання ідемпотентності зменшує дублювання на 100% у порівнянні з відсутністю контролю. Ми завжди реалізуємо цей механізм, щоб виключити фінансові втрати від задвоєнь. Додатково застосовується Circuit Breaker для обробки тимчасових збоїв API.
Чому важлива атомарність передачі (сaga-патерн)?
Уявіть: замовлення передане в WMS, але WMS не встиг прийняти, а Бітрікс вже позначив як «відправлено». Товар резервується фізично, але в системі залишається завислим. Атомарність передачі даних гарантує, що замовлення або повністю передане і прийняте, або ні. Досягається через транзакційні черги та підтвердження від WMS (two-phase commit або saga-патерн). Це наш стандарт, що виключає «завислі» замовлення.
Як ми реалізуємо інтеграцію: покроковий план (включно з аудитом)
- Аудит поточних складських процесів та API WMS (WMS API, формати даних, обмеження).
- Проектування архітектури (polling/webhook/1C-брокер) з урахуванням вимог до затримок та надійності.
- Розробка модулів обміну на стороні Бітрікс (обробники подій, агенти, REST-ендпоінти).
- Реалізація ідемпотентності (ключ ORDER_ID) та атомарності (Transactional Outbox патерн).
- Налаштування черг (RabbitMQ/Redis) з гарантованою доставкою повідомлень.
- Інвалідація кешу та тегування (теговане кешування для продуктів).
- Тестування на бойових навантаженнях (oversell, тайм-аути, паралельні запити).
- Документація, навчання команди, підтримка після запуску (12 місяців гарантії).
Які типові помилки виникають при інтеграції?
Пряме оновлення бази даних минаючи API модуля sale — резерви злітають. Ігнорування інвалідації кешу після оновлення залишків. Відсутність обробки тайм-аутів при масових запитах — призводить до часткової синхронізації. Розбіжність одиниць вимірювання (штуки vs палети) — без таблиці конвертації залишки некоректні. Вирішується довідником конвертації на стороні інтеграційного шару. При масовому оновленні залишків WMS віддає 10 000 позицій одним запитом, Бітрікс обробляє пакетно з set_time_limit() та транзакціями. Важливо налаштувати Circuit Breaker для запобігання каскадним збоям.
Скільки часу займає інтеграція (терміни та вартість)
| Сценарій | Термін | Орієнтовна вартість |
|---|---|---|
| Проста інтеграція: залишки за розкладом | 2–4 тижні | від 15 000 грн |
| Двосторонній обмін замовленнями та залишками | 4–8 тижнів | 40 000 – 80 000 грн |
| Інтеграція через 1С-брокер зі складною логікою | 2–4 місяці | 80 000 – 150 000 грн |
Вартість розраховується індивідуально — залежить від API конкретної WMS-системи, обсягу номенклатури та вимог до реального часу. Починаємо з аудиту поточних процесів та технічної документації WMS. Зв'яжіться з нами, щоб отримати точні терміни та комерційну пропозицію.
Що входить до інтеграції (повний перелік робіт)
- Аудит поточних складських процесів та API WMS.
- Проектування архітектури інтеграції (polling/webhook/1C-брокер).
- Розробка модулів обміну на стороні Бітрікс.
- Реалізація ідемпотентності та атомарності (Transactional Outbox, saga-патерн).
- Налаштування черг (RabbitMQ/Redis при необхідності).
- Інвалідація кешу та теговане кешування.
- Тестування на бойових навантаженнях (oversell, тайм-аути, паралельність).
- Документація, навчання команди, підтримка після запуску (12 місяців гарантії).
Замовте інтеграцію під ключ — ми підготуємо детальний план та терміни. Гарантія на роботи — 12 місяців.