Dynamics365时间序列：逐次编辑怎样归入命名版本

Demand planning的时间序列既有数值，也有数值被修改的过程。Microsoft Learn说明，每次编辑单元格都会记入变更日志，记录改变的时间及作出改变的用户；与此同时，上次版本之后积累的编辑可以保存为新版本，并给予名称。[1] 这两种记录粒度不同：一次编辑是一项事件，一个版本则可以容纳多次编辑形成的状态。

版本历史中的日志按所属版本分组。官方文字说明，每个相关编辑事件都有日志项，这些项嵌套在对应版本下。于是，版本名称为一组变化提供整体身份，展开后的事件则继续解释它怎样形成。只转抄一个名称，会省略内部改动；只留下若干独立时间，又不说明它们归入哪个版本，也会丢失原有的分组联系。

“当前版本”还有需要保留的细节。文档明确指出，时间线顶部总是当前版本，但其中可能已经包含上次保存版本之后发生的编辑。[1] 因此，当前并不必然等于某个已经命名并保存的历史节点。阅读一份当前数据摘录时，若仅用最近保存版本的名字概括，就可能漏掉后来积累的修改。这是依据版本定义作出的资料分析，不是对某个真实账户状态的诊断。

初始版本则与创建事件相连。原文说明，初始版本及其日志项代表时间序列的建立，而且始终保存为一个版本。这个规则使建立时的状态有自己的历史节点，而后续编辑再逐渐形成其他版本。这里的先后是数据版本的演变，并不是序列横轴中日期的先后；不能把最早的一条业务日期直接叫作初始版本。

版本也能成为比较对象。文档举例，叠加时间序列时可以选择所用版本，甚至把同一序列的旧版本叠加到当前序列，以查看版本之间的变化。[1] 这种比较保留“同一个序列、不同版本”的条件。若一份说明只写两条曲线不同，却遗漏版本身份，读者便无法确定差别来自版本变化还是另一个序列。本文未读取图中数值，也没有运行叠加。

该页还说，停用一个版本不会影响较新版本的值，停用版本不再出现在版本选择器里。由此可见，版本可见状态与较新数据的值各有含义，不能把某个旧版本未列出直接写成后续数值被撤销。本文采用页面的版本控制与变更日志文字，2025年8月18日是更新标记，首次发布日期未知；不提供编辑、恢复或停用步骤，也不据这些历史记录形成预测、采购或财务建议。