订单已存在，净需求页为什么还可能保持旧结果

供应链计划人员看到一份新供应订单，却在净需求页找不到相应变化，容易把两个观察合成一个判断：“订单没有保存。”Microsoft Learn关于Planning Optimization与旧主计划引擎的差异表，说明订单记录形成与净需求结果显示之间，存在需要保留的计算背景。

差异表先描述已弃用的旧引擎：物料的手工供应订单会自动出现在该物料净需求中。它举从销售订单建立采购订单的例子，说采购订单无需先执行其他动作，就出现在Net requirements页。文档解释旧机制会记录库存交易，并在动态计划的净需求页显示变化。这个背景属于旧引擎，不能仅因同属Dynamics 365就无条件套到另一种引擎上。

对于Planning Optimization，原文写得不同：手工建立的订单要等到包含该物料的计划运行，或通过净需求页所述的物料主计划更新，才出现在该物料净需求中。这里采用的是两条途径都涉及计划计算这一信息，不转述点击入口或安排运行。尤其不能省去“包含该物料”，只写成系统任意一次计划运行都会更新所有结果。

下一行把同样的区别扩展到供需变化。旧引擎自动呈现变化，而Planning Optimization的净需求更新仍依赖相应计划计算。原文的例子包括计划订单数量变化。这让阅读者可以区分两种问题：供应或需求记录发生了什么变化，以及当前查看的净需求结果已经纳入哪次变化。后一个问题不能仅靠前一个记录的新时间戳回答。

设想一份只用于沟通的假设记录，甲处保存“订单已建立”，乙处保存“净需求页当前显示值”。若乙尚未包含新变化，两条记录并不必然相互否定。需要补充的是引擎类型、物料以及结果的计算背景，而不是根据一张截图断言采购失败。这个分析没有执行计划或检验任何企业数据，也不证明真实缺失一定由上述机制造成。

本文只采用微软差异表的这两行及相邻语境，首次发布日期未确认。不选择覆盖代码、不修改库存和计划参数、不安排补货或承诺交付。对供应链软件资料而言，将订单身份与结果更新时点分开，能帮助描述现象而不先补造原因；具体业务是否正常，仍要有与当前计划、物料和订单相对应的实际证据。