МойСклад и интернет-магазин: каталог, остатки, заказы

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

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

Как выбрать источник каталога и остатков?

Первое решение — не «какой модуль поставить», а «какая система главная по каждому типу данных». В связке МойСклад — сайт возможны три схемы, и только одна из них устойчива.

Правильный ответ почти всегда третий: источник каталога и остатков — учёт, потому что именно там остаток меняется физически — приёмкой, отгрузкой, списанием, инвентаризацией. Сайт не умеет знать о приёмке и о продажах в розничной точке или на маркетплейсе. На странице Like Sites про интеграцию с МоимСкладом это названо главной причиной расхождений: проблема не в подключении, а в структуре данных и в неопределённости владения полями — если наименование и описание правит контент-менеджер на сайте, а обмен затем перезаписывает их значениями из учёта, работа теряется каждый цикл (страница «Интеграция магазина с МоимСкладом», проверено 31 октября 2026).

Из этого следует таблица владения полями — первый документ проекта, без которого настраивать обмен нельзя:

Отдельно про остатки. В МоемСкладе есть остаток, резерв и ожидание, а доступное количество считается как остаток плюс ожидание минус резерв. На сайт должен уходить не физический остаток, а доступный — иначе магазин продаст товар, уже зарезервированный под другой заказ. Включать ли ожидание в доступный остаток — решение компании: для сайта с пометкой «под заказ» это допустимо, для продажи «в наличии» — нет.

Какие объекты передавать?

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

Заказ покупателя в МоемСкладе — документ с позициями, контрагентом, складом, состоянием и полем внешнего кода; у документов есть дополнительные поля, в которые можно записать номер заказа сайта, способ доставки и оплаты (документация JSON API МоегоСклада, работа с документами и дополнительными полями). Это важно для защиты от дублей: внешний код или дополнительное поле с идентификатором заказа сайта — ключ, по которому обмен находит уже созданный документ.

Документы — отдельное решение. Like Sites формулирует границу так: заказ и связанные с ним документы могут формироваться в учёте автоматически, но формирование бухгалтерских документов и электронный документооборот остаются в контуре клиента, и перечень документов, попадающих в обмен, фиксируется явно (страница «Интеграция магазина с МоимСкладом»). Минимальный состав для розницы — заказ покупателя и статусы; отгрузка и входящий платёж создаются либо автоматически по правилу, либо менеджером в учёте — это решается на этапе проектирования, а не настройкой «галочкой».

Когда достаточно готового коннектора?

Готовые коннекторы к МоемуСкладу есть у большинства платформ сайтов и у самого сервиса. Они закрывают подключение: выгрузить товары, обновить остатки и цены, загрузить заказы. Вопрос не в том, работает ли коннектор, а в том, хватает ли его вашей схеме.

Сравнение по функциональным требованиям — без оценок «лучше или хуже», только по тому, что обычно умеет готовое подключение и что требует индивидуального обмена:

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

Признак, что коннектора не хватает, формулирует сама страница услуги Like Sites в диагностике: синхронизация настроена типовым модулем, но регулярно расходится, и причину найти нельзя (страница «Интеграция магазина с МоимСкладом»). «Причину найти нельзя» — ключевое: коннектор без журнала и очереди переносит данные и молчит о том, что не перенёс.

Когда нужен индивидуальный обмен?

Индивидуальный обмен — не замена коннектора ради замены, а ответ на конкретные требования, которые готовое подключение не покрывает. Перечень, при котором разработка оправдана:

• Несколько каналов на один запас. Сайт плюс Wildberries и Ozon плюс розница — остаток должен считаться в одном месте и раздаваться всем с буфером или квотами. Коннектор «МойСклад — сайт» этого не знает. Как устроен такой контур и что проверять при сдаче, описано на странице интернет-магазин с собственным складом.
• Нестандартная структура вариантов. В учёте товар с размерами описан как отдельные позиции, а на сайте — как одна карточка с вариантами, или характеристики названы по-разному. Нужны правила сопоставления, а не настройка.
• Правила владения полями по каждому полю. Контент под SEO готовится на сайте, учёт отдаёт только наименование, цену, остаток и характеристики.
• Короткий интервал обновления остатков. Товары с быстрым оборотом требуют обновления по событию и очереди с учётом лимитов.
• Наблюдаемость. Журнал с составом переданных данных, повторная отправка, уведомления ответственному — без этого сбой обнаруживается по жалобе покупателя.
• Документы по правилам компании. Автоматическое создание отгрузки при определённом статусе, входящего платежа по уведомлению от платёжного сервиса, счёта для B2B-покупателя.
• Сложная логика заказа. Разделение заказа по складам, резерв по правилу, частичные отмены, возвраты с привязкой к исходной отгрузке.

Состав индивидуального обмена на условиях Like Sites — восемь модулей: аудит структуры данных, правила владения полями, сопоставление товаров и вариантов, остатки и резервы, заказы, статусы и документы, частота обмена и лимиты, ошибки, повторы и журнал, тестовые заказы и запуск; стоимость определяется состоянием данных и составом обмена, а не числом товаров, и формируется после аудита (страница «Интеграция магазина с МоимСкладом»). Средних цен интеграции с МоимСкладом здесь нет намеренно: без аудита данных и перечня объектов любая цифра — предположение.

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

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

Ситуация: у вас МойСклад, магазин работает или запускается, и неясно, хватит ли коннектора или нужен свой обмен. Что разберём: тариф и объекты учёта, число позиций и складов, каналы продаж, текущий коннектор и проблему, с которой вы сталкиваетесь. Результат: прямой ответ — коннектор, коннектор с доработкой или индивидуальный обмен — с обоснованием по требованиям из таблицы выше. Действие: проверить сценарий интеграции с МоимСкладом.

Как учитывать модификации, комплекты и цены?

Три типа объектов дают большинство расхождений в каталоге, потому что в учёте и на сайте они устроены по-разному.

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

1. Карточка сайта соответствует товару, вариант — модификации; связь — по внутреннему идентификатору МоегоСклада, а не по наименованию.
2. Характеристики сопоставляются таблицей: «Размер» в учёте — «Размер» на сайте, «Цвет» — «Цвет». Если на сайте варианты строятся по одной характеристике, а в учёте их две, нужно правило: какая характеристика становится вариантом, какая — свойством.
3. Товар без модификаций — карточка без вариантов; появление первой модификации — событие для человека, а не автоматическое превращение карточки.
4. Снятая модификация скрывается на сайте, но не удаляется: у неё есть история заказов.

Самая частая ошибка — товары с размерами заведены в учёте как отдельные позиции «Футболка S», «Футболка M» без связи через модификации. Коннектор выгрузит их как отдельные карточки, и на сайте не будет выбора размера. Это проблема данных, а не интеграции; её решают на аудите — либо перестраивают номенклатуру в учёте, либо задают правило группировки на стороне обмена.

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

Цены. Типы цен создаются в МоемСкладе; на сайт передаются выбранные. Для розничного сайта — одна цена; для B2B — несколько уровней по типу цены контрагента. Акции и промокоды живут на сайте, но тогда в заказ в учёт передаётся фактическая цена продажи, и учёт должен её принять, а не пересчитать по прайсу. Округление, валюта и признак «цена с НДС» фиксируются в таблице владения.

Изображения. Передавать их из учёта на сайт можно, но витринные изображения обычно готовятся под сайт — сжатие, формат, alt-тексты — и принадлежат ему. В таблицу владения заносится решение, и оно одно.

Как связать заказ, резерв, отгрузку и возврат?

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

Правила, без которых цикл не работает:

• Заказ создаётся в учёте один раз. Ключ — внешний код или дополнительное поле с идентификатором заказа сайта. Повторная отправка находит документ и обновляет его или ничего не делает.
• Резерв ставится в учёте, а не на сайте. Сайт сообщает о событии, учёт меняет доступный остаток, обмен раздаёт новое значение. Мягкий резерв на время оплаты — минуты, с автоматическим снятием при неоплате.
• Статусы сопоставлены таблицей. Названия состояний в МоемСкладе и статусов на сайте разные; соответствие фиксируется письменно, а дисциплина проставления состояний в учёте — зона компании, не интегратора.
• Отмена снимает резерв по позициям. Частичная отмена — одна позиция из трёх — не должна снимать резерв со всего заказа.
• Возврат в доступный остаток — только по факту приёмки документом. Возврат покупателя в МоемСкладе создаётся на основании отгрузки, и именно его проведение возвращает товар; интеграция может передать заявку на возврат как событие, но документ проводит человек после проверки состояния товара.
• Изменение состава заказа после создания — по согласованному правилу. Либо сайт запрещает менять оплаченный заказ, либо изменения передаются как обновление позиций с пересчётом резерва.

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

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

Как работать с несколькими складами?

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

Решения, которые фиксируются до настройки:

1. Какие склады участвуют в продажах на сайте. Обычно — основной и, возможно, розничные точки для самовывоза; склад брака, транзитный и склады площадок — нет.
2. Что показывать покупателю: сумму по участвующим складам или наличие в конкретной точке. Для доставки — сумма; для самовывоза — наличие в выбранной точке.
3. На какой склад создаётся заказ. Правило приоритета: ближайший к покупателю, с полной комплектацией из одного места, основной по умолчанию. Разбиение заказа по складам — отдельное решение, которого в простых схемах лучше избегать.
4. Как учитываются перемещения. Товар в пути между складами — не доступен ни одному; доступен после приёмки на складе назначения.
5. Остатки складов маркетплейсов (FBO). Это ваш товар, но продать его на сайте нельзя — он не у вас. Такие склады исключаются из доступного остатка сайта.

Остатки по складам в МоемСкладе доступны отчётом остатков с разбивкой по складу; обмен запрашивает только участвующие склады и считает доступный остаток по правилу. Эти правила проверяются при сдаче контрольными заказами из разных зон.

Для компании, которая продаёт один запас на сайте и на площадках, вопрос складов — часть общей задачи единого остатка: правила буфера, квот по каналам и поведения последних единиц задаются один раз для всех каналов, а не отдельно для сайта.

Как учитывать ограничения API и повторы?

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

Что говорит документация. JSON API ограничивает число запросов в единицу времени и число параллельных запросов от пользователя и от аккаунта; при превышении возвращается ошибка 429, а остаток лимита можно узнать из заголовков ответа — X-RateLimit-Limit, X-RateLimit-Remaining, X-Lognex-Retry-TimeInterval, X-Lognex-Retry-After; лимиты на параллельные запросы в заголовках не отображаются и проявляются ошибкой 429 с кодом 1073. Списки отдаются страницами не более 1000 элементов, а превышение размера запроса — например, более 1000 позиций в документе — возвращает ошибку 413 (документация JSON API МоегоСклада, общие сведения). Точные значения лимитов зависят от тарифа и меняются — перед запуском их проверяют в документации, а в обмене читают из заголовков, а не зашивают в код.

Сам сервис рекомендует вебхуки вместо периодических запросов изменений — чтобы взаимодействие с интернет-магазином шло в реальном времени (руководство разработчика МоегоСклада, вебхуки). Для остатков и заказов это правильная модель: изменился остаток — пришло событие — обмен обновил сайт; вместо опроса всего каталога каждые пять минут.

Правила обмена, которые из этого следуют:

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

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

Как принять интеграцию и сопровождать её?

Интеграция принимается не по факту «остатки обновляются», а по поведению в конфликтных ситуациях и по данным. Перечень проверок согласуется до работ и прогоняется тестовыми заказами до включения на живом потоке.

Чек-лист приёмки:

1. Правила владения полями согласованы письменно и соответствуют настройкам обмена.
2. Правка поля на стороне владельца сохраняется после цикла обмена.
3. Контрольная выборка товаров с модификациями и характеристиками сопоставлена верно; переименование позиции связь не рвёт.
4. Изменение остатка в учёте доходит до сайта в согласованный интервал; интервал измерен.
5. Заказ с сайта создаётся в учёте один раз, без дублей, с полным составом и внешним кодом.
6. Изменение состояния в учёте отражается на сайте по таблице соответствия.
7. Нужные документы формируются в учёте по заказу — ровно те, что зафиксированы в перечне.
8. Отмена до отгрузки возвращает остаток; возврат после отгрузки — только по приёмке документом.
9. Заказ с несколькими позициями и частичная отмена обрабатываются по позициям.
10. При повышенной нагрузке операции не теряются, а обрабатываются очередью.
11. Ошибка обмена фиксируется в журнале и порождает уведомление ответственному.
12. Повторная отправка не создаёт дубль заказа.
13. Комплект недоступен при отсутствии компонента.
14. Остатки складов, не участвующих в продажах, не попадают на сайт.

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

Сопровождение. Обмен — не разовая настройка. Меняются тарифы и лимиты сервиса, добавляются склады и типы цен, появляются новые характеристики, обновляется платформа сайта. На странице услуги это сформулировано прямо: после запуска идёт наблюдение за первыми циклами с корректировкой интервалов и правил, а дальнейшее сопровождение — предмет отдельной договорённости, поскольку речь о постоянной работе (страница «Интеграция магазина с МоимСкладом»). В бюджет магазина эту строку нужно закладывать с первого года; как складывается полная стоимость магазина с интеграциями и какие расходы в нём регулярные, разобрано в статье сколько стоит интернет-магазин с 1С, складом и CRM — логика для МоегоСклада та же, отличается техника.

Что входит в сопровождение по смыслу: просмотр журнала и расхождений по расписанию, разбор исключений, обновление сопоставлений при новых характеристиках, адаптация к изменениям API и платформы, пересмотр буфера и интервалов по статистике. Что не входит: содержание данных в учёте — дубли позиций, пустые характеристики, несвоевременные приёмки — это зона клиента, и ответственность за передачу и за достоверность исходных значений разделена явно.

Когда интеграцию делать не стоит?

Честный раздел. Интеграция с МоимСкладом не нужна или преждевременна в нескольких ситуациях, и лучше узнать о них до сметы.

• Учёт в МоемСкладе не ведётся реально. Если остатки правятся «потом», приёмки проводятся раз в неделю, а продажи вносятся одной суммой, обмен перенесёт на сайт неверные данные и будет честно их синхронизировать. Сначала дисциплина учёта.
• Нет устойчивой структуры номенклатуры. Дубли позиций, товары с размерами как отдельные позиции без модификаций, пустые характеристики, разные единицы измерения. Аудит покажет объём работы по приведению данных в порядок; часто её эффективнее сделать на стороне учёта до интеграции: обмен переносит значения, а не исправляет их.
• Один канал и малый поток. Десятки заказов в месяц и редкие изменения остатков — ручное или регламентное обновление с консервативным буфером даёт тот же результат дешевле; коннектора более чем достаточно.
• Тариф не допускает нужного объёма операций. Лимиты API зависят от тарифа; если обмену нужно больше, чем он позволяет, сначала тариф, потом обмен.
• Нет решения о владельце полей. Если компания не готова решить, кто правит описания и кто — остатки, любая настройка будет конфликтовать с чьей-то работой. Это решение клиента, и без него настройка невозможна.
• Задача на самом деле — не обмен. Если проблема в том, что менеджеры не обрабатывают заявки, нужна CRM; если в доставке и ПВЗ — интеграции со службами доставки; если в едином остатке на нескольких площадках — контур магазина со складом. Страница услуги перечисляет эти случаи отдельно и отправляет на другие страницы, чтобы не платить за лишний объём.
• Нет ответственного за уведомления и статусы. Обмен с журналом и уведомлениями бесполезен, если их никто не читает, а состояния заказов в учёте не проставляются.

Если магазин только запускается рядом с маркетплейсами, порядок такой: сначала каталог и учёт в порядке, затем магазин как канал с обменом, затем единый остаток с площадками. Как построить такой магазин, чтобы он сразу стал каналом с общим остатком, разобрано в статье интернет-магазин для селлера Wildberries и Ozon: как запустить второй канал.

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