(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了)