Can the logic of partner Determination be extracted and invoked in our Odata Service Implementation code in the form of API?
- Can the logic of the research partner determination be extracted and invoked in our Odata Service implementation code by API driving?
I sent a small report ZPARTNER_DETERMINE_VIA_CODE to AG3. The core of the Partner Determination is function module CRM_PARTNER_DETERMINATION_OW. Please refer to the code in this report for details about how to use this FM and what parameters are sent to the Runtime. Finally, the output of determination is an internal table, which contains the BP ID (partner function) determined by each determinate. In my example, employee responsible is determined, as shown in the figure below:
After extracting the logic of Partner Determination, investigate whether the embedded Partner Determination Call can be suppressed in CRM_ORDER_MAINTAIN.
Technically speaking, our requirement is that the partner Determination API should not be called in the entire sub Callstack of CRM_ORDER_MAINTAIN of Callstack 28. But now callstack 36 appears, from the code found callstack 35, line 374 calls the FM statically, without a switch, like the following statement to selectively call:
IF IV_partner_determination_active = ‘X’ CALL FUNCTION ‘CRM_PARTNER_DETERMINATION_OW’ ENDIF
So the research I need to do is to see if there is a way to make this determination call in CRM_ORDER_MAINTAIN execute but not work. I have some ideas, and I need to write POC verification.
- Partner determination in CRM_ORDER_MAINTAIN can also be disabled as follows:
As shown in the second screenshot of the email below, although we cannot prevent the FM CRM_PARTNER_DETERMINATION_OW from being called, we can make it return without doing anything after it is called. The purpose of the Disable Determination is thus achieved.
We simply pass the switch parameter in the Call Order Maintain: (A stands for not executing partner determination. I have tried B, but it cannot be done. If B is passed, the partner determination will be executed in another part of CRM_ORDER_MAINTAIN subcallstack.)
In this way, when the determination API is called, it will check the flag. If the flag is A, EXIT, so that the actual determination step will not be executed.
The Last step: Write a report, set partner_DETERm to inactive, then create an order with CRM_ORDER_MAINTAIN, hard code a BP, If the order can still see the BP after the call CRM_ORDER_SAVE, the path is fine.
For more of Jerry’s original articles, please follow the public account “Wang Zixi “:
