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

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

В этой статье разберем типовую архитектуру интеграции 1С с несколькими маркетплейсами и покажем, где чаще всего возникают проблемы при обмене.

Что происходит между 1С и маркетплейсом

Если упростить, обмен идет в двух направлениях:

• 1С → маркетплейс: товары, карточки, цены, остатки и другие данные для продаж.

• Маркетплейс → 1С: заказы, статусы, данные о доставке, отмены и возвраты.

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

В качестве базы для обмена данными мы использовали одно из готовых решений для интеграции 1С с маркетплейсами. В личном кабинете выглядит это примерно так.

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

Какие данные нужно синхронизировать

Чаще всего проблемы возникают с шестью группами данных:

• Заказы. В 1С должны попадать состав заказа, количество, стоимость, идентификаторы и данные для сборки и отгрузки.

• Статусы. Заказ проходит несколько этапов, и каждому статусу маркетплейса должен соответствовать статус в 1С. Иногда нужно еще и массово перевести заказы в другой статус — например, собрать заказы со всех площадок одновременно.

• Цены. Цена в 1С и цена на витрине могут различаться из-за правил площадки, скидок и акций.

• Остатки. Когда товар продан или изменились данные склада, новый остаток должен быстро попасть на маркетплейс. Логика передачи зависит от модели работы — FBO или FBS — и учитывает резервы, продажи и задержки обмена.

• Возвраты. Возврат — это не просто «минус один заказ». Его нужно связать с исходным заказом и правильно отразить движение товара.

• Карточки товаров. У каждой площадки свой набор атрибутов и свои требования к данным.

Идентификаторы (ID)

У одного и того же товара в 1С и на трех маркетплейсах могут быть разные ID. Например, в 1С у товара свой код номенклатуры, а площадки используют собственные ID карточек, SKU и другие ключи. Если связь между ними потеряна, API вернет успешный ответ, но данные запишутся не в тот товар.

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

Перед созданием заказа 1С проверяет, нет ли уже заказа с таким внешним ID на этой площадке. Если есть, система обновляет существующий объект, а не создает дубль. Если соответствие неоднозначное, операцию лучше остановить и отправить на ручной разбор.

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

FBO и FBS: как различается логика обмена

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

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

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

Частота обмена и страховой остаток

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

• заказы и статусы — регулярно, с интервалом, при котором соблюдаются сроки обработки;

• остатки — после изменения складских данных и резервов, но не чаще, чем позволяет API;

• цены и карточки — при изменении в 1С, с проверкой того, как площадка обработала данные;

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

Между обменами данные могут временно расходиться. Например, заказ уже оформлен на одной площадке, но еще не загружен в 1С, а остаток на другой витрине пока не обновился. Так возникает overselling — один и тот же товар продают нескольким покупателям.

Для FBS этот риск снижают двумя способами:

• Резерв. Товар под уже принятые заказы исключают из доступного количества.

• Страховой остаток. Это дополнительный запас, который не показывают на витринах. Он компенсирует задержки обмена и продажи, которые еще не отразились во всех системах.

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

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

Где чаще всего ломается обмен

Ошибки можно условно разделить на три уровня.

1. Ошибки получения данных

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

Нужен механизм повторных попыток: при временном сбое запрос должен выполниться еще раз, но без дублей.

Делать это лучше с паузами между попытками. А постоянную ошибку, например неверные параметры запроса, повторной отправкой не исправить: сначала нужно устранить причину.

2. Ошибки преобразования

API разных площадок отдают данные в разных форматах. Одно и то же по смыслу поле может называться по-разному и принимать разные значения.

Например, статусу «отменен» на одной площадке соответствует одно значение, а на другой — сразу несколько.

Здесь нужен слой сопоставления:

• Идентификатор маркетплейса → объект 1С.

• Статус площадки → внутренний статус.

• Структура заказа → структура документа 1С.

• Единицы и значения атрибутов → формат учетной системы.

3. Ошибки бизнес-логики

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

Поэтому мало проверить HTTP-ответ. Нужно убедиться, что данные действительно изменились так, как ожидалось.

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

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

Логи и уведомления: как быстро заметить сбой

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

В логе полезно сохранять:

• время и направление операции;

• маркетплейс;

• тип сущности;

• внешний идентификатор объекта;

• результат запроса;

• текст ошибки;

• число попыток и информацию о повторной отправке.

Тогда при сбое можно быстро ответить на главный вопрос: что именно произошло с конкретным объектом.

Например, пользователь пишет, что заказ не появился в 1С. В таком случае нужно найти этот заказ в логе и посмотреть: был ли запрос, что ответила площадка и была ли повторная попытка.

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

• заказ не удалось загрузить после нескольких попыток;

• остаток или цена не подтвердились при обратной проверке;

• обмен не запускался дольше установленного интервала.

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

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

Повторная отправка без дублей

Повторная отправка — отдельная техническая задача. Простого принципа «ошибка — отправь еще раз» недостаточно.

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

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

Пример — та же проверка внешнего ID и площадки перед созданием заказа в 1С. Если API поддерживает ключ идемпотентности, его тоже стоит передавать.

Сводная таблица обмена

Собрали ключевые правила в таблицу. Это типовая схема: в каждом конкретном случае детали нужно сверять с API и настройками каждой площадки.

Что меняется при подключении нескольких площадок

Второй или третий маркетплейс добавляет не только API-запросы. Растет число связей между сущностями, вариантов статусов и сценариев ошибок.

Рабочая интеграция должна учитывать:

• единый контур данных в 1С;

• отдельные правила конкретных площадок;

• раздельную логику FBO и FBS, резервы и частоту обмена;

• сопоставление идентификаторов товаров, заказов и возвратов;

• контроль статусов;

• повторную обработку временных ошибок без дублей;

• регулярную сверку и уведомления о критичных сбоях;

• журналирование операций и понятный порядок разбора ошибок.

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