Маркетплейсы ↔ 1С
▍Двусторонняя синхронизация WB / Ozon с 1С: остатки, заказы, цены, статусы — без овер-селла.
Контекст
Продавец товаров повседневного спроса торговал на трёх площадках, а складской учёт вёл в 1С. Остатки разъезжались: менеджеры правили цены и количества руками в личных кабинетах, 1С узнавала о заказах с задержкой в часы.
Дороже всего обходился овер-селл: товар, проданный на двух площадках одновременно, приходилось отменять — это штрафы маркетплейса, падение рейтинга карточки и испорченный клиент. По условиям NDA имя компании не раскрываем.
Нас позвали закрыть это интеграцией, а не ещё одним человеком с Excel: единый контур, где 1С остаётся источником правды, а площадки получают одинаковую картину остатков за минуту.
Задача
- 01Двусторонняя синхронизация остатков между WB, Ozon и 1С с лагом меньше минуты.
- 02Заказы с площадок автоматически попадают в 1С, статусы (сборка, отгрузка, доставка) едут обратно.
- 03Цены и акции выгружаются из 1С в карточки без ручной правки в кабинетах.
- 04Защита от овер-селла: резерв остатка списывается атомарно, повторные события не дублируют заказы.
- 05Прозрачность: видно, что синхронизируется, где затык и почему, без захода в код.
Решение
Очередь как буфер между мирами
API маркетплейсов и 1С работают в разном ритме и иногда отвечают ошибками. Поставили очередь: события не теряются при сбое площадки и обрабатываются с управляемой скоростью, без перегрузки 1С.
Идемпотентность по ключу события
Каждое событие несёт стабильный ключ. Повторная доставка (а маркетплейсы её гарантируют) не создаёт второй заказ и не списывает остаток дважды — обработчик узнаёт уже виденное и тихо подтверждает.
1С как источник правды по остаткам
Через HTTP-сервисы и OData 1С отдаёт актуальный остаток по складам, а назад принимает заказы и резервы. Площадки не спорят между собой — они выравниваются на одну цифру из учёта.
Атомарный резерв против овер-селла
Продажа на одной площадке мгновенно уменьшает доступный остаток на остальных. Списание и публикация идут как одна операция, поэтому два кабинета не могут продать последнюю единицу одновременно.
Мониторинг и алерты на затыки
Дашборд показывает лаг синхронизации, очередь, повторы и расхождения остатков по складам. Если событие застряло или площадка отвечает ошибкой — приходит алерт раньше, чем это заметит покупатель.
Архитектура
Контур построен вокруг очереди: коннекторы маркетплейсов и адаптер 1С только публикуют и читают события, а вся логика синхронизации живёт в обработчиках. Это развязало площадки между собой — падение или таймаут WB не останавливает обмен с Ozon и не блокирует 1С.
Каждый обработчик идемпотентен по ключу события и пишет в 1С через HTTP-сервисы, а актуальные остатки читает по OData. Поверх — мониторинг с метриками лага, длины очереди и расхождений по складам; повторяемые ошибки уходят в ретраи с backoff, неустранимые — в карантин с алертом оператору.
Результаты
- остатки синхронны
- овер-селлов
- маркетплейса в контуре
- SLA доставки событий
Что не получилось с первого раза
- ✕Первая версия дёргала остатки по таймеру раз в 15 минут — лаг был виден глазом и овер-селл всё ещё проскакивал в часы пик. Переписали на событийную модель с очередью: остаток списывается в момент продажи, а не на следующем тике.
- ✕Недооценили повторную доставку событий: маркетплейс прислал один заказ дважды, и в 1С на тесте задвоился документ. Добавили идемпотентность по ключу и дедуп на входе — после этого повторы стали безопасны by design.
“Раньше день начинался с ручной сверки остатков и отмены случайных продаж. Теперь я открываю дашборд, вижу зелёную очередь и просто работаю. Овер-селл из ежедневной боли стал редким исключением.
Команда
Что дальше
- →Подключить четвёртую площадку в тот же контур без переписывания обработчиков.
- →Синхронизировать движение по нескольким складам и схемам FBO/FBS отдельно.
- →Автоподбор цены под правила площадок и акции прямо из 1С.
