Автоматизация управления остатками на маркетплейсах: зачем это нужно, как настроить
Торговля на маркетплейсах требует строгого учета остатков: отмены заказов, штрафы площадок и дефицит ходовых позиций напрямую бьют по прибыли и рейтингу. Как только продаж становится больше одного канала, вручную свести остатки уже невозможно. Разберем, зачем нужна автоматизация, что такое единый пул остатков, как пошагово настроить синхронизацию и не потерять деньги на оверселле.
Зачем автоматизировать управление остатками
Ручное обновление остатков тормозит рост и создает цепочку типовых проблем.
Заказы на нулевой остаток и штрафы. Покупатель заказывает товар, которого на складе уже нет, — заказ отменяется, а маркетплейс штрафует за невыполнение и роняет карточку в выдаче. Автоматизация отслеживает количество в реальном времени и не дает продать то, чего нет.
без Excel и хаоса
- QR-код у каждого номера
- Горничные берут белье со склада в 2 клика
- Чек-листы по номерам и зонам
Быстрый запуск для отелей и гостиниц
Оверселл при нескольких каналах — «окно хаоса». Это главная боль мультиканальной торговли: товар продали на Ozon, а на Wildberries он еще висит в наличии — приходит второй заказ на ту же единицу, дальше отмена и штраф. Пока остатки на площадках не синхронизированы за секунды, каждое такое «окно» между продажей и обновлением превращается в потерю.
Недополученная прибыль. Отсутствующий на витрине товар не приносит доход: пока селлер не обновит остаток, продажи стоят, и для ходовых позиций теряется выручка каждый час простоя.

-
87%
видят результат в первый месяц -
31%
среднее сокращение издержек -
42%
рост скорости операций -
18%
увеличение оборота

Ручной труд и ошибки. Обновление остатков вручную — рутина на часы, особенно при большом ассортименте, с высоким риском указать количество больше или меньше реального. Автоматика делает это точно и мгновенно, освобождая менеджеров.
Единый пул остатков: мастер-система как источник правды
Основа автоматизации — единый пул остатков. Вместо того чтобы вести количество отдельно в каждом кабинете, все каналы получают данные из одной мастер-системы учета — это может быть 1С, товароучетный сервис или облачный SaaS. Именно она становится единственным источником правды: любое движение (продажа, приемка, возврат, списание) сначала меняет остаток в мастер-системе, а она уже раздает актуальное количество на Ozon, Wildberries, Яндекс Маркет и другие площадки.
Такой подход убирает «окно хаоса»: физическая единица товара не может быть продана дважды, потому что резерв и пересчет происходят централизованно, а не в каждом кабинете по отдельности.
Как настроить синхронизацию: пошагово
Настройка мультиканальной синхронизации не зависит от площадки и строится по одной схеме:
- Выбрать мастер-систему учета — 1С, товароучетный сервис или облачный SaaS, где будет храниться единый пул остатков.
- Подключить каналы через API — Wildberries, Ozon, Яндекс Маркет и другие площадки.
- Загрузить каталог товаров в мастер-систему.
- Сопоставить артикулы и SKU между системой учета и кабинетами площадок — без корректного маппинга остатки будут «уезжать» не на те карточки.
- Настроить правила резервов и распределения остатков между схемами FBO/FBS/DBS, чтобы одна единица не предлагалась к продаже в двух местах сразу.
После этого синхронизация идет автоматически: продажа в любом канале мгновенно уменьшает единый пул и обновляет остатки во всех остальных.
Схемы работы: FBO, FBS и DBS
Модель фулфилмента напрямую определяет, кто и как обновляет остатки.
FBS (Fulfillment by Seller). Товар хранится у продавца, при заказе он сам комплектует и передает отправление. Остатки полностью зависят от внутреннего учета, поэтому нужна моментальная синхронизация: когда единицу продали на одном канале, на остальных остаток должен обновиться за секунды.
FBO (Fulfillment by Operator). Товар лежит на складе маркетплейса, продавец поставляет партии, а площадка отвечает за хранение, сборку и доставку. Остатки обновляются системой площадки после приемки, а вывод товара запрашивается через кабинет или API.
DBS (Delivery by Seller). Витрина на маркетплейсе, но хранение и доставка — на стороне продавца. Как и в FBS, остатки завязаны на собственный учет, поэтому единый пул критичен.
Часто селлер работает в нескольких схемах одновременно — тогда правила распределения остатков между FBO/FBS/DBS в мастер-системе особенно важны, иначе один и тот же товар задваивается.
Механика синхронизации на примере
Проще всего понять на одной единице товара. Допустим, на складе 2 штуки и два магазина — Ozon и Wildberries. После первичной выгрузки на обеих площадках висит по 2 штуки. Приходит заказ на Wildberries — мастер-система мгновенно ставит резерв на 1 единицу, пересчитывает пул и отправляет на Ozon обновленный остаток: 1 штука. Покупатель на Ozon все еще видит товар в наличии, но не может купить больше, чем есть физически. Именно так резервирование закрывает «окно хаоса».
Методы обновления остатков (на примере Ozon)
На уровне конкретной площадки остаток можно обновлять четырьмя способами — покажем на Ozon.
- Вручную — в кабинете продавца найти карточку, изменить значение, сохранить. Без технических навыков, но неэффективно при большом ассортименте и частых изменениях.
- Через шаблон Excel — скачать шаблон из кабинета, заполнить артикул, штрихкод и количество, загрузить обратно. Требует аккуратности, не годится для оперативного обновления в реальном времени.
- Через API — изменения передаются автоматически, синхронизация мгновенная, риск ошибок минимален. Нужна техническая настройка.
- Через мобильное приложение — Ozon Seller Mobile удобен для точечных правок «в пути», но не для массового обновления.
Чтобы снять товар с продажи, остаток обнуляют любым из способов. Важно: при FBO обнуление в кабинете лишь заблокирует новые заказы, но физически не вернет товар со склада площадки — для этого нужна распродажа или возврат партии.
Типичные ошибки: неверные штрихкоды или артикулы в Excel-файле, неправильный расчет доступного остатка (не учтен товар в пути или в резерве), путаница между остатками FBS и FBO, игнорирование задержки отображения данных после загрузки. Большинство из них исчезает при переходе на единый пул и API-синхронизацию. Где еще селлеры теряют деньги на складе — разобрано в материале где селлеры теряют прибыль при работе с маркетплейсами.
Как выбрать решение для синхронизации
Инструмент подбирают под масштаб и модель работы.
Самописные решения гибкие и дают контроль над данными, но требуют IT-команды, крупных вложений в разработку и поддержку и часто уступают готовым сервисам по стабильности.
Облачные сервисы работают через веб-интерфейс, синхронизируют остатки в реальном времени, легко настраиваются, обновляются автоматически и имеют гибкие тарифы — оптимальны для большинства селлеров.
Модули интеграции с 1С связывают складскую программу и площадки: изменения в 1С передаются на Ozon, Wildberries и другие маркетплейсы. Подходят компаниям с налаженным учетом в 1С, но требуют квалификации для настройки.
Отдельно стоит настроить точку заказа — минимальный уровень остатка, при котором пора отгружать новую партию. Ее расчет критичен для FBS: ошибки ведут к дефициту или излишкам. Как прогнозировать спрос и не замораживать деньги в излишках — в статье как прогнозировать продажи на маркетплейсах. Если склад перестает справляться с ростом заказов, поможет разбор как масштабировать продажи, когда склад не справляется, а базовые принципы учета для площадок — в материале про складской учет для маркетплейсов.
Управление остатками через Складолог
Складолог — универсальное решение для синхронизации остатков на Ozon, Wildberries, Яндекс Маркет и других площадках. Данные из учетной системы продавца передаются на площадки автоматически, изменения на складе мгновенно отражаются во всех каналах, а ручное обновление и риск продажи отсутствующего товара уходят. Для ходовых позиций настраиваются уведомления о критическом запасе и автозаказ поставщику по достижении минимума. Мобильное приложение позволяет вести приемку, перемещение и инвентаризацию со смартфона, а отчеты по оборачиваемости помогают выявлять неликвиды и решать, что поставлять, а что выводить из продажи. Внедрение быстрое, без сложного ПО и долгого обучения.










