Credit management with SAP

SAP Credit Management is a component of FSCM(*). SAP Credit Management will replace completely ECC CM. Credit management aims at reducing the risks of financial losses and allow to the optimization of functions of the credit control department. 

Just for information: SAP Credit Management (FIN-FSCM-CR) is a separate application for centralized management.  The business systems connected report the commitment of a business partner to SAP Credit Management (FIN-FSCM-CR) via XML.

In SAP S/4HANA No additional license is required for using the “Basic” Credit Management solution. However, to use additional functionality like scorecards, automatic determination of limits, workflow, integration of external credit information SAP-clients must acquire License.

Content: 

1. Credit management processes
1. Document decision
2. Credit check with the parent-child relationship 
3. Mass data changes
4. Credit limit request
5. Sales order credit check
6. Recreate the credit exposures 
2. Business partner credit master data 
3. Configuration Steps for Credit Management
4. Restrictions
5. Transactions 
• UKM_CASE: Releasing Credit Blocked Sales Orders
• UKM_MY_DCDS: Credit Blocked SD Documents (Still available although as workaround cases)
• UKM_BP: Credit Account Master Data
• VKM1 - Blocked SD documents 
• S_ALR_87012215 - Display changes to credit management 
• S_ALR_87012218 - Credit master sheet 
• There is a transaction called UKM_MALUS_DSP, and a report: UKM_MALUS_DISPLAY SAP Credit Management: Credit Exposure List. With this report we can evaluate and analyze the Resubmission date.
• UKM_BLACK_WHITE - Negative and Premium Customer Lists 
• UKM_BP_DISPLAY - Master Data List 
• UKM_COMMITMENTS - Credit Exposure 
• UKM_VECTORS - Payment Behavior Summary 
• UKM_MASS_DSP2 - Credit Segment 
• UKM_MASS_DSP1 - Credit Profile 
• UKM_RFDKLI20 FSCM: SD Restructuring of Credit Data After Organizational Changes
• UKM_RVKRED77
• UKM_ RVKRED88 SD: Test of XI Messages for Liability Update in Credit Management
6. Debugging tips
7. Enhancements
• New chek step ( User exit )
• Bypass the credit check
8. Additional information
• 2632975 - Disable Credit Check on Sales Order Where FSCM Credit Management is Active
• 2828716 - Released sales documents are blocked again by RVKRED06
• 2939371 - Dynamic Limit Check with Credit Horizon in SAP Credit Management (FSCM)
• 2578881 - How to use report RVKRED08
• 370022 - RFDKLI20: Not all documents are updated

Credit management processes

Document decision

Companies may be obligated to document credit decisions for legal reasons. This documentation is necessary if a customer contests the reasons for a decision when they are disclosed. There are two different types of documented credit decision:

• The documented credit decision for the document documents the data used as the basis of a negative credit check, resulting in a blocked SD document.
• The documented credit decision for the account documents the status of a credit account at a particular time, for example, if a credit analyst blocks the account. 

Cases in SAP Credit Management: it enables to search for documented credit decisions in the system, and to process them.

Setting parent-child relationship of business partners for a credit check  

With SAP Credit Management in this scenario, 'CREDIT_ACCOUNT' is considered the Higher-level business partner, 'Account_A' and 'Account_B' are the Lower-level business partners.

• In UKM_BP you have two possible 'Relationship categories' especially referring to Credit Management:
• FUKM001 - Higher-level Credit Management Account of... (e.g. holding company/parent company - head office)
• TUKM001 - Lower-level Credit Management Account for... (e.g. subsidiary/affiliate/associated company - branch)

Credit Exposure

• The credit exposure of the higher-level business partner and the lower level business partners ordered to it will be summed up.
• We can check the individual credit exposure of the business partners in transaction UKM_COMMITMENTS. In order to exclude the values coming from the related credit accounts, we should remove the flag from the indicator 'Display Subordinate Nodes' when executing the transaction for the higher-level business partner. If we flag the 'Add. contribution to the main segment' option in the credit segment settings, then the credit check will not only consider the current segment determined in the sales order/delivery (VBAK-KKBER/LIKP-KKBER) but the main segment as well. The setting itself is used to collect the liabilities of sub-segments to the main segment (e.g. parent company and associated companies scenario).

Credit check

• The credit limit check should be performed only for the Higher-level business partner, as it happened with classic credit management. When we make the 'Relationship' setups, we should assign the 'normal' check rule to the higher level account (parent) and the lower level (child) accounts should receive a special check rule, which does not perform Credit Limit Check (neither static nor dynamic).

Release blocked documents 

Release the sales order with VKM1/VKM4 or UKM_CASE/SCASE/UKM_MY_DCDS transaction and expect that now the output should be correctly triggered.

Sales and delivery documents blocked by SAP Credit Management can be are managed with documented credit decisions. We use transaction UKM_CASE to recheck, release, or reject blocked documents.

Settings for Documented Credit Decisions 

• Recommended: Activate BC Set UKM_DCD_CUST using transaction SCPR20. If you don’t activate this BC set, you have to manually maintain the settings for DCD in customizing – lot of steps involved.

Recreate the credit exposures from an SD system

Use the following reports:

• UKM_RFDKLI20 to recreate the credit exposure after organizational changes
• UKM_RVKRED77 to recreate the credit exposure where you have removed the cause of the error in the case of data inconsistencies
• UKM_RVKRED88 to simulate report UKM_RVKRED77 without setting blocks on the documents affected. This report prepares an update run of report UKM_RVKRED77 to determine suitable selection parameters, for example.

Mass changes

• UKM_MONITOR - Update Entries for Ext. Credit Info. 
• UKM_MASS_UPD1 - External Credit Information 
• UKM_MASS_UPD2 - Score 
• UKM_MASS_UPD3 - Credit Limit 
• UKM_MASS_UPD4 - Rule for Scoring and Credit Limit Calculation and Check Rule 
• LTMC ( https://blogs.sap.com/2019/09/18/ltmcmass-business-partner-role-extension-sap-credit-management-ukm000-parameters/ )

Credit Limit Request

You use the credit limit request if the credit limit is not to be changed immediately in the master data and requires a decision or approval process first.

1. Enter credit limit requested
2. Enter notes
3. Link documents
4. Forward credit limit requests to another processor for approval, whereby this processor can enter an approved credit limit that is different from the limit requested.

If the credit limit of a credit account is increased, manually or via an automatic process (for example, mass change), by more than the percentage rate defined in the rule, the increased value is not transferred to the Credit Limit field immediately; instead, it is entered in the Credit Limit Requested field. At the same time, a workflow item is generated that provides information about this request and offers access to the business partner maintenance. If the user has the relevant authorization, he can accept the limit requested (it is included in the credit limit) or reject it.

Process of credit check in the sales order

1. Filling data relevant for credit management in sales order
• https://wiki.scn.sap.com/wiki/display/SD/Usage+of+report+CHECK_CM
• Credit price - CMPRE: Transaction V/08 - In the pricing procedure used for pricing, subtotal "A" must be entered in a line for determining the credit value.
• Confirmed quantity - KBMENG: This also occurs for documents that are blocked by the credit check. As a result of the credit block, the confirmed quantities are deleted so that an open sales order value can no longer be updated. These requirements are defined in transaction VOFM under the menu path 'Requirements -> Subsequent functions -> Reqs.availability'. 
• Credit Control Area The credit control area is stored by a sales order in the VBAK-KKBER field. The definition of the sphere of credit control is performed in the functional module SD_DETERMINE_KKBER. The following algorithm (in descending order) is used to determine the credit control area:
1. User exit: EXIT_SAPFV45K_001
2. Credit control area of the payer. 
• Transaction BP role FLCU01 «Customer (defined)».
3. Credit control area of the Sales Area
4. Credit control area of the Company Code
• An item with active credit function / relevant for credit (VBAP-CMPNT)
• Determining the relevance of sales orders and delivery for credit control
• https://wiki.scn.sap.com/wiki/display/SD/Update+Groups+in+Credit+Management
2. Run credit check 
• There are methods in BADI_SD_CM: FSCM_CREDIT_CHECK_ORDER and FSCM_CREDIT_CHECK_DELAY that implement sending credit request to the module FSCM-Credit Management and receive credit check result.
• In a credit check with the check steps Statistical Check of Credit Limit Utilization or Dynamic Limit Check with Credit Horizon , before the comparison with the credit limit, the credit exposure is reduced by the amount of the collateral and/or credit insurance if the indicator Consider Collateral or the indicator Consider Credit Insurance is set in Customizing and the current date is in the validity period of the collateral or credit insurance and the relevance indicator is set.
3. Set credit status
• Method cl_ukm_xi_facade_r3_50=>if_ukm_credit_query_r3~check_credit return parameter LV_CHECK_CONF that have value «X» (if credit check successful) or “” (if credit check do not successful)
• If the credit check is not successful, the VBAK- CMGST field is filled in with the value B “Credit check was executed, document not OK”.
4. Update credit exposure
• At the implementation UKM_SD_FSCM_INTEGR1 there are methods FSCM_COMMITMENT_UPDATE_ORDER, FSCM_COMMITMENT_UPDATE_DELVRY, FSCM_COMMITMENT_UPDATE_INVOICE, which prepares credit data and send request to the FSCM-Credit Management (for update data in the table UKM_ITEM). The message is generated and sent using the method cl_ukm_xi_facade_r3_50=>if_ukm_commitment_push_r3~push_commitment.

Follow up processing

There are certain scenarios during SAP Credit Management activities that trigger follow-on processes. Examples of these situations are:

• Business partner's score changes --> Risk class is automatically changed
• Credit check fails --> Blocked in credit management indicator (UKMBP_CMS_SGM-XBLOCKED) is automatically set on the Business Partner
• Limit utilization changes --> Blocked in credit management indicator (UKMBP_CMS_SGM-XBLOCKED) is automatically set on the Business Partner
• Limit utilization exceeds 100% --> Credit Limit of the Business Partner in the given credit segment is set to invalid
• Business partner's check rule changes --> Credit re-check is triggered on the sales documents
• Credit limit is changed manually --> approval process is triggered, Credit Limit Request is issued and needs to be approved
• etc.

Automatic follow-on processes are maintained under the following IMG Path (transaction SPRO) -->

Financial Supply Chain Management

    Credit Management

        Credit Risk Monitoring

            Processes

                Define Events and Follow-On Processes --> select the combination of Activity and Type of Event --> in the left panel double click the Follow-On Processes

BAdI: Follow-On Process for Event (UKM_PROCESSES).

Business partner 

The Standard BP role for Credit Management is UKM000 – SAP CREDIT MANAGEMENT.

In the master data of the business partner we can define the following:

• Which rule is used to calculate the score, the risk class, and the credit limit?
• Alternatively, you can define the score, risk class, and/or the credit limit manually.
• The credit analyst can determine and manage both external and internal credit information for a business partner. This information is used mainly as input parameters for the Credit Rules Engine, which companies can use to carry out automatic business partner ratings (scoring), making credit decisions, or calculating credit limits.
• Which check steps are executed in a credit check for the business partner?
• In a credit check for this partner, those checks for which check exceptions are defined are omitted if the current date is within the validity period for the check exception and the indicator Consider Check Exceptions is set in the Customizing for the check rule.
• Which customer credit group does the business partner belong to?
• Which analyst or analyst group is the business partner assigned to?
• Should credit checks also be carried out for additional business partners that are related to him?
• External credit information
• Collateral and credit insurance?
• In a credit check with the check steps, Statistical Check of Credit Limit Utilization or Dynamic Limit Checks with Credit Horizon, before the comparison with the credit limit, the credit exposure is reduced by the amount of the collateral and/or credit insurance if the indicator Consider Collateral or the indicator Consider Credit Insurance is set in Customizing and the current date is in the validity period of the collateral or credit insurance and the relevance indicator is set.
• Negative credit events, block reasons, an indicator for special attention?
• In the definition of formulas for scoring or the credit limit calculation, you can use the function NEGATIVE_CHARS to check the existence of negative credit events. You usually use this function to assign a bad score to a partner in such a case.
• A credit check for a blocked credit account (that is, partner and credit segment) always has a negative result if the block indicator is set. Any block reason appears in the log for the credit check.

Configuration Steps for Credit Management in S/4 HANA

Entities: business partner, credit segment, risk class, credit limit, checking rule, the score 

1. Activating the Business Partner Role for Credit Management
• BUS1 - Applications: UKM is active
2. Define Credit Control Area
3. Define the rating procedure 
• External information providers, government organizations, or internal departments rate business partners for different business processes. In Germany, external information providers could be, for example, Dun & Bradstreet, SCHUFA, or Creditreform. The individual providers each use their own rating names and procedures.To compare and mix ratings from different internal and external information providers, you make the rating procedure uniform by means of a ranking order that you assign the different ratings from the providers to.
4. Define customer credit groups: customer credit groups to group business partners. The customer credit group is used as a selection criterion in reporting and when generating worklists.
5. Create credit segments ( define the corresponding credit segments later in the master record of your business partner ) 
• Assign Credit Control Area and Credit Segment. Transaction Code: UKM_SEGMENT
• Assign Sales Area to Credit Control Area
6. Note of External Credit Information, you need to create Rating Procedure: Credit Information Query out (Query Credit Information from External Data Providers) in the namespace http://sap.com/xi/FSCM.
7. Define the formulas for calculating the score and the credit limit.
• The credit limit is the variable we can manage via formulas 
8. Create credit risk classes
• To use the automatic assignment of the creditworthiness value to the risk class, assign the score intervals to the corresponding risk classes.
• To ensure automatic calculation, in the Define Events and Follow-On Processes Customizing activity, define the EVL_RISK_C (Determine Risk Class) follow-on process.
9. Define Blocking Reasons
• When a business partner is blocked, the credit analyst sees the block reason in the credit segment data in the Control screen area. You can also use predefined event types.
10. Define checking group
• A check rule can consist of several individual checks ( check steps); in addition, you can define which parameters are relevant for each check step.
• In the  Parameter Display for Check step, you can define that the parameters of the check steps that you have defined and implemented via BAdI are also displayed in the Parameter Overview under Checks. For each check step, you can define one or more field groups that are to be displayed.
11. Enter Settings:
• Condition Partner: Update the subtotal with value “A” for Credit Release check for NET VALUE condition type
12. Determine Active Receivable Per Item Category. Transaction Code: OVA7
13. Define Credit Group. Transaction Code: OVA6
14. Assign Sales Documents and Delivery Documents
• Rund simple credit limit check and error message
• Run simple credit limit check and a warning message
• Run simple credit limit check and delivery block
• Credit management: Automatic credit control
• No credit limit check
15. Define Automatic Credit Control. Transaction Code: OVA8
16. Define Rick Category and Assignment
17. Activate the BADI for the following Credit Management in S/4 HANA.
18. Customer Master Setup: UKM000 BP role
• Enter the Rules, Risk Class, Check Rule and Customer Group under the Credit Profile tab
• Go to Credit Data Segment and fill up the value
19. Set the checking rule
• The following check steps are delivered in the standard FSCM:
• 010 UKM_CHECK_010 Statistical Check of Credit Exposure
• 020 UKM_CHECK_020 Check for Maximum Document Value
• 030 UKM_CHECK_030 Dynamic Limit Check with Credit Horizon
• 100 UKM_CHECK_100 Check for Maximum Dunning Level
• The system does not use the dunning level from the customer master data for the check but determines the highest dunning level in the open items of a customer and uses it for the check.
• 110 UKM_CHECK_110 Check for Age of Oldest Open Item
• Oldest open items are overdue as per specified day then...
• Go to FBL5N. Check the net due date with the billing date Whether it is exceeding the number of days specified against the oldest open item
• 120 UKM_CHECK_120 Check of Payment Behavior Index
• 130 UKM_CHECK_130 Check for Overdue Open Items
• The available per segment settings can be assigned to the following credit check steps: 
• 020 - Max doc Value: MAX_DOC_VAL
• 030 - Dynamic with Credit Horizon: CREDIT_HORIZON
• 120 - Check of Payment Behavior Index: PAY_HIST_LIMIT
• 130 - Check for Overdue Open Items: MAX_OVDUE_PC; MAX_OVDUE_DAYS

Important notes

OVA8 Automatic control setup has fewer fields than it was in ECC

Risk class, credit control area, and checking group

• A number of the routine used for copying, use cases:
• No check, if the document does not contain any items
• No check, if the new net value does not exceed the old net value
• Credit checks during header/item processing
• This indicates that the system carries out credit checks not only when you save the document but already when you enter single items or header data.
• Credit check: Set credit status (block)
• Credit check: System reaction (warning, error)
• Released documents are still unchecked:
• ( V_T691F-CRPRC ) Deviation of document value by x %
• Use case: You set the deviation factor at 10%. An order for 10 boxes of material (price = 100 USD per box) has a total value of 1,000 USD and is approved for credit. The customer then calls and wants to add additional boxes to the order. If this causes the deviation factor to exceed 10%, the system carries out another credit check.
• V_T691F-CRPRC Number of days without check: This function is used for checking documents that have already been released by a credit representative, but that has subsequently been changed. The system does NOT carry out another credit check if the following conditions are met:
• The value of the changed order is not greater than the value already approved for credit (inclusive of the deviation factor), AND
• The current date is not greater than the original release date plus the num
• ber of days specified here.
• SAP credit management
• If the checkbox is set, the system performs a credit check.
• Own credit checks can be set in BAdI BADI_SD_CM:
• Order: FSCM_CREDIT_CHECK_ORDER
• Delivery: FSCM_CREDIT_CHECK_DELVRY

Credit check steps ( exclusion logic )

The checking rule is set at the general level and cannot be maintained at the Credit segment level in comparison to the ECC setup. It comes from the data model:

• only the credit profile ( table ) has the field for the checking group: UKMBP_CMS (Credit Profile) and the table UKMBP_CMS_SGM (Credit Segment) has no it in the structure.

So we cannot assign several checking rules to the same business partner. The settings we have with OVA8 (customer, credit control area, credit risk…) has migrated to the Checking group + Credit segment level.

• check steps that are defined in the check rule
• but are defined as exceptions in the respective business partner master record
• are excluded from the credit check.

Ideally, the checking rule should have all the necessary steps for all possible cases, and then it is specified by exclusion logic at the credit segment level.

The existing setup is not complete, as a user cannot add the additional information under the 30 Exception type. With the reference to the SAP Note  2183870 - UKM_BP: 'Additional Information' not stored correctly or your receive an error message while trying to store the data

The info category and info type can be stored in the Credit Management side with the following IMG path: Financial Supply Chain Management> Credit Management> Credit Risk Monitoring> Credit> Limit Check> Define Info Categories and these should also be stored in the related tables for the business partner. The following tables must be synchronized (!)

• UKM_INFOCAT (above customizing) to table TPZ20 
• UKM_INFOTYP (above customizing) to table TP19 

We should add customizing for TPZ20 and TP19 (views V_TPZ20 and V_TP19) with SM30. There, please enter the SAME info categories and types as done in the Credit Management path.

Then exclusion can be set for a credit segment in the business partner master record. 

Transactions

RVKRED06: The report checks all blocked documents from the credit view

UKM_CASE: Releasing Credit Blocked Sales Orders
UKM_MY_DCDS: Credit Blocked SD Documents (Still available although as workaround cases)
UKM_BP: Credit Account Master Data
VKM1 - Blocked SD documents 
S_ALR_87012215 - Display changes to credit management 
S_ALR_87012218 - Credit master sheet 
There is a transaction called UKM_MALUS_DSP, and a report: UKM_MALUS_DISPLAY SAP Credit Management: Credit Exposure List. With this report we can evaluate and analyze the Resubmission date.
UKM_BLACK_WHITE - Negative and Premium Customer Lists 
UKM_BP_DISPLAY - Master Data List 
UKM_COMMITMENTS - Credit Exposure 
UKM_VECTORS - Payment Behavior Summary 
UKM_MASS_DSP2 - Credit Segment 
UKM_MASS_DSP1 - Credit Profile 

UKM_RFDKLI20 FSCM: SD Restructuring of Credit Data After Organizational Changes

Report UKM_RFDKLI20 restructures SD credit data following organizational changes. You need to execute this report after the following changes:

General settings that affect SD:

• Settings that change the how the credit control area is determined: assignment from company code, entry in customer master data, entry in sales area data, user exit
• Currency of credit control area
• Risk class in master data of credit account

You need to start this report after any of the above changes for the following reasons:

• In clearing, exactly the amount in the credit limit currency is withdrawn and therefore the amount must be converted and available in the correct currency.
• The control area is determined during a posting from the company code; if this assignment changes, earlier postings must be assigned to the new control area to ensure that the sum of the receivables is accounted for correctly.

Features

• The report updates sales documents with regard to their credit data (credit control area, credit account, credit currency, credit value, risk class) within an "internal VA02"; that is, the document is read, the credit data is changed, and then saved again.
• In certain circumstances, this can lead to further changes in the document; these are the same changes that would occur if VA02 was executed manually and then saved again.
• The type and scope of the XI messages created for commitment updates in SAP Credit Management depends on the active BAdI method. They are the same XI messages that you would encounter if you were to change the documents manually.

UKM_RVKRED77

The report selects open sales values (the open credit values in SD) and creates XI messages for the liability update in SAP Credit Management. You can then check and evaluate the data in SAP Credit Management.
You need to use the report in the following cases:

• Errors have occurred in the updating of these sales values, and ideally the cause of the errors has been eliminated so that you can continue afterwards with correct values without errors.
• The update group (T014-STAFO) was changed in a credit control area.

For the following reasons the report is not suited for frequent use:

• To ensure an error-free run, it is necessary to completely block tables VBAK, LIKP and VBRK. As a result, the run of the report is not possible during the current operation.
• Depending on the selection, a program run of UKM_RVKRED77 can last a few hours, in extreme cases you may even experience a runtime of a few days.

UKM_ RVKRED88 SD: Test of XI Messages for Liability Update in Credit Management

UKM_ RVKRED88 simulates report UKM_RVKRED77. However, it does not block tables VBAK, LIKP or VBRK as does UKM_RVKRED77  as a result, differences may occur in the result if relevant documents are changed during the run or if new documents are created.

It is very well suited to estimate the runtime of UKM_RVKRED77, and thus to determine suitable selections.

Data model 

• In SAP Credit Management (FSCM) the maintenance of credit management customer master data is performed on the base of the business partner in transaction BP or UKM_BP and the data is stored in tables UKMBP_CMS (SAP Credit Management: Credit Master Data for Partner) and UKMBP_CMS_SGM (SAP Credit Management: Master Data for Credit Account).
• The SAP Credit Management is using the so-called 'Credit Management is managed by' (TUKMSB0) and 'is in Credit Analyst Group' (TUKMSBG) as 'Relationship category' and is stored in BUT050 table.

Restrictions 

• AFS: SAP Credit Management does not support the Dynamic Credit Check in the allocation run (credit check in the release rule at sales order header or item level during allocation run).
• IS-Retail: SAP Credit Management does not support processes in which a customer has been created as a plant in SAP Retail ERP 6.0 and higher.
• SAP Credit Management does not support processes with stock transport orders or the dynamic credit check for billing plans of all types.

Debugging Credit management

CM logic is implemented in Proxies in S4HANA, so to debug it, go to Package – UKM_XI_PROXIES
> Go to Enterprise Services —> Service Provider – CreditWorthinessQuery_In
Open the Implementing Class and Go to the method Execute, Put a Debug Point to continue Debug.

SD_ORDER_CREDIT_CHECK

Development 

Bypass the credit check

In classical credit management functionality, indicator "no_check" can be used to bypass the whole credit check and variable "bypass" and "status_reset" can be used to control individual credit checks in custom routine. However, in SAP Credit Management (FSCM), the indicator "no_check" should not be used anymore and all the individual credit checks.

Solution:

• In transaction VOFM, create custom routine (menu 'requirements'->'Credit checks') to set indicator "bypass-credit_management" to 'X'.
• In transaction OVA8, assign the above routine to field "No credit check" under the "Document controlling" section.

New chek step ( User exit )

• There are further options to create custom specific solutions by additionally implementing your own check steps with the BAdI UKM_CHECK_STEP.
• BAdI: Individual Step of Credit Check
• BAdI: Adjust Result of Credit Check
• The BAdI UKM_CHECK_STEP can access data via the input parameter IO_ACCOUNT of class CL_UKM_ACCOUNT. Via SE24 transaction you can display the methods this class is using. The credit check step coding is executed on FSCM side, therefore SD data is not directly available. If you find that you need SD data that is not accessed with IO_ACCOUNT parameter (e.g. VBKD), then you can consider implementing the SD related credit check directly to a custom implementation of BADI_SD_CM (Credit Check Methods FSCM_CREDIT_CHECK_ORDER, FSCM_CREDIT_CHECK_DELVRY).

Example with 010:

• prepare an item
• CALL FUNCTION 'UKM_COMMITMENTS_CALCULATE'
• calculate total of totals, converted to local currency

Example with 130

• CALL FUNCTION 'UKM_COMMTS_AGING_DISPLAY' with days

Information

2706299 - Parent-child relationship of business partners for credit check in SAP Credit Management (FSCM)

You require the credit limit check to happen with the credit limit maintained at the parent level.
The credit exposure of the child partners should be accumulated at the parent level.

With SAP Credit Management in this scenario 'CREDIT_ACCOUNT' is considered the Higher-level business partner, 'Account_A' and 'Account_B' are the Lower-level business partners.

In UKM_BP you have two possible 'Relationship categories' specially referring to the Credit Management:
FUKM001 - Higher-level Credit Management Account of... (e.g. holding company/parent company - head office)
TUKM001 - Lower-level Credit Management Account for... (e.g. subsidiary/affiliate/associated company - branch)

To make the assigment on the Higher-level business partner, you edit the business partner in UKM_BP and under the 'Relationships' tab you add the 'Relationship category' FUKM001. Then you can add the Lower-level business partners into the field 'Relationship to BP'.
After saving the settings you can open the Lower-level business partner in UKM_BP and under 'Relationships' a new tab will appear, which shows that this business partner is a 'Lower-level Credit Management Account for' the BP listed on the screen.

On the tab of the credit management relevant relationship you can check the assignment of the business partners by changing the 'Format' of the display to 'Hierarchy'.

Credit Exposure:
The credit exposure of the higher level business partner and the lower level business partners ordered to it will be summed up.

You can check the individual credit exposure of the business partners in transaction UKM_COMMITMENTS. In order to exclude the values coming from the related credit accounts, you should remove the flag from indicator 'Display Subordinate Nodes' when executing the transaction for the higher-level business partner.Credit check:
The credit limit check should be performed only for the Higher-level business partner, as it happened with classic credit management.

When you make the 'Relationship' setups, you should assign the 'normal' check rule to the higher level account (parent) and the lower level (child) accounts should receive a special check rule, which does not perform Credit Limit Check (neither static nor dynamic).

For this reason you could create a check rule without any check steps assigned following the IMG path:
SPRO -->
Financial Supply Chain Management
Credit Management
Credit Risk Monitoring
Credit Limit Check
Define Checking Rules --> Create new entry (e.g. Z1)During sales document creation the Lower-level account, which is determined based on the payer, will trigger the credit check process. The multi-level account settings are used by the FSCM side, however the Higher-level account is not known to the SD side and it is not updated directly to the sales document.
Based on the 'Relationship' settings and the above mentioned check rule setup the credit check is performed as followings:
1. the Lower-level account triggers the credit check,
2. the FSCM side finds the Higher-level account
3. and performs the credit check according to the check rule maintained for this Parent account as well.

Documented Credit Decisions:
As the credit check is triggered by the Lower-level business partner and the Higher-level account is not known to the SD side, the DCDs are created for the Lower-level account, which initiates the credit check process. The Business Partner in the DCD will be the Lower-level account. In the DCD you can review the detailed outcome of the credit checks under "Display Credit Check Log" section and find the checks performed for the Higher-level account.

Additional information

2828716 - Released sales documents are blocked again by RVKRED06

A sales order or a delivery that has been credit released, according to the credit status and changelog of the sales document, is re-checked by RVKRED06. This credit re-check leads to the order/delivery to be credit blocked/approved again, instead of keeping the released status (VBUK-CMGST on ECC, VBAK/LIKP-CMGST on S/4HANA).

You typically notice this behaviour when the re-check by RVKRED06 is executed as a background job and parallely or in an overlapping period there are sales documents released.


Reproducing the Issue
1. You release a sales order/delivery with VKM* transaction or via DCD in transaction UKM_CASE/SCASE/UKM_MY_DCDS.
2. During this period a re-check with RVKRED06 is being executed manually or in a background job.
3. You notice that the status of the order/delivery is not 'D' (released), but 'A' (approved) or 'B' (blocked) as a result of a new credit check.
4. In the changelog of the sales document you see that the status change to 'D' and then again to 'A'/'B' is close in time (within hours).
5. In SM37 you find a background job of RVKRED06 report was running during the time of sales document release.

Report RVKRED06 is hard-coded to perform credit check for blocked (CMGST = 'B') sales orders/deliveries only. Therefore, it should not happen that an already released sales document is re-checked by this report.

The processing of sales documents by RVKRED06 happens in two steps:
1. At the time of the selection the RVKRED06 program looks for the blocked sales documents. It creates a list and sorts the documents.
2. The report then one-by-one executes the credit re-check on the sales documents.


At the moment of the re-check on a given sales document RVKRED06 will not check again the credit status of the order/delivery, as status check has already happened at the time of selection.
Selected documents are not locked for processing by other transactions, so you can edit or release the order/delivery, up until the moment it is re-checked by RVKRED06 and opened in an internal edit mode.
If you release a document which has been selected but not yet re-checked by RVKRED06, then the system will still initiate the re-check, even though at that moment the credit status is already 'D'.


It is standard behaviour and related to the timing of the release and re-check processes.


To avoid the undesired credit status changes it is recommended to execute the VKM* transaction (or DCD) release and the RVKRED06 re-check during different time periods.


Otherwise you need to implement a minor modification in the coding of report RVKRED06, that will perform additional check of the sales order/delivery credit status immediately before re-check.


The sales orders selected to the pool are listed in xm_vmvah. The CMGST status should be checked before Function Module 'SD_ORDER_CREDIT_RECHECK' is called.
The deliveries selected to the pool are listed in xm_vmvld. The CMGST status should be checked before Function Module 'SD_DELIVERY_CREDIT_RECHECK' is called.
Regarding such changes of the standard code SAP Note 170183 must be considered.

2939371 - Dynamic Limit Check with Credit Horizon in SAP Credit Management (FSCM)

You are using SAP Credit Management (FSCM) on your system with Dynamic Credit Limit Check (credit check step 030 Credit check with horizon). 

It is not clear when sales documents are blocked due to the Dynamic Credit Limit Check and how the Credit Exposure in Horizon is being updated.

General Principle

The principle of the dynamic credit check is to compare the consumption (credit exposure) within the defined horizon to the credit limit.

If the consumption within the horizon is exceeding the credit limit, the document is credit blocked.

The dynamic check consists of a dynamic and a static part.

• The open deliveries (liability cat. 400), billing documents (liability cat. 500) and open items (liability cat. 200) belong to the static part. The open sales order items with delivery-related billing (liability cat. 100) belong to the dynamic part.

To the Exposure within Horizon the open order values are updated within the defined time interval. Therefore the method of the Dynamic Credit Limit Check is the same as in Classic ERP Credit Management in regards that for the dynamic part the system still uses the static part and all open order values which lie within the predefined credit horizon.

What to consider with Dynamic Credit Limit Check with Credit Horizon in FSCM

1.) Credit horizon of the dynamic check

With FSCM the credit horizon is set in days and the end of the credit horizon is a specific date. This is different compared to the classic credit management, where the OMO1 time interval of credit value update had an influence on this. See SAP Note 379007 to compare the behavior.

You can set a credit horizon for the Check Step in the Check Rule configuration or you can specify different horizon days based on Credit Segments. See KBA 2926009.

It is advised to select a credit horizon period meaningful for the business. 0 days is not advised as credit horizon, in that case from the dynamic part only the credit values of the current date are used.

You can check Credit Horizon and the Credit Exposure in Horizon for the relevant Business Partner/Credit Segment combination in transaction UKM_BP -> Credit Segment Data tab.

The Credit Check Simulation with Dynamic Credit Check is also showing the credit exposure within horizon and how it compares to the credit limit.

2.) Updating open sales order values

The credit value update with credit horizon is performed using the material availability date (VBEP-MBDAT) of delivery-relevant schedule lines if a delivery-related billing has been set for the sales order item.

The Credit Exposure in Horizon can be checked in transaction UKM_BP on Credit Segment level. You can drill down to list the entries of the different liability categories.

In FSCM the individual credit value updates can be identified based on the 'Key' parameter (Choose Layout and display the column if not shown).

For Dynamic Credit Check and update the following is relevant:

Commitment of update group 12: <Document number>-<currency>-<item number-schedule line number>-<Material Availability Date (MBDAT)>​

The sales documents with order-related billing are completely included in the dynamic credit limit check and the entire value of these orders is updated to the credit exposure. This is further clarified if you check the 'Key' for order-related billing items in the credit exposure: <Document number>-<currency>. (No material availability date/delivery date/billing date included as these items are not considered to be updated in time intervals.)

3.) Credit check with horizon

The Dynamic Credit Check is comparing the Credit Exposure in Horizon to the Credit Limit.

In the case of the sales order being checked it is not important whether the sales order itself lies within or outside the horizon. The system simulates the values of the sales order currently being edited and adds them to the Credit Exposure in Horizon (credit consumption).

If the sales order items lie within the horizon, the system adds their open values to the consumption, if the sales order items lie outside the horizon, they do not increase the consumption.

This means the material availability date is also relevant during credit check.

However, keep in mind that documents which lie outside the horizon are also credit blocked if the consumption within the horizon already exceeds the credit limit (that is, if the customer has exceeded the credit limit beforehand).

In case of FSCM the 'Check' indicator on the Liability Category also has an influence on the Dynamic Credit check.

IMG => Financial Supply Chain Management => Credit Management => Credit Risk Monitoring => Credit Exposure Update => Define Liability Categories.

The 'Check' indicator is effective when the system calculates the credit limit utilization. If you set the indicator, the system includes the corresponding items irrespective of when they are due. This means it also includes items that are not due within the credit horizon. See further information in KBA 2780432.

4.) Re-check of documents that reach the horizon

If you use the dynamic check, you can still use report RVKRED08 to recheck sales documents that reach the credit horizon. RVKRED08 report is still available with FSCM on S/4HANA as well.

5.) Update group

As with Classic Credit Management, the update group for dynamic credit check should be set as 000012 - 'Open order value on time axis, delivery and bill.doct value'.

2578881 - How to use report RVKRED08

 In the documentation for the report, the term 'Period' refers to an option on the initial screen for report RVKRED08 where a selection option for 'Date of next credit check' is provided. The default period is the start to the end of the current month, however this can be adjusted if the date lies outside this default period.

The option 'Take release data into account' allows the user to exclude documents which have been manually released. For example, if this option is selected, all documents which were manually released will not be included when the report is executed. 

2306970 - How to keep the confirmed quantity when the sales order is credit blocked

The deletion of the confirmed quantities in credit-blocked sales orders is implemented by means of requirements. Requirement 101 in transaction OVB8 makes that confirmed quantities are set to zero if the credit block is set.

If you want to change the behavior, you may consider simply removing the requirement 101 in OVB8, or creating and storing a separate requirement which does not cancel the confirmed quantity. After doing that, the sales order item confirmed quantity will not be removed, and thus it will update the open sales order value although the document is credit-blocked.

2912130 - Standard requirement routines to reset confirmed quantities with credit block in S4 SAP Credit Management

The standard requirement routines are still valid.

Although table VBUK is depreciated, the structure VBUK is still in use. The VBUK-CMGST in these routines is referring to the in memory VBUK structure. VBUK structure is filled during sales document processing.
Hence, requirement routines referencing structure VBUK are backward compatible.

2221284 - Field change results in credit block

The critical fields check is set against a customer in transaction OVA8 - T691F-CMPAD (See 'Resolution' for a more detailed explanation).
The Critical fields check is executed with every save on a sales document. The system analyses the internal tables YVBKD against XVBKD to check for differences between the old values and the new value. The fields that are checked specifically are; VBKD-ZTERM, VBKD-VALDT, VBKD-VALTG (Terms of Payment Key, Fixed value date, Additional value days). There is no error, the system is behaving as designed.

779389 - VKM*: Extend list with user-defined fields

1. Extend structure VBKRED. For this purpose use structure VBKRED_EX1 which has been inserted as an Include in structure VBKRED.
2. Fill the additional fields in program DBKMVF02 in FORM routine USER_EXIT_FUELLEN_XVBKRED. In the user exit, internal table XVBKRED, which also contains your additional fields now, is known.
3. Afterwards the additional fields are available in the list that are displayed by Transactions VKM1 - 5. Add the fields to the display variant which you use.

Other 

• 1124271 – “Operational concept SAP Credit Management”: This note describes how to handle error situations that may occur when you use SAP Credit Management, Sales & Distribution (SD), ERP Financials (FI), and SAP NetWeaver Process Integration (PI, previously Exchange Infrastructure (XI)).
• 2742707 - Correction Options for Incorrect SD credit values (liability category 100, 400, 500) in UKM_COMMITMENTS: You are using FSCM SAP Credit Management and notice incorrect credit values in the credit exposure for the Business Partner using transaction UKM_COMMITMENTS / UKM_BP.
• 2315269 - FSCM Credit Management: Error when calling credit management (Technical error, web service issues)
• 2761313 - Maintain Credit Checks for SAP Credit Management (FSCM)
• 2926009 - Credit check step per segment customizing in SAP Credit Management (FSCM)
• 2788718 - Configuration checklist for SAP Credit Management (FSCM)
• 2706299 - Parent-child relationship of business partners for a credit check in SAP Credit Management (FSCM)
• 2801882 - Credit check happens with the wrong credit limit in SAP Credit Management (FSCM)
• 2469457 - Bypass credit check in custom routine in SAP Credit Management(FSCM)
• 1096009 - Restrictions in SAP Credit Management
• 2828670 - Follow-on processes in SAP Credit Management (FSCM)
• 2656921 – FSCM: How to maintain Credit Analyst?
• 2371714 – Next Review Date and Resubmission date in new credit management
• 398105 - Delivery receives credit block with change of delivery
• 2826824 - Credit Check Against Overdue Open Items doesn't work on the day of the due date

370022 - RFDKLI20: Not all documents are updated

Sales orders that were not updated by report RFDKLI20 (because they are completed together with their subsequent documents) can be re-edited in Transaction VA02 so that they are open again. For example, this is the case if you add a new item or increase the quantity in an existing item. During the credit check for these documents, the system rereads an alternative risk category (VBAK-CTLPC) from the credit master data (KNKK-CTLPC).

This only applies to the risk category and not to a changed credit control area or to other changed credit master data! In the case of a changed credit control area, the system displays an information message V1677 "Credit data will not be redetermined" when you change the document in Transaction VA02. If you nevertheless want to use the credit control area according to the new settings, report RFDKLI20 must be run again.

Change of the credit account (KNKLI):

• You change the credit account in FD32. You want to reflect this change in the existing sales documents, but after executing RFDKLI20, nothing changes. Report RFDKLI20 updates only SD documents that are still open or that contain open documents in their document flow. If a document and all its subsequent documents are completed (overall processing status VBUK-GBSTK = 'C'), this document is no longer updated by report RFDKLI20.  This applies generally for all change in the master data.

 

Change of the risk category (CTLPC):

• Sales orders that were not updated by report RFDKLI20 (because they are completed together with their subsequent documents) can be re-edited in Transaction VA02 so that they are open again. For example, this is the case if you add a new item or increase the quantity in an existing item. During the credit check for these documents, the system re-reads an alternative risk category (VBAK-CTLPC) from the credit master data (KNKK-CTLPC). This only applies to the risk category and not to a changed credit control area or to other changed credit master data!

Caution: If you have not changed anything except the risk category, you can actually use the RFDKLI20 report, but it is too large for this purpose. If you only change the risk category, the RVKRED09 report is sufficient.

  

Settings that change the determination of the credit control area (KKBER):

• You change the customizing of the credit control area determination. More about the determination itself you can read here. Only open documents are updated or that contain open documents in their document flow.

Caution: You have removed the assignment of the credit control area for a company code in the Customizing. You then run the RFDKLI20 report to write this change into the open documents. The RFDKLI20 report does not delete the credit control area from the open documents as expected.

The RFDKLI20 report cannot "delete" the credit control area from documents.

Also in case you change the payer in a sales order, you get mesage: V1677 "Credit data will not be redetermined". This might be the case when already subsequent document (i.e. deliveryI exists for the sales order. The credit data are not redetermined, as already subsequent documents for this sales order do exist. Redeterming credit data for, already delivered sales orders would result in inconsistency. If you nevertheless want to use the credit control area according to the new settings, report RFDKLI20 must be run.

  

Credit active flag change in the item category (CMPNT):

• Changes in field "Credit funct. active" (CMPNT) from the Customizing for the item category (Transaction VOV7) are ignored during the recreation of the credit data after organizational changes (report RFDKLI20). Therefore field CMPNT cannot be affected anymore in existing documents. A change of field CMPNT concerns all new documents. A consistent change of field "Credit funct. active" in the existing documents is not compatible with the existing logic of RFDKLI20 for technical reasons.

  

Documents that are excluded by RFDKLI20:

• For the reorganization of SD data, the report RFDKLI20 calls the function module SD_CREDIT_RECREATE. The function module selects the SD documents for the credit customers. Depending on the setting in your system, the documents are selected according to one of the following two options. 
• A) Selection using the index table VAKPA: This selection is used if you have activated the order update (TRVOG = '0') for the payer function (c= 'RG') in the table TINPA
• B) In all other cases, the original table VBPA is selected.
• When the index table VAKPA is used for the selection, scheduling agreements are excluded from the reorganization. Contracts that are relevant for billing are also excluded, for example, service contracts with billing plan. In this case, no solution is available in the standard SAP system. You can create your own report to select the scheduling agreements and execute the reorganization. In all other cases for contracts read note 439085.

Disable Credit Check on Sales Order Where FSCM Credit Management is Active (06.08.2021)

You want to create a Sales Order and FSCM Credit Management (Financial Supply Chain Management) is active and causing the Sales Order to be credit blocked.

1. Enter transaction OVA8 and select the applicable Credit Control Area (CCAr), Risk Category (Risk Cat.) and Credit Group (CG) to display and maintain Automatic Credit Control details.
2. Go to the tab 'Checks', where there is a checkbox called 'SAP Credit Mngt', with additional check boxes under 'Reaction' and 'Status/Block'.
3. Deselect the 'Status/Block' option to disable the credit block.

2801882 - Credit check happens with wrong credit limit in SAP Credit Management (FSCM)

You have activated SAP Credit Management (FSCM) on your system. You are using 'Statistical Check of Credit Exposure' and/or 'Dynamic Limit Check with Credit Horizon' check steps.

When you create a sales order or a delivery the credit check fails, even though the credit limit of the Business Partner in the relevant credit segment is not yet exceeded.

The credit check pop-up message shows a wrong credit limit, also in transaction UKM_LOGS_DISPLAY the credit check log entry shows a different credit limit than what you expected.

2786413 - Role of 'Credit active' indicator in credit management

The effect of the 'Credit active' indicator on the credit check:

• The credit check on the sales orders and deliveries is controlled at document level in transactions OVAK (order) and OVAD (delivery, PGI). 
• A credit check is carried out, even though the 'Credit active' indicator is deactivated for the respective item categories. However, once the 'Active receivable' indicator is turned off, the given item does not have a credit value. This can influence the outcome of 'Static', 'Dynamic' and 'Maximum Document Value' credit checks, because these are considering the credit value of the document. On the other hand, the other credit checks (e.g. 'Oldest Open Item', 'Highest Dunning Level') are not based on the credit value.
• The credit status of the sales order or the delivery will be nevertheless determined in the header status field 'CMGST' (VBUK or VBAK depending on the release). See SAP Note 368343.

• The effect of the 'Credit active' indicator on the credit value update:
• The update of the credit values happens differently at SD and FI side.
• From SD side the sales orders, deliveries and invoices are updating the 'Open sales orders', 'Open delivery' and 'Open billing document' categories of the credit exposure respectively (in SAP Credit Management these are 100, 400 and 500 liability categories). When the 'Credit active' indicator of an item category is deactivated, then the system is not calculating and not updating a credit value for this item. 
• However, this indicator is only relevant from SD point of view for the SD sales documents.
• Once the billing document is transferred to FI (you create an accounting document) the system always updates the 'Open receivables' category (200 in FSCM). See SAP Note 412004.

2696793 - Licensing of SAP Credit Management in SAP S/4HANA On Premise

You need an additional license when you want to use the following functions in SAP Credit Management:

• Calculate the internal credit score of a business partner automatically
• Derive the risk class automatically from the internal score
• Store external credit information like a rating from credit agencies on the business partner or to integrate credit agencies in another manner
• Import credit score, credit risk class or credit limits from 3rd party systems and assign it to a business partner
• Automatically calculate credit limits
• Work with credit limit requests
• Work with documented credit decissions (DCD) that are not automatically generated by the system for a sales document
• Use the credit event / follow-on process functionality
• Setup a central Credit Management in a multi-system landscape

You do not need an additional license when you want to use following functions in SAP Credit Management:

• Set credit limits for a business partner manually
• Set the risk class for a business partner manually
• Do credit checks on a sales documents
• Process credit blocked sales documents as documented cedit decision
• Calculate payment behaviour key figures
• Define relationships for a business partner (like "in Credit Management is managed by...", "Higher level Credit Management Account of...")

SAP may verify your usage of SAP Credit Mangement functions in detail during a license audit.

2590205 - Last payment date in FSCM Credit Management

Execute transaction UKM_BP, enter business partner, choose ’Credit Segment data’ (Ctrl+F2), go to 'Payment behavior key figures' tab and check field 'Last payment date'.

The field 'Last Payment Date' in the FSCM Credit Management is updated, only when the 'Payment Amnt' (field NEBTR) is filled in the related FI document.

The function module FDM_COLL_LAST_PAYMENT_SET belongs to area Collections Management (in component FIN-FSCM-COL).

A payment is only relevant for Credit Management if the payment amount is not zero. If the paymnt amount is zero, then the payment will not be transfered to the Payment Behaviour Key figures. Thus the correct last payments were transfered to FSCM.

2742707 - Correction Options for Incorrect SD credit values (liability category 100, 400, 500) in UKM_COMMITMENTS

The Open Order (type 100), Open Delivery (type 400) or Open Billing Documents (type 500) values in the credit exposure are not what you expect or do not align with the values in SD (for example the open values displayed in report UKM_RVKRED88).

There are a number of reasons for why the Open Order or Open Delivery values in SD may not match with the credit exposure shown in UKM_COMMITMENTS / UKM_BP. Common examples of incorrect Open Order and Open Delivery values in FSCM SAP Credit Management include:

• Incomplete / incorrect FSCM SAP Credit Management configuration - see SAP Note 2315269 for the Configuration Guide and KBA 2788718.
• Problems with communication between SD and SAP Credit Management - see SAP Notes 2315269, 1124271.
• Non-standard implementation of BADI_SD_CM - see SAP Note 1994046.
• Empty methods in BAdI UKM_FILL. The method FILL_FIELDS can be used to modify the update of commitment types, however, activating the BAdI with empty method will result in missing credit exposure updates from SD side.

Checking for inconsistencies

• Check that the values in SD are correct using report UKM_RVKRED88 (transaction SE38) for the appropriate Credit Account (customer), Credit Control Area or Document number.
• Check the values in UKM_COMMITMENTS / UKM_BP to see if they differ to the values in UKM_RVKRED88. If there is an inexplicable difference between the credit order values of a customer in SD and the credit exposure values of the relevant business partner (UKM_COMMITMENTS), we recommend that you reconstruct the credit exposure for the customer or business partner.

Correcting inconsistencies

• First, delete the existing credit exposure in SAP Credit Management (transaction UKM_COMMITMENTS or UKM_COMMTS_DELETE).
• Run the report UKM_RVKRED77 (transaction SE38) to reconstruct the values from the SD system. Make sure that no transactions are executed in SD while the report is running. See the report documentation for more information.

This is a simplified overview of how to correct credit values in UKM_COMMITMENTS. If the problem is reoccurring, a root cause needs to be identified for which a reproducible example is required so that the credit update can be debugged.