Единый контроль остатков: как связать сайт, склад и маркетплейсы в одну систему

Почему остатки расходятся сами по себе и что нужно сделать, чтобы товар не продавался дважды

Кому и зачем это нужно

Проблема появляется не сразу. Пока у компании один канал продаж — сайт или один маркетплейс, — остаток можно вести вручную или в простой таблице. Ситуация меняется, как только количество каналов превышает один: продавец физически не успевает вручную поддерживать актуальные цифры сразу в личном кабинете Ozon, Wildberries, Яндекс Маркета и в CMS сайта. Расхождение остатков — это не разовая техническая накладка, а системный риск, который растёт пропорционально числу площадок и обороту.

Материал полезен владельцам интернет-магазинов и селлерам, которые уже продают или планируют продавать на нескольких площадках одновременно, а также ИТ-специалистам и руководителям, которым предстоит выбрать архитектуру интеграции между 1С, сайтом и маркетплейсами.

Что такое единый остаток простыми словами

Единый остаток — это принцип, при котором реальное количество товара хранится и обновляется только в одном месте, а все остальные системы (сайт, WB, Ozon, Яндекс Маркет) получают из него актуальные цифры и никогда не считают их самостоятельно. Систему, которая играет эту роль, обычно называют мастер-системой: интеграция делает учётную систему единственным источником остатков, а продажа на любой площадке автоматически пересчитывает и рассылает актуальное количество на все остальные каналы [1]. На рынке такие решения часто и продвигаются под названием «единый остаток» — как гибкое объединение складов для разных маркетплейсов с автоматическим изменением количества везде при заказе на любой из площадок [2].

Показательный пример логики: если у продавца физически 2 единицы товара и они выставлены на двух площадках, после оформления первого заказа система обязана мгновенно уменьшить показ на второй площадке до 1 единицы, а не оставлять там прежние 2 — именно так работает механика резервирования в специализированных сервисах синхронизации [5]. Без этого шага второй покупатель успевает оформить заказ на товар, которого физически уже нет, — а дальше вступают в силу штрафы площадки.

Как устроена синхронизация технически

Любая схема единого контроля остатков строится на трёх элементах.

Источники данных. Это физический склад (или несколько складов), учётная система (1С, МойСклад и аналоги) и каналы продаж — сайт и личные кабинеты маркетплейсов. Для интернет-магазинов на 1С-Битрикс типовая схема выглядит так: в центре стоит 1С, которая знает реальное количество товара, а сайт и маркетплейсы не считают остатки самостоятельно, а лишь синхронизируются с учётной системой [4]. Каждому реальному складу должен соответствовать понятный набор виртуальных складов в кабинетах площадок; нередко один физический склад отражается сразу в нескольких «складах» личного кабинета — например, у продавца с несколькими магазинами на одной площадке, — и эти склады стоит объединять, а при отсутствии товара передавать именно ноль, а не пустое значение [18].

Событийная модель обновления. Хорошо спроектированная интеграция реагирует не по расписанию («раз в час»), а на события: любое изменение остатка — продажа, возврат, приход товара — сразу же должно попадать в мастер-систему и рассылаться на все подключённые каналы, а не просто периодически выгружаться пакетом [6]. Периодическая синхронизация (например, раз в 15–30 минут) снижает риск, но не убирает его полностью — в окно между обновлениями заказ всё ещё можно оформить на товар, которого больше нет.

Разделение статусов «резерв» и «списание». Это ключевой технический нюанс, который часто упускают при самостоятельной разработке: в момент оформления заказа товар должен переходить в статус «забронирован», уменьшая доступный для продажи остаток на всех площадках, но физически списываться со склада только после подтверждённой отгрузки; при отмене заказа бронь автоматически снимается и товар возвращается в продажу везде [6]. Без резервирования возможна обратная проблема: товар уже продан, но ещё числится доступным, пока не пройдёт полный цикл документооборота.

С точки зрения расчёта доступного количества логика одинакова для большинства схем работы маркетплейсов: доступный остаток равен физическому количеству за вычетом уже зарезервированного под заказы [15].

Российская специфика: площадки, штрафы и особенности API

Модели работы с маркетплейсами

У каждой крупной площадки есть несколько схем размещения товара, и от выбранной схемы зависит, кто отвечает за актуальность остатков:

• FBO / FBY (фулфилмент маркетплейса) — товар физически хранится на складе площадки (Ozon, Яндекс Маркет), и площадка сама отвечает за учёт наличия; продавцу нужно лишь вовремя пополнять поставки.
• FBS (фулфилмент продавца) — товар лежит на складе продавца, площадка лишь показывает остаток, который передаёт сам продавец: для моделей FBS, «Экспресс» и DBS передавать остаток нужно самому магазину, и только для товаров на складе самой площадки (FBY) она пересчитывает их сама [17].
• DBS / rFBS («Витрина») — продавец сам обрабатывает заказы и доставку и полностью отвечает за актуальность остатков, которые передаёт на площадку [11].

Именно схемы FBS и DBS создают основную нагрузку на интеграцию: за актуальность цифр в этих случаях полностью отвечает продавец, и именно здесь чаще всего возникает рассинхронизация с сайтом и другими каналами. Технически у каждой площадки для этого свои методы API: например, у Wildberries обновление остатков и работа со складами продавца вынесены в отдельные разделы публичного Marketplace API [16].

Штрафы за неактуальные остатки

Штрафы за продажу отсутствующего товара — не абстрактный риск, а конкретные и быстро накапливающиеся списания.

На Wildberries заказ, оформленный на нулевой (по факту) остаток, который продавец не успел обнулить, наказывается серьёзно: если товар вовремя не обнулить и по нему поступит заказ, штраф составит 100% от стоимости заказа, но не менее 100 ₽ за единицу товара — норма распространяется на модели «Склад WB», «Маркетплейс», «Витрина» и «Витрина Экспресс» [12]. Отдельно площадка прямо рекомендует продавцам на модели DBS указывать в остатках количество чуть меньше фактического, чтобы избежать невыполнимых заказов, при этом штраф за невыполненный заказ по этой модели может доходить до 50% стоимости товара [11]. Полный официальный перечень штрафов и удержаний Wildberries публикует для продавцов в собственной справке [10].

На Ozon система штрафов привязана к «индексу отмен» — доле отменённых по вине продавца заказов за период [7]. Чем выше индекс, тем больше процент от стоимости заказа удерживается: при индексе от 2,1 до 5% штраф за отмену составляет 4,5% от стоимости товара, при индексе от 5,1 до 10% — 9%, а при индексе выше 10% — 13% [8]. При устойчиво высокой доле отмен площадка не ограничивается денежным штрафом: с апреля 2026 года при превышении доли отмен примерно в 5% кабинет продавца автоматически перестаёт отгружать новые заказы, пока причины не будут устранены [22]. Для схемы FBO отдельно штрафуется недостача при поставке товара на склад площадки — например, за недопоставленный объём в грузоместе взимается по 5 рублей за литр с ограничением по сумме за партию [9].

Отдельная категория штрафов Wildberries связана не с отменой заказа, а со срывом уже согласованной поставки на склад: если продавец отменяет или переносит поставку менее чем за сутки до назначенного времени, с него взыскивается 25 000 рублей [21] — это подчёркивает, что контроль остатков важен не только на витрине, но и на этапе планирования пополнения склада.

Маркировка и другие особенности российского контекста

Если ассортимент подлежит обязательной маркировке (система «Честный знак»), задача синхронизации остатков усложняется дополнительным слоем данных: помимо количества нужно сопоставлять коды маркировки между учётной системой, складом и площадкой. Основная сложность здесь обычно не в самом вызове API системы маркировки, а в сопутствующих задачах — настройке криптографии для подписи запросов, сопоставлении данных между учётной системой и государственной системой мониторинга и поддержании интеграции актуальной по мере обновления документации [23].

Также стоит учитывать, что карточки товаров, по которым долго не обновляются данные об остатках, площадки могут автоматически скрывать из продажи: например, Ozon переносит такие карточки в архив [3] — то есть отсутствие синхронизации бьёт не только по риску штрафа, но и по видимости товара в каталоге.

Варианты реализации

Единый контроль остатков можно построить разными способами — выбор зависит от масштаба, числа каналов и уже используемой учётной системы.

1. Модуль или расширение для 1С. Для компаний, которые уже ведут учёт в 1С (Управление торговлей, Комплексная автоматизация, ERP, УНФ), логичный путь — подключить специализированный модуль обмена, который автоматизирует передачу заказов, остатков и цен и снижает риск ручных ошибок [19]. Для старых или доработанных версий 1С (УТ 10.3, УПП и подобных), где типовые решения маркетплейсов не работают напрямую, применяются отдельные коннекторы, которые встраиваются в имеющуюся учётную систему и обмениваются номенклатурой, ценами и остатками в едином формате, возвращая обратно заказы и документы реализации [20].

2. Облачный сервис учёта товаров (SaaS). Такие сервисы берут на себя роль мастер-системы вместо 1С или наряду с ней: они хранят остаток, автоматически пересчитывают его при заказе на любой из подключённых площадок и передают новые данные всем каналам [1]. Такой вариант обычно быстрее внедрить и дешевле поддерживать, но он менее гибок, если у компании нетиповые бизнес-процессы или сложная складская логистика.

3. Индивидуальная интеграция по API. Для крупных продавцов с нестандартной архитектурой (несколько юридических лиц, распределённые склады, собственная WMS) готовые модули могут не покрывать всех сценариев. В этом случае разрабатывается собственная интеграция, которая напрямую обращается к Seller API маркетплейсов и к учётной системе, с собственной логикой резервирования, приоритетов между складами и обработкой ошибок; работа с самим API обычно делится на блоки — работу со справочниками товаров, загрузку и обновление остатков и цен, управление заказами по разным схемам [14].

Официальная документация Ozon отдельно подчёркивает, что при работе с несколькими площадками не обязательно дублировать полные выгрузки: передавать остатки нужно только для тех товаров, по которым зафиксировано изменение количества вне платформы, а сами запросы на обновление стоит отправлять только после того, как изменения зафиксированы в базе данных продавца [13]. Это снижает нагрузку на API и уменьшает количество лишних запросов при интеграции с несколькими каналами одновременно.

Практические этапы внедрения

1. Выбрать мастер-систему. Определить, какая система будет единственным источником правды об остатках — 1С, облачный товароучёт или собственная база. Все остальные системы должны только получать данные, а не считать остаток самостоятельно.
2. Сопоставить справочники. Свести номенклатуру сайта, 1С и карточек на каждой площадке к единым идентификаторам (артикул, штрихкод, SKU) и явно сопоставить единицы измерения — расхождение в упаковках или единицах измерения — частая причина сбоев синхронизации.
3. Сопоставить склады. Каждому реальному складу продавца сопоставить соответствующие виртуальные склады в личных кабинетах маркетплейсов, включая случаи, когда несколько кабинетов на площадке физически ссылаются на одно и то же помещение.
4. Подключить API или push-уведомления. Настроить обмен остатками через официальный Seller API каждой площадки; там, где доступны push-уведомления об изменении остатка, использовать их вместо постоянных опросов, чтобы сократить задержку и число запросов.
5. Настроить резервирование заказа. Реализовать (или включить в готовом решении) логику, при которой оформление заказа немедленно уменьшает доступный остаток на всех каналах, а не только на площадке, где произошла покупка.
6. Определить неснижаемый остаток. Для товаров с высокой оборачиваемостью установить минимальный резерв или буфер, который не выставляется на продажу, — это снижает риск овербукинга при задержке синхронизации.
7. Протестировать обмен. Провести пробный заказ на каждой площадке, проверить журналы синхронизации, сверить остатки в личном кабинете и в мастер-системе, устранить расхождения, включить постоянный мониторинг ошибок обмена.

Ограничения, типичные ошибки и риски

• Периодическая синхронизация вместо событийной. Обновление остатков раз в час или раз в сутки оставляет окно, в течение которого товар может быть продан на нескольких площадках одновременно.
• Расхождение единиц измерения и артикулов. Если товар продаётся поштучно на одной площадке и упаковками — на другой, а в 1С заведён в третьей единице измерения, автоматическая синхронизация даёт неверные цифры без выхода в ошибку.
• Игнорирование резерва. Без явного разделения «зарезервировано» и «списано» возможна ситуация, когда несколько заказов на одну и ту же последнюю единицу товара успевают пройти до того, как остаток обнулится на всех площадках.
• Слишком частые запросы к API. Полная выгрузка всех остатков по расписанию вместо передачи только изменившихся позиций создаёт лишнюю нагрузку на API и повышает риск попасть в лимиты запросов площадки.
• Отсутствие буфера (неснижаемого остатка). При высоком темпе продаж даже секундная задержка синхронизации способна привести к превышению фактического наличия — отсюда рекомендация ряда площадок сознательно занижать выставляемый остаток.
• Отдельный слой маркировки. Для маркированных товаров ошибка в передаче кодов «Честного знака» приводит к отдельным штрафам и блокировкам, не связанным напрямую с количеством товара, и требует отдельного контроля помимо количественного учёта.
• Ручной перенос заказов. Если заказы с площадок не попадают в мастер-систему автоматически, менеджеры физически не успевают вовремя корректировать остаток при высоком потоке заказов.

Как выбрать решение под свой масштаб

Если компания работает с одной-двумя площадками и типовой номенклатурой без сложной складской логистики, чаще всего достаточно готового облачного сервиса синхронизации или стандартного модуля для 1С — их настройка не требует программиста и занимает от нескольких минут до нескольких дней. Если у компании несколько юридических лиц, распределённые склады, нестандартные схемы резервирования или доработанная (устаревшая) версия 1С, готовые модули могут не покрыть всех сценариев, и тогда оправдана индивидуальная разработка или доработка интеграции под конкретные бизнес-процессы. Не всегда сложная разработка обязательна: часто задачу закрывает правильная настройка уже имеющегося модуля и наведение порядка в сопоставлении справочников и складов, без написания кода с нуля.

Как может помочь «Пятый фактор»

Основная сложность подобных интеграций редко сводится к самому факту подключения к API маркетплейса — она обычно кроется в сопоставлении справочников и номенклатуры между 1С, сайтом и личными кабинетами площадок, в корректной обработке ошибок обмена и в поддержании интеграции актуальной по мере изменения документации API. Команда «Пятого фактора» может изучить текущую схему учёта остатков, оценить, достаточно ли для задачи готового модуля или сервиса синхронизации, либо требуется индивидуальная разработка, и помочь с архитектурой обмена данными между 1С (или другой учётной системой) и каналами продаж — включая случаи, где к количественному учёту добавляется маркировка товаров и обмен с государственными системами.

Вывод

Расхождение остатков между сайтом, складом и маркетплейсами — не разовая техническая недоработка, а системный риск, который растёт вместе с числом каналов продаж. Штрафы площадок за отсутствие товара исчисляются процентами от стоимости заказа и способны привести к блокировке склада при повторяющихся нарушениях, поэтому единый контроль остатков стоит рассматривать не как техническую роскошь, а как часть базовой финансовой дисциплины бизнеса. Универсального решения нет: выбор между готовым сервисом, модулем для 1С и индивидуальной интеграцией зависит от масштаба компании, числа площадок и особенностей уже выстроенных процессов — но в любом случае в основе решения лежит один и тот же принцип: одна система хранит правду об остатке, а все остальные лишь синхронизируются с ней.

Источники

[1] blog.albato.ru — МойСклад и маркетплейсы: синхронизация остатков и заказов — https://blog.albato.ru/moysklad-i-marketplejsy-sinhronizaciya-ostatkov-i-zakazov/

[2] insales.ru — Управление продажами на маркетплейсах от inSales — https://www.insales.ru/page/marketplace

[3] 1c-usoft.ru — Управление остатками товаров на маркетплейсах из 1С — https://www.1c-usoft.ru/article/upravlenie-ostatkami-tovarov-na-marketpleysakh-iz-1s/

[4] it-vector.group — Синхронизация остатков 1С-Битрикс: единый склад для сайта и маркетплейсов — https://it-vector.group/news/sinkhronizatsiya-ostatkov-1s-bitriks-kak-nastroit-edinyy-sklad-dlya-sayta-i-marketpleysov-/

[5] uniseller.io — Управление остатками на маркетплейсах: синхронизация из единого окна — https://uniseller.io/blog/upravlenie-ostatkami-na-marketpleysakh-edinoe-okno/

[6] uniseller.io — Синхронизация остатков на маркетплейсах: как избежать штрафов — https://uniseller.io/blog/sinkhronizaciya-ostatkov-marketpleysy/

[7] selsup.ru — Штрафы Ozon: полный обзор балльной системы и удержаний — https://selsup.ru/blog/shtrafy-ozon-polnyj-obzor-ballnoj-sistemy-i-uderzhanij/

[8] sellplus.ru — Штрафы Ozon для продавцов: полный гайд по системе санкций — https://sellplus.ru/blog/klientam/shtrafy-ozon-dlya-prodavtsov-polnyy-gayd-po-sisteme-sanktsiy/

[9] wildcrm.ru — Штрафы Озон — какие бывают и сколько — https://wildcrm.ru/blog/indicators/tpost/9m25sanjj1-shtrafi-na-ozon-dlya-sellerov-polnoe-ruk

[10] seller.wildberries.ru — Штрафы, удержания и другие взыскания для продавцов на Wildberries — https://seller.wildberries.ru/instructions/ru/ru/material/fines-retentions-and-other-penalties-for-sellers

[11] seller.wildberries.ru — Отмена заказов, возвраты и штрафы при работе по модели «Витрина» (DBS) — https://seller.wildberries.ru/instructions/ru/ru/material/order-cancelling-and-fines-in-dbs

[12] cdek-busines.ru — Штрафы WB для продавцов в 2026 г. — как их избежать — https://cdek-busines.ru/marketplaces/wildberries/shtraf

[13] dev.ozon.ru — Рекомендации по управлению остатками в Seller API — https://dev.ozon.ru/start/299-Rekomendatsii-po-upravleniiu-ostatkami-v-Seller-API/

[14] dev.ozon.ru — Как работает Seller API: авторизация, настройка и первые шаги — https://dev.ozon.ru/start/297-Kak-rabotaet-Seller-API-avtorizatsiia-nastroika-i-pervye-shagi/

[15] habr.com — Инструмент для контроля остатков на складе Озон через API и Google-таблицы — https://habr.com/ru/articles/672194/

[16] openapi.wildberries.ru — Публичное API Marketplace Wildberries (разделы «Остатки», «Склады») — https://openapi.wildberries.ru/marketplace/swagger/api/ru/swagger.yaml

[17] yandex.ru — Передача остатков через API. Партнёрский API Яндекс Маркета — https://yandex.ru/dev/market/partner-api/doc/ru/step-by-step/stocks

[18] yandex.ru — Как управлять остатками. Справка Маркетплейса Маркета — https://yandex.ru/support/marketplace/assortment/operations/stocks.html

[19] 1cbit.ru — Как настроить интеграцию между 1С:Управление торговлей и маркетплейсами — https://www.1cbit.ru/blog/kak-nastroit-integratsiyu-mezhdu-1s-upravlenie-torgovley-i-marketpleysami/

[20] rdv-market.ru — Интеграция 1С:УТ с маркетплейсами: инструменты и возможности — https://rdv-market.ru/press-center/blog/integratsiya-1c-upravlenie-torgovley-s-marketpleysami/

[21] e-kontur.ru — Штрафы Wildberries: полное руководство для селлеров — https://e-kontur.ru/enquiry/2450/shtrafy-wildberries

[22] vc.ru — Полный справочник штрафов Ozon 2026: за что, сколько и как не попасть — https://vc.ru/marketplace/2884664-shtrafy-ozon-spravochnik-sanktsiy

[23] 5factor.ru — True API «Честного знака»: подключение и УКЭП — https://5factor.ru/resources/true-api-chestnogo-znaka-podklyuchenie-avtorizacziya-i-obmen-dannymi