Реализация двусторонней синхронизации каталога товаров с МойСклад

Синхронизация МойСклад с сайтом: где расходится каталог

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

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

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

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

Что даёт двусторонняя синхронизация каталога

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

Настроенный обмен снимает три вещи сразу. Витрина перестаёт продавать то, чего нет: остатки в реальном времени обновляются после каждой операции на складе, а не раз в сутки по расписанию. Заказы с сайта падают в учётную систему готовыми документами — доля заказов без ручной правки выходит на 90%+ и держится там. Уходит целый класс отказов: продажа в минус, задвоенные позиции, расхождение цен между витриной и каталогом.

• Скорость обновления каталога — от минут до секунд на позицию вместо ночной выгрузки целиком.
• Остатки в реальном времени — витрина видит склад после каждой приёмки, отгрузки и списания.
• Ручная правка заказов — только на нестандартных случаях: самовывоз, частичная отгрузка, ручная скидка.
• Класс отказов «продали то, чего нет» — закрывается на уровне сверки остатков перед оформлением.
• Рассинхрон цен и характеристик — ловится автоматически, а не глазами менеджера.
• История изменений — видно, кто и когда поправил карточку, и можно откатить.

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

Способы обмена данными: обмен по расписанию, событиям и запросу

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

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

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

Опишите, как часто меняется ваш каталог и насколько критична задержка, — подберём режим и вернёмся с оценкой.

Этапы внедрения синхронизации: от аудита данных до передачи

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

1. Аудит номенклатуры. Сверяем объём справочников, дубли, битые связи «товар — характеристика — единица измерения», историю изменения цен и остатков. Фиксируем, какие записи требуют ручной нормализации до старта.
2. Проектирование схемы соответствия полей. Составляем таблицу «поле источника → поле приёмника → правило преобразования»: как склеивается название, чем различаются оптовая и розничная цена, что делать с товарами без остатка, как помечаются архивные позиции.
3. Определение правил конфликтов. Договариваемся, какая сторона ведущая по цене, остаткам и описаниям, и что происходит при одновременном изменении одной карточки с двух сторон. Без этого правила обмен зацикливается на взаимных перезаписях.
4. Настройка обмена. Поднимаем канал, включаем журналирование каждого запроса и ответа, задаём расписание и порции выгрузки, чтобы обмен не блокировал работу каталога в часы пик.
5. Проверка на расхождениях. Прогоняем тестовый контур на реальных данных: сверяем количество позиций, цены, остатки и категории до и после обмена, отдельно смотрим позиции, изменённые с обеих сторон.
6. Обработка ошибок и повторные попытки. Настраиваем поведение при недоступности одной из систем: очередь, повтор, уведомление ответственному. Обмен не должен терять изменения при кратком сбое связи.
7. Передача регламентов. Отдаём документацию: схему соответствия, правила конфликтов, инструкцию по добавлению новых полей и порядок действий при расхождении. Обучаем сотрудников, которые будут вести каталог.

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

Правила сопоставления товаров, цен и складов

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

Единицы измерения и кратность — второй источник расхождений. Товар может храниться в учёте в упаковках, а продаваться поштучно или на вес, поэтому в правилах прописывается коэффициент пересчёта и базовая единица, к которой приводятся остатки и цены. Без этого синхронизация МойСклад отдаёт корректное число, но в неверной размерности, и на сайте появляется «1» вместо «12».

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

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

Что заказчик получает на руки после внедрения

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

• Настроенные правила обмена — какие сущности синхронизируются (номенклатура, цены, остатки, контрагенты, заказы), в какую сторону, с какой периодичностью и по какому триггеру запускается обмен.
• Схема соответствия — таблица сопоставления полей и справочников между учётной системой и каталогом сайта: артикул, единицы измерения, категории, ставки налогов, склады. По ней видно, что произойдёт с товаром при изменении любого атрибута.
• Журналы обмена — логи по каждому сеансу: сколько позиций принято, отклонено, какие записи ушли в ошибку и почему. По ним разбирается инцидент без доступа к серверу.
• Инструкции оператора — что делает менеджер при появлении нового товара, смене цены или ручной правке карточки на сайте, чтобы следующая синхронизация не перезаписала изменения.
• Регламент восстановления — порядок действий при сбое: как откатить неудачный сеанс, перезапустить обмен с контрольной точки, восстановить каталог из резервной копии.
• Документация обмена — описание логики интеграции, точек расширения и ограничений: где добавляется новое поле, как подключается новый склад или прайс-лист.
• Доступы и роли — учётные записи для сервиса обмена с минимально необходимыми правами и порядок их ротации.

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

Опишите задачу — вернёмся с оценкой и планом.

Чем отличается односторонняя выгрузка от двусторонней синхронизации?

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

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

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

Второй слой — идемпотентность. Сетевой сбой, повторная доставка события или ручной перезапуск обмена не должны задваивать заказ или списывать остаток дважды. Каждая операция получает идентификатор, и повтор с тем же идентификатором распознаётся как уже применённый. Это то, что отличает рабочий двусторонний обмен от выгрузки, которая «иногда дублирует заказы».

Третий слой — разрешение расхождений, когда правила всё же не покрыли случай. Нужен журнал операций с обеих сторон и понятная процедура разбора: видно, кто и когда изменил поле, какое значение победило и почему. Без такого журнала двусторонняя синхронизация превращается в источник, которому никто не доверяет, и команда возвращается к ручной сверке.

Кейс: как каталог перестал расходиться с учётной системой

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

Что было до

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

Что изменили

Настроили двусторонний обмен с МойСклад через API: остатки, цены и номенклатура подтягиваются в каталог, а оформленные заказы и их статусы уходят обратно в учётную систему. Обмен идёт по событиям, а не по расписанию, поэтому карточка обновляется почти сразу после изменения на складе.

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

Что стало

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

Частые технические сомнения перед стартом

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

Как разрешаются конфликты, если товар изменили с двух сторон?

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

Можно ли обмениваться частично, а не всем каталогом?

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

Что с восстановлением данных, если что-то пошло не так?

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

Обсудим вашу задачу синхронизации

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

Что изменили

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

Что стало

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

Что входит в работу по вашей задаче:

• разбор текущей схемы обмена: какие системы, какие сущности, кто инициатор изменений;
• правила сопоставления товаров, категорий, цен и остатков между системами;
• политика разрешения конфликтов и обработка удалённых позиций;
• журналирование операций и оповещения о сбоях;
• план внедрения по этапам с проверкой на тестовом контуре;
• оценка сроков и состава работ под ваш объём каталога;
• документация по схеме обмена и инструкция для менеджеров.

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