Чем больше систем в контуре, тем важнее договориться, кто чем владеет. МойСклад чаще всего играет роль товароучётного хаба между сайтом, CRM и маркетплейсами, а каждая пара систем требует своего направления обмена и мастер-системы. Разберём связки с точки зрения JSON API 1.2.
МойСклад как центр контура
Когда систем больше двух, обмен «каждый с каждым» превращается в паутину: N систем дают N×(N−1) направлений. Практичнее топология «звезда», где МойСклад — центральный узел товароучёта, а остальные системы обмениваются через него.
- Сайт — витрина и приём заказов;
- CRM — работа с клиентами и сделками;
- Склад/МойСклад — остатки, документы, цены;
- Маркетплейсы — Ozon, Wildberries, Яндекс Маркет как каналы продаж.
Мастер-система для каждого поля
Главное архитектурное решение — определить владельца каждого типа данных. Без этого две системы будут перезаписывать друг друга. Базовое распределение для связки сайт—CRM—склад—маркетплейс:
| Данные | Мастер-система | Направление |
|---|---|---|
| Каталог, цены | МойСклад / PIM | В сайт и маркетплейсы |
| Остатки | МойСклад | Во все каналы |
| Заказы | Сайт / маркетплейс | В МойСклад и CRM |
| Клиенты, сделки | CRM | Из заказов |
| Статусы отгрузки | МойСклад | В сайт и CRM |
Такое разделение убирает гонки: остатки идут только из МойСклад, заказы — только в МойСклад, и ни одно поле не имеет двух хозяев одновременно.
Типовые пары интеграций
Каждую связку удобно проектировать как отдельную пару со своим контрактом обмена. Разбивка «страница на каждую пару» оправдана: у пар разные сущности и частота обмена.
- Сайт ⇄ МойСклад — каталог и остатки из МойСклад, заказы (
customerorder) с сайта; - CRM ⇄ МойСклад — контрагенты (
counterparty) и сделки, документы отгрузки и оплаты; - Маркетплейс ⇄ МойСклад — остатки в канал, заказы FBS обратно в учёт;
- Сайт ⇄ CRM — лиды и заказы напрямую, если нужен быстрый контакт с менеджером.
Для маркетплейсов критична частота обновления остатков: продажа одного и того же товара в нескольких каналах без быстрой синхронизации ведёт к оверселлингу и штрафам площадки.
Механика обмена через JSON API
Технически связки опираются на одни и те же инструменты JSON API 1.2:
- Вебхуки (
POST /entity/webhook) — события об изменении заказов, товаров, остатков; - Отчёт остатков (
/report/stock/allи/report/stock/bystore) — актуальные количества по складам; - Массовые операции — пакетные POST для синхронизации каталога;
- Фильтры
updated— инкрементальная выборка изменений.
Единые остатки без оверселлинга
Остатки — самое чувствительное поле в мультиканальной связке. Один физический склад питает несколько витрин, поэтому продажа в любом канале должна быстро уменьшать доступное количество во всех остальных.
Рабочая схема:
- МойСклад — единственный источник остатков;
- резервирование под заказ через
customerorderуменьшает доступный остаток; - вебхук на изменение остатка триггерит рассылку во все каналы;
- для маркетплейсов остаток можно отдавать с буфером под задержку синхронизации.
Так исключается ситуация, когда товар продан на Ozon и на сайте одновременно, а на складе он был в единственном экземпляре.
Наблюдаемость связок
Чем больше пар, тем важнее видеть, что происходит в обмене. Минимальный набор для эксплуатации мультисистемного контура:
- единый журнал с меткой пары (сайт↔МС, МС↔Ozon и т. д.);
- трассировка заказа сквозь все системы по внешнему коду;
- алерты на расхождение остатков и рост ошибок;
- периодическая полная сверка каталога и остатков.
На 1С-Битрикс роль хаба-посредника или витрины часто берёт на себя сам портал: он агрегирует данные МойСклад и раздаёт их в каналы, оставаясь точкой контроля и диагностики.
Итог
Связки сайт—CRM—склад—маркетплейс проектируются как набор пар с чётко назначенной мастер-системой для каждого поля. МойСклад выступает товароучётным хабом: остатки и каталог идут из него, заказы — в него, а вебхуки и отчёты остатков держат каналы в актуальном состоянии в рамках общего лимита API.
Мы в B2Bsite собираем такие мультисистемные контуры на 1С-Битрикс: единая мастер-модель, координация коннекторов, защита от оверселлинга и прозрачная диагностика. Поможем связать ваши системы в один управляемый поток данных.
Частые вопросы
Почему МойСклад удобно делать центром контура?
Он ведёт единую мастер-модель товаров и остатков, к которой подключаются сайт, CRM и маркетплейсы. Топология звезды проще паутины связей каждый с каждым.
Как избежать взаимных перезаписей между системами?
Назначить мастер-систему для каждого типа данных: остатки и каталог ведёт МойСклад, заказы — сайт и маркетплейсы, клиентов — CRM. Ни одно поле не должно иметь двух хозяев.
Почему связки лучше проектировать попарно?
У каждой пары свои сущности, направление и частота обмена. Отдельный контракт на пару сайт↔МойСклад или МойСклад↔маркетплейс проще поддерживать и отлаживать.
Что грозит при медленной синхронизации остатков?
Оверселлинг: один и тот же товар продаётся в нескольких каналах, хотя на складе он в единственном экземпляре. Для маркетплейсов это ещё и штрафы за отмену.
Как несколько коннекторов делят лимит API?
Лимит 45 запросов за 3 секунды общий на аккаунт. При нескольких активных коннекторах их нужно координировать через общую очередь, иначе они мешают друг другу.
Как отдавать остатки на маркетплейс безопасно?
Единственным источником остатков делают МойСклад, а в канал можно отдавать значение с буфером под задержку синхронизации, чтобы снизить риск оверселлинга.
Какими инструментами API строятся связки?
Вебхуками на изменения, отчётами остатков /report/stock/all и bystore, пакетными POST для каталога и фильтрами updated для инкремента. Набор общий для всех пар.
Как диагностировать проблемы в мультисистемном контуре?
Вести единый журнал с меткой пары, трассировать заказ по внешнему коду через все системы и настроить алерты на расхождение остатков и рост ошибок.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.