研究partner determination的逻辑能否抽出来，以API的形式被我们Odata service implementation code里调用？

研究partner determination的逻辑能否抽出来，以API的形式被我们Odata service implementation code里调用？

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，如下图：

将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，说明这条路没问题。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":