(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驗證。

2. 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完成三件事情：

1. 建立一個新的process type為SC1的service contract
2. call partner determination的API，完成determination 邏輯(這個例子裡determine出來的是employee responsible：Jerry)
3. 將step2 得到的partner assign到step1建立的service contract裡，同時hard code 另一個Bill to party：Wuji
4. 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的原創文章，盡在："汪子熙":