Fans Or Not

如下图所示，第一个是标准功能的工作流通知，第二个是自己开发的工作流通知。

在通知正文中，都有发件人信息，但是在工作列表中有的有，有的没有。这一点，事实上也是我对Oracle Workflow颇有微词的地方:) 既然在通知正文的活动历史记录中拥有发件人信息，为什么在列表中就没有呢？

Message中有许多内置的属性，要在列表中显示发件人信息，只需设置一个role类型的attribute，内部名称为#FROM_ROLE。还有许多特殊用途的内部名称，详细可以参考文档《Oracle Workflow Developer’s Guide》。

某月的第一天早上，突然许多业务部门反映无法使用系统了。快速重现了下问题，出错提示是“PO_INV_MUL_PERIODS”（竟然没有Message内容）。查会计期，8月份出现两条同样的记录。

如果存在两条同样的会计期记录——除ACCT_PERIOD_ID以外——可能会导致数据传总账等模块出现异常，所以必须首先确定两条记录是否同时产生，也就是说，在第一条记录产生到第二条记录产生之间有没有有过事务处理，以及第二个ACCT_PERIOD_ID有没有相应的事务处理（通常情况下应该没有的）。大致需要检查以下几处：
1. WIP_COST_TXN_INTERFACE
2. WIP_MOVE_TXN_INTERFACE
3. MTL_MATERIAL_TRANSACTIONS
4. MTL_MATERIAL_TRANSACTIONS_TEMP
5. MTL_TRANSACTIONS_INTERFACE

如果没有记录，则删除后产生的那条重复的会计期记录即可。遇到这种突然状况，只能自认倒霉，糟糕的是，我根本无法重现。Metalink 459128.1 讲到过这个问题，据说打上那个补丁就不会出现类似问题。

当然，为了避免出现隐患，我依旧询问了Oracle的工程师，给出的解决方案和我判断的一致。

EBS 11i的接收事务处理器是不公开源代码的，你不知道它的内部处理逻辑。在利用接口来衔接不同的系统时，我们只能相信文档所言。但是有时候，答案往往又令人困惑。

接收开放接口 RCV_TRANSACTIONS_INTERFACE 中有个字段：VALIDATION_FLAG，该字段告诉接收开放接口是否在处理数据之前进行验证。它接受”Y”和”N”。接收开放接口该字段默认为”Y”。

重现交货时分配数量计算错误的BUG（Oracle一度坚持说这是特性）：
1, 创建一个PO，五个分配行，数量分别为5327,2003,3555,11830,359,15。
2, 对PO做接收（交货路线为要求检验），实际接收数量为7420.98（小于可接收数量），并检验。
3, 此时会出现奇怪的现象，见截图：

留意第三个交货行数量。如果第一行和第二行被交货，则地三行会是90.98。Oracle唯一的解释就是，当第1、2个分配行交货后，该数值被四舍五入了，但是为何如此，他给不出解释，而是转而问我对业务影响有多大。

通过接口处理：
1，将配置文件 RCV: Processing Mode 设置为 Batch
2，接收事务处理选择之前的记录（第3条），数量修改为90.98
3，保存
4，修改接口数据，VALIDATION_FLAG 默认为空，将其修改为 Y
5，手工执行接收事务处理器。
6，返回接口表，显示错误信息：此事务处理没有要处理的数量。
7，重新将 VALIDATION_FLAG 修改为空，并执行接收事务处理器。
8，返回接口表，发现记录已被正常处理。

利用这个BUG可以发现，VALIDATION_FLAG 实际上并非如文档所言默认为“Y”。