Разработка решений под МойСклад — обвязка с CRM, маркетплейсами и сайтом

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

Главная задача почти всегда одна: чтобы остатки, заказы и цены не вели в трёх местах руками. Я пишу коннектор под JSON API МойСклад — прослойку с очередью, повторными попытками и мониторингом расхождений, которая держит данные в одном контуре и не разваливается на первой же ошибке сети.

Под задачу бизнеса соединяю МойСклад с тем, что у вас уже есть:

• amoCRM или Bitrix24 — заказы и оплаты идут в сделки, статусы синхронизируются в обе стороны.
• Сайт или интернет-магазин — остатки и цены уезжают на витрину, заказы возвращаются в учёт.
• Маркетплейсы — синхронизация остатков и заказов, чтобы не продать то, чего нет на складе.
• 1С — обмен номенклатурой, документами и взаиморасчётами без двойного ввода.

Первый источник расхождений — сопоставление по названию. Готовые модули ищут товар по наименованию, поэтому лишний пробел или правка буквы порождают дубль позиции, и остаток разъезжается. Я связываю справочники по коду или артикулу, а таблицу соответствий храню в базе коннектора, чтобы сопоставление переживало переименования и смену поставщика.

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

Третий — лимиты и сбои. У JSON API МойСклад есть ограничение по частоте запросов, и при массовой выгрузке модуль упирается в него, теряя часть данных молча. В коннекторе стоит очередь с повторными попытками и выдержкой, идемпотентный ключ на заказ, чтобы повтор не создавал дубль, и журнал: видно, какая позиция не доехала и почему.

Отдельная история — модификации и характеристики. Размеры и цвета на витрине и в учёте описаны по-разному, и без явного отображения вариантов остатки сходятся только по общей сумме карточки. Это разбираю до кода, вместе с вашим товароведом.

Начинаю со сверки справочников. Выгружаю номенклатуру из МойСклад и из систем, которые к нему привязываются, и ищу расхождения: дубли, позиции без артикула, товары, которых в учёте нет вовсе. Пока справочники не сведены, обмен будет размножать ошибки, поэтому чистку делаю до разработки.

Дальше фиксирую карту полей и правила: откуда берётся цена для каждого канала, что считается свободным остатком с учётом резервов, какому статусу заказа в МойСклад соответствует этап сделки в CRM. Карту согласовываем письменно, она же становится основой документации и передаётся вместе с кодом.

Коннектор поднимаю отдельным сервисом и сначала гоняю на тестовых складах и заказах. Перед переключением прогоняю догоняющую синхронизацию по истории, чтобы данные совпали на старте. Первые две недели после запуска держу ежедневный отчёт расхождений и разбираю каждое, дальше отчёт остаётся как постоянный мониторинг.