创建和处理计划

创建和验证单一计划

若要集成传入下达订单的需求，“下达管理”会为 BOD 消息创建新的单一计划。针对计划排程和发货排程创建单独的单一计划。PlanningSchedule、ShipmentSchedule 和 SequenceSchedule BODs 映射到消息类型为“Planning Schedule”或“Shipment Schedule”的对应单一计划。

在需求经过完全处理并转换成新计划之前，新单一计划会一直经过不同的处理级别。单一计划的当前处理状态表示一系列处理中的某个步骤。执行并完成这些步骤来验证和计算新需求。新建单一计划会收到处理状态“新建”。

单一计划是特定于货品。如果 BOD 消息包含几个货品的需求，则必须按货品将需求分割并映射到单一计划。

然后，验证单一计划。验证检查，例如：客户、客户的收货方、消息类型和消息子类型。检查还会评估货品，并将新计划指定给相应合同行。结果是全局验证的单一计划。单一计划会收到处理状态“已全局验证”。

进行全局验证后，系统会执行特定于过程的验证。例如，特定于过程的验证可以包括对传输号序列的检查或对编号的检查。单一计划会收到处理状态“计划已特别验证”。

计算某消息类型的新单一计划

对于每个消息类型的需求，都存在单独的单一计划。

根据定义的日期范围规则准备新单一计划。定义了日期范围的需求排程设定在该时间范围内的特定日期。或者，这些需求拆分到整个日期范围内的几个相等需求。新单一计划会收到处理状态“日期范围规则已处理”。

在下一步中，定义的 CUM 调整规则用于计算在途数量。单一计划会收到处理状态“在途数量已计算”。

必须根据需求合并规则合并相同消息类型的新需求与当前需求。这些规则确定现有需求如何集成到新的单一计划。单一计划会收到处理状态“已调整”。

在下一步中，检查定义的手动审批规则。这些规则确定是否必须在“未处理计划”页面上手动审批单一计划。

合并新需求与其他消息类型的现有需求

合并计划用于计算某消息类型的新需求数量，以及其他消息类型的现有需求数量。例如：在现有计划排程时间跨度以内的新发货排程的需求。完成这一步之后，计划会收到处理状态“已合并”。

下一步计算合并计划的净数量。必须将此数量发送到 ERP 系统。计划会收到处理状态“净数量已计算”。在途数量抵消有效需求数量。

将某消息类型的调整需求另存为新单一计划。将不同消息类型的合并需求另存为新合并计划。

将合并计划的需求传输到 BOD 消息

在下一步中，新合并计划的订单行需求将被分解并传输到 PlanningSchedule、ShipmentSchedule 和 SequenceSchedule BOD。根据 BOD 分解规则，将合并计划的需求传输到其他 BOD 类型。这些 BOD 将由 ION 连接程序服务发布到 ION，并由连接的 ERP 系统导入。