Как найти товары, которые скоро закончатся на WB и Ozon

Коротко

• Дни запаса = доступный к продаже остаток ÷ средний дневной расход. Оба показателя считаются на одном и том же периметре складов.
• Резерв и товары в пути в доступный остаток не входят. Их показывают отдельными колонками.
• Расход — это одна выбранная мера: заказы, выкупы или отгрузки в штуках. Подменять одну другой без сверки нельзя.
• Если расход за период нулевой или данных о нем нет, дни запаса не определены. Такие SKU выносятся в отдельный список.
• Товар попадает в зону риска, если дней запаса меньше, чем срок пополнения плюс страховой запас.
• Каждый расчет привязан к дате наблюдения. Через несколько дней его нужно делать заново.

Метод по шагам

Шаг 1. Зафиксируйте дату наблюдения и периметр

Дата наблюдения — момент, на который снят остаток. Например, утро 2026-10-16. Все дальнейшие цифры относятся к этому моменту.

Периметр — это границы, внутри которых вы сравниваете запас и расход. Выберите один из вариантов:

• маркетплейс целиком, одна модель работы (только FBO или только FBS/rFBS);
• конкретный склад или кластер складов.

FBO и FBS лучше разделять: у них разные остатки, разные сроки пополнения и разные способы поставки. Если товар лежит на нескольких складах WB или в нескольких кластерах Ozon, общий остаток может выглядеть нормально, а на складе в нужном регионе товар уже закончился. В таком случае считайте по складам. Но расход тогда тоже нужен по складам, то есть заказы, отгруженные именно с этого склада.

Шаг 2. Разделите остаток на три части

Для каждого SKU на дату наблюдения нужны:

1. Доступный к продаже остаток — штуки, которые покупатель может заказать прямо сейчас.
2. Резерв — штуки, закрепленные за уже оформленными заказами. Они уже израсходованы, хотя физически еще на складе.
3. Товары в пути — поставки на склад маркетплейса и возвраты от покупателей, которые еще не приняты. Пока их не приняли, продавать их нельзя.

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

Шаг 3. Выберите меру расхода

Расход должен показывать, как быстро уменьшается именно этот остаток на этом периметре. Варианты:

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

Выберите одну меру и подпишите ее в таблице. Нельзя брать заказы для одного SKU и выкупы для другого. Нельзя и сравнивать заказы с WB с отгрузками с Ozon, пока вы не проверили, что они измеряют одно и то же.

Шаг 4. Выберите окно и уберите дни без наличия

Средний дневной расход считается за окно, например последние 14 или 28 полных дней до даты наблюдения. Короткое окно быстрее ловит изменения. Длинное устойчивее к случайным всплескам.

Важная поправка: если в окне были дни, когда товара не было в наличии, заказов в эти дни не было по технической причине. Если делить на все дни окна, расход окажется заниженным, а дней запаса — больше, чем на самом деле. Делите на дни, когда товар был доступен. Если таких дней в окне меньше трех, расход ненадежен: пометьте SKU как «мало данных».

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

Шаг 5. Посчитайте дни запаса

Формула: дни запаса = доступный остаток ÷ средний дневной расход на одном периметре.

Учебный пример, цифры вымышленные:

• доступный остаток на 2026-10-16 — 120 шт.;
• заказы без отмен за 28 дней — 168 шт.;
• из 28 дней товар был в наличии 24;
• средний расход — 168 ÷ 24 = 7 шт. в день;
• дни запаса — 120 ÷ 7 ≈ 17 дней.

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

Шаг 6. Сравните со сроком пополнения

Порог риска = срок пополнения + страховой запас (в днях).

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

Продолжим учебный пример. Срок пополнения 10 дней, страховка 5 дней, порог 15 дней. При 17 днях запаса поставку пора планировать сейчас: запас всего на 2 дня больше порога.

Статусы для таблицы:

• Критично — дней запаса меньше срока пополнения. Даже срочная поставка, скорее всего, не успеет.
• Скоро — дней запаса меньше порога, но больше срока пополнения.
• Норма — дней запаса больше порога.
• Расход не определен — нулевой расход или мало данных.
• Нет данных — нет остатка или расхода по SKU.

Шаг 7. Учтите поставки в пути отдельно

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

Ручной вариант: CSV и отчеты

Без подключенного ассистента всё то же самое делается в таблице.

1. Выгрузите из личного кабинета каждого маркетплейса отчет об остатках на дату наблюдения. Набор колонок и названия отчетов со временем меняются, поэтому проверьте, есть ли в выгрузке разбивка по складам, резерв и товары в пути.
2. Выгрузите отчет по заказам за выбранное окно с датой заказа, артикулом, количеством, складом отгрузки и признаком отмены.
3. Приведите артикулы к одному ключу. На WB и Ozon у одного товара разные идентификаторы, поэтому нужна таблица соответствия с вашим внутренним артикулом.
4. Отфильтруйте заказы по периметру и уберите отмены, если они видны.
5. Посчитайте сводной таблицей сумму заказов по SKU и число дней с наличием, если у вас есть ежедневные снимки остатков. Если снимков нет, честно делите на все дни окна и помечайте, что расход может быть занижен.
6. Добавьте колонки: доступный остаток, резерв, в пути, расход в день, дни запаса, срок пополнения, порог, статус.
7. Отсортируйте по статусу и дням запаса по возрастанию.

Слабое место ручного варианта — свежесть данных. Выгрузка устаревает уже через день, а по быстро продающимся SKU всего за несколько часов.

Какие данные нужны

Для этой задачи достаточно:

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

Готовый промт

Промт подходит для ИИ-ассистента, у которого есть доступ к данным магазина или загруженные CSV.

Подставьте значения в квадратных скобках.

Задача: найти SKU, которые скоро закончатся, на маркетплейсе [вставить WB или Ozon], модель [вставить FBO или FBS], периметр складов [вставить "все склады модели" или список складов].

Дата наблюдения остатков: [вставить дату].
Окно расхода: [вставить число] полных дней до даты наблюдения.
Мера расхода: заказы в штуках за вычетом отмен. Не заменяй ее выкупами или отгрузками. Если отмены не видны, напиши об этом явно.
Срок пополнения: [вставить число] дней. Страховой запас: [вставить число] дней.

Правила:
1. Для каждого SKU раздели остаток на: доступный к продаже, резерв, в пути. В расчет дней запаса бери только доступный остаток. Если в данных нет разделения, укажи допущение.
2. Расход считай только по заказам с того же периметра складов, что и остаток.
3. Средний дневной расход = заказы за окно / число дней окна, когда товар был в наличии. Если данных о наличии по дням нет, дели на все дни окна и пометь "расход может быть занижен". Если дней с наличием меньше 3, статус "мало данных".
4. Если расход равен нулю или отсутствует, дни запаса не вычисляй, статус "расход не определен".
5. Дни запаса = доступный остаток / средний дневной расход, округли до целых вниз.
6. Порог = срок пополнения + страховой запас. Статусы: "критично" (дни < срока пополнения), "скоро" (дни < порога), "норма".
7. Отдельная колонка "дни с учетом поставок": прибавляй товары в пути, только если их ожидаемая приемка раньше даты обнуления текущего остатка.
8. Не делай выводов о причинах падения или роста спроса.

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

Если просите ассистента обработать данные WB и Ozon одновременно, делайте два отдельных расчета. Объединяйте их по внутреннему артикулу только на этапе решения о поставке.

Где нужны актуальные данные

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

Артель подключает ИИ-ассистента к поддерживаемым данным и инструментам Wildberries и Ozon. Ассистент может получить остатки и заказы на момент запроса, а не по старой выгрузке. Какие именно данные и инструменты доступны в вашей связке, проверьте в подключенном ассистенте: спросите, какие инструменты ему видны. Настройка и совместимость описаны в актуальной инструкции подключения.

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

Как сверить результат

Требование в промте не гарантирует, что ассистент его выполнил. Проверьте:

1. Три SKU вручную. Возьмите один «критичный», один «нормальный» и один «расход не определен». Пересчитайте по исходной выгрузке остаток, заказы и дни.
2. Периметр. Убедитесь, что остаток и заказы взяты по одним и тем же складам и модели.
3. Мера расхода. Проверьте, что везде использованы заказы без отмен, а не где-то выкупы.
4. Дата наблюдения. Проверьте, что она указана и совпадает с моментом получения остатков.
5. Нули. Убедитесь, что у SKU с нулевым расходом нет числа в колонке дней запаса.
6. Сумма. Сумма доступных остатков в таблице должна совпадать с итогом отчета по тому же периметру.

Если расхождение есть, найдите его причину до того, как планировать поставку.

Ограничения метода

• Это прогноз, а не факт. Средний расход за прошлый период не учитывает акции, сезонность и изменения цены, которые будут впереди.
• Поправка на наличие приблизительная. Она убирает дни без товара, но не говорит, каким был бы спрос, если бы товар был в наличии.
• Распределение по складам. Маркетплейс может перераспределять заказы между складами, поэтому расход по одному складу менее стабилен, чем по всему периметру.
• Возвраты. Возвращенный покупателем товар становится доступным только после приемки и проверки. До этого он в пути, а бракованная единица в остаток может не вернуться.
• Новые SKU. Без истории продаж дни запаса не считаются. Для них нужен отдельный план, а не формула.

Частые вопросы

Какое окно расхода выбрать: 7, 14 или 28 дней?

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

Можно ли сложить остатки WB и Ozon в одну цифру?

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

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

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

Что делать с товаром, у которого остаток есть, а заказов нет?

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

Как часто пересчитывать список?

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

Вывод

Чтобы найти товары, которые скоро закончатся, нужно на одном периметре взять доступный остаток и сопоставимый расход, отдельно показать резерв и поставки в пути, а не вычислять дни там, где расхода нет. Готовая таблица со статусами показывает, где поставку нужно планировать сейчас. Цифры в ней всё равно нужно сверять с исходными отчетами.

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