(1) 研究partner determination的逻辑能否抽出来，以API的行驶被我们Odata service implementation code里调用？
Yes. 我在AG3写了一个小的report ZPARTNER_DETERMINE_VIA_CODE，partner determination的核心是function module CRM_PARTNER_DETERMINATION_OW，关于如何使用这个FM，runtime时需要传递哪些参数，请参考该report的代码。
最后determination的output是一个internal table，里面包含了每个determine出来的BP id即partner function。在我的这个例子里，determine出来的是employee responsible，如下图：
(2)将Partner determination的逻辑抽出来之后，研究能否在CRM_ORDER_MAINTAIN里suppress住里面内嵌的partner determination call？
Technically speaking，我们的需求是在callstack 28的CRM_ORDER_MAINTAIN的整个sub callstack里，不应该出现partner determination API的调用。
但是现在callstack 36出现了，从代码发现callstack 35 ， line 374静态地调用了这个FM，并没有一个开关，形如下面的语句来选择性地进行调用：
IF iv_partner_determination_active = ‘X’.
CALL FUNCTION ‘CRM_PARTNER_DETERMINATION_OW’
ENDIF.
所以我需要做的research就是，看是否有方法让CRM_ORDER_MAINTAIN里的这个determination call执行但不生效。我已经有了一些idea，需要写个POC验证。
- CRM_ORDER_MAINTAIN里的partner determination也可以disable，方法如下：
如下面邮件第二个截图，我们虽然没法阻止CRM_PARTNER_DETERMINATION_OW 这个FM本身被调用，但我们可以做到让这个FM被call到了之后，不做任何事情，直接return，从而也就达到了disable determination的目的。
我们只需在call order maintain时传个switch参数进去：（Ａ代表不执行partner determination, 我试过传B不行，传B的话，partner determination会在CRM_ORDER_MAINTAIN subcallstack的另一处执行）
这样determination API被call到的时候，里面会去检查这个flag，如果为A，则EXIT，这样真正的determination step不会执行。
Last step：写一个report，将partner_determ置为inactive，然后用CRM_ORDER_MAINTAIN创建一个order，
hard code一个BP进去，如果最后call CRM_ORDER_SAVE之后order仍然能够看到这个BP，说明这条路没问题。
POC做完了，AG3 report ZDETER_AND_CREATE
这个report完成三件事情：
- 创建一个新的process type为SC1的service contract
- call partner determination的API，完成determination 逻辑(这个例子里determine出来的是employee responsible：Jerry)
- 将step2 得到的partner assign到step1创建的service contract里，同时hard code 另一个Bill to party：Wuji
- call order save将创建的service contract保存到DB
如何使用该report请参考附件的video。
下图是一个使用POC report创建的service contract的截图，红色是report hard code的，黑色是partner determination API计算出来的。
Organization unit determination的实际和Partner determination稍有不同。
首先要明确，Organization unit determine的API（A），是每次document上partner 数据发生change后，由one order framework注册的一个callback（B）调用的。
我们没有办法阻止B去call A。
关于organization unit determination（以下简称OUD）的disable，以WebUI为例，分三种scenario讨论：
新建一个opportunity，手动输入organization unit，回车，trigger CRM_ORDER_MAINTAIN
OUD不会触发，user 的manual input具有更高优先级。Technically speaking，在call OUD API之前有个条件判断。
我在AG3上写了一个report，用hard code sales org的方式来模拟user 手动输入，发现API确实不会被call到。
如果一个Opp已经存盘，且organization unit不为空，那么当partner信息发生change后，OUD API不会触发。
如果一个Opp已经存盘，user从UI手动把org unit信息置为空，回车：
我的测试结果是OUD API会触发：
Determine出4个candidate 以popup的形式让user选择：
如果直接关掉popup，可以成功保存，此时org unit数据成功被清空：
针对FIORI的情况
CASE 1:
在创建OPPT的时候，输入ACCOUNT，触发DETERMINATION。 如果ORG被DETERMING出来了，存盘时，对后台来说这其实是个手动输入的ORG，不会触发OUD，没问题。
CASE 2:
在创建OPPT的时候, 输入ACCOUNT，触发DETERMINATION。ORG没有被DETERMING出来，但用户手工输入了，存盘时，对后台来说这是个手动输入的ORG，不会触发OUD，没问题。
CASE 3:
在创建OPPT的时候ORG没有被DETERMING出来，但用户没有手工输入，存盘时，OUD是否触发关系不大，因为大概率事件是OUD DETERMING不出来任何东西，不会改变订单，没问题。(小概率事件是由于在OPPT中输入了其他PARTNER，导致存盘的时候能DETERMING出来ORG了)
更多Jerry的原创文章，尽在："汪子熙":
网友评论