# Настроить Политику под сезон: расчёт пополнения глазами аналитика
> Как аналитику разобрать формулу точки заказа по частям и настроить горизонт покрытия, уровень сервиса и коэффициент спроса под конкретную ситуацию.
published: 2026-08-05T22:34:20+03:00
updated: 2026-08-05T22:34:20+03:00
## Зачем этот раздел
Две одинаково дорогие ошибки продавца на маркетплейсе стоят по разные стороны одного и того же
решения. Закончился ходовой товар — упали продажи, просела карточка в выдаче, покупатель ушёл к
конкуренту. Затарились с запасом — деньги заморожены в коробках, растёт плата за хранение, а
капитал мог бы работать в другом товаре. Прикинуть «на глаз», сколько и когда докупить, для одной
позиции ещё можно, но при ассортименте в сотни и тысячи SKU ручной прикидкой быстро набирается
и дефицит, и затоваривание одновременно — просто по разным товарам. Раздел
[«Пополнение»](/inventory/replenishment) считает это по каждому товару автоматически и одинаково,
без человеческого «примерно».
## Откуда данные и как считается
Для каждого товара платформа считает две связанные величины: **точку заказа** (при каком остатке
пора заказывать новую партию) и **рекомендуемый объём закупки** (сколько именно заказать).
Логика в человеческих терминах, без формул с символами: сначала берётся фактическая скорость
продаж товара в день — не «на глаз», а по историческим данным, с учётом возможных всплесков
спроса. Она умножается на срок поставки поставщика — это и есть ответ на вопрос «сколько товара
понадобится, пока едет новая партия». Сверху добавляется страховой запас — буфер на случай, если
спрос неожиданно подскочит или поставщик задержит партию; чем выше выбранный «уровень сервиса» в
настройках [«Политики»](/inventory/policy), тем больше этот буфер. Отдельно учитывается
минимальный остаток, если он задан в Политике, — жёсткий пол, ниже которого система никогда не
предложит опуститься.
Целевой уровень запаса в итоге равен: скорость продаж, умноженная на сумму срока поставки и
горизонта покрытия в днях (тоже настройка Политики), плюс страховой запас — но не меньше
минимального остатка, если он задан.
Рекомендуемая закупка — это целевой уровень запаса минус то, что у вас уже есть: остаток на складе
плюс то, что уже в пути от поставщика (едет как открытый заказ). Уже заказанное **вычитается** —
платформа не предложит докупить то, что и так скоро приедет. Итоговое количество округляется вверх
до кратности упаковки поставщика и не может быть меньше минимальной партии (MOQ) — заказ меньше
физически невозможен, если поставщик так не отгружает.
Товар помечается флагом «нужно заказать», когда остаток плюс то, что в пути, опускается до точки
заказа или ниже.
На реальной организации такой расчёт единовременно показал 1610 товарных позиций, по которым пора
докупать, суммарно 27579 штук, — вручную такой объём по каждой позиции отдельно не пересчитать.
## Настройки расчёта: раздел «Политика»
Раздел [«Политика»](/inventory/policy) — это параметры расчёта выше. Их можно задать по всей
организации (по умолчанию для всех товаров сразу) или переопределить для конкретного товара:
- **Горизонт покрытия, дней** — на сколько дней вперёд планировать запас сверх срока поставки (по
умолчанию 30).
- **Уровень сервиса, %** — целевая вероятность не уйти в дефицит; чем выше процент, тем больше
страховой запас (по умолчанию 95%).
- **Минимальный остаток, шт** — жёсткий пол, ниже которого система никогда не предложит опуститься
(по умолчанию 0).
- **Окно спроса, дней** — за сколько дней назад считать среднюю скорость продаж.
- **Целевая оборачиваемость, дней** — ориентир по скорости движения запаса для этого товара.
- **Коэффициент спроса** — ручная корректировка прогноза, например перед сезоном, когда исторические
продажи ещё не отражают ожидаемый рост.
- **Ручной прогноз продаж в день** и **Прогноз действует до** — для случаев, когда исторические
продажи не подходят вовсе, например у нового товара без истории продаж.
- Переключатели **«считать по выкупам, а не по заказам»** и **«включать бандлы в расчёт»** —
меняют, какие данные о продажах и какие товарные позиции участвуют в расчёте скорости продаж.
## Как читать экран
В «Пополнении» по каждому товару видно: текущий остаток, товар в пути, точку заказа, рекомендуемый
объём закупки и флаг «нужно заказать». Если флаг стоит, значит остаток вместе с тем, что уже едет,
опустился до точки заказа или ниже — откладывать закупку дальше рискованно. Если рекомендуемая
закупка кажется больше, чем ожидалось, — вероятно, сработало округление под MOQ или кратность
упаковки конкретного поставщика (см. карточку в [«Поставщиках»](/inventory/suppliers)).
## Как работать
**Еженедельно:** просматривайте «Пополнение», отфильтрованное по флагу «нужно заказать», и
оформляйте заказы через [«Закупки»](/inventory/purchase-orders) — оттуда же расчёт сразу увидит,
что заказ открыт, и учтёт его как «уже в пути» при следующем пересчёте.
**Перед сезоном:** заранее скорректируйте коэффициент спроса или задайте ручной прогноз в
[«Политике»](/inventory/policy) для товаров, где ожидаемый рост спроса ещё не отражён в
исторических продажах, — иначе расчёт будет ориентироваться на прошлый, более низкий темп.
**По новому товару без истории продаж:** задайте «Ручной прогноз продаж в день» и срок его
действия — до накопления собственной истории продаж расчёт иначе будет занижать потребность.
**Сверяясь с оборачиваемостью:** прежде чем заказывать по рекомендации, проверьте товар в разделе
[«Оборачиваемость»](/inventory/turnover) — если дни запаса уже большие, стоит присмотреться,
действительно ли нужно пополнять именно сейчас и именно такой партией.
## Частые вопросы
- **Почему рекомендация докупить больше, чем кажется нужным на глаз?** Скорее всего, сработало
округление вверх до кратности упаковки поставщика или до минимальной партии (MOQ) — заказ меньше
физически невозможен для этого поставщика.
- **Я уже заказал партию — почему «Пополнение» всё ещё показывает высокую рекомендуемую закупку?**
Проверьте, что заказ действительно отражён как открытый в [«Закупках»](/inventory/purchase-orders)
— только открытые заказы (не закрытые и не отменённые) вычитаются из потребности как «уже в пути».
- **Что делать с новым товаром, у которого ещё нет истории продаж?** Задайте ручной прогноз продаж
в день в [«Политике»](/inventory/policy) на срок, пока не накопится собственная статистика, —
иначе расчёт будет исходить из отсутствия спроса.
- **Зачем нужен «уровень сервиса», если можно просто задать минимальный остаток?** Это разные
инструменты: минимальный остаток — жёсткий пол вне зависимости от спроса, уровень сервиса —
гибкий буфер, который автоматически растёт вместе со скоростью продаж и её колебаниями.
- **Можно ли пополнять товар без заполненной карточки поставщика?** Да, но расчёт будет грубее —
без срока поставки и MOQ платформа использует консервативные значения по умолчанию, а не ваши
реальные условия закупки.
## Спросите ИИ-ассистента
- «Что нужно закупить прямо сейчас и сколько штук?»
- «Какие товары скоро достигнут точки заказа в ближайшие недели?»
- «Покажи товары, где рекомендуемая закупка выросла из-за MOQ поставщика».
## Коротко
- Целевой уровень запаса = скорость продаж в день × (срок поставки + горизонт покрытия) + страховой запас, минус остаток на складе и то, что уже в пути; итог округляется вверх до кратности упаковки поставщика.
- Каждое из трёх слагаемых управляется отдельной настройкой «Политики», и типичная ошибка — крутить не тот параметр: частые мелкие дефициты правит уровень сервиса, общий избыток при ровном спросе — горизонт покрытия или коэффициент спроса.
- Горизонт покрытия задаёт объём и частоту партии, уровень сервиса — размер страхового запаса против непредсказуемости; окно спроса регулирует чувствительность к трендам, а коэффициент спроса и ручной прогноз — временная заглушка для сезонности и новых товаров без истории.
- Прежде чем доверять рекомендации, сверяйте её с классом ABC и днями запаса в «Оборачиваемости»: большая рекомендация при уже высоких днях запаса обычно значит завышенные параметры Политики, а не реальный дефицит.
## Расчёт — это не чёрный ящик, а сумма понятных слагаемых
Раздел [«Пополнение»](/inventory/replenishment) выдаёт готовую рекомендуемую закупку по каждому
товару, но для аналитика важно понимать, из чего она складывается, чтобы уметь объяснить
результат и вовремя скорректировать настройки, если реальность расходится с прогнозом.
Подробно: из чего складывается формула и какая настройка за что отвечает
Целевой уровень запаса раскладывается на три части: **скорость продаж в день**, умноженная на
**срок поставки плюс горизонт покрытия** (сколько дней вперёд планировать сверх времени доставки),
плюс **страховой запас** — буфер на случай всплеска спроса или задержки поставки. Дальше из этого
целевого уровня вычитается то, что уже есть: остаток на складе плюс то, что уже в пути от
поставщика по открытым заказам. Итог округляется вверх до кратности упаковки поставщика и не может
быть меньше минимальной партии.
Ключевое для аналитика наблюдение: каждое из трёх слагаемых управляется отдельной настройкой в
[«Политике»](/inventory/policy), и типичная ошибка — крутить не тот параметр. Если проблема в
частых мелких дефицитах между поставками, скорее всего, стоит увеличить уровень сервиса, а не
горизонт покрытия. Если проблема в общем избытке товара при ровном спросе — вероятно, завышен
горизонт покрытия или коэффициент спроса, а не уровень сервиса.
## Как подбирать параметры Политики под ситуацию
Каждый параметр «Политики» решает свою отдельную задачу расчёта.
Подробно: назначение каждого параметра Политики
**Горизонт покрытия, дней** (по умолчанию 30) — сколько дней вперёд планировать запас сверх срока
поставки поставщика. Это единственный параметр, который стоит трактовать буквально как «на сколько
дней вперёд мы готовы закупать разом» — увеличение горизонта прямо увеличивает объём каждой
партии и одновременно снижает частоту заказов.
**Уровень сервиса, %** (по умолчанию 95%) — целевая вероятность не уйти в дефицит. Чем выше
процент, тем больше страховой запас поверх ожидаемого спроса. Это правильный параметр для товаров
с нестабильным, всплесковым спросом (акции, инфоповоды) — увеличение уровня сервиса компенсирует
непредсказуемость, не меняя саму логику расчёта средней скорости продаж.
**Окно спроса, дней** — за сколько дней назад считается средняя скорость продаж. Короткое окно
быстрее реагирует на реальные изменения тренда, но чувствительнее к разовым всплескам; длинное
окно сглаживает случайные колебания, но медленнее подхватывает устойчивый рост или падение спроса.
Подбирайте окно исходя из волатильности конкретной категории, а не одно значение на весь каталог.
**Коэффициент спроса** и пара **«Ручной прогноз продаж в день» / «Прогноз действует до»** — это
инструменты для ситуаций, где исторические продажи объективно не годятся как основа прогноза:
перед сезоном, когда ожидается рост, которого ещё нет в истории, или у нового товара, у которого
истории попросту нет. Коэффициент спроса масштабирует автоматический расчёт (например, ×1,5 перед
пиковым месяцем), а ручной прогноз с датой действия полностью заменяет расчёт на заданный срок —
используйте его именно как временную заглушку, а не постоянную настройку, и снимайте после того,
как накопится собственная история продаж по товару.
**Минимальный остаток, шт** и переключатели «считать по выкупам, а не по заказам» и «включать
бандлы в расчёт» — более редкие корректировки: минимальный остаток задаёт жёсткий пол вне
зависимости от расчёта скорости продаж, а переключатели меняют, какие именно данные о продажах и
какие товарные позиции (в том числе собранные из бандла) участвуют в вычислении скорости.
## Проверка результата
Прежде чем доверять рекомендации по товару целиком, сверьте её с классом ABC и днями запаса в
разделе [«Оборачиваемость»](/inventory/turnover) — если рекомендация на закупку большая, а дни
запаса уже и так велики, вероятная причина не в реальном дефиците, а в завышенных параметрах
Политики (горизонт покрытия или коэффициент спроса) для этого товара или всей категории.
## Частые вопросы
- **Какой параметр менять, если постоянно случаются мелкие дефициты между поставками?** Уровень
сервиса — он напрямую управляет размером страхового запаса на случай всплесков спроса и
задержек поставки.
- **Какой параметр менять, если склад стабильно затоварен при ровном спросе?** Горизонт покрытия
или коэффициент спроса — они управляют объёмом каждой партии закупки, а не буфером на случай
форс-мажора.
- **Когда снимать ручной прогноз с товара?** Как только по товару накопилась собственная история
продаж достаточной длины — до этого момента расчёт без ручного прогноза будет либо занижать
потребность (новый товар без истории), либо основываться на нерепрезентативном периоде.
- **Можно ли настроить Политику по-разному для разных товаров?** Да, все параметры задаются как
по умолчанию для всей организации, так и переопределяются для конкретного товара — используйте
переопределение для сезонных или нестандартных позиций, а не меняйте общую настройку целиком.
## Спросите ИИ-ассистента
- «У каких товаров рекомендация на закупку выросла сильнее всего за последний месяц?»
- «Покажи товары, где стоит ручной прогноз продаж и когда он перестаёт действовать?»
- «Сравни рекомендуемую закупку с днями запаса — где расчёт противоречит фактической оборачиваемости?»