Интеграция 1С-Битрикс с МойСклад (WMS)
Сталкивались с ситуацией, когда после отгрузки в МойСклад остатки в Битрикс застыли, и клиент заказывает товар, которого уже нет? Или модификации товара дублируются при каждой синхронизации? Типичные проблемы интеграции 1С-Битрикс с МойСклад (WMS) — рассинхронизация остатков, потеря модификаций, ошибки частичных отгрузок. Наш опыт: за 6+ лет реализовали более 50 проектов, где каждый раз приходилось решать уникальные задачи маппинга и высоконагруженной синхронизации. Мы используем агенты, вебхуки и кастомные обработчики, чтобы интеграция работала стабильно даже при 1000+ заказов в день. Основной стек: PHP 8.1, Битрикс ORM, REST API МойСклад, MySQL с индексацией по MOYSKLAD_ID. Без правильной архитектуры синхронизация может упасть из-за лимитов API (45 запросов/с на бесплатном тарифе, 100 на платном), что приводит к блокировке на 5 минут. Мы предусматриваем пакетирование запросов и повтор при ошибках.
Проблемы, которые решаем
Синхронизация модификаций. В Битрикс торговые предложения живут в 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 раз медленнее при пиковых нагрузках.
Способы синхронизации: вебхуки vs агенты
| Способ | Задержка | Нагрузка | Применимость |
|---|---|---|---|
| Вебхуки | 1-3 сек | Низкая | Интенсивные отгрузки |
| Агенты | 5-15 мин | Средняя | Большие каталоги |
Вебхуки МойСклад
МойСклад поддерживает вебхуки для событий: CREATE, UPDATE, DELETE по любой сущности. Подписка:
POST /notification/webhook { "entityType": "customerorder", "action": "UPDATE", "url": "https://your-bitrix-site.ru/api/moysklad/webhook/" } На стороне Битрикс создаём контроллер (наследник \Bitrix\Main\Engine\Controller) или простой init.php-обработчик. Важно вернуть HTTP 200 в течение 3 секунд — иначе МойСклад ретраит.
Пошаговая настройка вебхука
- Создать контроллер в Битрикс, обрабатывающий запросы от МойСклад.
- Подписаться на события через
POST /notification/webhook. - В обработчике проверить целостность данных и обновить сущности.
- Настроить логирование и уведомления об ошибках.
Что входит в работу
- Аудит номенклатуры и схемы складов
- Настройка таблицы маппинга
- Разработка сценариев синхронизации (остатки, заказы, вебхуки)
- Тестирование на тестовом и боевом контуре
- Документация для администраторов
- Обучение сотрудников работе с интеграцией
- Поддержка первый месяц после запуска
Ориентиры по срокам
| Сценарий | Срок |
|---|---|
| Односторонняя синхронизация остатков | 1–2 недели |
| Двусторонний обмен заказами и остатками | 3–6 недель |
| Полная синхронизация с вебхуками и частичными отгрузками | 6–10 недель |
Стоимость рассчитывается индивидуально после анализа номенклатуры, схемы складов и бизнес-процессов. Получите консультацию — оценим ваш проект за 1 день. Подробнее о REST API МойСклад.