Hello everyone. I am Rodrigo from SAP Support team. I have been working at SAP since 2021 with the SD team.

After noticing many problems related to credit exposure update that are hard for customers to troubleshoot, I have decided to write this blog to empower customers getting further knowledge in the topic. On this blog, I am going to focus on credit exposure update during creation of a sales order with an item relevant for delivery. The item in the order would have quantity of 1 PC and the price would be of 1 EUR.

The analysis will be from SD perspective. It will be explained steps until the commitments are sent to method IF_UKM_COMMITMENT_PUSH_R3-PUSH_COMMITMENT. The example is meant for SAP Credit Management (FSCM) only.

The system used is an internal SAP system S/4HANA 2021. In the example, credit check will not block the document since it resets the confirmed quantities and then there would be no credit exposure updated as per standard logic.

Before showing the debugging steps, there are some points important to know for analysis that I will mention below.

Important points to know about credit exposure update before debugging:

The structure MCVBEP (internal tables OWL_MCVBEP, XMCVBEP, XMCVBEP_LS) is the one used for passing the credit values of the items in the document to the structures used for updating credit exposure.

The fields to be aware of, for credit exposure analysis, from MCVBEP structure, are the following:

• OEIME: Open delivery quantity
• OEIKW: Open delivery credit value
• OEIKWGES: Total open delivery credit value (without guarantee)
• OEIKWAA : Guaranteed open delivery value

For a document which is not guaranteed by any Payment Guarantee Procedure (Credit card and Letter of credit), OEIKW and OEIKWGES will always have the same value as the system does only support 100% of the values guaranteed or nothing. In the following example, only field OEIKW is relevant.

The standard logic for commitments calculation for a schedule line is the following:

• VBAP-CMPRE * VBEPD-OLFMNG (confirmed quantity not yet delivered)

Credit Management in SD is based on Badi BADI_SD_CM. The Badi can be activated or not.

The credit exposure calculation takes place in method IF_EX_BADI_SD_CM~FSCM_COMMITMENT_UPDATE_ORDER. The standard class is CL_IM_UKM_SD_FSCM_INTEGR1. It may be used a different class if there is a custom implementation of the BADI_SD_CM. The example in this post uses the standard class.

To have the credit exposure updated for a delivery relevant item, it is needed to have confirmed quantity in the schedule lines and some configurations like:

• The item on the sales document needs to be relevant for billing (FKREL). Billing relevance of the item category can be set in transaction VOV7.
• For the credit value update of the item the ‘Credit active’ indicator needs to be flagged on the item category in transaction OVA7 or in transaction VOV7. (The setting is also referred to as ‘Active receivable’.)
• In the pricing procedure used for pricing, subtotal ‘A’ must be entered in a line for determining the credit value (VBAP-CMPRE). You maintain the credit price in transaction V/08.

Further information about Credit Management configurations can be checked in KBA 2788718.

Checking if the exposure would be correct with the standard class:

Before showing the credit exposure update steps, I would like to demonstrate where in the code it is checked if there is a custom implementation of BADI_SD_CM and how to test the credit exposure update with the standard class to tell if the issue you are facing is because of the custom implementation.

The method FSCM_COMMITMENT_UPDATE_ORDER is the one responsible for sending the commitments. It is called from FM MCV_UPDATE_CM_ORDER. To troubleshoot an error with credit exposure update in a non-production environment, if there is any custom implementation of BADI_SD_CM active, we can change variable BADI_SD_CM_ACTIVE to blank and the update will happen with the standard class CL_IM_UKM_SD_FSCM_INTEGR1. That should be done in update task.
Then if the update is correct, the issue is probably caused by the custom implementation of BADI_SD_CM.

Below are the debugging steps I took to analyze the credit exposure update for the sales order. It is shown the code that is run after saving the order. Later in the blog, I also demonstrate the steps in update task.

Steps for credit exposure update from SD for a sales order with an item relevant for delivery:

# Step 1:

In the below screenshot, method FSCM_CREDIT_CHECK_ORDER was called during saving of a sales order and we can see that XVBEP-OLFMNG is 1 for one of the schedule lines. So, we can expect the quantity of 1 being used in form CMPRE_CALCULATE to calculate the credit price.

#Step 2

In that sales order, only the second schedule line has confirmed quantity. Here we can see that when CMPRE_CALCULATE is performed for that schedule line (OWE_MCVBEP-ETENR = 0002),  the open delivery value (OWE_MCVBEP-OEIKW) was calculated as 1.

#Step 3

The actual calculation of the commitments happens during method FSCM_COMMITMENT_UPDATE_ORDER. Form CMPRE_CALCULATE will calculate again OWE_MCVBEP-OEIKW, which will send the value to internal variable XMCVBEP_LS-OEIKW in the method.

#Step 4

That value from XMCVBEP_LS-OEIKW is sent to the variable LV_OEIKW, which represents the open delivery value from the schedule line that will be sent to the internal tables used to update the credit exposure.

#Step 5

During simulation (before commit work), LT_COR_D is the structure used to store the data that represents what would be sent to update the commitments in UKM_ITEM table.

Internal table LT_COR_D should be updated with the credit value from lv_oeikw as per the screenshot below.

#Step 6

This is how LT_COR_D looks like at the end of FSCM_COMMITMENT_UPDATE during simulation.

Steps in update task:

#Step 7

The same calls to form CMPRE_CALCULATE that happened before update task should happen now as well. That will update variable LV_OEIKW (open delivery value) as in step 4. In the next screenshot, it is shown when LT_COR internal table is updated for the schedule line with the confirmed quantity.

#Step 8

Here the data from LT_COR is transferred to LT_COM, which is the table from SD used to send commitments information to method push_commitment.

#Step 9

This is how LT_COM should look before being sent to push_commitment. The amount of 1 will be update for the currency of the credit segment.

#Step 10

Now the method push_commitment is called. That is the logic from SD side used to update commitments

If the structure LT_COM is correctly sent to push_commitment and still the credit exposure is not correctly updated, then there may be an implementation of badi UKM_FILL active that is changing the credit exposure or there is another issue to be checked with FIN-FSCM-CR side for updating the commitments.

I hope this blog is useful for those who want to investigate credit exposure update issues. You are welcome to post any questions/feedback you may have in the Comments section.

Best Regards,

Rodrigo

Digital Core Sales