库存数据怎么做成补货产品：从缺货提醒到采购待办

库存低于 10 就提醒，看起来像最简单的数据产品。真正运行后，团队会马上追问：这是哪个仓、哪个变体、可售还是在手、已经承诺给订单的数量算不算、在途什么时候到、补多少、向谁采购、建议是否已经执行。一个数字只有进入采购和调拨工作流，才可能减少缺货与积压。

r/InventoryManagement 的一则多平台库存讨论描述了卖家依靠记忆和未及时更新的表格管理多个渠道，结果同一批库存可能被重复承诺。帖子和回复只是个人情景，不能证明某种软件必然解决问题；它提供的好问题是：哪个系统才是库存真源，渠道标识怎样映射，更新失败时谁会知道。

先定义库存对象，再谈预测

跨渠道时，同一件实物可能拥有内部 SKU、平台 listing ID、商品 ID、变体 ID 和条码。颜色、尺寸、包装数量或套装关系只要映射错误，系统就会更快地同步错误数字。第一版应先建立可人工核对的商品主数据，而不是直接训练销量模型。

一个最小库存键通常需要 inventory item、variant、location 和 quantity state。Shopify 的数量与状态管理指南也将 ProductVariant、InventoryItem、InventoryLevel 和 Location 分成不同对象。渠道 listing 是销售入口，不应自动成为内部商品主键。映射表要记录谁确认、何时生效、是否一对多，以及拆包、组合装和替代品怎样换算。

Shopify 的 InventoryLevel 资源把库存表达为某个 inventory item 在特定 location 的数量，并通过不同 quantity states 访问可售、在手、在途和已承诺等状态。这个模型不能代表所有平台，但足以说明“某 SKU 还有 8 件”缺少地点和状态时是不完整的。

可售、在手、承诺和在途不能混成现货

Shopify 库存应用指南区分 incoming、on_hand、available、committed、reserved、damaged、safety_stock 和 quality_control 等状态。on_hand 是实体地点的总量，其中部分可能已经承诺、保留、损坏或等待质检，不能都用于接受新订单。

补货产品至少要展示四个业务问题：现在可卖多少、已经对订单承诺多少、实物在库多少、已有多少在途且预计何时可用。若某个平台只提供其中一部分，就明确标记覆盖范围，不要通过相减推导出一个看似精确的“真实库存”。

安全库存也不是隐藏地从 available 中扣掉一个固定数。产品要让用户看到安全库存规则、适用地点和生效时间。促销期、供应波动或新品阶段可能需要不同缓冲；任何自动调整都应留下原因和操作记录。

事件更新和定期对账要同时存在

订单、取消、退款、收货、调拨和盘点都会改变库存。事件驱动同步可以缩短延迟，却不能替代定期全量对账。Webhook 可能延迟、重复、乱序或丢失，渠道也可能只对部分状态发送事件。

Shopify 官方指南特别说明，committed、reserved、damaged、safety_stock 和 quality_control 等部分状态变化不会触发相应库存 webhook。只订阅 inventory_levels/update 并不等于掌握全部状态变化。产品需要按来源能力设计补充查询和对账周期。

每个库存事件建议保留来源事件 ID、商品映射、地点、状态、变化量、来源时间、接收时间与处理结果。幂等键防止重复扣减，版本或时间规则处理乱序；定期快照则用于发现事件累计值与来源当前值不一致。

同步失败必须进入异常队列。一个渠道已更新、另一个渠道失败时，不能显示全局成功。站内的API 错误与自愈指南可以帮助区分限流、超时、权限、无效映射和来源错误；这些错误对应不同重试与人工处理方式。

缺货提醒要升级为可解释的补货建议

固定阈值适合非常稳定的小规模业务，但无法处理交货期、销量变化、已下采购单和最小订货量。一个可解释的补货建议至少说明：基于哪个销售窗口、当前可售和在途、预计交货期、目标覆盖天数、供应商约束以及建议数量。

不要把公式藏在“AI 建议”后面。即使使用预测模型，用户也需要看到关键输入和敏感性：如果交货期从 7 天变成 21 天，建议怎样变化；如果促销销量不应外推，谁可以排除这段数据；如果新品没有历史，使用的初始假设是什么。

补货候选可以分三类：

• 立即处理：按当前可售、已承诺、在途和交货期，预计在补货到达前出现缺口。
• 需要确认：销量或交货期数据不足，系统给出缺少字段和建议核对人。
• 暂不补货：库存足够、已有在途覆盖，或商品处于停采和清仓状态。

“暂不补货”不是永久判断。建议应带生成时间、使用的库存版本和失效条件；发生大额订单、供应延期或人工盘点后重新计算。

采购待办才是补货产品的交付终点

提醒之后，采购人员还要选择供应商、确认起订量和包装、申请预算、创建采购单、跟踪发货、收货与质检。若产品只发一封“库存不足”邮件，用户仍要在多个系统里重新整理相同信息。

一张采购候选卡可以包含商品、地点、缺货预计时间、建议数量、在途订单、供应商与交货期、计算依据和异常项。负责人确认后生成采购待办，而不是直接下单。自动下单会产生真实资金与库存风险，应当是后续经过授权、限额和回滚设计的独立能力。

收货后也不能立刻假设全部可售。数量差异、破损与质检状态需要回写，采购单部分到货要保持未完成余额。最终闭环是“建议—批准—下单—在途—收货—可售—结果复盘”，而不是提醒被点击。

数据对象与状态接口可以参考站内的统一数据 API 设计指南。如果同时监控外部商品价格，应将补货决策与价格监控订阅产品分开：价格变化可以影响采购判断，但不能替代内部库存和供应证据。

多仓与多渠道需要明确分配规则

全公司还有库存，不代表某个地点能履约。补货系统应先判断调拨是否优于采购：另一仓是否有可转移库存，运输时间和成本怎样，调出后是否会造成新的缺货。调拨建议和采购建议使用不同动作与审批链。

渠道分配同样需要规则。把全部可售数量同步给每个渠道可能造成超卖；为每个渠道固定切割又可能让库存闲置。可以设置共享池、渠道上限或安全缓冲，但产品要显示策略和最近同步状态。所谓“实时”仍然存在并发订单、网络延迟和平台处理时间，不应承诺零超卖。

对于套装和多包装规格，订单事件要换算为底层组件消耗。例如一个两件装售出一单，需要减少两个基础单位；若同一组件参与多个套装，补货建议必须在组件层汇总需求。映射不确定时，宁可阻塞自动同步并要求确认，也不要继续传播错误数量。

数据质量看板比更复杂的预测更早产生价值

补货误差常常不是算法造成，而是缺少交货期、错误 SKU 映射、盘点滞后、取消订单未回补或在途状态未更新。产品应把这些缺口做成工作队列：哪些商品没有供应商，哪些地点长期未盘点，哪些事件处理失败，哪些采购单已超过预计到货日。

预测也要与实际结果对比。建议时预计何日缺货，最终是否缺货；建议数量是多少，批准数量为何不同；到货后多少天售出，是否形成积压。人工修改不是模型失败的噪声，而是理解业务约束的高价值反馈。

覆盖中断要单独统计。若某渠道授权失效，销量突然变少可能让模型误判需求下降；若库存查询失败，系统可能过度补货。数据新鲜度和来源健康应该与业务指标并列显示。

MVP 从一个采购周期开始

第一版可以只覆盖一个渠道、一个仓库和几十个高频 SKU。先完成商品映射、库存状态、事件对账和采购候选卡，再用一个完整采购周期验证。复杂预测、多仓优化和自动下单都可以后置。

验收指标包括缺货前可用预警时间、同步异常发现时间、建议被采纳或修改的原因、紧急采购次数、缺货和积压变化，以及从建议到下单的处理时间。不要只看通知发送量，也不要在没有对照的情况下把所有库存改善归因于系统。

本文讨论的是库存数据产品化方法，不代表 EveryInfra 已发布库存或采购管理产品。库存数据真正产生价值的时刻，不是看板刷新，而是团队基于可解释建议完成了正确动作，并且系统能够在来源变化、同步失败和人工调整后继续对账。