MRP运算过程添加数据策略干预计划订单信息

MRP运算是大数据量级运算，并且标准逻辑已经将生成的目标单计划订单（或组织间需求单）数据计算正确，完整。正常情况不允许外界干预，因此生成的计划订单走的是ORM保存，并不触发保存插件。

不过通常情况下，一些客户的需求是，并不用干预计划订单产生的核心逻辑，只是对一些自定义字段仅做信息携带，但是因为计划订单未走保存插件，因此没办法通过常规的添加计划订单保存插件来实现。

对于这种情况，也是有解决方案，MRP的强大之处正是客户化扩展。通过以下四个步骤，即可实现MRP生成的计划订单完成一些信息携带：

一、
在BOS中对MRP数据模型元数据进行扩展，将附加策略类页签放开可见，并且设置该表体的策略实现类和实现类描述这两个字段设为可编辑。如下图：

二、在前端打开编码为“MRP_DP_NC_CommitData”（名为“MRP计算逻辑--提交计算数据并释放资源”）的MRP数据策略，将二开的数据策略作为附加策略类添加上去，这里只能手工填。留意下图的策略实现类写法，该字段值分为两部分，前面是实现类，后面是组件名，中间用逗号隔开。如下图：

三、编写上一步注册的附加策略类，以下策略是经过验证OK的示例，代码结构可直接使用，具体业务逻辑需要根据实际调整。策略示例：
using Kingdee.K3.Core.MFG;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Kingdee.K3.MFG.PLN.App.MrpModel.PolicyImpl.NetCalc
{
///

/// MRP运算将产生的计划订单或组织间需求单数据提交保存前更新数据策略
///

[MrpProgressItem("P0033", "30")]
public class UpdatePlanOrderCustInfoPolicy : AbstractNetCalcPolicy
{
///

/// 后置策略：单条执行模式
///

public override AbstractNetCalcPolicy.Enu_NetCalcPolicyCallStyle CallStyle
{
get { return Enu_NetCalcPolicyCallStyle.KdLastSingleExecutionMode; }
}

///

/// 策略执行前事件
///

///
protected override bool BeforeExecuteDataPolicy()
{
foreach (var demandGroupRow in this.MrpDemandDimContext.MrpNetDemandContextGroupRows)
{
if (demandGroupRow.PlanOrderItem != null)
{
///TODO：本分支可对计划订单数据在提交保存前进行干预
//这里示例更新计划订单量=需求数量+计划订单数量
//因为在整个MRP过程中，为提升性能，因此内存中都是基本数量在运转，实际业务数量将在提交数据库保存之后直接进行update更新，所以本示例是用基本数量来说明。
//如果需要取得计划订单业务数据进行再加工，则可跟帖讨论，是在另一个时机的数据策略中可实现
demandGroupRow.PlanOrderItem["BaseSugQty"] =
Convert.ToDecimal(demandGroupRow.PlanOrderItem["BaseDemandQty"]) + Convert.ToDecimal(demandGroupRow.PlanOrderItem["BaseOrderQty"]);
}

if (demandGroupRow.RequirementOrderItem != null)
{
///TODO：本分支可对组织间需求单数据在提交保存前进行干预
}
}

return base.BeforeExecuteDataPolicy();
}
}
}

四、重启IIS，重跑MRP，即可看到附加策略类已经生效。如下图：

结语，可能有人已经留意到，第三步插件更改的其实是基本单位建议数量，而第四步截图展现的却是业务建议数量被更改。这里就存在一个时机问题，因为第二步所述的数据模型是在计划订单数据运算完成，即将提交至数据库保存，并且后续才进行单位换算。因此我们在第三步的插件中更改了基本单位数量后，业务数量后续被换算正确了。
当然，计划订单的数量作为核心逻辑，二开原则上不应该干预，本例是为了说明更多原理（比如策略执行时机，单位换算时机等），才举了数量字段进行讲解。
另外，如果还有需要针对计划订单已经保存进数据库的数据进行干预，虽然也是支持的，但我们并建议这种玩法，尽量参照本例的做法对保存前的计划订单数据进行有限的干预。