Интеграция МойСклад с сайтом: где ломается синхронизация
Интеграция МойСклад с сайтом почти никогда не ломается «целиком» — она деградирует точечно, и это опаснее. Синхронизация остатков идёт по расписанию, а не в момент покупки: между выгрузкой и оформлением заказа проходит окно, в котором сайт показывает товар в наличии, хотя на складе он уже продан. Отсюда двойные продажи, ручные возвраты и клиенты, которым приходится объяснять, почему оплаченный заказ не поедет.
Вторая тихая поломка — расхождение номенклатуры. Артикулы в учётной системе и на сайте живут по разным правилам: где-то меняли вручную, где-то товар завели дважды, где-то единицы измерения не совпали. Обмен заказами при этом продолжается, но позиции сопоставляются по названию — и заказ уходит в учёт с «нулевой» строкой, которую менеджер ловит уже после подтверждения клиенту.
Третий класс сбоев — потеря событий. Если обмен построен на периодическом опросе без журнала изменений, любая правка цены или остатка между двумя проходами просто исчезает. Сайт и учётная система расходятся нарастающим итогом, и через пару недель никто не может сказать, какая сторона «правильная» — приходится сверять вручную.
Цена этих сбоев считается не в ошибках интеграции, а в сорванных заказах: клиент оформил, оплатил, ждёт — и получает отказ. Ниже разбираем, как каждый из этих сбоев закрывается на уровне схемы обмена, а не ручными правками.
Что даёт настройка обмена: товары, заказы, остатки
Синхронизация товаров: каталог перестаёт расходиться с полкой
Обмен тянет номенклатуру, цены, единицы измерения и характеристики из учётной системы в каталог сайта. Сопоставление идёт по внешнему идентификатору позиции, а не по названию — переименование или смена артикула не плодит дубли и не рвёт связи. На выходе каталог на несколько тысяч позиций сходится с учётным за минуты, а не за ночной прогон, и правка цены появляется на сайте без ручной выгрузки файла.
Выгрузка заказов: документ создаётся один раз
Оформленный заказ уходит в учётную систему отдельным документом с составом, скидками и данными покупателя. Идемпотентность по номеру заказа закрывает главный риск — повторную отправку при обрыве связи: дубликатов в учёте не появляется, а статус на сайте подтягивается обратно после сборки и отгрузки. Клиент видит движение заказа, менеджер не сверяет две базы вручную.
Актуальные остатки: продажа без отказа
Остатки по складам обновляются чаще каталога и с приоритетом — позиция с нулевым остатком уходит в «под заказ» или скрывается по правилу. Это снимает класс отказов «оплатил, а товара нет»: доля отменённых заказов падает, а резерв под оформленную корзину не даёт продать одну единицу дважды.
Режим обмена и расписание синхронизации
Обмен строят на штатном программном интерфейсе учётной системы: события (вебхуки) для заказов и остатков плюс плановый обход для каталога. Расписание задаётся под ритм продаж: остатки — каждые несколько минут, каталог — реже, тяжёлые выгрузки — в окно низкой нагрузки. Очередь с повторами держит обмен при недоступности одной из сторон и не теряет изменения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Событийный обмен (вебхуки) | Заказы, остатки, частые точечные изменения | Нужна обработка повторов и недоставленных событий |
| Плановый обход по расписанию | Каталог, цены, массовые обновления | Задержка равна интервалу обхода |
| Гибрид: события + обход | Магазины с активными продажами | Сложнее настройка очереди и правил приоритета |
| Прямой обмен через промежуточную базу | Высокая нагрузка, несколько каналов продаж | Требует отдельного сервиса и его поддержки |
МойСклад отдаёт товары, остатки и заказы через документированный интерфейс — этого достаточно, чтобы построить обмен без ручных выгрузок и сторонних надстроек.
Как мы внедряем обмен: от аудита до передачи
Обмен между учётной системой и сайтом почти никогда не сводится к «включить синхронизацию». Нужно заранее договориться, что считается источником истины по остаткам, как сопоставляются номенклатура и склады, что делать с заказом, который на сайте оформлен в момент, когда товар уже списан в зале. Поэтому работу ведём этапами, и каждый заканчивается артефактом, который можно проверить.
- Аудит учётной системы. Смотрим справочники номенклатуры, склады, цены и типы цен, историю движений, дубли и «мусорные» позиции. Фиксируем, какие сущности вообще готовы к обмену, а какие придётся нормализовать до старта.
- Проектирование схемы обмена. Определяем направление потоков, частоту и триггеры: остатки и цены идут на сайт, заказы — в учётную систему, статусы — обратно. Прописываем правила сопоставления по артикулу и внешнему идентификатору, поведение при конфликте и при удалении позиции.
- Настройка синхронизации. Реализуем обмен через штатные механизмы и API, ставим обработку ошибок и повторные попытки, ограничиваем нагрузку при массовых выгрузках, чтобы каталог не «замирал» в часы пик.
- Сборка тестового контура. Копия каталога и учётной базы, где прогоняем сценарии: изменение цены, списание остатка, оформление и отмена заказа, возврат, появление новой позиции. Смотрим, что расхождений между системами не остаётся.
- Проверка на реальных данных. Переносим обмен на рабочий контур с ограниченным набором товаров, сверяем остатки и заказы построчно, замеряем, за сколько проходит полный цикл и как система ведёт себя при обрыве связи.
- Регламент и мониторинг. Настраиваем оповещения о сбоях обмена и расхождениях, описываем, что делает оператор при ошибке, чтобы проблема не ждала разработчика.
- Передача документации. Отдаём схему потоков, карту сопоставления полей, инструкции для менеджеров и доступы к настройкам.
Такой порядок даёт предсказуемый результат: обмен запускается без остановки продаж, а расхождения видно на тестовом контуре, а не в первый день работы. Опишите вашу учётную систему и каталог — вернёмся с оценкой и планом работ.
Чем отличается обмен по расписанию от обмена в реальном времени?
Интеграция МойСклад с сайтом почти всегда начинается с одного вопроса: как часто гонять данные. Обмен по расписанию запускается по таймеру — раз в 5, 15 или 60 минут — и забирает изменения пакетом. Синхронизация в реальном времени работает иначе: событие в учётной системе (создали заказ, изменили остаток, обновили цену) сразу уходит на сайт через вебхук или поток изменений. Разница не в «современности», а в том, какие задержки и какую нагрузку вы готовы принять.
Задержка обновления — ключевая метрика выбора. При обмене по расписанию остаток на витрине отстаёт на интервал таймера: если товар продан в зале, а сайт обновится через час, покупатель оформит заказ на то, чего нет. В реальном времени остаток сходится за секунды, но каждое событие — это отдельный запрос к сайту и к учётной системе. При ассортименте в несколько тысяч позиций и активных продажах поток событий становится плотным, и сайт начинает тратить ресурсы на приём обновлений вместо отдачи страниц.
Частота обмена — это компромисс между свежестью данных и нагрузкой на сайт. Практика такая: остатки и цены — часто (каждые 1-5 минут или по событию), номенклатура и описания — редко (раз в сутки или по факту правки), заказы — сразу, потому что потерянный заказ дороже лишнего запроса. Гибридная схема закрывает почти все сценарии: критичные для продажи данные идут в реальном времени, тяжёлые справочники — пакетно по расписанию.
Отдельно стоит учесть пиковые нагрузки. Массовое обновление цен или поступление товара по расписанию может совпасть с вечерним трафиком и уронить отклик сайта. Поэтому обмен выносят в очередь, ограничивают число одновременных запросов и разводят тяжёлые задачи по времени. Тогда синхронизация не мешает покупателям, а данные остаются актуальными настолько, насколько требует бизнес.
Кейс: как мы убрали двойные продажи при обмене
Клиент — розничная сеть с интернет-магазином на выделенном сервере и учётом в облачной системе. Обмен был построен на регулярном выгрузе файлов: сайт забирал остатки раз в час, заказы уходили обратно той же дорогой. При пиковой нагрузке — распродажа, поступление новой партии — окно рассинхрона растягивалось, и два покупателя оформляли последнюю единицу товара. Доля заказов с расхождением остатков доходила до 8%, а на разборе отмен и возвратов менеджеры тратили по несколько часов в день.
Что именно ломалось
Корень был не в самом факте обмена, а в его асинхронности и отсутствии блокировки на момент оформления. Сайт резервировал товар только после того, как заказ долетал до учётной системы, — а до этого момента остаток на витрине оставался прежним. Вторая проблема — конфликты при одновременной записи: если менеджер правил карточку в учётной системе, а сайт в этот же момент отправлял заказ, часть изменений затиралась.
Что изменили
Мы перевели обмен на событийную модель: учётная система сама сообщает сайту об изменении остатка, а сайт резервирует товар в момент добавления в корзину и подтверждает резерв при оформлении. Очередь сообщений сглаживает пики и гарантирует, что ни одно событие не потеряется при кратком разрыве связи. Конфликты записи развели по приоритетам: справочные данные — за учётной системой, оперативные резервы — за сайтом.
| Метрика | До | После |
|---|---|---|
| Доля заказов с расхождением остатков | до 8% | менее 0,3% |
| Задержка обновления остатка | до 60 минут | секунды |
| Отмены по причине «нет в наличии» | регулярные | единичные |
| Ручной разбор конфликтов | ежедневно | по исключениям |
МойСклад в этой схеме остаётся источником истины по номенклатуре и остаткам — сайт лишь своевременно на неё реагирует. Такой подход убирает саму почву для двойных продаж: покупатель видит актуальный остаток, а резерв фиксируется до подтверждения оплаты.
Сомнения по совместимости, миграции и откату обмена
Интеграция МойСклад редко вызывает вопросы на этапе «подключить обмен» — они появляются позже: что будет с накопленной историей заказов, как обмен уживётся с текущим каталогом и что делать, если после запуска всплывёт расхождение остатков. Разбираем эти сомнения по существу.
Что если на сайте уже есть своя база товаров и заказов? Обмен не требует чистой установки: на первом проходе сопоставляем позиции по артикулу и штрихкоду, конфликты по остаткам и ценам выводим отдельным отчётом, а не «затираем» молча. История заказов переносится отдельным проходом, чтобы не ломать уже собранную аналитику.
Что если обмен сломается ночью? Каждая операция идёт через очередь с повторными попытками, а расхождения фиксируются в журнале — при сбое видно, какой именно заказ или остаток не синхронизировался. План отката строится на резервной копии каталога и заказов перед первым запуском: возврат к прежнему состоянию — это переключение на сохранённый снимок, а не ручной разбор.
Насколько сложно вернуться к прежней схеме работы, если обмен не подойдёт?
Откат продумывается до запуска: снимок каталога и заказов, зафиксированные точки переключения и понятный порядок возврата. Если после тестового периода решите остановиться, возвращаемся к исходному состоянию без потери данных, накопленных за время обмена.
Что если понадобится ограничить доступ? Роли и права настраиваются отдельно: обмен работает через выделённого пользователя с минимально нужными правами, а не через учётную запись администратора. Это же упрощает аудит — видно, какие действия совершал обмен, а какие человек.
После сдачи заказчик получает на руки:
- схему обмена с перечнем сущностей и направлений синхронизации;
- конфигурацию сопоставления товаров, цен и остатков;
- регламент обработки конфликтов и расхождений;
- описание плана отката и точек возврата к прежнему состоянию;
- матрицу доступов и ролей для обмена;
- журнал синхронизации с примерами разбора сбоев;
- документацию по обмену для команды, которая будет его сопровождать.
Опишите вашу текущую схему — какие данные уже накоплены, как устроен каталог и кто работает с заказами. Вернёмся с оценкой и планом миграции под ваш случай.
Сроки внедрения обмена по этапам
Сроки зависят от числа складов, каналов продаж и того, насколько грязные данные в учётной системе. Ниже — ориентир по этапам для типового проекта: каталог до нескольких тысяч позиций, один сайт, один склад. Этапы идут последовательно, но часть работ по подготовке справочников идёт параллельно обмену.
Итого для типового проекта — от двух до четырёх недель. Основное время уходит не на сам обмен, а на приведение справочников в порядок: пока номенклатура дублируется и цены лежат в разных местах, любой обмен будет давать расхождения.
Что если у нас несколько складов и точек продаж? Добавляется этап настройки правил приоритета склада и логики резерва — плюс примерно неделя.
Что если сайт уже работает и обмен нужен без остановки продаж? Тестовый запуск идёт на копии, рабочий контур переключаем в один короткий интервал, обычно ночью или в затишье.
Можно ли ускорить? Да, если справочники уже чистые и правила соответствия очевидны — этап подготовки сокращается почти вдвое.
Опишите вашу конфигурацию складов и каналов продаж — вернёмся с оценкой и планом по этапам.
