Остатки Ozon обновляются сами, если склад отдаёт данные по API, а планировщик раз в 15 минут пишет их в метод обновления остатков Ozon Seller API. На один канал такая связка поднимается за один-два дня. Ниже — логика обмена, частота, поведение при сбоях и схема для сайта, CRM и нескольких маркетплейсов сразу.
Почему ручной ввод остатков ведёт к овербукингу и штрафам Ozon
Ручной ввод ломается на арифметике, а не на дисциплине. Каталог из 500 позиций и три канала продаж — сайт, Ozon, Wildberries — дают 1500 значений. Их нужно переписать после каждой крупной отгрузки.
При 10 секундах на позицию (замер по нашим проектам) полный круг занимает 4,2 часа: 1500 × 10 с = 15 000 с. Столько времени у менеджера склада не бывает никогда.
В итоге обновляют выборочно: ходовые артикулы утром, остальное «когда будет пауза». Именно на необновлённых позициях и возникает овербукинг. Товар продан на сайте, но карточка Ozon всё ещё показывает четыре штуки. Покупатель оформляет заказ, а отгрузить нечего.
Дальше начинается то, что дороже недополученной выручки. Отмена по вине продавца портит показатели аккаунта. Покупатель получает отказ вместо товара и в следующий раз выбирает другого продавца.
Есть и обратная ошибка — страховочный буфер. Продавец руками занижает остаток, чтобы не уйти в минус. На пиках он теряет продажи: каждая единица уходит за часы, а карточка показывает меньше, чем лежит на полке. Автоматический обмен убирает обе крайности, и буфер становится ненужным.
Как устроена техническая логика синхронизации: API, вебхуки, частота обновления
Любая синхронизация остатков держится на трёх вопросах: откуда берём число, куда пишем и как часто. Источником выступает одна система — 1С, МойСклад, таблица склада или база на Supabase. Если источников два и они спорят, овербукинг вернётся уже на уровне логики.
Ozon принимает остатки через Seller API: отдельный метод обновляет количество по артикулу и складу, документация метода лежит в справочнике Ozon Seller API. Ключевой момент — привязка вашего артикула к offer_id в кабинете Ozon. Таблица соответствий артикулов — это половина проекта. Хранить её лучше в базе, а не в голове менеджера.
Вебхуки работают в обратную сторону: Ozon сам сообщает о новом заказе, и сценарий сразу списывает резерв со склада. Остатки же уходят по расписанию: источник обычно не умеет сигнализировать о каждом изменении. Рабочая частота по нашим проектам — раз в 15 минут для обычного ассортимента.
Сценарий не должен отправлять весь каталог целиком каждый цикл. Дельта-обмен сравнивает текущий остаток с последним отправленным и передаёт только изменившиеся артикулы. Это экономит лимиты API: вместо 1500 значений уходят единицы строк. Логика поведения при ошибках описывается один раз: повтор с задержкой, очередь неотправленных значений, уведомление в Telegram при трёх неудачах подряд.
Материал по теме: выход на Ozon: настройка кабинета и синхронизация с 1С
Что кроме остатков стоит синхронизировать: цены, заказы, себестоимость
Остатки — первый поток, но не единственный. Цены живут по тем же правилам. При ручной переоценке акция на сайте уже кончилась, а на Ozon товар месяц уходит с дисконтом. Один прайс в источнике и автоматическая отправка в каждый канал снимают вопрос.
Заказы нужны в обратную сторону. Сценарий забирает новые отправления из Ozon, создаёт сделку в CRM и списывает резерв. Тогда сайт и Wildberries видят уменьшившийся остаток через тот же цикл в 15 минут. Без этого потока синхронизация остаётся односторонней и на пиках всё равно даёт минус.
Третий поток — себестоимость и комиссии. Когда в базу вместе с заказом попадают цена продажи, закупочная цена и удержания площадки, маржа по артикулу считается без ручной выгрузки отчётов. Продавец видит, какие позиции на Ozon работают в убыток после логистики. Такие артикулы снимают с продвижения, а не гадают по общему обороту.
Четвёртый поток — статусы и контент: габариты, фото, описания. Их обычно синхронизируют реже, раз в сутки: цена ошибки здесь ниже, чем у остатка.
Готовые сервисы синхронизации и когда их возможностей уже не хватает
МойСклад, Мультисклад и подобные коробки закрывают типовой случай: один склад, два-три маркетплейса, стандартная схема FBS. Подключение делают без программиста, платить нужно по подписке. Пока связка типовая, брать что-то другое смысла нет.
Сложности начинаются на нестандартной логике. Ниже — где именно коробка упирается в потолок по нашим проектам автоматизации магазинов.
| Задача | Коробочный сервис | Сценарий на n8n |
|---|---|---|
| Один склад, Ozon и WB, FBS | Закрывает полностью | Избыточен |
| Остаток считается по формуле с резервами и бонусами | Формулу не задать | Любая логика расчёта |
| Сайт на Tilda, CRM и 1С в одной цепочке | Часть систем без коннектора | Любой HTTP-источник |
| Свои правила при сбое API и алерты в Telegram | Фиксированное поведение | Настраивается вручную |
Граница видна по таблице. Коробка работает, пока ваша схема совпадает с её моделью данных. В день, когда остаток нужно считать по своей формуле, придётся либо ломать процесс под сервис, либо собирать обмен самому.
Синхронизация остатков на n8n: связка сайта, CRM и маркетплейсов
n8n собирает обмен из блоков: расписание, HTTP-запросы к API, база для хранения соответствий и очереди, ветвление по условиям. Вы получаете сценарий, который читает остаток там, где он реально лежит. Пишет он это число туда, куда нужно вам, без ограничений чужой модели данных.
Рабочая схема выглядит так. Планировщик раз в 15 минут забирает остатки из источника. Сценарий считает доступное количество по вашей формуле: минус резервы под сборку, минус товар в пути, минус витрина в офлайн-точке. Затем он сравнивает результат с последним отправленным значением и отправляет только дельту в Ozon, Wildberries и на сайт.
Поверх этого добавляются правила, которых нет в коробках. Дефицитным артикулам можно задать более частый цикл, а неликвиду — раз в сутки. Товар с одной оставшейся единицей можно оставить в продаже только на Ozon, если там маржа выше. Всё это — условия в одном сценарии, а не запрос на доработку в поддержку сервиса.
Хранилище стоит вынести отдельно. В таблице лежат соответствия артикулов, история отправленных значений и лог ошибок. Тогда при расхождении вы видите, какое число и когда ушло на площадку, а не спорите с поддержкой наугад. Как связать n8n с базой, мы разбирали в гайде по автоматизации на n8n и Supabase.
Запускать сценарий лучше на своём сервере. Тогда лимиты облачного тарифа не режут частоту обмена, а данные о заказах и себестоимости остаются у вас.
Сценарии, где автоматизация остатков спасла продажи на пике
Первый сценарий из наших проектов (без раскрытия клиента) — магазин на Tilda с бонусной программой. Остаток на витрине считался не как число на складе: из него вычитался товар, зарезервированный под оплату бонусами. Коробочный сервис такую формулу не принимал.
Поэтому расчёт делает сценарий. Он собирает данные из базы заказов и бонусного счёта, а готовый итог отдаёт на сайт и в маркетплейс.
Второй сценарий — продавец с одним физическим складом и тремя каналами. До автоматизации остатки правили вечером, и утренние заказы на Ozon по проданным позициям приходилось отменять. После перехода на обмен раз в 15 минут карточка перестаёт показывать проданный товар: остаток уходит в ноль до того, как придёт следующий заказ.
Третий сценарий — распродажа, когда дневной оборот вырастает в несколько раз. Здесь важна не средняя частота, а поведение на границе. Последняя единица должна исчезнуть из карточки до того, как её купят второй раз. Дельта-обмен с приоритетом для дефицитных позиций снимает эту проблему.
Общий знаменатель у всех трёх — единый источник числа и понятное поведение при сбоях. Сколько стоит такая автоматизация целиком, мы посчитали в разборе бюджета автоматизации интернет-магазина.
Частые вопросы
Сколько времени занимает настройка автоматической синхронизации остатков Ozon?
Один канал с одним складом — один-два дня. Нужно получить ключи Seller API, сопоставить артикулы с offer_id и собрать сценарий с расписанием. Потом обмен проверяют на десятке позиций. Основное время уходит не на сценарий, а на таблицу соответствий. Если в источнике артикулы записаны иначе, чем в кабинете Ozon, их один раз приводят к одному виду. Связка сайта, CRM, 1С и двух маркетплейсов с формулой расчёта остатка занимает одну-две недели по нашим проектам.
Можно ли синхронизировать остатки сразу с несколькими маркетплейсами?
Да, и это основной аргумент против ручного ввода. Источник остаётся один, а сценарий после расчёта доступного количества рассылает значение параллельно в Ozon, Wildberries, на сайт и в CRM. Каждой площадке нужен свой метод API и своя таблица соответствий артикулов, но логика расчёта пишется один раз. Отдельно задаются правила распределения: например, последнюю единицу отдавать только каналу с самой высокой маржой.
Что произойдёт, если API Ozon временно недоступен во время синхронизации?
При корректно собранном сценарии — ничего критичного. Неудачная отправка попадает в очередь, сценарий повторяет её с растущей задержкой и продолжает работать с остальными каналами. Последнее успешно отправленное значение хранится в базе, поэтому после восстановления доступа уходит актуальная дельта, а не устаревший срез. Если три попытки подряд не проходят, приходит уведомление в Telegram — вы узнаёте о проблеме до первой отмены заказа, а не из отчёта по показателям.
Нужна ли программная разработка или можно обойтись no-code инструментами?
Для обмена остатками хватает no-code: в n8n расписание, HTTP-запросы и ветвление собираются мышью, без написания сервиса. Код появляется точечно — короткое выражение для расчёта доступного количества или разбор нестандартного ответа API. Опыт работы с API всё же нужен: нужно читать документацию площадки, понимать лимиты запросов и структуру полей. Похожая задача на стороне другого маркетплейса разобрана в материале про парсер Wildberries без программирования.
Что делать дальше
Начните с инвентаризации потоков. Выпишите, где лежит настоящий остаток, какие каналы его показывают и кто переносит числа руками. Затем соберите обмен для одного канала с циклом 15 минут. Проверьте его на группе ходовых артикулов: расхождения видно до подключения остальных площадок.
Если ваша схема не влезает в коробочный сервис, посмотрите нашу услугу автоматизации e-commerce. Мы соберём обмен остатками, ценами и заказами между складом, CRM и маркетплейсами. Карточки будут показывать то же количество, что лежит на полке.
