Интеграция RetailCRM и МойСклад

RetailCRM отвечает за приём и обработку заказов, а МойСклад — за складской и товарный учёт. Связка этих систем убирает двойной ввод данных и делает остатки в CRM достоверными. Разбираем, как настроить обмен, что синхронизируется автоматически, а где интегратору приходится дописывать логику.

Зачем связывать RetailCRM и МойСклад

RetailCRM и МойСклад закрывают разные участки процесса, но работают с одними и теми же сущностями — товарами, заказами и клиентами. Если системы не связаны, менеджер вручную переносит заказ из CRM в складскую программу, а кладовщик отдельно правит остатки. Это источник ошибок: пересорт, продажи «в минус», расхождение цен.

Связка решает три задачи:

• Единый справочник товаров. Номенклатура ведётся в МойСклад и подтягивается в RetailCRM, чтобы менеджер видел актуальные позиции.
• Достоверные остатки. CRM показывает реальное наличие по складам, а не абстрактное «есть/нет».
• Сквозной заказ. Оформленный в RetailCRM заказ автоматически создаёт отгрузку в МойСклад, а статусы возвращаются обратно.

Способы интеграции: штатный модуль и API

Для связки доступно несколько путей, и выбор зависит от того, насколько нестандартны ваши процессы.

У RetailCRM есть встроенный модуль интеграции с МойСклад в разделе маркетплейса. Он покрывает базовые сценарии: выгрузку каталога, синхронизацию остатков и передачу заказов. Для магазинов с дилерскими ценами, наборами товаров или сложной логикой резервов чаще собирают собственный обмен на REST API — у МойСклад это JSON API 1.2, у RetailCRM — API v5.

Маппинг товаров и справочников

Первый и самый ответственный шаг — сопоставление номенклатуры. Ключ связи — не название (оно меняется), а стабильный идентификатор. В МойСклад это id или внешний код externalCode, в RetailCRM — externalId товара и торгового предложения.

1. Определите, что в МойСклад является товаром, а что — модификацией (variant). RetailCRM работает с торговыми предложениями, поэтому модификации МойСклад маппятся на offer'ы.
2. Сопоставьте единицы измерения, группы товаров и склады.
3. Согласуйте артикулы (article) и штрихкоды — по ним удобно находить дубли.

Синхронизация остатков и цен

Остатки почти всегда живут в МойСклад — там оформляются оприходования, отгрузки и инвентаризации. RetailCRM должна получать эти цифры, чтобы менеджер не обещал клиенту то, чего нет.

• Направление: остатки МойСклад → RetailCRM (одностороннее).
• Гранулярность: по каждому складу отдельно, если у вас несколько точек хранения.
• Резервы: при создании заказа в RetailCRM резерв должен уменьшать доступный остаток, чтобы не продать одну единицу дважды.

С ценами сложнее. У магазина обычно несколько типов цен: розничная, оптовая, дилерская. В МойСклад это priceType, в RetailCRM — разные priceType и группы клиентов. При настройке важно явно указать, какая цена МойСклад в какой тип цены RetailCRM попадает.

Передача заказов и статусов

Заказ рождается в RetailCRM (менеджер оформил звонок, заявку с сайта или из мессенджера) и должен превратиться в документ МойСклад. Здесь связка работает в обе стороны.

Прямой поток — RetailCRM → МойСклад:

• создание заказа покупателя или отгрузки;
• привязка к контрагенту (по телефону/email);
• перенос состава заказа, скидок и способа доставки.

Обратный поток — МойСклад → RetailCRM:

• смена статуса (собран, отгружен, оплачен);
• факт оплаты и создание входящего платежа;
• изменение состава при частичной отгрузке.

Ключевой момент — маппинг статусов. Статусы заказа RetailCRM и статусы документов МойСклад устроены по-разному, поэтому нужна таблица соответствия. Например, статус RetailCRM «Отгружен» инициирует создание отгрузки в МойСклад, а проведённая отгрузка возвращает в CRM финальный статус.

Типичные проблемы и как их избежать

За годы интеграций складывается один и тот же список граблей.

• Дубли товаров и клиентов — из-за отсутствия единого ключа. Решение: сопоставление по артикулу/штрихкоду и телефону до запуска.
• Продажа «в минус» — если остатки обновляются реже, чем поступают заказы. Решение: сократить интервал синхронизации остатков и включить резервирование.
• Расхождение цен — когда типы цен смапплены неверно. Решение: зафиксировать таблицу соответствия priceType.
• Потеря заказов при сбое API — временная недоступность одной из систем. Решение: очередь с повторными попытками и логированием.

Для контроля обмена полезно вести журнал: какое событие, когда, с каким результатом обработано. Это резко ускоряет разбор инцидентов, когда «заказ не долетел». Тему подробнее раскрываем в материалах про обработку ошибок и мониторинг очередей.

Итог

Связка RetailCRM и МойСклад работает надёжно, когда для каждого типа данных назначена мастер-система, номенклатура сопоставлена по стабильным идентификаторам, а статусы заказов и отгрузок описаны единой таблицей соответствия. Штатного модуля достаточно типовому магазину; для дилерских цен, наборов и сложных резервов нужен обмен на REST API с очередью и логированием.

Мы в B2Bsite проектируем такие связки под конкретные процессы магазина: настраиваем маппинг, резервы и проброс статусов, добавляем контроль ошибок и мониторинг. Если RetailCRM и МойСклад у вас работают порознь или дают расхождения — поможем собрать обмен, которому можно доверять.