restock

Restock

把两个 Skill 串联起来，让补货最终落到账本里，而不是止步于一封被遗忘的邮件：inventory-planner 决定采购什么，ap-processor 预先登记它将产生的成本。

这一步要填补的缺口很小，但代价不低。补货量算出来了，采购订单（PO）起草好了，邮件也发了，却没有在任何地方留下记录。于是六周后账单寄到时，没人能判断当初的价格或数量是否正确。

第 1 步：确定采购什么（inventory-planner）

调用 inventory-planner。

• 输入： 来自 Shopify、Square 或 NetSuite 的销售历史和库存现量，或上传的包含两者的 CSV 文件。
• 输出： 每个商品的 7 天和 28 天周转速度、保守的缺货日期、附带美元成本的 60 天补货量，以及单独的滞销品清单。

inventory-planner 负责所有计算，包括两个周转速度窗口、异常数据处理、交期比对以及季节性规则。此处不要重复任何计算。

其中有两条规则足够重要，需要在流程中点明：

• 零周转商品永远不是补货候选。 它们会以滞销品的形式列出，并标明占压的资金。没有销量意味着停止采购，而不是多买。
• 缺货期间不等于零需求。 那段时间是被抑制的需求，若将其视为零，该商品将持续被少订。

审批关口：采购清单。 在起草任何文件之前，先展示总金额和即将缺货的商品数量。由负责人批准清单、删减，或调整数量。每一行都包含周转速度、可售天数、交期、数量和成本，使决策只需一分钟，而无需重新计算。

第 2 步：起草采购订单和供应商邮件（inventory-planner）

对于已批准的条目，inventory-planner 按供应商分别起草采购订单，并以负责人的口吻撰写随附邮件。

审批关口：采购订单和邮件需分别获得明确同意，且与第 1 步分开。 批准采购清单只是对采购什么达成一致。发送采购订单则意味着承诺资金并消耗供应商关系。提问前应先说明供应商、明细行和总金额。

若未连接邮件连接器（Gmail 或 Microsoft 365），采购订单和邮件将以文件形式交由负责人手动发送。这同样是一个完整的结果。

第 3 步：留下供未来账单比对的记录

这里发生两件不同的事情，必须明确哪个 Skill 负责哪一部分。

inventory-planner 保管采购订单本身。 已批准的采购订单是它的文件，包含供应商、明细行、数量、价格和预计日期。它会在第 2 步中保存并交给负责人，这就是已下单内容的记录。

ap-processor 接收的是编码备注，而非采购订单。 向它提供供应商、采购订单号、总金额、预计日期，以及该笔支出所属的科目、类别和项目。ap-processor 不会在账本中创建采购订单，而是在账单到达时读取它们，以执行账单、采购订单与收货单的三单匹配。这一步交给它的，是一条已编码的记录，并放在三单匹配时会查找的位置。

• 输入： 供应商、采购订单号、总金额、预计日期和编码信息。
• 输出： 一条归档在该供应商名下的编码备注，使得六周后账单到达时，可以将价格和数量与实际批准的内容进行核对。

审批关口：编码确认。 这是 ap-processor 自身的关口，在此同样适用。在负责人同意之前，不会向账本写入任何内容；也不会作为账单或付款入账。本命令不产生任何资金流动，为到货付款属于 /pay-the-bills 的职责。

若新供应商的编码不确定，ap-processor 会先提问，而不是猜测。现在多问一个问题，好过全年编码错误。

若未连接账本连接器，编码备注将与采购订单一同作为导入文件和摘要输出。三单匹配之后仍会手动进行，只是比对的对象已经是一份实际存在的记录。

第 4 步：让它成为一种节奏

Ray Okonkwo 经营 Okonkwo Mechanical，他靠一个零件货架，缺货时才去查，而那时通常已经太晚。连接 Google Calendar 后，在一次老板觉得有用的补货之后提供一次选项：在日历上添加一个定期时段，用于补货决策。

把它做成节奏，远比做成救火要好。只提供一次。如果对方说不，或者没有回应，就取消这个提议。

备选路径

销售 CSV 加上库存盘点，是完全受支持的输入。许多企业是用纸和笔盘点的，这同样是合法数据。周转速度、缺货日期、补货数量、采购单和供应商邮件，结果都一样。账目条目则变成导入文件。

不要做的事

• 未经批准，不要发送采购单或供应商邮件。 前者花钱，后者消耗信誉。
• 不要把采购清单的批准当作发送的批准。 两道关口，两次决定。
• 不要为零周转的商品补货。
• 不要在计算补货数量时不扣除已在途的数量。 重复订购一件滞销品，会把现金压上好几年。
• 不要编造周转速度、交货周期或缺货日期。 历史数据不足的，要按 SKU 单独说明。
• 这里不要付任何款项。 采购单只是暂存，不是付款。付款请使用 /pay-the-bills。
• 不要只报数量不报金额。 老板要决定的是现金，而不是件数。

输出

按老板保存的输出偏好交付补货计划，绝不默认生成 markdown 文件。 请检查 ## Business context 区块中的 Output preference（参见共享样式指南规则，../../shared/artifact-style.md）：

• 可视化成果物（默认）： 以符合站点风格的 HTML 页面呈现计划。将计划承诺的总金额作为首个主要数据卡片，以金额显示；每个 SKU 为一行，包含周转速度、缺货日期和补货数量，数字使用等宽数字（tabular-nums）；对已在途的商品加一个标签。采购单文档及任何导入文件作为工作文件附带，不作为第二份交付物。
• 偏好 docx / md / notion / canva： 以该形式交付相同内容：DOCX 或 markdown 文件；通过连接器创建的 Notion 页面（指定目标名称，绝不覆盖现有页面）；或通过 Canva 连接器创建的 Canva 文档（每次运行新建一个设计，以日期命名；表格转为列表）。如果 Notion 或 Canva 未连接，则退回可视化成果物，并说明原因。
• Best for skill： 使用可视化成果物。此输出是一项采购决定，而非散文。

运行之后

采购单已发出，一份已编码的记录正在等待，以便账单到达后进行匹配。账单到达后，自然的下一步是“付账单”：/pay-the-bills 会执行匹配、现金检查和付款关口。另外相关的还有“现金预测”（cash-flow-snapshot），用于查看已承诺的订单会如何影响未来 60 天；以及“结账本月”（/close-month），在期间结束时使用。最多提供三个选项，并跳过老板在本次会话中已拒绝的任何选项。

使用未列出的工具

本技能中提及的连接器是经过测试的路径，并非唯一选择。如果老板希望此流程使用未连接或未列出的工具，可提供 build-connector：它会先检查连接器目录，否则通过 Zapier 进行连接，绝不直接调用原始 API 手动构建。连接建立后，该工具将和其他可选连接器一样加入本技能，并受同样的批准关口约束。