Планирование запасов и дозаказа

Считает, что и когда дозаказать по реальным продажам, показывает замороженные в залежавшемся товаре деньги и готовит заказы.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Считает, что и когда дозаказать по реальным продажам, показывает замороженные в залежавшемся товаре деньги и готовит заказы.
Когда брать: Когда нужно понять, что закончится на складе, сколько и когда заказывать и какой товар не продаётся.
Когда не брать: Если нет ни истории продаж, ни остатков: без этих данных скилл ничего не посчитает.
Пример запроса: Посмотри продажи за последние месяцы и скажи, что мне нужно дозаказать, а что лежит без движения.
Работает лучше с: Shopify, Square или NetSuite, календарь, QuickBooks, почта

Входит в плагин small-business. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку inventory-planner в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: inventory-planner
description: >
  Определяет, что и когда дозаказывать, исходя из того, что реально продаётся:
  берёт историю продаж и остатки на складе из Shopify, Square, NetSuite или
  загруженного CSV, считает скорость продаж по каждой позиции за 7 и за 28
  дней, прогнозирует осторожную дату, когда товар закончится, рассчитывает
  объём дозаказа на 60 дней и готовит заказы поставщикам и письма им. Также
  показывает замороженные деньги — затоваривание, неходовой товар и позиции с
  нулевой скоростью продаж, которые подаются как медленно идущий товар для
  распродажи, а не как то, чего нужно купить ещё. Сезонность учитывается там,
  где её подтверждает история, и называется там, где не подтверждает.
  Без одобрения ничего не заказывается и ни одному поставщику не пишется.
  Обращайся к скиллу, когда речь заходит об остатках: «что мне нужно
  дозаказать», «у меня закончится товар», «что заказать в этом месяце», «у нас
  постоянно кончаются фильтры», «сколько денег лежит на складе», «что не
  продаётся» или «набросай заказ для моего поставщика».
allowed-tools: Read, WebFetch
---

Планирование запасов

Закупай то, что продаётся, до того как оно закончится, и перестань закупать то, что не продаётся.

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

Шаг 1. Получи продажи и остатки

Предпочтительно: Shopify для продаж и уровней запасов. Square и NetSuite работают так же.

Запасной вариант, полностью поддерживаемый: CSV с историей продаж плюс подсчёт остатков на складе. Два файла или один с обоими. Этот путь работает без единого коннектора и даёт тот же результат. Многие считают запасы по бумажке на планшете, и это допустимый вход.

По каждой позиции нужны: SKU, название, продано единиц по датам, текущий остаток, себестоимость единицы, цена единицы, поставщик и срок поставки, если он известен. Недостающий срок поставки спрашивается один раз и запоминается — см. reference/data_sources.md.

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

Шаг 2. Посчитай скорость продаж по обоим окнам

Для каждой позиции посчитай:

Скорость за 7 дней — единиц в день за последнюю неделю. Ловит то, что происходит сейчас.
Скорость за 28 дней — единиц в день за четыре недели. Устойчивая база.

Важны обе, и расхождение между ними — информация. Позиция, которая на этой неделе продаётся втрое быстрее, чем по 28-дневному темпу, либо набирает обороты, либо получила один крупный заказ, и реагировать нужно по-разному. Как их различить, описано в reference/velocity_and_reorder.md.

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

Шаг 3. Спрогнозируй даты окончания товара — осторожно

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

Затем сравни со сроком поставки. Важно не то, когда товар закончится, а то, остаётся ли ещё время заказать:

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

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

Шаг 4. Рассчитай объём дозаказа

Целевой запас по умолчанию — 60 дней покрытия плюс срок поставки, рассчитанный по 28-дневной скорости, а не по большей из двух. Запасов должно хватить с того дня, когда товар приедет, до того дня, когда приедет следующий заказ, поэтому если не учитывать срок поставки, позиции каждый цикл не хватит ровно на столько дней. Затем поправь на размер упаковки, минимальный объём заказа и то, что уже заказано.

Две скорости выполняют разную работу, и обе называются в строке: большая говорит, когда товар закончится, 28-дневная — сколько покупать. Рассчитывать заказ на 60 дней по недельному всплеску — верный способ превратить деньги в паллету.

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

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

Шаг 5. Разберись с позициями, которые не движутся

Позиции с нулевой скоростью и очень медленные — отдельный список с отдельной целью. Они никогда не кандидаты на дозаказ.

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

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

Шаг 6. Учитывай сезонность только там, где её подтверждает история

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

Если меньше года, скажи об этом и не корректируй. Сезонный коэффициент, выдуманный по девяти месяцам данных, — догадка в деловом костюме. Спроси лучше владельца: свой сезон он знает лучше, чем короткая история. Оба пути описаны в reference/seasonality.md.

Шаг 7. Покажи список закупок

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

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

Оформи список закупок как HTML-артефакт в фирменном стиле артефактов (../../shared/artifact-style.md): таблица окончания запасов, отсортированная по дате окончания, с моноширинными цифрами одинаковой ширины (tabular-nums), метками срочности (заказывать сейчас / заказывать скоро / в порядке / точка невозврата пройдена), панель дозаказа с количествами и суммами в деньгах и раздел медленно идущего товара с замороженными в нём деньгами. Итог в чате остаётся — артефакт показывает полную картину, а не единственную.

Шаг 8. Подготовь заказы поставщикам и письма им — с одобрения

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

Перед запросом одобрения назови поставщика, позиции и итог. Пиши письмо поставщику голосом владельца по [общему профилю голоса](../../shared/voice-profile.md). Если профиля ещё нет, следуй указанию этого файла «Если образца нет»: попроси три письма, которые владелец уже отправлял поставщику. Если он не хочет, напиши письмо просто и нейтрально и скажи, что оно написано не его голосом. Никогда не выдумывай характер для отношений владельца с поставщиком.

Если подключён Google Calendar, предложи повторяющийся блок для решения о пополнении запасов — это работает гораздо лучше как ритм, чем как аврал. Одобренный документ заказа храни здесь — он принадлежит этому скиллу. Если подключён QuickBooks или NetSuite, передай ap-processor размеченную по статьям записку на каждый заказ (поставщик, номер заказа, итог, ожидаемая дата, счёт, класс и объект учёта), чтобы счёт при поступлении сверялся с реальной записью по трём документам. ap-processor читает заказы, но не создаёт их.

Завершающее предложение

Закончи одной строкой о принятом решении — общая сумма закупки и позиции, которые скоро кончатся. Затем предложи самый уместный следующий шаг с точной фразой-триггером: «дозаказать» (/restock), когда владелец хочет, чтобы заказы были подготовлены и отправлены от начала до конца. До двух других предложений из таблицы маршрутизатора, например «прогноз денежных средств» (cash-flow-snapshot) или «оплати счета» (/pay-the-bills). Не больше трёх предложений и никогда не повторяй то, от чего владелец уже отказался в этой сессии.

Чего не делать

Не выдумывай скорость продаж, срок поставки или дату окончания товара. Недостаточная история указывается по SKU, а не сглаживается.
Не считай период отсутствия товара нулевым спросом. Это подавленный спрос, и он искажает всё дальнейшее.
Не рекомендуй дозаказывать позицию с нулевой скоростью продаж. Нет продаж — перестать закупать, а не купить больше.
Не рассчитывай дозаказ, не вычтя то, что уже в пути.
Не применяй сезонность без годовой истории. Спроси владельца.
Не отправляй заказ или письмо поставщику без одобрения. И то и другое тратит деньги или доброе отношение.
Не показывай штуки без денег. Владелец думает деньгами.

Справочные файлы

reference/data_sources.md — Shopify, Square, NetSuite и путь через CSV, с обязательными полями
reference/velocity_and_reorder.md — расчёт по 7 и 28 дням, обработка искажений и расчёт дозаказа
reference/seasonality.md — когда корректировать, когда спрашивать и как сказать, что ты сделал
reference/po_drafting.md — структура заказа поставщику и написание письма поставщику
reference/gotchas.md — ошибки, из-за которых хит продаж заканчивается, а деньги оседают на паллете

Если нужного инструмента нет в списке

Коннекторы, названные в этом скилле, — проверенные пути, а не стена. Если владелец хочет, чтобы этот процесс использовал инструмент, который не подключён или не указан, предложи build-connector: он сначала смотрит каталог коннекторов, а если там нет, подключает через Zapier и никогда не собирает вручную интеграцию с сырым API. Когда подключение появится, инструмент входит в скилл как любой другой необязательный коннектор, на тех же условиях одобрения.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/inventory-planner, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: inventory-planner
description: >
Works out what to reorder and when, from what is actually selling: pulls
sales history and stock on hand from Shopify, Square, NetSuite, or an
uploaded CSV, computes 7-day and 28-day sales velocity per item, projects a
conservative stockout date for each, sizes a 60-day reorder quantity, and
drafts the purchase orders and vendor emails to cover it. Flags the money
sitting still too — overstock, dead stock, and zero-velocity items, reported
as slow movers to clear rather than things to buy more of. Seasonality is
applied where the history supports it and named where it does not. Nothing
is ordered and no vendor is emailed without approval. Reach for this
whenever stock comes up — "what do I need to reorder," "am I going to run
out," "what should I order this month," "we keep running out of filters,"
"how much cash is sitting in the warehouse," "what is not moving," or "draft
a PO for my supplier."
allowed-tools: Read, WebFetch
---

# Inventory Planner

Buy what sells, before it runs out, and stop buying what doesn't.

Stock is cash the owner already spent. Two things go wrong: running out of the item customers came for, and sitting on a pallet of something nobody wants. Both are visible in the sales history well before they become a problem, which is what this skill reads for.

## Step 1 — Get sales and stock

**Preferred:** Shopify for sales and inventory levels. Square and NetSuite work the same way.

**Fallback, fully supported:** a CSV of sales history plus a stock-on-hand count. Two files, or one with both. This path works with zero connectors and gives the same output. Many businesses count on a clipboard, and that is a legitimate input.

You need, per item: SKU, name, units sold by date, current stock on hand, unit cost, unit price, vendor, and lead time if known. Missing lead time is asked for once and remembered — see `reference/data_sources.md`.

**Say what the count is as of.** A stock figure two weeks old produces a stockout date two weeks wrong.

## Step 2 — Compute velocity, both windows

For every item, compute:

- **7-day velocity** — units per day over the last week. Catches what is happening now.
- **28-day velocity** — units per day over four weeks. The stable baseline.

Both matter, and disagreement between them is information. An item selling three times its 28-day rate this week is either trending or had one bulk order, and those need different responses. `reference/velocity_and_reorder.md` covers how to tell them apart.

Exclude one-off distortions from the baseline where you can identify them: a single wholesale order, a returned batch, a stockout period where the item could not sell. **A period of zero sales because there was no stock is not zero demand**, and treating it as such is how an item gets under-ordered forever.

## Step 3 — Project stockout dates, conservatively

Stockout date is stock on hand divided by the daily velocity you trust least — the higher of the two windows. Being early is cheap; being late loses the sale.

Then compare against lead time. The number that matters is not when it runs out, it is whether there is still time to order:

- **Past the point of no return** — lead time exceeds days of cover. Already going to stock out. Say so plainly.
- **Order now** — cover is within lead time plus a safety buffer.
- **Order soon** — comfortable, but on the next cycle.
- **Fine** — no action.

**Never state a stockout date for an item with no reliable velocity.** New items with two weeks of history and items whose sales were interrupted get flagged as "not enough history," by name.

## Step 4 — Size the reorder

Default target is **60 days of cover plus the lead time**, sized on the **28-day rate** — not on the faster of the two. The stock has to last from the day it lands until the next order lands, so leaving the lead time out runs the item short by exactly that many days every cycle. Then adjust for pack size, minimum order quantity, and what is already on order.

The two rates do different jobs and both get named on the line: the higher one says when it runs out, the 28-day one says how much to buy. Sizing a 60-day order off a one-week spike is how cash ends up in a pallet.

Never size a reorder without subtracting inbound stock. Double-ordering a slow item is how a business ends up with three years of it.

Round to the vendor's pack size and say which direction you rounded. Show the dollar cost of every recommendation — the owner is deciding about cash, not units.

## Step 5 — Handle the items that are not moving

Zero-velocity and very slow items are a separate list with a separate purpose. **They are never reorder candidates.**

- **Zero velocity** — no units in 28 days. Report as a slow mover with the cash tied up in it. **Never compute days of cover for these** — nothing is selling, so nothing is running out, and the number is either an error or nonsense. The one exception is an item inside a season the owner has named, which goes on a dated watch list instead of the clear-out list.
- **Overstock** — more than 120 days of cover. Report the excess units and the dollars.
- **Dead stock** — no movement in 90 days. Suggest clearing, bundling, or discounting.

Total the cash sitting in these. That figure is usually the most surprising number in the whole report and often the most useful one.

## Step 6 — Apply seasonality only where history supports it

With at least a year of history, compare the coming period against the same period last year and adjust.

**With less than a year, say so and do not adjust.** A seasonal multiplier invented from nine months of data is a guess wearing a suit. Ask the owner instead — they know their season better than a short history does. `reference/seasonality.md` covers both paths.

## Step 7 — Present the buy list

Lead with the total dollar amount and the count of items about to stock out. Then: order now, order soon, slow movers, and anything with too little history to judge.

Every line carries the numbers behind it — velocity, days of cover, lead time, quantity, cost. An owner who can see the reasoning approves in a minute; one who cannot rebuilds the whole thing by hand.

Render the buy list as an HTML artifact using the house artifact style (`../../shared/artifact-style.md`): a stockout table sorted by stockout date with mono tabular-nums numerals, urgency status pills (order now / order soon / fine / past the point of no return), a reorder panel with quantities and dollar totals, and a slow-movers section with the cash tied up in it. The chat summary stays — the artifact is the full picture, not the only one.

## Step 8 — Draft POs and vendor emails, with approval

Purchase orders commit money and vendor emails go out under the owner's name, so both wait for an explicit yes.

State the vendor, the line items, and the total before asking. Draft the vendor email in the owner's voice per [the shared voice profile](../../shared/voice-profile.md). **If no profile exists yet, follow that file's "When there is no sample" instruction** — ask for three emails they have already sent a supplier. If they would rather not, write the email plain and neutral and say it is not in their voice. Never invent a personality for someone's vendor relationship.

With Google Calendar connected, offer a recurring block for the restock decision — this works far better as a rhythm than as a fire drill. Keep the approved PO document here — this skill owns it. With QuickBooks or NetSuite connected, hand `ap-processor` the coded memo for each one (vendor, PO number, total, expected date, and the account, class, and job), so the bill three-way-matches against a real record when it arrives. `ap-processor` reads POs; it does not create them.

## Closing offer

Close with one line on what was decided — the total buy and the items about to run out. Then offer the most relevant next step with its exact trigger phrase: "reorder" (`/restock`) when the owner wants the POs drafted and sent end to end. Up to two more from the router's table, such as "cash forecast" (`cash-flow-snapshot`) or "pay the bills" (`/pay-the-bills`). Three offers at most, and never repeat one the owner already declined this session.

## What not to do

- **Do not invent a velocity, a lead time, or a stockout date.** Too little history is reported by SKU, not smoothed over.
- **Do not treat an out-of-stock period as zero demand.** It is suppressed demand and it biases everything downstream.
- **Do not recommend reordering a zero-velocity item.** No sales means stop buying, not buy more.
- **Do not size a reorder without subtracting what is already inbound.**
- **Do not apply seasonality without a year of history.** Ask the owner instead.
- **Do not send a PO or a vendor email without approval.** Both spend money or spend goodwill.
- **Do not report units without dollars.** The owner thinks in cash.

## Reference files

- `reference/data_sources.md` — Shopify, Square, NetSuite, and the CSV path, with required fields
- `reference/velocity_and_reorder.md` — the 7/28-day math, distortion handling, and reorder sizing
- `reference/seasonality.md` — when to adjust, when to ask, and how to say which you did
- `reference/po_drafting.md` — purchase order structure and vendor email drafting
- `reference/gotchas.md` — the mistakes that stock out a bestseller or bury cash in a pallet

## Using a tool that isn't listed

The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer `build-connector` — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.

Источник: anthropics/knowledge-work-plugins / small-business / inventory-planner ↗. Ссылка проверена 2026-10-10.

---
name: inventory-planner
description: >
  Определяет, что и когда дозаказывать, исходя из того, что реально продаётся:
  берёт историю продаж и остатки на складе из Shopify, Square, NetSuite или
  загруженного CSV, считает скорость продаж по каждой позиции за 7 и за 28
  дней, прогнозирует осторожную дату, когда товар закончится, рассчитывает
  объём дозаказа на 60 дней и готовит заказы поставщикам и письма им. Также
  показывает замороженные деньги — затоваривание, неходовой товар и позиции с
  нулевой скоростью продаж, которые подаются как медленно идущий товар для
  распродажи, а не как то, чего нужно купить ещё. Сезонность учитывается там,
  где её подтверждает история, и называется там, где не подтверждает.
  Без одобрения ничего не заказывается и ни одному поставщику не пишется.
  Обращайся к скиллу, когда речь заходит об остатках: «что мне нужно
  дозаказать», «у меня закончится товар», «что заказать в этом месяце», «у нас
  постоянно кончаются фильтры», «сколько денег лежит на складе», «что не
  продаётся» или «набросай заказ для моего поставщика».
allowed-tools: Read, WebFetch
---

# Планирование запасов

Закупай то, что продаётся, до того как оно закончится, и перестань закупать то, что не продаётся.

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

## Шаг 1. Получи продажи и остатки

**Предпочтительно:** Shopify для продаж и уровней запасов. Square и NetSuite работают так же.

**Запасной вариант, полностью поддерживаемый:** CSV с историей продаж плюс подсчёт остатков на складе. Два файла или один с обоими. Этот путь работает без единого коннектора и даёт тот же результат. Многие считают запасы по бумажке на планшете, и это допустимый вход.

По каждой позиции нужны: SKU, название, продано единиц по датам, текущий остаток, себестоимость единицы, цена единицы, поставщик и срок поставки, если он известен. Недостающий срок поставки спрашивается один раз и запоминается — см. `reference/data_sources.md`.

**Скажи, на какую дату сделан подсчёт.** Остаток двухнедельной давности даёт дату окончания товара с ошибкой в две недели.

## Шаг 2. Посчитай скорость продаж по обоим окнам

Для каждой позиции посчитай:

- **Скорость за 7 дней** — единиц в день за последнюю неделю. Ловит то, что происходит сейчас.
- **Скорость за 28 дней** — единиц в день за четыре недели. Устойчивая база.

Важны обе, и расхождение между ними — информация. Позиция, которая на этой неделе продаётся втрое быстрее, чем по 28-дневному темпу, либо набирает обороты, либо получила один крупный заказ, и реагировать нужно по-разному. Как их различить, описано в `reference/velocity_and_reorder.md`.

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

## Шаг 3. Спрогнозируй даты окончания товара — осторожно

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

Затем сравни со сроком поставки. Важно не то, когда товар закончится, а то, остаётся ли ещё время заказать:

- **Точка невозврата пройдена** — срок поставки больше, чем запас в днях. Товар уже закончится. Скажи об этом прямо.
- **Заказывать сейчас** — запас укладывается в срок поставки плюс страховой буфер.
- **Заказывать скоро** — запас комфортный, но заказ на следующий цикл.
- **В порядке** — действий не нужно.

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

## Шаг 4. Рассчитай объём дозаказа

Целевой запас по умолчанию — **60 дней покрытия плюс срок поставки**, рассчитанный по **28-дневной скорости**, а не по большей из двух. Запасов должно хватить с того дня, когда товар приедет, до того дня, когда приедет следующий заказ, поэтому если не учитывать срок поставки, позиции каждый цикл не хватит ровно на столько дней. Затем поправь на размер упаковки, минимальный объём заказа и то, что уже заказано.

Две скорости выполняют разную работу, и обе называются в строке: большая говорит, когда товар закончится, 28-дневная — сколько покупать. Рассчитывать заказ на 60 дней по недельному всплеску — верный способ превратить деньги в паллету.

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

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

## Шаг 5. Разберись с позициями, которые не движутся

Позиции с нулевой скоростью и очень медленные — отдельный список с отдельной целью. **Они никогда не кандидаты на дозаказ.**

- **Нулевая скорость** — ни одной единицы за 28 дней. Подай как медленно идущий товар с указанием замороженных денег. **Никогда не считай для них запас в днях** — ничего не продаётся, значит, ничего не кончается, и цифра либо ошибка, либо бессмыслица. Единственное исключение — позиция внутри сезона, который назвал владелец: она попадает в список наблюдения с датой, а не в список на распродажу.
- **Затоваривание** — запас больше чем на 120 дней. Покажи избыток в единицах и в деньгах.
- **Неходовой товар** — движения нет 90 дней. Предложи распродать, объединить в набор или сделать скидку.

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

## Шаг 6. Учитывай сезонность только там, где её подтверждает история

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

**Если меньше года, скажи об этом и не корректируй.** Сезонный коэффициент, выдуманный по девяти месяцам данных, — догадка в деловом костюме. Спроси лучше владельца: свой сезон он знает лучше, чем короткая история. Оба пути описаны в `reference/seasonality.md`.

## Шаг 7. Покажи список закупок

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

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

Оформи список закупок как HTML-артефакт в фирменном стиле артефактов (`../../shared/artifact-style.md`): таблица окончания запасов, отсортированная по дате окончания, с моноширинными цифрами одинаковой ширины (tabular-nums), метками срочности (заказывать сейчас / заказывать скоро / в порядке / точка невозврата пройдена), панель дозаказа с количествами и суммами в деньгах и раздел медленно идущего товара с замороженными в нём деньгами. Итог в чате остаётся — артефакт показывает полную картину, а не единственную.

## Шаг 8. Подготовь заказы поставщикам и письма им — с одобрения

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

Перед запросом одобрения назови поставщика, позиции и итог. Пиши письмо поставщику голосом владельца по [общему профилю голоса](../../shared/voice-profile.md). **Если профиля ещё нет, следуй указанию этого файла «Если образца нет»:** попроси три письма, которые владелец уже отправлял поставщику. Если он не хочет, напиши письмо просто и нейтрально и скажи, что оно написано не его голосом. Никогда не выдумывай характер для отношений владельца с поставщиком.

Если подключён Google Calendar, предложи повторяющийся блок для решения о пополнении запасов — это работает гораздо лучше как ритм, чем как аврал. Одобренный документ заказа храни здесь — он принадлежит этому скиллу. Если подключён QuickBooks или NetSuite, передай `ap-processor` размеченную по статьям записку на каждый заказ (поставщик, номер заказа, итог, ожидаемая дата, счёт, класс и объект учёта), чтобы счёт при поступлении сверялся с реальной записью по трём документам. `ap-processor` читает заказы, но не создаёт их.

## Завершающее предложение

Закончи одной строкой о принятом решении — общая сумма закупки и позиции, которые скоро кончатся. Затем предложи самый уместный следующий шаг с точной фразой-триггером: «дозаказать» (`/restock`), когда владелец хочет, чтобы заказы были подготовлены и отправлены от начала до конца. До двух других предложений из таблицы маршрутизатора, например «прогноз денежных средств» (`cash-flow-snapshot`) или «оплати счета» (`/pay-the-bills`). Не больше трёх предложений и никогда не повторяй то, от чего владелец уже отказался в этой сессии.

## Чего не делать

- **Не выдумывай скорость продаж, срок поставки или дату окончания товара.** Недостаточная история указывается по SKU, а не сглаживается.
- **Не считай период отсутствия товара нулевым спросом.** Это подавленный спрос, и он искажает всё дальнейшее.
- **Не рекомендуй дозаказывать позицию с нулевой скоростью продаж.** Нет продаж — перестать закупать, а не купить больше.
- **Не рассчитывай дозаказ, не вычтя то, что уже в пути.**
- **Не применяй сезонность без годовой истории.** Спроси владельца.
- **Не отправляй заказ или письмо поставщику без одобрения.** И то и другое тратит деньги или доброе отношение.
- **Не показывай штуки без денег.** Владелец думает деньгами.

## Справочные файлы

- `reference/data_sources.md` — Shopify, Square, NetSuite и путь через CSV, с обязательными полями
- `reference/velocity_and_reorder.md` — расчёт по 7 и 28 дням, обработка искажений и расчёт дозаказа
- `reference/seasonality.md` — когда корректировать, когда спрашивать и как сказать, что ты сделал
- `reference/po_drafting.md` — структура заказа поставщику и написание письма поставщику
- `reference/gotchas.md` — ошибки, из-за которых хит продаж заканчивается, а деньги оседают на паллете

## Если нужного инструмента нет в списке

Коннекторы, названные в этом скилле, — проверенные пути, а не стена. Если владелец хочет, чтобы этот процесс использовал инструмент, который не подключён или не указан, предложи `build-connector`: он сначала смотрит каталог коннекторов, а если там нет, подключает через Zapier и никогда не собирает вручную интеграцию с сырым API. Когда подключение появится, инструмент входит в скилл как любой другой необязательный коннектор, на тех же условиях одобрения.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/inventory-planner, лицензия Apache-2.0. Изменения: перевод на русский язык.