inventory-planner

Inventory Planner

买进会卖的货，要赶在断货之前；别再买卖不动的货。

库存就是老板已经花掉的现金。常见的问题有两个：客户要买的商品断货，或者仓库里压着一托没人要的货。这两种情况在销售历史中都能提前看出端倪，而本技能读取的正是这些数据。

第 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 步 — 呈现采购清单

先给出总金额，以及即将断货的商品数量。随后依次列出：立即订购、尽快订购、慢销品，以及历史数据过少而无法判断的商品。

每一行都须附上依据的数字：流速、可售天数、交货周期、数量和成本。业主若能看清推理过程，几分钟内即可完成审批；若看不清，就只能自己从头重新核算。

按照 ../../shared/artifact-style.md 中的统一产物样式，将采购清单渲染为 HTML 产物：包含一张按断货日期排序的断货表格（数字使用等宽且等宽数字的字体），紧急状态标签（立即订购 / 尽快订购 / 正常 / 已错过最晚订购时间），一个包含数量和金额小计的补货面板，以及一个展示占用资金的慢销品板块。聊天摘要保留不变，该产物是完整视图，而非唯一视图。

第 8 步 — 起草采购单和供应商邮件，并等待批准

采购单会承诺资金支出，供应商邮件会以业主名义发出，因此两者都须等待业主明确同意。

在询问之前，先说明供应商、各行明细和总金额。按照共享语气档案，以业主的语气起草供应商邮件。若尚无语气档案，请遵循该文件中“无样本时”的说明，即请业主提供三封其已经发给供应商的邮件。若业主不愿提供，则撰写平实中性的邮件，并说明该邮件不符合其语气风格。切勿为他人的供应商关系虚构某种人设。

若已连接 Google 日历，可为补货决策提供一个定期时间块。相比临时应急处理，这种有节奏的安排效果要好得多。在此保留已批准的采购单文档，因为本技能负责该文档。若已连接 QuickBooks 或 NetSuite，则为每份采购单向 ap-processor 提供带编码的备注（包括供应商、采购单号、总金额、预计到货日期，以及科目、类别和项目），以便账单到货时能与真实记录进行三单匹配。ap-processor 负责读取采购单，但不负责创建采购单。

结束语与后续提议

用一行话总结已做出的决定：本次采购总额和即将售罄的商品。随后提出最相关的下一步，并附上准确的触发短语："reorder"（/restock），适用于业主希望端到端起草并发出采购单的情况。另可从路由器表中再提出至多两项，例如 "cash forecast"（cash-flow-snapshot）或 "pay the bills"（/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：导致畅销品断货或让资金积压在库存中的常见错误

使用未列出的工具

本 Skill 中提及的连接器是经过测试的路径，并非唯一选择。如果店主希望此流程使用尚未连接或未列出的工具，可以提供 build-connector。它会先检查连接器目录，若没有对应连接器，则通过 Zapier 进行连接，绝不会基于原始 API 手动构建。连接建立后，该工具与其他可选连接器一样加入本 Skill，并同样受相同的审批关卡约束。