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

Обмен магазина с МойСклад или 1С — это не «сайт видит склад», а служба, которая переносит между двумя базами четыре потока данных: товары, остатки и цены, заказы и статусы. Устроена она вокруг трёх вещей: ключа сопоставления, очереди задач и журнала. Разберу, как это работает внутри и почему ломается.

Почему нельзя ходить в учёт напрямую

Соблазн простой: пусть страница товара при открытии спрашивает остаток у учётной системы и показывает актуальное число.

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

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

Ключ сопоставления

Первое решение, которое определяет судьбу проекта: чем товар на сайте связан с товаром в учёте.

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

Устройство простое: у каждой позиции на сайте есть поле с внешним идентификатором. Оно заполняется один раз при первичном сопоставлении и дальше не редактируется руками.

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

Направление первое: товары и остатки в магазин

Учётная система владеет ценой, остатком, артикулом и складскими характеристиками. Сайт получает их и не меняет.

Внутри это два разных процесса с разной частотой.

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

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

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

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

Направление второе: заказы в учёт

Сайт формирует заказ и передаёт его как документ: покупатель, состав, цены, доставка, оплата.

Здесь возникает вопрос, который решается один раз: где заказ живёт после создания. Если его ведут в учёте, сайт передаёт документ и дальше только показывает статус. Если ведут в админке сайта, учёт получает копию и не редактирует её.

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

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

Очередь вместо прямых вызовов

Самая важная деталь устройства, и её чаще всего экономят.

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

Что это даёт:

• покупатель не ждёт чужой сервис на кнопке оплаты;
• недоступность учёта не ломает оформление;
• задачу можно повторить, если она упала;
• повторы делаются с нарастающей паузой, а не десять раз подряд;
• виден порядок: задачи по одному заказу выполняются последовательно.

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

Журнал и что в нём видно

Обмен без журнала не поддерживается — это проверено на любом проекте, где журнала не сделали.

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

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

Где обмен ломается на практике

Список короткий и повторяющийся.

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

Товар удалили в учёте — на сайте он остался и продаётся. Лечится обработкой признака архивности, а не физическим удалением.

Изменили единицу измерения или упаковку — остатки поехали в разы. Лечится фиксацией коэффициента и проверкой на резкое изменение.

Сменился ключ доступа к сервису — обмен встал молча. Лечится уведомлением при отсутствии успешных обменов дольше заданного времени.

Когда обмен не нужен

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

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

Коротко

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

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