Как посмотреть остатки на складах Ozon и понять, какой товар ещё можно продать
Показываю, где искать складские остатки и как отделять доступный товар от резерва и поставок в пути. Объясняю, почему общий запас не сходится с суммой по складам и как по данным своего магазина заранее заметить нехватку товара в кластере.
Я ошибался с пополнением, когда смотрел на общий остаток товара и не проверял, какая его часть действительно доступна для новых заказов. В учёте запас ещё был, поэтому поставку я откладывал. Потом открывал детализацию и видел другую картину: часть товара уже занята заказами, часть едет, а свободный остаток лежит не там, где нужен. Число в сводке не было неправильным — я задавал ему неправильный вопрос. С тех пор в моих магазинах проверка остатков начинается не с вопроса «сколько у меня товара», а с вопроса «что из этого можно продать и откуда».
Когда меня спрашивают, как посмотреть остатки на складах Озон, я разделяю поиск отчёта и чтение его содержимого. Найти таблицу обычно проще, чем понять, почему её итог не совпадает с собственной учётной системой. Для проверки мне нужны артикул, склад, статус запаса и момент, на который получены данные. Если чего-то из этого нет, сравнение легко превращается в спор между разными числами, каждое из которых посчитано по своим правилам. Ниже я прохожу весь путь: от кабинета продавца до решения, какой товар пора пополнять, даже если общий остаток ещё выглядит спокойным.
Где посмотреть остатки на складах Ozon
Я начинаю в кабинете продавца с раздела, связанного с нужной схемой работы: FBO или FBS. Для товара, который хранится у Ozon по FBO, ищу экран остатков, управления запасами или соответствующий отчёт с детализацией по складам. Точные названия пунктов я здесь не закрепляю: интерфейс меняется, а актуального вида вашего кабинета у меня нет. Если нужная таблица не находится через меню, использую поиск по кабинету или справку по словам «остатки» и «склады». Ориентир для меня — возможность увидеть конкретный артикул на конкретном складе, а не просто количество товара в карточке.
Перед тем как смотреть количество, я проверяю выбранный магазин и схему работы. При нескольких кабинетах легко открыть правильный товар не в том магазине и начать искать несуществующую пропажу. Дальше снимаю лишние фильтры, нахожу артикул и раскрываю складскую детализацию, если она предусмотрена на этом экране. Когда нужна сверка всего ассортимента, выгружаю доступный отчёт и сохраняю вместе с ним время получения данных и выбранные параметры. Поиск по названию оставляю для ориентира, а сопоставляю строки по устойчивому идентификатору товара: похожие названия слишком легко перепутать.
С FBS есть отдельная ловушка: остаток на складе продавца в кабинете не означает, что этот товар физически лежит на складе Ozon. Я читаю такое количество как данные о своём запасе, переданные площадке, и отдельно сверяю их с фактическим наличием. Товар, отправленный покупателю по заказу, тоже не становится свободным складским остатком только потому, что находится в логистической цепочке. Поэтому перед ответом на вопрос «где посмотреть остатки на складах Озон» я уточняю, чьи именно склады имеются в виду. Смешивать FBO и FBS в одном итоге можно для отдельных управленческих задач, но для решения о поставке нужна раздельная картина.
Доступный остаток я использую как отправную точку для оценки новых продаж, но сначала читаю пояснение к конкретному полю отчёта. Мне нужно понять, исключены ли из него резерв, ограничения и другие состояния, при которых товар нельзя свободно продать. Само слово «остаток» этого не гарантирует: в одной таблице речь может идти о физическом наличии, в другой — о количестве, доступном для заказа. Если есть отдельные колонки по статусам, я сохраняю их при выгрузке, а не оставляю один общий итог. Так видно, почему физически товар ещё присутствует на складе, а свободного запаса уже почти нет.
Зарезервированный товар я не считаю запасом для следующего покупателя, пока резерв не снят. Он уже связан с текущим процессом заказа, хотя физическое движение может ещё не завершиться. При этом я не вычитаю резерв автоматически из любого числа, которое нашёл в кабинете: доступный остаток уже может быть рассчитан без него. Сначала проверяю состав показателя, затем выбираю действие. Иначе получится обратная ошибка — я сам уменьшу свободный запас повторным вычитанием и отправлю на склад лишний товар.
Поставку в пути я держу рядом с остатками, но не внутри количества, доступного прямо сейчас. Между отправкой со своего склада и появлением товара в свободном запасе есть движение, приёмка и возможные расхождения, поэтому одного факта отгрузки недостаточно. Для пополнения мне нужны направление поставки, её текущее состояние и ожидаемый момент доступности, насколько его вообще можно обоснованно оценить. Возврат тоже не прибавляю к свободному запасу заранее: сначала должно стать понятно, где товар находится и пригоден ли он к продаже. Если таких данных нет, я прямо помечаю количество как ожидаемое, а не выдаю его за гарантированное наличие.
Я не складываю колонки остатков, пока не проверю, что они описывают разные, не пересекающиеся количества. Общий остаток может уже включать резерв, а показатель поставок — содержать товар на промежуточном этапе обработки. Для новых продаж мне нужен подтверждённый свободный запас, а для планирования — отдельный список ожидаемых поступлений. Смешение этих величин создаёт запас на бумаге, которым нельзя закрыть новый заказ.
«Мой склад» держит то, чего нет у Ozon: сколько лежит у вас, сколько едет из Китая и когда пора заказывать следующую партию, чтобы она успела к концу запаса.
Почему сумма по складам не совпадает с моим запасом
В собственном учёте я могу считать своим запасом всё, во что уже вложил деньги и что ещё не списал: товар у себя, поставки в дороге, принятое складом и возвраты на разных этапах. Складской отчёт отвечает на более узкий вопрос и может показывать только определённые места хранения или статусы. Поэтому несовпадение итогов само по себе ещё не говорит о потере товара. Я сначала выписываю, какие группы включены в каждую сторону сравнения, и убираю различия в охвате. Искать недостачу имеет смысл после этого, иначе под неё легко принять обычную поставку, которую я уже списал со своего склада, но ещё не вижу в принятом остатке.
Следующая причина расхождения — разный момент обновления данных. Между выгрузкой складского отчёта и открытием учётной системы могли пройти заказы, отмены, приёмка или другие движения. Я сохраняю время снимков и проверяю операции между ними, вместо того чтобы требовать совпадения от несинхронных таблиц. Отдельно смотрю на единицы учёта и соответствие артикулов: комплект и отдельное изделие нельзя сравнивать как одинаковые позиции. Если после выравнивания времени, состава и идентификаторов разница остаётся, собираю детализацию движений и документы по спорному товару — тогда обращение в поддержку получается предметным.
Для нескольких магазинов ручная сверка быстро становится неудобной, особенно когда нужно сохранить историю, а не только посмотреть текущий экран. Я сделал SellOps, потому что не нашёл готового сервиса аналитики, которому мог бы доверить свои расчёты без постоянной перепроверки. При этом для меня любой сводный экран должен оставаться проверяемым через исходные данные: красивый итог не объясняет расхождение сам по себе. О том, как устроен SellOps, я рассказываю отдельно, а здесь разбираю саму проверку независимо от выбранного инструмента. Начать её можно и в таблице, если не терять статусы, склады и время обновления.
Сколько денег стоит товар на складах — отдельно в закупочных ценах и в ценах продажи, с запасом в днях по каждой позиции. Видно, где деньги лежат мёртвым грузом.
Как рассчитать запас и не посчитать резерв повторно
Сначала я выбираю товар, магазин, схему работы и момент сверки, затем определяю границы расчёта: отдельный склад, кластер или все склады. Из отчёта беру подтверждённое наличие внутри этих границ и читаю, какие статусы оно включает. Если это общий физический остаток, из него нужно исключить входящие в него количества, недоступные для новых продаж. Если источник уже показывает свободный остаток, повторно очищать его от тех же статусов нельзя. В рабочей таблице я подписываю происхождение показателя, чтобы при следующей сверке не угадывать, что именно было взято за основу.
Затем я вычитаю из общего наличия резерв, если он входит в исходное количество, и остальные недоступные части, также включённые в эту базу. Перед вычитанием проверяю, не пересекаются ли сами исключаемые статусы: одну и ту же единицу товара нельзя убрать повторно. Механика расчёта такая: свободный запас равен исходному наличию за вычетом всех входящих в него недоступных единиц, учтённых без повторов. Полученный результат сверяю с доступным остатком из источника, если такой показатель там есть. При расхождении сначала ищу отличие в составе полей, а не исправляю число вручную до удобного совпадения.
После этого я оцениваю, сколько свободного товара останется до следующего реального пополнения. Из свободного запаса вычитаю ожидаемый спрос до момента, когда новая поставка станет доступна, а подходящие по сроку поступления учитываю отдельно. Для запаса непосредственно перед поступлением вычитать спрос нужно без прибавления самой ожидаемой партии: иначе она замаскирует нехватку, которая возникнет раньше. Потребность в пополнении считаю как ожидаемый спрос на выбранный период плюс страховой запас, затем вычитаю свободное количество и подтверждённые поступления внутри этого периода. Отрицательный результат означает, что по этим исходным данным дополнительная поставка не требуется, но сроки внутри периода всё равно нужно проверить.
Конкретная ошибка здесь — взять общий остаток, прибавить поставку в пути и назвать результат доступным запасом. Тогда резерв выглядит свободным, а ещё не принятый товар будто уже ждёт следующего заказа, из-за чего пополнение откладывается. Денежный эффект я оцениваю через спрос, который действительно мог остаться неудовлетворённым, и маржинальный доход с продажи после переменных расходов, а не через всю цену товара. Без данных о спросе во время отсутствия я не называю такую оценку точной потерей: часть покупателей могла заказать товар с другого склада или вернуться позднее. Обратная ошибка с повторным вычитанием резерва замораживает деньги в лишней партии, поэтому отдельно считаю её закупочную стоимость и фактические дополнительные расходы на размещение и перемещения.
По каждому складу видно доступный остаток, резерв и то, что уже едет, — с датой прибытия. Ozon эту дату не сообщает: она считается по заявке на поставку и реальному сроку доставки в кластер, а если срок вышел, а товар всё ещё в пути, дата подсвечивается.
Как читать остатки по кластерам и заметить нехватку заранее
Общий остаток по стране может скрывать нехватку в отдельном направлении, поэтому после складской сверки я перехожу к кластерам. Для группировки использую актуальное соответствие складов кластерам из доступных данных Ozon, а не собственные догадки по географическим названиям. При этом кластер хранения и регион покупателя — разные разрезы: товар может участвовать в доставке за пределы своего расположения. Я не считаю, что остаток внутри кластера обслуживает исключительно местный спрос, если у меня нет такого подтверждения. Мне нужно увидеть распределение запаса и сопоставить его с заказами, сохранив понимание того, откуда товар отгружался и куда направлялся.
Чтобы понять, на сколько хватит товара, я делю свободный остаток на средний дневной расход за выбранный сопоставимый период. Для этого заранее определяю, какое событие считаю расходом, и не смешиваю в одном ряду заказы, отгрузки и продажи без поправок на отмены и возвраты. Затем сравниваю получившееся покрытие со своим фактическим временем пополнения: от подготовки партии до доступности после приёмки. Универсального срока здесь нет, поэтому я опираюсь на историю собственных поставок по нужному направлению. Если покрытия уже не хватает на этот путь с выбранным страховым запасом, товар требует решения, даже когда его абсолютный остаток кажется большим.
Средний расход тоже может обмануть, если в выбранном периоде товар отсутствовал, действовала акция или заметно менялась цена. Продажи во время нехватки отражают ограниченное предложение, поэтому по ним легко занизить будущую потребность. Я отмечаю такие отрезки и проверяю динамику в сопоставимых условиях, а при недостатке истории оставляю оценку предварительной. Тревожным сигналом для меня становится сокращение покрытия вместе с ростом спроса, особенно когда ожидаемая поставка ещё не имеет понятного момента доступности. По одному медленно продающемуся артикулу я не делаю вывод о целом кластере: проверка должна оставаться на уровне товара и направления.
Завтра я бы начал с выгрузки остатков из нужного кабинета и выбрал товар, по которому уже возникает вопрос о пополнении. Для него собрал бы рядом свободный запас, резерв, остальные недоступные состояния, поставки в пути и время обновления каждого источника. Затем сверил бы собственный учёт с данными площадки в одинаковых границах, рассчитал покрытие по нужным складам или кластерам и сравнил его с историей пополнения. Результатом такой проверки должно стать конкретное действие: готовить поставку, уточнять её приёмку, исправлять учёт или пока сохранять текущий запас. Так вопрос «как узнать остатки на складах Озон» перестаёт заканчиваться найденной таблицей — у меня появляется проверяемое основание для следующего решения.
Разбор для продавцов Ozon
Как передавать коды маркировки
Разбор8 ноября 2026 г.
Как передавать коды маркировки в Ozon на FBS и что делать с УПД
Разбираю путь кода от получения товара до сборки заказа FBS, передачи сведений в Ozon и проверки возврата. Объясняю, почему УПД не заменяет код в отправлении, где искать причину ошибки и что меняется при работе по FBO.