Dynamics 365的Period期间，从首个需求而非固定周历起算

把一份需求计划按周一到周日排好，再用它核对Dynamics 365的Period覆盖结果，可能从起点上就出现错位。微软文档中的“期间”不必是固定日历周：它从产品的首个需求开始，覆盖所定义的时间长度；后续期间再从之后的需求开始。

Period是一种补货或批量计算方法。它将一个期间内的需求合并到产品的一张计划订单，订单计划在该期间第一天，数量用于满足该期间的净需求。与之相比，Requirement方法为产品的每项需求建立相应的计划采购、转移或生产订单。两者的关键差别在于怎样组合需求，而不是名称里是否都有“计划”。

为理解起点，可以设想一个没有实际运行过的例子：某项产品的首个需求出现在周三，期间长度被定义为若干天。读Period结果时，应先查从这个需求开始的区间，而不能先把周一固定为起算点。这个例子只说明锚点关系，没有给出具体日历、需求数量或计划结果，也不代替系统对实际工作日和其他条件的处理。

需求被组合后，也不宜把文档中的“一张订单”理解成不受其他设置约束。微软在同一补货说明中列出订单数量的倍数、最小值与最大值等条件：倍数会约束计划数量，最小值规定下限，最大值可能使较大的需求由多张计划订单覆盖。因此，覆盖代码说明了组合方法，却不是从需求表直接推出最终订单数和数量的全部公式。

还有设置来源需要核对。覆盖设置既可以来自覆盖组，也可以针对产品定义；官方指出，产品的Item coverage页面设置优先于Coverage group页面。若只拿一张通用覆盖组截图解释某个产品结果，可能没有看见产品层面的覆盖设置。把“使用了哪个代码”和“这个产品实际上采用了哪一层设置”放在一起记录，才更容易追溯差异。

这里的核对目标是解释计划数据，而不是为企业选择采购策略。Period不因把需求合并就天然更省钱，Requirement也不因逐项形成计划就必然更准确；本文没有比较成本、库存或交付绩效，更没有运行真实补货。

资料依据为2026年10月12日读取的微软Dynamics 365 Supply Chain Management官方说明。阅读Period时，先找到首个需求和所定义的期间长度，再核具体覆盖设置及数量条件，能避免用固定周历解释一个按需求启动的区间。