Интеграция с маркетплейсами: как синхронизировать заказы, остатки и статусы с ERP и 1С

Интеграция с маркетплейсами — это автоматический обмен товарами, ценами, остатками, заказами и статусами между Ozon, Wildberries, Яндекс Маркетом и учётной системой компании: 1С, ERP или WMS. Чтобы она работала без дублей заказов и перепродаж, до кода нужно определить владельца каждой сущности, защиту от повторных событий, карту статусов и правило расчёта доступного остатка. Подключённый API доказывает только то, что канал открыт; правила обмена приходится проектировать отдельно.

Типичный симптом их отсутствия — два одинаковых заказа в ERP и товар, проданный в офлайне, но всё ещё доступный на маркетплейсе. Для оператора это разные ошибки, а причина часто одна: системы обмениваются данными без точных правил. В документации Яндекс Маркета прямо сказано, что площадка может несколько раз отправить уведомление об одном изменении, а время и состояние заказа в уведомлении, ответе API и системе магазина могут различаться. Интеграции с 1С, ERP, WMS и API площадок QTIM проектирует в рамках разработки маркетплейсов и e-commerce. Ниже — решения, которые нужно принять до запуска, и критерий готовности, который можно проверить.

Почему подключённого API недостаточно

Токен, работающий запрос и первый полученный заказ доказывают только техническую доступность канала. Рабочая интеграция начинается с ответов на более неудобные вопросы: какая система владеет каждым полем, как распознать повторное событие, какой статус считать актуальным и что делать после тайм-аута. У площадок разные контракты и операционные модели. В WB API отдельно описаны товары, остатки и несколько схем исполнения заказов. Яндекс Маркет делит методы по кабинетам, магазинам, складам и моделям работы. ERP хранит собственные документы, регистры, резервы и правила проведения. Прямое соединение «API в ERP» быстро обрастает условиями внутри учётной системы. Мы обычно выносим работу с площадками в интеграционный слой. Он переводит внешние сущности во внутреннюю модель, хранит соответствия идентификаторов, принимает события, запускает повторы и ведёт журнал. ERP получает согласованный контракт вместо логики трёх площадок, размазанной по обработчикам. Сама 1С допускает несколько способов интеграции. Её REST-интерфейс позволяет читать и изменять объекты, создавать документы и получать остатки. Конкретный транспорт выбирают после разбора конфигурации, нагрузки и допустимых изменений. Схема обмена важнее модного названия протокола.

Три способа интеграции с маркетплейсами

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

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

Карта данных: кто владеет товаром, ценой, остатком и заказом

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

• товар и SKU: ERP или PIM (система управления товарными данными) хранит внутренний идентификатор, интеграционный слой связывает его с внешним ID каждой площадки;
• цена: владелец зависит от модели ценообразования; рядом фиксируются акции, минимальная цена и момент вступления значения в силу;
• доступный остаток: ERP, WMS (система управления складом) или отдельная система управления заказами считает физический запас, резервы и страховой остаток;
• заказ: маркетплейс владеет внешним номером и исходными условиями, ERP создаёт внутренний документ с постоянной ссылкой на этот номер;
• статусы, возвраты и выплаты: площадка сообщает внешнее состояние, а компания отдельно ведёт операционный, логистический и финансовый контуры.

Карту нельзя заполнять по принципу «всё берём из ERP». Учётная система может знать количество на складе и не знать, что площадка уже создала заявку на отмену. Маркетплейс видит свой заказ и не учитывает продажу из розничной точки. Интеграционный слой связывает эти факты, не присваивая себе владение бизнес-данными.

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

Синхронизация заказов: защита от дублей

Сетевой обмен не обещает, что каждое событие придёт ровно один раз и строго по порядку. Площадка повторяет уведомление, клиент повторяет запрос после тайм-аута, очередь доставляет сообщение заново. Поэтому мы делаем создание заказа идемпотентным: повтор той же команды сохраняет прежний результат. Практический ключ можно собрать из площадки, кабинета продавца и внешнего ID заказа. На эту комбинацию ставят уникальное ограничение. При повторе слой интеграции находит созданный документ, сверяет версию или время обновления и применяет только новое изменение. Мы сохраняем след каждого события: внешний ID, внутренний ID, направление, тип операции, время источника, номер попытки и результат. В журнал записываем и цифровой отпечаток сообщения, то есть хэш полезной нагрузки. Тогда оператор видит, пришла копия прежнего сообщения или площадка прислала другой состав с тем же номером. Тайм-аут требует особой осторожности. Отсутствие ответа не доказывает, что операция провалилась: ERP могла принять документ, а сеть потеряла подтверждение. Без проверки по внешнему ключу автоматический повтор создаст дубль именно в тот момент, когда система пытается восстановиться.

Синхронизация статусов: доставка, оплата и возврат отдельно

Попытка свести все состояния к одному полю рождает странные значения: «отгружен, частично выкуплен, возврат в пути, выплата ожидается». Человеку фраза ещё понятна. Для автоматизации это четыре разных процесса. Мы разделяем как минимум внешний статус площадки, внутренний статус обработки, доставку и финансовое состояние. Затем описываем разрешённые переходы. Система знает, кто меняет статус, какое событие разрешает следующий шаг и можно ли откатить операцию. Такой граф защищает от запоздавших сообщений. Событие «готов к отгрузке», пришедшее после подтверждённой доставки, попадёт в журнал и очередь разбора, но не вернёт заказ на склад. В документации Яндекс Маркета порядок переходов указан отдельно: нарушение последовательности приводит к ошибке. Для бизнеса карта статусов даёт ещё один результат: становится видно, где заказ застрял и кто должен действовать. «Ошибка интеграции» превращается в конкретную очередь: не найден SKU, ERP отклонила документ, склад не подтвердил резерв, площадка не приняла переход.

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

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

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

Рабочее место оператора: очередь исключений вместо графиков

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

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

Каждая строка ведёт к операции с историей: кто изменил данные, что отправила система, какой ответ пришёл, сколько было попыток и что можно сделать сейчас. Зелёная галочка «успешно» здесь не годится: HTTP-ответ подтверждает доставку запроса, но не результат. В документации WB API для загрузки цен и скидок отдельно предусмотрена проверка обработанного запроса — часть товаров может не обновиться, и причину нужно получить после отправки. У изменения цены поэтому как минимум четыре состояния: создано, отправлено, принято в обработку, применено или отклонено с причиной.

Семь сбоев, которые проверяем до запуска

Успешный сценарий проверяет API. Набор аварийных ситуаций проверяет всю операционную систему. Перед первым боевым заказом мы проводим семь испытаний:

• одно уведомление приходит дважды;
• два статуса приходят в обратном порядке;
• ERP создаёт документ, но ответ теряется по тайм-ауту;
• площадка возвращает ограничение частоты или временную серверную ошибку;
• в пакете из ста остатков часть строк отклонена;
• один внешний SKU связан с неверной номенклатурой;
• товар одновременно покупают на маркетплейсе и в другом канале.

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

Первый релиз: один сквозной заказ

Первый релиз разумно ограничить одной площадкой, одной схемой исполнения, одним складом и одним типом заказа. Заказ проходит весь путь: появляется на площадке, создаётся в ERP, резервирует товар, меняет статусы, отгружается, отменяется или возвращается. После этого подключение следующего канала становится добавлением адаптера к устойчивому ядру. В проекте HOTZ мы связали с 1С одну витрину для четырёх продуктовых линеек: товары, цены, остатки и заказы участвуют в двустороннем обмене. За интерфейсом работает тот же принцип: у сущностей есть владельцы, операции идут в правильной последовательности, а состояние заказа можно разобрать по шагам. Интеграция готова, когда один заказ проходит от площадки до ERP и обратно с тем же внешним ID, составом, количеством и разрешённой цепочкой статусов. Повтор события сохраняет один документ, ошибка попадает в журнал, а сверка восстанавливает пропущенные изменения. Тогда оператор открывает ERP и видит один заказ вместо двух, а покупатель видит доступным только тот товар, который компания действительно может отгрузить. В B2B-каталоге для дистрибьютора «Тепломаш» у каждого бренда свой сайт и отдельный проект, а каталог, цены, остатки и заказы синхронизируются с 1С: заказы автоматически попадают в учётную систему, и менеджеру не нужно переносить их вручную.

Вопросы и ответы

Что входит в интеграцию с маркетплейсами?

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

Можно ли интегрировать маркетплейсы напрямую с 1С?

Да. REST-интерфейс 1С позволяет читать и изменять объекты, создавать документы и получать остатки. При нескольких площадках правила обмена лучше вынести в отдельный интеграционный слой, чтобы логика каждой площадки не оседала в конфигурации 1С.

Как избежать дублей заказов?

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

Как часто синхронизировать остатки?

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

С какой площадки начинать?

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

Когда нужен собственный интеграционный слой, а не готовый коннектор?

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

Можно прислать схему текущего обмена или описать проблемный заказ команде интеграций e-commerce и маркетплейсов QTIM: разберём источники данных, статусы и точки отказа, затем предложим состав первого релиза.