头图

关于用 ABAP 代码手动触发 SAP CRM organization Model 自动决定的研究

JerryWang_汪子熙

(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验证。

  1. CRM_ORDER_MAINTAIN里的partner determination也可以disable,方法如下:

如下面邮件第二个截图,我们虽然没法阻止CRM_PARTNER_DETERMINATION_OW 这个FM本身被调用,但我们可以做到让这个FM被call到了之后,不做任何事情,直接return,从而也就达到了disable determination的目的。

我们只需在call order maintain时传个switch参数进去:(A代表不执行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的原创文章,尽在:"汪子熙":

阅读 278

Jerry Wang的SAP技术专栏
SAP成都研究院开发专家,SAP社区导师,SAP中国技术大使

Jerry 2007年从电子科技大学计算机专业硕士毕业后进入SAP成都研究院工作至今, SAP社区导师,SAP中国技术...

781 声望
1k 粉丝
0 条评论

Jerry 2007年从电子科技大学计算机专业硕士毕业后进入SAP成都研究院工作至今, SAP社区导师,SAP中国技术...

781 声望
1k 粉丝
文章目录
宣传栏