(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的原创文章，尽在："汪子熙":