Остатки на Ozon: где смотреть, как обновлять и почему они расходятся с реальностью

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

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

Остаток это три числа, а не одно

Запросив детальные остатки по складу, продавец получает на каждый товар три значения:

Покупатель на витрине видит третье число. Продавец, глядя на свою складскую программу, обычно держит в голове первое. Разница между ними и есть резерв: товар физически лежит на полке, но продать его второй раз нельзя, он уже чей-то.

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

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

Где посмотреть остатки на Ozon

Единого экрана «все остатки» нет, и это первое, обо что спотыкаются новички. Данные разнесены по схемам работы.

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

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

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

Чем остатки FBS отличаются от остатков FBO

Разница не в самих числах, а в том, кто их считает и кто отвечает за расхождение.

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

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

Сравнивать схемы по выгодности здесь не будем, для этого есть отдельный разбор FBO и FBS. Для темы остатков важно одно: в первом случае вы читаете чужие числа, во втором отвечаете за свои.

Шесть уровней остатка вместо «есть или нет»

По каждому товару площадка считает две величины, и обе полезнее, чем само количество:

• среднесуточные продажи за последние шестьдесят дней: сколько единиц в день уходит в среднем;
• запас в днях: на сколько дней хватит текущего остатка при этой скорости.

Дальше товар получает оценку уровня. Уровней шесть, а не два:

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

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

Как обновить остатки: три ограничения одновременно

Метод обновления количества выглядит просто, но живёт под тремя ограничениями сразу, и нарушение любого ломает выгрузку.

Сто пар за один запрос. Считается не количество товаров, а количество пар «товар и склад». Один товар на трёх складах занимает три места из ста, а не одно. Продавец с тысячей товаров на трёх складах отправляет не десять запросов, а тридцать.

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

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

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

Когда обновление проходит, но ничего не меняется

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

Четыре случая, когда остаток не встанет:

1. Товар ещё не готов. Задать наличие можно только после того, как статус товара сменится на отправленную цену. До этого момента остаток просто не примут.
2. Крупногабаритный товар не на том складе. Остатки таких товаров обновляются только на складах, предназначенных для крупногабарита.
3. В запросе оба идентификатора. Если передать одновременно артикул продавца и идентификатор товара в системе площадки, изменения применятся к артикулу. При расхождении между ними вы обновите не тот товар и не заметите этого. Документация советует передавать только один идентификатор.
4. Слишком частое обновление. Та самая ошибка тридцати секунд.

Ни один из этих случаев не выглядит как поломка: запрос уходит, ответ приходит, число на витрине остаётся прежним.

Как добавить остаток новому товару

Отдельная история, на которой спотыкаются при заведении первых позиций. Карточка создана, товар виден в кабинете, а количество не встаёт.

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

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

Третье касается крупногабаритных позиций. Для них подходят не все склады, и остаток примут только на тех, что для них предназначены.

Что значит «осталось мало» в карточке

Подпись, которая появляется в кабинете и в карточке товара, и вызывает вопрос «мало это сколько». Точного числа за ней не стоит: это не порог в штуках, а один из уровней остатка из шкалы, разобранной выше.

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

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

Учёт и управление остатками: что нужно делать регулярно

Остатки это не разовая настройка, а процесс, и у него есть три обязательных элемента.

Сверка. Число в кабинете и число на полке должны совпадать. Расхождение появляется само: возвраты, бой, пересорт, и чем реже сверка, тем дороже разбор.

Обновление. Выгружать нужно доступное количество, а не общее, и с той частотой, с которой у вас меняется физический остаток. Ограничения на обновление разобраны выше.

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

Почему остатки расходятся с реальностью

Сведём причины в одном месте, от самой частой к самой редкой:

Резерв не вычли. Выгружается общий складской остаток вместо доступного. Расхождение равно количеству активных заказов и растёт вместе с продажами.

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

Обновление не долетело. Строка вернула ошибку, а её никто не прочитал, потому что смотрели только на общий код ответа.

Обновление уперлось в лимит. Тридцать секунд на пару или восемьдесят запросов в минуту на кабинет, особенно когда обновляющих систем несколько.

Расхождение по факту. Пересорт, бой, недостача при инвентаризации: на витрине число честное, но на полке товара нет физически. Это уже не про интеграцию, а про складской учёт.

Что делать, чтобы не продавать несуществующее

Порядок действий, который закрывает большинство случаев:

1. Выгружайте доступный остаток, а не общий. Из общего вычитайте резерв, который отдаёт площадка, а не тот, что посчитала ваша система.
2. Разбирайте ответ построчно. Считайте успешными только строки с признаком обновления, остальные логируйте с кодом ошибки и повторяйте позже.
3. Держите буфер. Раз мгновенной синхронизации не бывает, часть запаса не должна участвовать в продажах. Размер буфера считается от скорости продаж: товар с высокой среднесуточной скоростью требует большего запаса, чем медленный.
4. Считайте запас в днях, а не в штуках. Пятьдесят штук это много или мало, зависит только от скорости продаж. Запас в днях сравним между товарами, количество нет.
5. Разведите системы, которые обновляют остатки. Если их несколько, они делят один лимит и мешают друг другу. Лучше один источник истины, который собирает данные и общается с площадкой.
6. Проверяйте оба конца шкалы. Дефицит грозит отменами, избыток платным хранением. Тревожная отметка появляется в обоих случаях, а действия противоположные.

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

Что запомнить

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