В прошлом году к нам пришел продавец товаров для дома - около 4 500 SKU, Wildberries, Ozon, своя 1С и уверенность, что интеграция уже сделана. По факту менеджеры тратили 2-3 часа в день на сверку остатков, а отмен стало больше. Проблема была не в API. Просто никто заранее не решил, где живет реальный остаток и в какой момент товар уходит в резерв.
Если упростить, интеграция с маркетплейсами почти всегда ломается в одном и том же месте: бизнес автоматизирует обмен, но не фиксирует правила учета. В итоге система лишь быстрее разносит старые ошибки по всем каналам.
Сначала нужно разделить обмен на контуры
Связка «1С + маркетплейсы» выглядит как один проект, но системно это несколько разных контуров: остатки, цены, заказы, статусы, возвраты, справочники, сборка. У каждого своя частота, своя цена ошибки и свой момент истины.
У Wildberries и Ozon похожий фасад, но логика событий разная. Сценарий «заказ - резерв - отгрузка» нельзя просто перенести с одной площадки на другую. У нас однажды был унаследованный проект, где одинаковый доступный остаток отправлялся сразу в оба канала, а резерв в 1С появлялся с задержкой. Через 3 недели отмены выросли на 18%, хотя по бумагам интеграция считалась завершенной.
Самый дорогой вопрос в таком проекте звучит скучно: кто у вас хозяин остатка и что происходит в первые 15 минут после сбоя.
Когда ответа нет, 1С показывает одно, маркетплейс - другое, менеджер сверяет Excel, а склад работает по третьей цифре.
Первый этап должен быть скучным и коротким
Мы обычно режем запуск до ядра: номенклатура, остатки, заказы, статусы. Это дает рабочий контур за 4-6 недель, а не проект на квартал с красивыми обещаниями и ручными костылями на финише.
Самое уязвимое место - сопоставление карточек. У одного оптово-розничного клиента каталог был 3 200 SKU, и артикул в 1С, SKU маркетплейса и штрихкод не были жестко связаны. Пока люди проверяли руками, система еще держалась. После автоматизации склад начал собирать похожие позиции вместо нужных. Исправили это не «магией API», а таблицей соответствий и валидацией перед выгрузкой.
| На старте | Можно позже | Критично сразу |
|---|---|---|
| Номенклатура, остатки, заказы, статусы | Возвраты, акции, отчеты | Резервы, связка SKU, журнал ошибок |
На одном B2C-проекте такой урезанный старт убрал 57% ручных правок заказов уже в первый месяц. Причина простая: в релиз не тянули второстепенные сценарии.
Мгновенный обмен нужен не всем
Многие просят real-time синхронизацию просто потому, что «так надежнее». На практике надежнее то, что можно контролировать. Если оборачиваемость спокойная, обновление раз в 15-30 минут часто работает лучше, чем дерганый обмен без очередей и повторов.
Для ходовых SKU картина другая. Когда товар параллельно продается на сайте, в WB и Ozon, интервал в 60 минут почти гарантированно ведет к продажам сверх остатка. На проектах с плотным потоком заказов переход на 5-10 минут и отдельную логику резервирования обычно заметно снижает отмены уже в первый месяц.
если пришел новый заказ:
проверить доступный остаток в master-системе
уменьшить свободный остаток
записать резерв
отправить обновление в каналы
если отправка не удалась:
поставить событие в очередь на повтор
сохранить ошибку в журнале
Здесь систему держат три вещи: очередь, повторные попытки и идемпотентность. Если событие пришло дважды, система не должна создать второй заказ и повторно списать товар. Мы обычно собираем такой слой на Node.js 20 + NestJS, Redis и PostgreSQL 16, а 1С оставляем мастером по учету.
Коробка хороша до первого усложнения
Коробочный модуль имеет смысл, когда у вас одна 1С, один склад, типовой каталог и мало доработок. Для бизнеса с 500-800 SKU это часто самый разумный старт.
Проблемы начинаются, когда в игре несколько складов, юрлица, сайт, свои правила распределения остатков и нестандартные статусы. У нас был проект в дистрибуции косметики: 2 юрлица, 4 склада, сайт, WB, Ozon. Клиент сначала пошел в типовой модуль «для быстрого запуска». Он закрыл базовую выгрузку, а дальше начались обходы, ручные корректировки и расхождения по резервам. Через 4 месяца мы все равно вынесли обмен в отдельный сервис. Если честно, один раз мы сами слишком долго пытались дотянуть похожую коробочную схему до нужной сложности, и это было ошибкой: архитектура оказалась меньше бизнеса.
Если кроме 1С, WB и Ozon у вас есть CRM, WMS или ERP, я бы сразу смотрел в сторону промежуточного сервиса. Это уже не подключение площадки, а управляемый обмен.
Перед стартом задайте пять скучных вопросов
Вот короткий чеклист, который я бы прошел до любого договора и любой оценки:
- где живет реальный остаток по каждому SKU;
- в какой момент возникает резерв;
- как связаны артикул 1С, SKU маркетплейса и штрихкод;
- как часто обновляются остатки для медленных и быстрых товаров;
- кто и как разбирает сбой в первые 15 минут.
Если на эти вопросы отвечают общими словами, проект еще не готов к разработке. Он готов только к новым расхождениям.
Я за 20+ лет не видел интеграцию, которая вообще не падает. Зато видел много систем, где сбой обходился дешево, потому что правила были определены заранее. Перед запуском попросите команду показать не демо обмена, а путь одного зависшего заказа от ошибки до ручного восстановления - это и есть настоящая проверка.
