(1) Can the logic of partner determination be extracted and invoked in our Odata Service implementation code with API driving?

Yes. I have written a small report ZPARTNER_DETERMINE_VIA_CODE in AG3, The core of the Partner Determination is the function module CRM_PARTNER_DETERMINATION_OW. Please refer to the code in the report for information on how to use this FM and what parameters to pass at runtime. The output of the final determination is an internal table, which contains the BP ID of each determined, namely the partner function. In my example, the determine is employee responsible, as shown below:

(2) After extracting the logic of Partner determination, study whether the embedded Partner determination call can be suppressed in CRM_ORDER_MAINTAIN?

G: Technically speaking, our requirement is that there should be no partner Determination API call in the whole sub callstack of CRM_ORDER_MAINTAIN of CallStack 28. But now callStack 36 appears, and from the code we find callStack 35, line 374 statically calls this FM, without a switch, and optionally calls it like this:

IF iv_partner_determination_active = ‘X’.
CALL FUNCTION ‘CRM_PARTNER_DETERMINATION_OW’
              ENDIF.

Therefore, the research I need to do is to see if there is a way to make the determination call in CRM_ORDER_MAINTAIN execute but not take effect. I have some ideas and need to write a POC verification.

  1. The 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 the FM return without doing anything after it is called. Thus, the purpose of disable determination is achieved.

We simply pass a switch parameter when we call order Maintain: (A means not to perform the partner determination. I tried to pass B. If B is passed, the partner determination will be performed in another part of the CRM_ORDER_MAINTAIN subcallstack.)



When the determination API is called, it checks for the flag, and if it is A, EXIT, so that the actual determination step is not executed.

The Last step: Write a report, set partner_determ to inactive, then create an order with CRM_ORDER_MAINTAIN, hard code a BP in, If the order can still see the BP after the last call CRM_ORDER_SAVE, the path is ok.

POC finished, AG3 report ZDETER_AND_CREATE

This report accomplishes three things:

  1. Create a new service Contract with process type SC1
  2. Call partner Determination API, complete the determination logic (in this example, determine out is Employee Responsible: Jerry)
  3. Assign the partner obtained in step2 to the service contract created in step1, and hard code another Bill to party: Wuji
  4. Call Order Save Saves the created Service Contract to DB

Please refer to the attached video for how to use the report.

The following figure is a screenshot of the Service Contract created using POC Report. The red is report Hard code, and the black is calculated by the Partner Determination API.

The practice of Organization unit determination is slightly different from Partner determination. The Organization Unit Determine API (A) is called by A callback (B) registered by the One Order Framework every time the partner data changes on the document.

We have no way to stop B from calling A.

Regarding the disable of Organization Unit Determination (HEREINAFTER referred to as OUD), the following three scenarios are discussed using WebUI as an example:

Create an opportunity, manually enter organization unit, press Enter, trigger CRM_ORDER_MAINTAIN OUD does not trigger, user’s manual input has a higher priority. Technically speaking, there is a conditional judgment before calling OUD API. I wrote a report on AG3, using hard code sales org to simulate user manual input, and found that the API did not get called.

If an Opp has been saved and the Organization Unit is not empty, the OUD API does not trigger when the partner information changes. If an Opp has been saved, the user manually sets the org unit information from the UI to null, and press enter:

My test result is that the OUD API will trigger:

Determine 4 candidates for the user to choose in the form of popup:

If popup is turned off directly, the data on the org Unit is successfully cleared:

For FIORI CASE 1: When creating OPPT, enter ACCOUNT to trigger DETERMINATION. If ORG is DETERMING out, when you save it, it’s actually a manual ORG for the background and it doesn’t trigger OUD, no problem.

CASE 2: When creating OPPT, enter ACCOUNT to trigger DETERMINATION. ORG is not DETERMING out, but the user enters it manually. When saved, it will be a manual ORG for the background and will not trigger OUD. No problem.

CASE 3: When OPPT is created, ORG is not DETERMING, but the user does not enter it manually. It does not matter whether OUD is triggered or not, because there is a large probability that nothing will come out of OUD DETERMING and the order will not change. (Low probability event is due to input other PARTNER in OPPT, resulting in DETERMING ORG when saving)

More of Jerry’s original articles can be found in “Wang Zixi “: