13｜智能物流上篇：库存、在途和到货日期，怎样一起判断？

双方可能都读到了真实记录，但使用了不同含义。九十六件中有一部分已经预留；在途尚不能销售；需求每天都在发生；延期造成的空档，也不能被更晚到达的数量自动填平。

本篇使用两个海外仓与一款蓝色 M 码 T 恤的模拟情境，介绍如何建立一致的供货事实。所有仓库、数量、日期与需求估计均用于学习，不是本站物流项目的实施成果。

采购真正需要完成的任务，是收到新事实后重新判断供货，再把结果交给有权批准和继续执行的人。读取通知、核对库存、关联单据、比较方案、取得批准和跟进结果，共同构成这项工作。

如果项目只做一张库存看板，采购仍可能在看板、聊天、报价和装箱单之间往返。若系统只生成“建议补货”的一句话，数量、日期、预算和责任还需要人工重新整理。

因此，调查应跟踪一次具体变化怎样传递。物流何时得知延期？原计划在哪里保存？哪些判断依赖旧日期？采购用了哪个库存快照？运营何时获得更新后的承诺？这条链会暴露数据与岗位之间真正需要改善的连接。

延期通知是事件，它应当改变相关在途对象的预计日期，并触发受影响方案重新检查。它不能只成为知识库里新增的一段文字，任由旧表格继续沿用原日期。

物流判断的基本粒度应足以区分实际履约对象。本例使用“SKU×仓库”：SKU 表示具体商品规格，至少需要区分款式、颜色与尺码；仓库表示货物所在位置。

同款蓝色 L 码不能直接替代蓝色 M 码，另一个仓库的数量也不能在没有调拨与运输条件的情况下，直接成为目标仓的现货。公司总库存有管理意义，但不能替代一项具体履约判断。

当前业务判断时点固定为九月十日九点。每份资料还需说明自己的观察时间和接收时间。今天九点上传的文件，可能记录前天的余额；九点形成的判断，可以使用八点观察的库存，但必须确认这种时效是否符合业务约定。

关键身份缺失时，应保留未知。单据只写“蓝 T”，可以给出候选商品，请责任人核对；不能因为系统当前正在处理 M 码，就静默把所有同类材料归到这个 SKU。

本例中，吉隆坡仓有实物 96 件，有效预留 24 件，质量隔离 0 件。按照本例的互斥扣减口径，当前可售为 96－24－0＝72 件。

这项关系必须服从原系统字段定义。有些系统的“可用库存”已经扣除了预留或隔离，接入时若再扣一次，就会产生新错误。因此不能把公式当成所有仓库通用规则，必须先核对字段是否重叠、是否已经净额处理。

另外还应区分声明、实收与合格。箱唛写二十四件，只说明发货方声明；签收说明运输交接发生，未必完成清点；合格可售则可能需要检验与入账。系统不能因为识别到了数字，就把它加进可售库存。

旧在途四十八件，可能同时出现在采购单、装箱单、两张箱唛照片和运输通知中。若按文档中出现的数量累加，会把一批货计算成多批。反过来，后续新采购也可能恰好是四十八件，又不能因为数字相同就与旧批次合并。

正确关联需要商品、采购行、运输批次、箱件和事件之间的关系。多份资料可以为同一个对象提供不同证据：采购单说明订购，装箱单说明装箱，通知更新预计日期，收货记录才产生实际接收状态。

图中的四个来源并不代表四次供给。系统需要能够从结论回到各份原件，也能知道哪条新通知改变了当前有效事实。

图像识别只是这个过程的一段。尺码被胶带遮挡时，模型应保留未知并查其他依据；文件内容相似时，应使用稳定业务标识关联。文件哈希能够发现完全相同的文件，却不足以判断两次不同扫描是否指向同一业务事件。

当前可售为 72 件，模拟需求从九月十一日起按每天 8 件估计。若没有新增供给，72 件可以覆盖十一日至十九日共九天的需求。

旧在途 48 件的预计可售日已经推迟到二十二日。因此，在没有其他补救措施、需求估计不变且库存条件成立的前提下，二十日和二十一日各有 8 件需求无法及时满足，累计为 16 件。

这里的 16 件是预测未满足需求，不是负十六件实物库存，也不是已经发生的退款或利润损失。二十二日到货能否处理积压，还取决于客户是否接受延迟、订单是否仍有效以及企业的分配规则，需要另外记录。

每日 8 件也是一个需求假设，应说明来源与适用范围。活动、订单或需求估计发生变化时，需要重算。系统可以帮助形成预测，但不应把预测写成已确认销售。

逐日计算适合交给确定性程序。模型可以解释为什么存在空档、整理待补资料和比较结果；数量运算与事件顺序应能够复算，避免每次措辞变化都产生不同结论。

假设系统收到一份刚上传的旧库存表，里面仍有更高可售数量。若按上传时间排序，它可能覆盖当前快照，风险提示随之消失。

正确做法是根据业务观察时间、来源权威性和版本规则判断。接收时间用于说明系统何时获得资料，不能单独决定业务事实的新旧。缺少观察时间或超过可用窗口时，应暂停相关批准或要求补充快照。

如果两份同一时点的权威资料仍然冲突，则需要展示差异并找责任人确认。系统可以计算影响，例如不同余额会使风险日期前后变化，但不能在缺少规则时自行选择更乐观的一份。

冲突处理也要留下状态。哪些结论仍可用，哪些暂时仅供分析，哪些动作已经被阻断，应当让采购与审批人清楚可见。一个“数据可能不准”的小提示，不足以支持继续执行高影响动作。

完成这些整理，采购应拿到一组可追溯的共同事实：目标 SKU 与仓库、当前判断时点、有效库存、需求假设、旧在途的独立身份、最新预计日期，以及不确定项。

这组事实可以写进供货判断卡：

这张卡不直接批准任何采购，也不表示货物一定按时到仓。它提供的是方案比较需要的可信输入。

第一期可以限定两个仓库、一个 SKU 和相关供货任务，先验证身份、时间、数量与反馈关系。范围越清楚，越容易知道系统在哪些条件下有效，也更容易发现一个错误究竟来自资料、规则还是后续协作。

可以用一个双时间练习检查输入是否可靠。准备两份相同 SKU 与仓库的库存文件：第一份观察时间更早但上传更晚，第二份观察时间更晚但先进入系统。让系统说明本次判断采用哪份，以及另一份为何保留为历史。若只按上传顺序选择，就应在进入方案比较前修正。

再将较新文件的观察时间移除。系统此时应明确时效无法确认，说明受影响判断，并向仓库责任人请求补充。它仍可以整理已有材料，却不应对当前可售作出没有条件的结论。

最后把同一在途批次的照片重新扫描一次。即使文件内容与哈希改变，只要仍指向相同业务对象，就不能增加供给。时间选择和对象关联分别通过，才有较可靠的预测输入；两项检查不能由最终算式碰巧正确来替代。

下一篇将基于这组事实比较三种补救方案，并继续追到批准、供应商确认、收货与质量反馈。物流系统的结果，需要随着实际发生的事情不断更新。

如果团队经常跨表格、消息和单据重新整理事实，AI随心创的AI 场景诊断与工作流设计可以从具体任务、资料条件和人工确认点开始讨论。一般资料提取也可先了解AI 助手，再评估哪些步骤需要规则、系统集成或专业复核。