How the Credit Horizon affects the Credit Exposure at FSCM

I search the credit horizon in FSCM and get lots of great explanations, but still not very clear how it calculates the credit horizon periods from a technical point of view. For example which date system used exactly for the Started date of credit horizon when processing credit check/exposure with open order/delivery.

What’s the credit horizon?

From the standard definition of SAP traditional credit management, it’s used at Dynamic Credit Limit Check.

The customer’s credit exposure is split into a static part; open items, open billing, and delivery values (see above), and a dynamic part, the open order value. The open order value includes all undelivered or only partially delivered orders. The value is calculated on the shipping date and stored in an information structure according to a time period that you specify (days, weeks, or months). When you define the credit check, you can then specify a particular horizon date in the future (for example 10 days or 2 months, depending on the periods you specify). For the purposes of evaluating credit, you want the system to ignore all open orders that are due for delivery after the horizon date. The sum of the static and dynamic parts of the check may not exceed the credit limit.

(One key point from the above definition is what’s the shipping date exactly.)

In my own words: If you online buy a new iPhone with $1000 using your credit card, then Apple tells you it may only be shipped in the next 3 weeks. Is that fair your credit limit been deducted $1000 immediately after your purchase? Or your credit limit should be deducted after the next 3 weeks? That’s the purpose to bring in credit horizon for a credit card company to calculate the credit limit more precisely. Delivery will be done after 3 weeks why the system has to check credit check now?

Credit Horizon setting at Credit Management

Compared with traditional credit management (FI-AR-CR), the setting of the credit horizon in FSCM has been moved from transaction OVA8 to individual check steps. It’s defined at the check steps which will be assigned to the check rule of a Business partner. SPRO path is Financial Supply chain management->Credit Management->Credit risk monitoring->Credit limit check->Define checking rules).

You can check this credit horizon day definition at the table: UKM_CHCK_STEP as well. It’s a quick place to check which check step involves the credit horizon.

UKM_CHECK_030 Dynamic Limit Check with Credit Horizon

The pre-defined standard check step 030 can be used directly at the check rule’s setting. You can create a new customized check step with a credit horizon using BADI: UKM_CHECK_STEP.

How the credit horizon been checked at the Check step?

Inside method ‘CHECK_STEP’ of BADI implementation for check step 030, the effective date equal to  SY-DATLO which is Local Date of Current User + Credit horizon days defined at check steps.  According to current understanding, days after this effective date, the credit check should be skipped.

Take IPhone’s example, the effective date is 3 weeks later from today. If the credit horizon been set as 2 weeks, it should be skipped for a credit check, which means no deduction from the credit limit after the purchase. Then comes the ultimate question: Which date does FSCM use to compare with this effective date to decide one open item fall in the credit horizon period or not?

Keep digging, we can find this effective date compared with field ‘ls_schedule–effective_date’ at method ‘check_commitment’.

Here is the key Comparation of this article: if the item’s effective date is larger than the effective date, then it’ll be ignored! (Continue statements at Line 47, means skip this item for a credit check). The goal is to find out the source of field ‘ls_schedule–effective_date’ comes from _s_item_to_be_checked–group_schedule, which refers to structure UKM_S_CHECK_ITEM (Credit Management: Line Items for Credit Check).

Where’s the item’s effective date comes from?

The group_schedule becomes the target which stores the schedule items that need to validate whether to carry out the dynamic check or not. All the open items details come from the SAP SD, then send it to the FSCM credit management process. So it must involves the star BADI at the FSCM world which is BADI_SD_CM (Connection between SD and Credit Management).

SAPACE

Usually, we need to implement BADI BADI_SD_CM for the following methods which will be triggered at various places to perform a credit check and update order, delivery, invoices, etc. plus credit exposure as well.  SAP already provides one implementation example Implementation Name UKM_SD_FSCM_INTEGR.

By global search, we can find the assignment of this effective date for order item and delivery item at method FSCM_CREDIT_CHECK_ORDER.

Search this global internal table gt_delta_order and find out it comes from ls_cor_d/ls_cob_d.

Finally, at method FSCM_COMMITMENT_UPDATE_ORDER / FSCM_COMMITMENT_UPDATE_DELIVRY we find the root where the system sets the date for open items/open delivery which will be used as item effective date to compared with the effective date.

◓ For open order, the item effective date is xmcvbak_ls–ERDAT (Date on Which Record Was Created)

◓ For open order with schedule data, the item effective date is xmcvbep_ls–MBDAT (Material Staging/Availability Date)

◓ For open delivery, the item effective date is xmclikp_ls-ERDAT (Date on Which Record Was Created)

◓ For open delivery with schedule data, the item effective date is xmcvbel_ls–MBDAT (Material Staging/Availability Date)