Единые остатки для сайта, Wildberries и Ozon без перепродаж

Единые остатки для сайта, Wildberries и Ozon — это не «одна цифра во всех каналах», а схема, в которой у остатка есть один главный источник, каждый канал видит не физический, а доступный остаток, резерв создаётся в понятный момент, а отмены и возвраты возвращают товар в продажу по правилу. Перепродажа — продажа одной и той же единицы двум покупателям — возникает не из-за «плохой интеграции», а из-за интервала между событием и его доставкой в другие каналы; избежать перепродаж и потерь можно, только признав этот интервал и спроектировав поведение системы внутри него.

Статья для компаний, которые продают один товарный запас через несколько каналов и сталкиваются с отменами, задержками обмена и расхождениями. Разбираем, чем физический остаток отличается от доступного, где должен находиться главный источник данных, как сопоставлять SKU и комплекты, когда создавать резерв, как обрабатывать отмены, возвраты, FBS и FBO, что делать с задержками и сбоями API, как находить расхождения, как перейти на новую схему без остановки продаж и что включить в приёмку. Речь о текущем учёте запасов, а не о прогнозе спроса и закупках — это отдельная тема. И мы нигде не обещаем «мгновенный обмен»: у площадок есть лимиты, и правильная схема строится вокруг них.

Чем физический остаток отличается от доступного?

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

В складском учёте это разделение формализовано. В МоемСкладе показатели строятся на трёх сущностях: остаток — фактическое количество на складе по проведённым документам, резерв — часть остатка, обещанная покупателю, но ещё не отгруженная, ожидание — товар, который должен поступить, но ещё не оприходован; доступное количество считается как остаток плюс ожидание минус резерв (справка МоегоСклада, проверено 31 октября 2026). В 1С логика та же, различаются названия регистров и механика резервирования в конкретной конфигурации.

Для многоканальных продаж формулу нужно уточнить. В каналы передаётся не «доступно» целиком, а доступное к продаже в этом канале:

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

Отдельный вопрос — ожидание. Включать товар в пути в доступный остаток можно только если канал умеет показывать срок и покупатель это принимает. Для сайта это реализуемо статусом «под заказ, отгрузка через N дней»; для FBS на площадках — нет, там срок сборки фиксирован правилами площадки, и товар в пути продавать нельзя.

Где должен находиться главный источник данных?

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

На странице Like Sites про магазин со складом это сформулировано как первый модуль решения — документально зафиксировать, какая система является источником истины по остаткам и ценам, и что происходит при расхождении, — и как первый вопрос в их же блоке ответов: мастер-источник находится там, где остаток меняется физически; если источников несколько, выбирается один и описывается поведение при расхождении с остальными (страница «Интернет-магазин с собственным складом», проверено 31 октября 2026).

Из этого следует архитектура из трёх слоёв:

1. Источник истины — учётная система. Здесь живут физический остаток, резервы, документы движения.
2. Интеграционный слой — отдельный сервис или модуль, который считает доступный остаток по каналам, применяет буферы и квоты, ведёт очередь обновлений и журнал. Он может быть частью обмена с 1С, частью платформы магазина или отдельной службой.
3. Каналы — сайт, Wildberries, Ozon, оптовый портал. Они получают доступный к продаже остаток и возвращают заказы.

Ozon в своих рекомендациях по управлению остатками прямо советует хранить актуальные остатки в собственной базе данных или WMS, передавать на площадку только изменения, зафиксированные вне Ozon, и отправлять обновление лишь после того, как изменение записано в вашей базе (Ozon for dev, рекомендации по управлению остатками, 9 августа 2024). Это и есть описание интеграционного слоя: площадка не хочет быть источником истины и говорит об этом прямо.

Три типичные ошибки при выборе источника:

• Несколько источников без приоритета. Остатки частично в 1С, частично в таблице, частично «в голове кладовщика». Сначала один источник, потом интеграция — иначе интеграция будет транслировать противоречия.
• Сайт как источник. Удобно на старте: там уже есть каталог и остатки вводятся вручную. Но при первом же заказе с площадки сайт о нём не узнает.
• Площадка как источник. Селлер, который начинал на Wildberries, нередко считает остаток в кабинете «настоящим». Это работает только при одном канале и схеме FBO.

Как именно устроен регулярный обмен остатками с 1С — какие регистры, с какой периодичностью, в каком формате — описано на странице интеграция интернет-магазина с 1С; для учёта в МоемСкладе — на странице интеграция с МоимСкладом. В этой статье обмен рассматривается как данность: источник есть, вопрос — что и как из него передавать.

Как сопоставлять SKU, варианты и комплекты?

Вторая причина расхождений, которую находят почти на каждом проекте, — одна и та же единица товара называется по-разному в разных системах, и интеграция сопоставляет её неверно или не сопоставляет вовсе.

У каждого канала своя модель идентификаторов. У Wildberries карточка идентифицируется артикулом WB (nmID), объединённые карточки — общим imtID, а остатки задаются не на карточку, а на размер — по ID размера chrtID, которому соответствуют один или несколько баркодов; баркод при этом является ID размера товара у продавца, и даже безразмерный товар имеет баркод (WB API, гайд «Работа с товарами», обновлён 21 апреля 2026). У Ozon — свой идентификатор товара и артикул продавца (offer_id), остатки задаются парой «товар — склад». В 1С — номенклатура и характеристики, в МоемСкладе — товары и модификации.

Единственный надёжный способ связать всё это — таблица соответствий с внутренним ключом, которым управляете вы:

Правила, без которых таблица быстро разъезжается:

• Ключ — на уровне продаваемой единицы, а не карточки. Платье в трёх размерах — три строки, потому что остаток у каждого размера свой.
• Баркод не должен быть единственным ключом. Разные партии одного размера могут иметь разные баркоды производителя; Wildberries позволяет объединять их в одном размере, и учёт должен знать все.
• Один внутренний SKU не может соответствовать двум разным карточкам на одной площадке. Если такое есть, это дубль, и его нужно устранить до запуска интеграции, иначе остаток разделится или удвоится.
• Таблица соответствий — часть учёта, а не файл у программиста. Новый товар появляется в каналах только после появления строки.

Комплекты — отдельный класс проблем. Набор из трёх товаров не имеет собственного физического остатка: его доступность равна минимуму по компонентам с учётом кратности. Если компонент А доступен в 10 штуках, Б — в 4, а в набор входит по одной единице каждого, доступно 4 набора. При этом продажа набора уменьшает остаток каждого компонента, а продажа компонента отдельно уменьшает доступность набора. Эту арифметику должен выполнять интеграционный слой, а не человек, и выполнять при каждом событии по любому компоненту, иначе набор будет продан при отсутствии одной из частей.

Если комплект собирается заранее и хранится как отдельная единица — это уже не комплект, а товар с собственным остатком и собственной строкой в таблице. Смешивать два подхода для одного набора нельзя.

В какой момент создавать резерв?

Резерв — это момент, когда единица перестаёт быть доступной для других покупателей. Выбор этого момента определяет и долю перепродаж, и долю «зависших» единиц, которые никто не купит, пока резерв не снимут.

Варианты по каналам:

Главный принцип: резерв ставится в учётной системе или в интеграционном слое, который синхронизирован с ней, а не в канале. Канал сообщает о событии, учёт уменьшает доступный остаток, интеграционный слой рассылает новое значение остальным каналам. Так одно событие на Ozon через секунды уменьшает остаток на сайте и Wildberries.

Схема движения резерва для единицы товара выглядит так:

1. Доступно. Единица видна во всех каналах с учётом буфера или квоты.
2. Мягкий резерв. Покупатель на сайте начал оплату или менеджер работает с заявкой. Единица скрыта из других каналов на ограниченное время — обычно минуты. Если оплаты нет, возвращается в «Доступно».
3. Жёсткий резерв. Заказ подтверждён или оплачен, или пришло событие заказа с площадки. Единица уменьшила доступный остаток во всех каналах. Снимается только отменой.
4. Списание. Заказ собран и передан в доставку. Физический остаток уменьшился, резерв закрыт.
5. Возврат. Товар вернулся на склад. После проверки состояния — снова «Доступно» или списание в брак.

Каждому переходу соответствует событие и запись в журнале. Если переход «Мягкий резерв → Доступно» не реализован, корзины с незавершённой оплатой будут держать остаток часами; если нет перехода «Жёсткий резерв → Доступно» при отмене, товар останется невидимым до инвентаризации.

Ozon в тех же рекомендациях предупреждает: если передать на площадку нулевой остаток, резерв по уже оформленным заказам это не затрагивает — заказы нужно исполнить (Ozon for dev, рекомендации по управлению остатками). Это важно при переходе на новую схему: обнуление остатков не отменяет обязательств.

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

Как обрабатывать отмены и возвраты?

Отмены и возвраты — главный источник «потерянного» остатка: товар физически есть, но ни один канал его не продаёт. Причина в том, что интеграции чаще проектируют от заказа к отгрузке и забывают обратный путь.

Отмена до отгрузки. Событие приходит из канала: покупатель отменил, менеджер отклонил, площадка отменила за просрочку сборки. Реакция одна: резерв снимается, доступный остаток пересчитывается и рассылается. Проблема возникает, когда отмена не доходит: статус поменялся в кабинете площадки, а интеграция читает только новые заказы. Поэтому обмен должен читать изменения статусов всех незакрытых заказов, а не только появление новых.

Отмена после передачи в доставку. Товар уже списан, едет к покупателю или обратно. Это не возврат в доступный остаток: единица физически отсутствует на складе. Учитывать её нужно как ожидание с источником «возврат в пути» и возвращать в доступный только при фактической приёмке на складе. Иначе интеграция «вернёт» в продажу товар, который приедет через две недели — или не приедет вовсе.

Возврат от покупателя. После приёмки товар проверяют: годен — оприходование в доступный; брак — списание. Пока проверка не проведена, товар не доступен ни одному каналу. На площадках возвраты по FBS проходят через их логистику, и момент физического возвращения на ваш склад отличается от момента, когда возврат отражён в кабинете.

Правило для всех трёх случаев: возвращать в доступный остаток можно только по физическому факту на вашем складе, подтверждённому документом в учётной системе. Канал сообщает о намерении, склад — о факте. Интеграция, которая пересчитывает остаток по событиям канала без документа учёта, рано или поздно продаст то, чего нет.

Типичные потери на этом участке и как их закрыть:

• Отменённые заказы висят в резерве неделями. Нужна проверка незакрытых резервов по сроку с автоматическим снятием или эскалацией менеджеру.
• Возвраты лежат в зоне приёмки без оприходования. Нужен регламент приёмки возвратов с проведением документа в тот же день.
• Частичная отмена — одна позиция из трёх — обрабатывается как полная или не обрабатывается. Резерв должен сниматься по позициям, а не по заказу.
• Замена товара покупателю оформляется словами, а не документами. Нужна отмена одной единицы и новый резерв на другую.

Как учитывать FBS, FBO и разные склады?

Единый остаток не означает, что все единицы лежат в одном месте и доступны всем каналам одинаково. Товар на складе площадки по схеме FBO принадлежит вам, но продать его на сайте нельзя — он физически не у вас. Товар на вашем складе доступен и сайту, и FBS-продажам на обеих площадках, и опту.

Wildberries различает это на уровне API: методы складов и остатков продавца используются для моделей продаж со склада продавца — FBS, DBS, EDBS, DBW и самовывоз, — а остатки задаются на виртуальном складе продавца, привязанном к конкретному физическому складу Wildberries; за один запрос обновляются остатки одного склада продавца (WB API, гайд «Работа с товарами», обновлён 21 апреля 2026). У Ozon остаток задаётся парой «товар — склад продавца», и изменение одного товара на нескольких складах считается отдельными обновлениями (Ozon for dev, рекомендации по управлению остатками).

Модель для компании с одним собственным складом и FBO-поставками:

Ошибка, которая встречается часто: при отгрузке поставки на FBO товар не списывают с собственного склада до подтверждения приёмки площадкой, и неделю он числится доступным для сайта. Правило — списывать при физической отгрузке, а расхождения по приёмке площадки разбирать отдельно.

Если собственных складов несколько, добавляется выбор, какой остаток передавать каждому каналу. Площадки по FBS привязывают склад продавца к конкретному региону и сроку сборки, поэтому передавать им суммарный остаток по всем складам нельзя — заказ должен собираться там, где товар лежит. Сайт, напротив, может показывать суммарный остаток с правилом выбора точки отгрузки, а для самовывоза — наличие в конкретной точке. Эти правила — приоритет склада, полнота комплектации из одного места, поведение при разбиении заказа — Like Sites выделяет в отдельный модуль и проверяет контрольными заказами из разных зон (страница «Интернет-магазин с собственным складом»).

Практическое следствие для таблицы соответствий из раздела про SKU: к ней добавляется измерение «склад». Внутренний SKU на складе А и тот же SKU на складе Б — разные строки для площадок и одна агрегированная строка для сайта.

Как работать с задержками, повторами событий и сбоями API?

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

Лимиты, которые задают нижнюю границу интервала, опубликованы. Для Ozon: до 100 пар «товар — склад» в одном запросе на обновление остатков, до 80 запросов в минуту с одного аккаунта и не чаще одного обновления в 30 секунд для одной пары (Ozon for dev, рекомендации по управлению остатками). Для Wildberries остатки обновляются списком ID размеров — до 1000 позиций в одном запросе на один склад продавца, — а после создания карточки или изменения габаритов нужно выждать до 30 минут синхронизации, прежде чем задавать остатки (WB API, документация раздела «Работа с товарами»). Точные лимиты запросов проверяйте в документации перед запуском: площадки меняют их, и статья не заменяет документацию.

Из этого следует, что «обновлять все остатки каждые пять минут» — не решение, а проблема. Ozon прямо относит к анти-паттернам периодическое обновление сразу по всем товарам, обновление чаще раза в 30 секунд без фактического изменения, обнуление остатка перед передачей актуального значения и несколько параллельно работающих интеграций, предупреждая, что при значительном числе невалидных запросов доступ к методам обновления остатков может быть ограничен (Ozon for dev, рекомендации по управлению остатками). Правильная модель — событийная: изменился остаток по SKU → в очередь → отправка в каналы с соблюдением лимитов.

Защита последних единиц на время интервала — буфер или квоты. Ozon описывает оба подхода: страховочный остаток, когда площадкам показывают меньше, чем есть, причём буфер может быть динамическим — например, при остатке больше 20 передавать всё, при 10 и меньше оставлять одну единицу, при 3 и меньше — две или скрывать остаток на всех площадках, кроме приоритетной; и квоты, когда общий остаток заранее делится между площадками с возможностью перераспределения (Ozon for dev, рекомендации по управлению остатками). Цена буфера — недопродажи: единицы в буфере не продаёт никто. Цена квот — сложность и риск, что товар закончится в одном канале при наличии в другом. Like Sites в своём ответе на вопрос об одном остатке для сайта и маркетплейсов называет те же два варианта и подчёркивает, что решение о допустимом риске принимает клиент (страница «Интернет-магазин с собственным складом»).

Таблица отказов и восстановления — артефакт, который должен существовать до запуска, а не появляться после первого инцидента:

Две детали, без которых таблица не работает. Первая — идемпотентность: любое событие может прийти повторно, и обработка должна давать тот же результат. Это достигается хранением идентификаторов обработанных событий. Вторая — «последнее значение побеждает»: при отправке остатка в канал передаётся текущее доступное количество, а не последовательность плюсов и минусов, иначе после сбоя очередь воспроизведёт устаревшие состояния. Ozon формулирует это как «сразу передавать актуальное значение остатков с учётом изменений» (Ozon for dev, рекомендации по управлению остатками).

Как обнаруживать расхождения?

Даже правильная событийная схема накапливает расхождения: событие потерялось, кладовщик провёл документ задним числом, площадка изменила заказ без уведомления. Поэтому помимо событий нужна регулярная сверка — сравнение того, что система думает о каналах, с тем, что каналы думают о себе.

Что сверять и как часто:

• Доступный остаток по каждому SKU и складу: значение в интеграционном слое против значения в кабинете площадки, полученного методом чтения остатков. У Ozon для этого есть метод получения информации о количестве товара и пуш-уведомления об изменении стока; периодичность опроса продавец выбирает сам (Ozon for dev, рекомендации по управлению остатками). У Wildberries остатки читаются по складу продавца и списку ID размеров (WB API, гайд «Работа с товарами»).
• Незакрытые заказы: список заказов в статусах до отгрузки на площадке против резервов в учёте. Каждый заказ без резерва и каждый резерв без заказа — расхождение.
• Физический остаток против учёта: инвентаризация по позициям с частыми расхождениями, не реже раза в период, который компания считает допустимым.

Частота сверки остатков — не «как можно чаще», а по риску: быстро расходящиеся позиции и позиции с остатком ниже порога сверяются чаще, залежавшиеся — реже. Сверка всего каталога каждые несколько минут упирается в те же лимиты API, что и обновление.

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

Журнал — это не отчёт для отчётности. По нему через месяц видно, какие SKU и какие каналы дают расхождения системно: например, все расхождения по одному складу означают проблему в обмене с этим складом, а по одному SKU — дубль в таблице соответствий. Разбор повторов — та часть работы, которую имеет смысл автоматизировать в первую очередь: сопоставление строк отчётов и поиск закономерностей — рутинная задача с понятными правилами. Как выбирать такие процессы и что в них оставить человеку, разобрано в статье про стоимость ИИ-агента для бизнеса на примере сверки отчётов площадок.

Как перейти на новую схему без остановки продаж?

Переход на единый остаток — не переключение рубильника. Старая схема, даже с ручным обновлением, работает и приносит заказы; остановить продажи на неделю миграции дороже любой перепродажи. Поэтому переход делается поэтапно, с параллельной работой и контролем на каждом шаге.

Этапы в порядке, который снижает риск:

1. Инвентаризация и таблица соответствий. Пересчитать физический остаток, устранить дубли карточек на площадках, заполнить таблицу соответствий для всего продаваемого ассортимента. Без этого шага интеграция стартует с неверных данных и будет их «синхронизировать».
2. Один источник. Перевести учёт остатков в одну систему, закрыть ручные таблицы. Объявить сотрудникам, что остаток меняется только документами в этой системе.
3. Чтение без записи. Подключить интеграционный слой к каналам только на чтение: заказы и остатки читаются, сверяются с учётом, расхождения пишутся в журнал. Остатки в каналы пока обновляются по-старому. Этот этап показывает реальную длину интервала и реальный процент расхождений.
4. Запись в один канал. Включить обновление доступного остатка в тот канал, где цена ошибки ниже, — обычно это сайт, где отмену объясняет свой менеджер. Буфер на этом этапе ставится консервативно.
5. Запись во все каналы. После недели без системных расхождений — включить обновление площадок, по одной. Старые механизмы обновления остатков на площадке отключить до включения новых: две параллельные интеграции — один из анти-паттернов, за который Ozon предупреждает об ограничениях (Ozon for dev, рекомендации по управлению остатками).
6. Настройка буфера и квот. По журналу расхождений и статистике продаж снизить буфер там, где он создаёт недопродажи, и поднять там, где были перепродажи.
7. Наблюдение. Регулярный просмотр журнала и доли отменённых заказов по причине «нет товара».

Что должно быть готово до шага 4: таблица отказов и восстановления, ответственный за разбор журнала и правило, при каком проценте расхождений шаг откатывается. Откат — это возврат к чтению без записи, а не выключение всего.

Для компании, которая одновременно запускает собственный магазин рядом с маркетплейсами, порядок шагов тот же, но первые два часто оказываются самой большой частью проекта: каталог с площадок переносится с дублями и без связи с учётом. Как построить такой магазин так, чтобы он сразу стал каналом с общим остатком, а не второй витриной с ручными цифрами, разобрано в статье интернет-магазин для селлера Wildberries и Ozon: как запустить второй канал. Бюджет такого магазина с учётом интеграций со складом и учётом — в статье сколько стоит интернет-магазин с 1С, складом и CRM.

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

Какие сценарии включить в приёмку?

Интеграция остатков принимается не по факту «остатки обновляются», а по поведению в конфликтных ситуациях. Перечень сценариев согласуется до разработки, прогоняется на данных, близких к реальным, и фиксируется протоколом с ожидаемым и фактическим поведением. Like Sites на странице услуги перечисляет обязательный минимум: заказ позиции с нулевым остатком, обнуление остатка в момент оформления, заказ из нескольких складов, выбор точки самовывоза без наличия, недоступность источника данных, полнота передачи заказа в приёмник (страница «Интернет-магазин с собственным складом»). Для многоканальной схемы список расширяется.

Чек-лист приёмки единого остатка:

1. Заказ на площадке уменьшает доступный остаток на сайте и второй площадке в пределах согласованного интервала; интервал измерен и записан.
2. Заказ на сайте с онлайн-оплатой создаёт мягкий резерв на время оплаты; при неоплате резерв снимается автоматически в заданный срок.
3. Отмена заказа до отгрузки возвращает единицу в доступный остаток всех каналов.
4. Отмена после передачи в доставку не возвращает единицу в продажу до приёмки на складе.
5. Возврат оприходован документом — единица появляется в каналах; возврат списан в брак — не появляется.
6. Частичная отмена снимает резерв только по отменённым позициям.
7. Комплект недоступен, если недоступен любой компонент; продажа компонента уменьшает доступность комплекта.
8. Поставка на FBO списывает товар с собственного склада при отгрузке; остаток FBO не попадает в доступный остаток сайта.
9. Последние единицы скрыты из каналов по правилу буфера; правило проверено на пороговых значениях.
10. При недоступности API площадки обновления встают в очередь, после восстановления отправляется актуальное значение, журнал содержит записи об ошибках.
11. При недоступности учётной системы сайт продолжает работать на последнем остатке, повторная проверка при оформлении блокирует заказ исчезнувшей позиции.
12. Повторное событие о том же заказе не создаёт второй резерв.
13. Сверка находит искусственно внесённое расхождение и записывает его в журнал с нужными полями.
14. Новый товар без строки в таблице соответствий не уходит в каналы, а попадает в список на сопоставление.
15. Количество запросов к площадкам за сутки укладывается в лимиты с запасом; обновления без изменения остатка не отправляются.

Каждый пункт проверяется не словами «работает», а конкретным действием и наблюдением результата в каждом канале. Протокол приёмки с датой — документ, к которому возвращаются при первом инциденте: если сценарий был в протоколе и прошёл, причина в изменившихся условиях; если не был — список нужно дополнить.

Когда отдельная интеграция не нужна?

Единый остаток с интеграционным слоем, очередями и журналом — не универсальный ответ. Есть ситуации, когда его строить рано или не нужно вовсе, и честнее сказать об этом до сметы.

• Один канал продаж. Если продажи идут только на одной площадке по FBO, остаток ведёт площадка, и интеграция остатков не решает ничего. Нужна она появится при втором канале или при переходе на FBS.
• Остаток не меняется быстро. Десятки SKU с запасом на месяцы и несколько заказов в день: ручное или регламентное обновление раз в сутки с консервативным буфером даёт тот же результат дешевле. Интеграция нужна, когда интервал между событиями короче, чем интервал ручного обновления.
• Учёт не готов. Если нет единого источника — остатки в таблицах, часть в голове, — интеграция будет синхронизировать хаос. Сначала учёт, и это может быть отдельный проект с собственным бюджетом.
• Учётная система уже делает это. У 1С и МоегоСклада есть собственные модули и партнёрские решения для обмена с площадками и сайтом. Если ассортимент типовой, складов один и специфических правил нет, готового обмена может хватить; отдельный интеграционный слой нужен, когда правила — буферы, квоты, комплекты, мультисклад — выходят за возможности готового модуля.
• Задача на самом деле про закупки. Если проблема не в том, что продают отсутствующее, а в том, что товар регулярно заканчивается или залёживается, это вопрос прогнозирования спроса и пополнения, а не синхронизации текущего остатка. Интеграция остатков даёт данные для этой задачи, но не решает её.
• Нет ответственного за остаток. Интеграция передаёт то, что в учёте. Если никто не отвечает за своевременную приёмку, списание и инвентаризацию, единый остаток будет единым неверным остатком во всех каналах сразу.

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

Ситуация: у вас один запас на сайт, Wildberries и Ozon, периодические отмены «нет товара» и неясно, нужна ли отдельная интеграция или хватит готового модуля учётной системы. Что разберём: каналы, учётную систему, число SKU и складов, схемы FBS/FBO и типичную ошибку, с которой вы сталкиваетесь. Результат: ответ, нужен ли вам интеграционный слой, какой буфер и какая частота обновления достаточны для вашего объёма, и если нужен — состав работ с перечнем проверяемых сценариев. Действие: проверить схему остатков и резервов.