前言： 用Oracle R12的寄售功能的时候，碰到了一个很麻烦的问题：价格抓取的问题。 由于这个问题导致寄售功能在公司一直用不好，库存报表基本都需要他们人工出（自己算每个月每种价格的产品的进出存）。 请教了别的公司的EBS同事，加上自己的实际解决逻辑的考
前言：
用Oracle R12的寄售功能的时候，碰到了一个很麻烦的问题：价格抓取的问题。
由于这个问题导致寄售功能在公司一直用不好，库存报表基本都需要他们人工出（自己算每个月每种价格的产品的进出存）。
请教了别的公司的EBS同事，加上自己的实际解决逻辑的考虑，终于都将问题给解决了，现在总结一下解决的思路，有类似需求的朋友可以参考一下。
由于机密性的考虑，开发的源代码就不共享了，希望理解哈。
一、问题提出
首先，对标准的寄售功能大概说明：
下一揽子PO(BPA)à下标准POà标准PO接收入库à领料等动作(消耗供应商库存)à所有权转移(转移的单价取BPA的(分段)价格)à产生应付(应付的价格取BPA的价格)
标准的寄售功能不能满足的核心问题点：
标准的寄售功能，做消耗的时候，价格都是抓一揽子PO(BPA)行的价格。而实际上，业务部门希望做消耗的时候，抓的价格应该是实际入库的标准PO行的价格(每次接收都是不一样的价格，这样子更加合理)。
同理，传到应付的价格也应该是标准PO行的价格。
就这个价格的问题，需要客制化。
二、问题分析和解决
(一) 客制化逻辑：
核心逻辑是料号启用批次管理，每次接收入库都新增一个批次，这个批次就是从头到尾跟踪物料消耗价格的依据。
举个例子：
料号A下了一揽子PO：BPA1，行价格是1元。
接着料号A用标准PO：SPO1，行价格是1.2元，入库入1000个，批次LOT001。
然后料号A用标准PO：SPO2，行价格是1.5元，入库入2000个，批次LOT002。
如果是直接用标准的寄售功能，在料号A消耗的时候，做所有权转移等物料事务处理的价格都是1元。
应收的价格也是1元。
客制修改后，可以实现的效果：
料号A消耗的时候，因为料号A启用批次管理，则其必须挑选一个消耗的批次。
如果挑选的是批次LOT001，则所有权转移的价格(交易成本)是1.2元，传到应付的价格也是1.2元。
如果挑选的是批次LOT002，则所有权转移的价格(交易成本)是1.5元，传到应付的价格也是1.5元。
不同的入库批次，消耗的价格是完全可以分开的。
(二) 程序实现过程：
主要的开发点是要修改系统在做杂发（或者库存转移）的时候，需要针对消耗寄售的库存部分做定制修改。
大概过程：
例如User是做杂发领料。
1每过账一行（准备做交易的时候），先判断该行是否一定走寄售的流程(是否会自动发生所有权转移)。
由于，料号A的库存，在杂发画面是供应商库存和本公司库存是混合在一起了，按照优先消耗本公司库存的严则，所以要首先判断是否是完全属于寄售的库存的交易，或者完全属于XYG库存的交易。
举个例子，物料A，库存共有5000个；其中本公司库存2000个，供应商库存3000个。
如果发料<=2000个，则肯定是直接扣本公司的库存，不需要走寄售流程了。
如果发料>2000个，则提示错误并禁止其发料。如果允许User这样子操作，程序逻辑很难走了，因为寄售的交易的价格是标准PO的价格，而非寄售交易的价格应该是走系统标准成本(我这里用的是移动平均成本)。一笔物料交易不可能有2个成本。
由于交易是按照组织+库别+货位+料号+批次来进行的，一般寄售的物料的库存和本公司的库存都是分开库别的，所以同时一个库别有2种不同类型的库存是很少的。
2上面第一步已经确定了该笔交易是否属于寄售的交易行。
2.1如果不是，则按照普通的交易走，不做任何的特殊处理。
2.2如果是属于寄售的库存的交易，那么系统会自动做所有权转移。所以，这时候要根据标准PO的价格更新BPA价格和交易成本。
1)根据批次找到对应接收的PO的信息（首次接收的）
更新批次表，记录对应的PO行ID。
自动更新接收方式：将发票匹配选项自动更新为接收R。
2)根据Po_Line_ID找到接收PO的价格
3)根据物料ID，供应商ID，供应商地点ID找到对应的一揽子协议的PO（BPA）行，然后直接根据标准的PO行价格更新BPA行价格。
4)强烈建议将上面找的信息记录到一个中间的控制记录表格。
3调用MTL_ONLINE_TRANSACTION_PUB.PROCESS_ONLINE过账对应的领料行。
4如果过账成功，并且是属于寄售的交易行，这时候应该要将寄售行的单价信息更新回去原来的。
按照上面的步骤一步一步来做，基本可以实现User的目的。
财务方面：
因为做的寄售杂发交易的单价（包括自动产生的所有权转移的交易行价格），都是标准接收PO的单价。
传到应付里面的价格也是标准接收PO的单价。
为了让User方便操作，AP标准的发票匹配画面我也做了一定的客制化。
主要的修改是，匹配画面的默认匹配数量=对应接收编号的PO行的消耗数量-已经开票的数量。
（标准的是，对应接收编码的PO行接收的数量-已经开票的数量）
