(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，并没有一个开关，形如下面的语句来选择性地进行调用：
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到。
针对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了)
