Oracle Fans

在定义说明性弹性域段的时候，我们通常只定义“Global Data Elements“的段。实际上，说明性弹性域还可以根据参考字段显示不同的字段，比如说，对于不同的国家区域显示不同的弹性域字段。

在定义说明性弹性域界面，点击”参考字段“，输入同一个块中存在的字段名，可以按需要输入多个。假设块中有一个字段叫“COUNTRY_CODE”，这时，在定义说明性弹性域段的时候，就可以在“参考字段”处的值列表中选择之前所输入的参考字段。在“上下文字段值”处假设有“CN”和“US”两行，分别定义相应的段。那么在form界面中，如果字段COUNTRY_CODE值为CN，则显示上下文字段值为CN的段。

定义说明性弹性域界面的参考字段包含但不仅限于所定义的，还可以直接引用相关字段值，比如:BLOCK.USER_COUNTRY_CODE。因此，在定义说明性弹性域的时候输入参考字段，在很多情况下并没有太多意义。

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

在通知正文中，都有发件人信息，但是在工作列表中有的有，有的没有。这一点，事实上也是我对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”。

将一个用户的某个职责失效后重新查询，发现出来两个同样的职责，并导致无法新增职责。

解决办法为依序执行下列并发请求：
1， 使责任职责数据与 WF 表同步。
2， 同步 WF 局部表
3， 工作流目录服务用户/职责验证 （参数：修正不匹配用户/职责，添加丢失的用户/职责分配 均为“是”）

基本上，用户职责相关信息存储在 FND_USER, FND_RESPONSIBILITY, WF_LOCAL_USER_ROLES, WF_USER_ROLE_ASSIGNMENTS 这四张表里，如果数据完整性被破坏，则可能导致相关问题。EBS中必须手工同步FND_USER到工作流用户职责表中，也可以设置为定期请求自动同步。

然而光是FND_USER和WF用户数据不同步并不能导致本文所述的问题。追溯该用户所有可能导致该问题的变动，可能可以联系到APC。Oracle EBS 的Advanced Product Catalog（高级产品目录）是11i版本中免费使用的应用，它主要用于工程物料的创建的维护。在APC中可以为物料的创建设置审批流，如果用户从该审批流中移除，则可能导致出现该问题。

如果是对采购订单做审批，在选择“Approve”后订单状态可立即更新为“批准”，但是采购申请的审批则不是这么回事。

图：活动历史记录

图：状态图

Metalink(382935.1) 上给出了解释，大意是说由于系统和当前审批人的联系非常紧密，如果他已登录，则会导致无法处理。这个理由，或者说是这个工作流的设计，有点不着头绪。Metalink 367659.1 列出了所有类似的问题，这些问题都出现在11.5.9 and 11.5.10 两个版本中。

In the case of delegate, deferring the workflow is inevitable as the whole application is closely tied with the person who is logging in.

The response from the delegated-to person has to be processed as if the original approver responds. Since the application is tightly integrated with the person who has logged the above cannot be achieved because the person who has logged in currently is the delegated-to person.

一种推荐的解决办法就是定期执行工作流后台流程 (workflow background process)，该程序会定期收集处于待定状态的工作流，并继续推动工作流到下一步骤。