Інтеграція 1С-Бітрікс з МойСклад (WMS)
Сталкивались з ситуацією, коли після відвантаження в МойСклад залишки в Бітрікс застигли, і клієнт замовляє товар, якого вже немає? Або модифікації товару дублюються при кожній синхронізації? Типові проблеми інтеграції 1С-Бітрікс з МойСклад (WMS) — розсинхронізація залишків, втрата модифікацій, помилки часткових відвантажень. Наш досвід: за 6+ років реалізували понад 50 проектів, де кожного разу доводилося вирішувати унікальні завдання мапінгу та високонавантаженої синхронізації. Ми використовуємо агенти, вебхуки та кастомні обробники, щоб інтеграція працювала стабільно навіть при 1000+ замовлень на день. Основний стек: PHP 8.1, Бітрікс ORM, REST API МойСклад, MySQL з індексацією по MOYSKLAD_ID. Без правильної архітектури синхронізація може впасти через ліміти API (45 запитів/с на безкоштовному тарифі, 100 на платному), що призводить до блокування на 5 хвилин. Ми передбачаємо пакетування запитів та повтор при помилках. Наша інтеграція 1С-Бітрікс з МойСклад в 900 разів швидша за агентів завдяки вебхукам.
Проблеми, які вирішуємо
Синхронізація модифікацій. У Бітрікс торгові пропозиції живуть в b_catalog_sku, у МойСклад — variant. Без таблиці мапінгу кожен імпорт плодить дублі. Ми зберігаємо відповідність у властивості інфоблоку MOYSKLAD_ID або окремій custom_moysklad_mapping, що виключає колізії.
Часткові відвантаження. При частковому відвантаженні статус замовлення в Бітрікс має стати «Частково відвантажено», а не «Виконано». Обробляємо через вебхук МойСклад на подію demand: порівнюємо позиції відвантаження і замовлення, оновлюємо статус. Без цього — втрата обліку.
Ліміти API. 45 запитів/с на безкоштовному тарифі, 100 на платному. При масових оновленнях (1000+ позицій) пакетуємо запити та додаємо затримку usleep(100000). Інакше — блокування на 5 хвилин.
Чому синхронізація модифікацій — найскладніша частина?
У 1С-Бітрікс товарні пропозиції (модифікації) зберігаються в b_catalog_sku та пов'язані з батьківським товаром через IBLOCK_ID торгових пропозицій. У МойСклад це variant з посиланням на product. Проблема виникає при первинному завантаженні: потрібно правильно зв'язати variant.id з ID торгової пропозиції в Бітрікс.
Без таблиці мапінгу кожен запуск синхронізації створює дублі. Зберігаємо відповідність у властивості інфоблоку MOYSKLAD_ID (або окремій таблиці custom_moysklad_mapping).
При оновленні залишків модифікацій: отримати variant.id → знайти в мапінгу offer.ID → оновити b_catalog_product:
\Bitrix\Catalog\ProductTable::update($offerBitrixId, [ 'QUANTITY' => $stockData['stock'], 'QUANTITY_RESERVED' => $stockData['reserve'], ]); \Bitrix\Catalog\Catalog::clearProductCache($offerBitrixId); Як правильно обробляти часткові відвантаження?
Нове замовлення в Бітрікс → customerorder в МойСклад. Мінімальний набір полів:
-
organization— посилання на організацію продавця -
agent— покупець (counterparty), мапиться по email -
positions— позиції з кількістю та посиланнями наvariant/product -
vatEnabled,vatIncluded— мають збігатися з налаштуваннями організації
Часткове відвантаження — сценарій, який ламає прості інтеграції. Замовлення на 5 позицій, відвантажили 3. У МойСклад створюється demand з 3 позиціями, пов'язаний з customerorder. Статус замовлення в Бітрікс — «Частково відвантажено», а не «Виконано». Обробляємо через вебхук МойСклад на подію створення demand — порівнюємо demand.positions з customerorder.positions і вибираємо потрібний статус в Бітрікс.
Які метрики покращує інтеграція?
Інтеграція з МойСклад скорочує час обробки замовлень на 60%, виключає ручне введення залишків і зменшує кількість помилок відвантаження до 2%. Типовий проект знижує ручну працю на 70%. Вебхуки оновлюють дані за 1-3 секунди, тоді як агенти — раз на 15 хвилин, що в 900 разів повільніше при пікових навантаженнях. За даними наших клієнтів, економія коштів на ручній синхронізації сягає до 50 000 грн на рік.
Способи синхронізації: вебхуки vs агенти
| Спосіб | Затримка | Навантаження | Застосовність |
|---|---|---|---|
| Вебхуки | 1-3 сек | Низька | Інтенсивні відвантаження |
| Агенти | 5-15 хв | Середня | Великі каталоги |
Вебхуки МойСклад
МойСклад підтримує вебхуки для подій: CREATE, UPDATE, DELETE по будь-якій сутності. Підписка здійснюється через POST запит на /notification/webhook з вказанням entityType, action та url вашого обробника. Детальніше в офіційній документації: REST API МойСклад.
На стороні Бітрікс створюємо контролер (наслідник \Bitrix\Main\Engine\Controller) або простий init.php-обробник. Важливо повернути HTTP 200 протягом 3 секунд — інакше МойСклад ретраїть.
Покрокове налаштування вебхука
Детальна інструкція
- Створити контролер в Бітрікс, що обробляє запити від МойСклад.
- Підписатися на події через POST на
/notification/webhook. - В обробнику перевірити цілісність даних та оновити сутності.
- Налаштувати логування та сповіщення про помилки.
Що входить в роботу
- Аудит номенклатури та схеми складів
- Налаштування таблиці мапінгу
- Розробка сценаріїв синхронізації (залишки, замовлення, вебхуки)
- Тестування на тестовому та бойовому контурі
- Документація для адміністраторів
- Навчання співробітників роботі з інтеграцією
- Підтримка перший місяць після запуску
Орієнтири за термінами
| Сценарій | Термін |
|---|---|
| Одностороння синхронізація залишків | 1–2 тижні |
| Двосторонній обмін замовленнями та залишками | 3–6 тижнів |
| Повна синхронізація з вебхуками та частковими відвантаженнями | 6–10 тижнів |
Вартість розраховується індивідуально після аналізу номенклатури, схеми складів та бізнес-процесів. Ми — сертифіковані партнери 1С-Бітрікс та МойСклад, надаємо гарантію на всі роботи — 12 місяців. Отримайте консультацію — оцінимо ваш проект за 1 день.
Нижче наведено відповіді на найпоширеніші запитання наших клієнтів щодо інтеграції 1С-Бітрікс з МойСклад.







