(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的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的关于用 ABAP 代码手动触发 SAP CRM organization Model 自动决定的研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。