Интеграция: ERP и учёт + Ozon

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

Типовые системы на этом конце: 1С:УТ, 1С:ERP, 1С:КА, «МойСклад», SAP, Microsoft Dynamics.

Ozon — маркетплейс со схемами FBO, FBS и realFBS, а также логистикой Ozon Rocket и программой Premium для продавцов.

Как с ней работать технически: Seller API: товары и цены, остатки, отгрузки FBS, поставки на склад, акции, отчёты и финансовые документы. Лимиты запросов зависят от тарифа и категории.

Из учётной системы идут номенклатура, характеристики, цены и остатки; в неё уходят заказы, оплаты, отгрузки и данные для документов (счёт, УПД, накладная).

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

«ERP и учёт» и «Ozon» отвечают за разные участки процесса, поэтому прямой коннектор между ними нужен не всегда — чаще они сходятся в одной из систем контура. Маркетплейс — отдельный канал со своими правилами, лимитами API и отчётностью. Синхронизацию ведём через очередь с ограничителем частоты запросов, остатки распределяем по каналам, а финансовые отчёты площадки регулярно сверяем с учётной системой.

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

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

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

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

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

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

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

Первый шаг — обследование: смотрим, какие данные уже ведутся, кто владелец каждой сущности и какие ограничения есть у API. Затем делаем прототип обмена на тестовом контуре, проверяем нештатные сценарии (повтор, отмена, частичное выполнение) и только после этого выводим интеграцию в продуктив.

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