重新分配审批工作流时 [ 授权您回应 ]和 [转让通知所有权] 之间的区别

重新分配审批工作流时 [ 授权您回应 ]和 [转让通知所有权] 之间的区别

Oracle EBS/ERP中,审批工作流或者分配工作流的时候，如果想授权或者转移工作流给一个用户的时候，有时候会遇到以下的选项

授权您回应
经理可以将所有通知审批权限授予给助手。

转让通知所有权
经理可以将特定项目通知传送给该项目的新经理。

界面如下图所示

虽然界面上有相应的注释，可是对于普通用户，这样的解释还是有点云里雾里，到底两者有什么区别呢？

我们来看看英文的界面，其界面如下:

相应的文字如下:

Delegate your response
A manager may delegate all notification approvals to an assistant.

Transfer notification ownership
A manager may transfer a notification for a specific project to the new manager of that project.

我们来看看Delegate和Transfer的含义:

Delegate
n.代表，代表团成员;
vt.委派代表; 授权给; [法律]债务转移;

Transfer
n. 转让；转移；传递；过户
vi. 转让；转学；换车
vt. 使转移；调任

采用比较直观的理解:假设通知是车，如果是授权(Delegate)，那就是车借你开下，车主不变，如果有罚单，那么还是车主收到，如果是转让通知所有权(Transfer),那就相当于车过户了。

关于这两个选项之间的区别，以下是个人理解的一些汇总:

1.只有当用户有权限选择[委托]或者[转移]通知的时候，才会出现此选项，如果用户只能使用其中的一个权限，那么系统默认根据唯一可以访问的权限进行通知再分配。决定该权限的是配置文件[WF: Notification Reassign Mode],其值可以是Delegate, Transfer或者Reassign。但是管理功能[Grant Worklist Access]不受此配置文件影响。

2."Delegate your response" "授权您回应" :如果你想授权其他人对你的通知进行回应，但是保留通知所有权的时候，使用此选项。比如，经理可以在授权度假期间的审批给其助手。这种选项，通知的所有权不发生变化。

3."Transfer notification ownership" "转让通知所有权":如果想让该用户拥有该通知完全的所有权和对该通知负责的时候，使用该选项。比如，如果你收到一个本来属于他人的通知或者需要其他人来解决和自己无关的通知的时候，就使用此选项。转让通知所有权，可能会影响通知的审批层次，举例来说，如果一个项目(Project)的所有权发生了变化，那么原有经理可以采用此选项将通知所有权转让给新经理。这种选项，通知的所有权发生变化。

4.授权Delegate

授权通知给其他用户，意味着被授权用户有责任处理该通知，但是该通知的所有权不会发生变化。当一个用户授权给其他用户的时候，系统会使用原用户的批注更新通知，然后以要求回应[PNF]和转发[FORWORD]的模式处理此通知，这样，被授权用户就可以在工作列表(worklist)中看见该通知，但是通知所有者(owner)始终未产生变化。

5.转移通知所有权 Transfer

转移通知所有权，以为着被转移人变成了该通知的所有者。转移之后，新用户可以完全掌握和对该通知做任何处理和回应，其他人也会看到该用户作为新拥有者出现，如果通知被转移，系统会以要求回应[PNF]和转发[FORWORD]的模式处理此通知，如果转移时有批注，这个时候，会被写入通知表中。通知的新主人就会在通知列表中看见该通知，接下来，其有责任回应，转移，授权或者忽视该通知(respond, transfer, delegate or ignore the notification)。

6.Ignore (忽视)

如果用户不回应通知，如果工作流设计的时候，设计了timeout功能，到期之后，那么工作流会按照timeout的规则来处理该工作流，如果没有过期功能，如果用户使用了忽视，该流程就会一停在那里，直到有人为干预。

7.我应该选择授权还是转移？(Transfer or Delegate?)

我们来看一个具体的例子，首先，设想有一个报销流程。用户收到了一个通知，询问其审批或者拒绝一个报销单。如果通知审批通过，系统就要开始验证该审批人是否有权限审批通过该报销单。

如果通知是通过委托(delegate)发送给了一个用户，那么通知的owner没有发生变化。当流程验证审批者是否有权限审批此报销单时，会去检查该通知的Owner是否拥有权限。
如果同时是通过转移(transfer)发送给了一个用户，那么通知的owner就变成了被发送的用户，在这种情况下，系统检查权限的时候，就是用该通知的新主人来检查。

假设初始通知人的审批权限是500,以下表格给出了在委托(Delegate)和转移(Transfer)的情况下，工作流会如何解释审批权限。

还能想到的例子是，Oracle采购中，采购中，工作流生成的通知有时会有对应的附件，用来审批时参考。如果转移工作流，附件是不会转移给新的用户，因此在审计上会有缺陷点。所以在采购中，通知只能委托不能转移，而系统中目前也是这么做的，对于需要审批的通知，不允许转移。

8.对审批层次的影响

假设系统中有两个审批层次，A-->B--->C 和 D-->E--F
A提交的审批由B审批，然后到C。

1) C "Transfers"通知给F.

经过F的最终审批，A会收到一个最终审批通知，显示最终审批人是F而不是C。

2) C "Delegates" 通知给F.
经过F的最终审批，A会收到一个最终审批通知，显示最终审批人是C.

3) A提交的审批到达B，然后B "Transfers" 给了 D。

D 审批之后，审批的层次结构发生变化，会到达 E 然后 F。

4) A提交的审批到达B，然后B "Delegates" 给了 D。

D 审批之后，审批的层次结构不发生变化，会到达C。

-EOF-