- У нас два маркетплейса, один склад и 1С. Почему остатки все равно расходятся?
- Как часто обновляете?
- Раз в 30 минут по cron.
- Пока заказов мало, этого хватает. В пике это уже отмены и потерянная выручка.
Я не раз видел такую схему у продавцов, которые выросли быстрее своей учетной логики. Когда в связке есть Ozon, Wildberries, 1С и хотя бы несколько ходовых SKU, вопрос уже не в том, есть ли доступ к API. Вопрос в деньгах: сколько заказов бизнес успевает обработать до того, как остаток устареет.
API передает данные, но не решает конфликт логики
Фраза «API - это провод, а не сама синхронизация» точно описывает проблему. Провод можно проложить быстро. Но если одна система считает товар зарезервированным, вторая - доступным, а третья еще не получила отмену, ошибки появятся даже при идеальном канале связи.
Рабочая схема строится вокруг событий: заказ создан, резерв поставлен, статус изменен, отгрузка подтверждена, отмена принята. Если этот список не описан заранее, Ozon, WB и 1С начинают жить по своим правилам. Обычно это проявляется не в день запуска, а через неделю - на возвратах, дублях и частичных отгрузках.
У нас был проект в дистрибуции бытовых товаров: один склад, 1С, два канала продаж. Остатки обновлялись раз в полчаса. После перехода на webhook + polling и буфер остатков 2-5% отмены по отсутствию товара снизились на 68% за 5 недель. Давайте посчитаем: если магазин терял хотя бы 120 заказов в месяц со средним вкладом 900 ₽ на заказ, это 108 000 ₽ потерь ежемесячно только на отменах.
Обычно ломается не обмен, а данные внутри учета
Первая тихая проблема - SKU. Один и тот же товар может продаваться поштучно, коробкой и набором, а в 1С идти под другим кодом. Если нет таблицы маппинга, списание формально проходит, но фактический остаток искажается.
Вторая проблема - идемпотентность. Повторный запрос не должен создавать второй заказ или второй резерв. Иначе система выглядит почти рабочей, но через несколько дней менеджеры уже разбирают минусы по складу вручную.
CTO логистической платформы однажды точно это сформулировал: самая дорогая ошибка в интеграции - тихое расхождение данных. Оно не падает с ошибкой, оно просто ест маржу.
На проекте с товарами для дома продавались и отдельные единицы, и наборы по 3 штуки. Поштучные остатки списывались верно, а наборы не пересчитывались. После появления отдельного слоя маппинга SKU и правил для комплектов ручные корректировки сократились примерно на 40%, а расхождения по остаткам - с 7,4% до 1,1%.
Мгновенная синхронизация нужна реже, чем кажется
Бизнес часто просит обновление в реальном времени. На практике ему обычно нужна предсказуемая обработка без потери событий. Если внутренняя 1С нестабильна, мгновенная доставка только быстрее разносит ошибку по всем каналам.
Мы пробовали строить обмен только на событиях. На одном проекте это не сработало: 1С дорабатывали почти каждую неделю, webhook приходил быстро, а обработчики внутри учета периодически ломались. После перехода на гибридную схему система стала медленнее на пару минут, но заметно надежнее.
Рабочий контур для SMB в 2026 году у нас обычно такой:
- заказ создан - получаем сразу
- резерв и списание - проводим сразу
- остатки - перепроверяем каждые 3-5 минут
- статусы доставки - по событию и контрольной сверке
Цифры говорят просто: если синхронизация занимает 1-3 минуты вместо 15-20 минут, окно для оверселлинга сжимается в несколько раз. Это уже влияет на P&L, а не только на удобство команды.
Между маркетплейсом и 1С почти всегда нужен промежуточный слой
Прямая связка Ozon -> 1С или WB -> 1С выглядит дешево только в стартовой смете. Потом появляются ретраи, дубли, разные форматы статусов, лимиты запросов, и код обмена постепенно превращается в набор исключений. TCO у такой «экономии» быстро растет: больше ручной работы, больше инцидентов, больше часов разработчиков на разбор.
Обычно мы ставим слой интеграции: нормализация событий, очередь, журнал обработки, повторная обработка сбойных сообщений. Для такого контура часто хватает Node.js 20 + NestJS, PostgreSQL 16 и RabbitMQ или Redis Streams. Малому бизнесу тяжелая шина данных чаще всего не нужна.
{
"event": "order.created",
"source": "ozon",
"external_id": "OZ-78453321",
"idempotency_key": "ozon:order:78453321:v1",
"items": [
{ "sku": "KIT-102", "qty": 1 }
],
"created_at": "2026-02-14T10:21:00Z"
}
На одном проекте после такой схемы заказ попадал в учетную систему за 1-3 минуты вместо 15-20 минут. Потерянные обновления почти исчезли, потому что событие можно было переобработать без ручного ремонта базы.
Коробка, кастом и главный вопрос перед стартом
Если у вас один склад, простые товары и нет комплектов, готовый коннектор часто окупается быстрее. Когда появляются несколько складов, своя ERP, частичные отгрузки и сложные резервы, коробка начинает обходиться дороже, чем казалось на старте.
Я бы перед оценкой проекта проверил пять вещей:
- где источник истины по остаткам
- есть ли маппинг SKU
- как обрабатываются повторы событий
- какой допустим SLA на заказ
- что происходит при сбое обмена
Мы один раз ошиблись и согласились считать маркетплейс источником истины сразу по остаткам и статусам. Через 2 недели на возвратах и частичных отменах получили лишние резервы и переделывали логику. Такие договоренности лучше фиксировать до старта, потому что код сам по себе хаос не исправляет.
В ближайшие 6-12 месяцев рынок еще сильнее уйдет в гибридные схемы: события для критичных операций и регулярная сверка для контроля. Выиграют не те, кто обновляет остатки «мгновенно», а те, кто может за 10 минут понять, где потерялся заказ и сколько денег это уже стоит.
