- SAP Managed Tags:
As SAP Credit Management (FSCM) is a different solution, several differences can be noticed that are impacting how credit checks function. Rather than providing a comprehensive guide to credit management, this blog is focusing on credit checks only. This blog explores the differences compared to ECC classic credit management (SD-BF-CM/FI-AR-CR) such as configuration in transaction OVA8 and on Credit Account (Business Partner) level, describes the presently available credit checks and mentions enhancement options.
Disclaimer: The information is relevant for SAP S/4HANA Private Cloud (On-Premise) releases, specifically the processing of SD Sales documents. The blog points out the standard design and only gives general suggestions to adjust the functionality, any modifications need to be implemented and tested at your own responsibility.
Content
- General remarks on credit checks
- SAP Credit Management overall configuration
- Available credit check steps
- Credit check enhancements
General remarks on credit checks
- Credit check from SD side is only performed for Sales Orders (activated in transaction OVAK) or Deliveries (activated in transaction OVAD, at the Delivery/PGI level). Billing documents do not undergo credit check.
- In transaction OVAK, the credit check type supported is 'Automatic' (Type 'D'). Simple credit checks are no longer recommended or supported by SAP.
- The credit group is maintained in transactions OVAK or OVAD. In standard 01 for sales orders, 02 for delivery, 03 for PGI level.
- Credit check can be triggered on a sales document if the Credit Control Area (VBAK/LIKP-KKBER) and Credit Account - based on Payer - (VBAK/LIKP-KNKLI) are determined. From the Credit Account the system is reading the risk class (VBAK/LIKP-CTLPC) which are used to look up the configuration in OVA8 transaction.
- No credit check can be triggered on delivery without reference to sales order (e.g. STO) as the necessary master data is missing.
- In transaction OVA8 the SAP Credit Management check has to be flagged, Reaction and Status/Block setting maintained per requirement. This is needed to even initiate a credit check from SD side. The credit checks are executed then on FSCM side per check rule.
- During the saving of a sales document, credit checks are being executed. Even if the user is only making changes to a non-critical field (such as customer reference, material description, or header text) without increasing the quantity or credit price, a credit check process will still be started.
- The credit check is valid for the whole sales document, the credit status is a header level field. The credit block cannot be set per items and credit release cannot be done for specific items either.
- In OVA8 transaction the ‘Item check’ flag can be set to trigger a credit check already when items are being added to the sales order. This informs the user if the order would fail on the credit check so they can decide to abort the document processing.
- The credit active indicator (item category setting, VBAP/LIPS-CMPNT) is not directly controlling the credit check, but the credit value of sales document items.
- The following 'Overall Credit Status' results can occur:
- 'Approved' - CMGST = 'A': All the assigned credit checks are OK, credit block did not occur. Sales order or delivery can be further processed. In general, the document will be updated to the credit exposure.
- 'Blocked / Not Approved' - CMGST = 'B': The document was credit blocked because one of the credit checks failed or a check which also uses credit status field failed. In general, blocked sales orders don't update the exposure, but deliveries do update even if credit blocked.
- 'Released' - CMGST = 'D': The document is getting released manually by the responsible person (credit analyst, credit representative). Releasing a sales document does not happen automatically (manual DCD release or VKM* transaction). During the release, fields VBAK/LIKP-CMFRE and VBAK/LIKP-AMTBL are also getting populated. The individual credit statuses are not changed during release to keep a record of failed credit check.
- 'Not Performed / Not checked' - CMGST = ' ': The sales document did not get its credit status filled because the prerequisites to perform credit check are not met or setting the status is not configured or a No check routine was bypassing the credit check.
- The FSCM credit statuses are as below:
- VBAK/LIKP-CMPS_CM = Status of Credit Check SAP Credit Management
- VBAK/LIKP-CMPS_TE = Status of Technical Error SAP Credit Management
- Overall credit status is based on the credit check status. Also, the Payment Cards authorization (VBAK/LIKP-CMPSK) and Letter of Credit (Financial documents, VBAK/LIKP-CMPSI) check can set the overall credit status to blocked if these failed.
References:
KBA 2788718 - Configuration checklist for SAP Credit Management (FSCM)
KBA 3196063 - Credit check results and credit status of a sales document
KBA 2786413 - Role of 'Credit active' indicator in credit management
SAP Credit Management overall configuration
- Credit master data is defined on Business Partner with role UKM000. Settings are maintained in transaction UKM_BP (preselected for role UKM000) on 'General Data' -> 'Credit profile' tab (important: Risk class and Check rule) and on 'Credit Segment data' tab (important: Credit limit, Option to simulate credit check).
- Credit segment is the organizational unit of FSCM. Credit segments need to be created and assigned to the equivalent credit control area. On the sales documents the system is determining the credit control area (CCAr) the same as on ECC (userexit or payer master data or based on sales area or based on company code) and this value is mapped to the credit segment.
- The credit checks are assigned to a credit 'Check Rule'. Follow SPRO > FSCM > ... > Credit Limit Check > Define Checking Rules. There are SAP delivered check rules, but any custom credit check rule can be created and credit check steps assigned per business requirement.
- The ‘Check Rule’ is maintained on the Business Partner -> Credit Profile tab in UKM_BP transaction. Accordingly, the credit checks added to the check rule are relevant for all credit segments of the Business Partner.
- OVA8 transaction looks different, the individual credit checks are no longer listed here. The only available credit check is SAP Credit Management. There is only one 'Reaction' and 'Status/Block' setting that can be maintained for the overall SAP Credit Management check. This is the correct system design, because the individual credit check step results (which are assigned to a given check rule) are also aggregated.
- The seasonal factor settings in OVA8 have also been removed. An alternative is the Business Partner/Credit segment level Further Information options.
- With FSCM it is possible to execute the credit check on main segment only, subsegment only or both main segment and subsegment levels. Follow SPRO > FSCM > ... > Master Data > Create Credit Segments. From S/4HANA 1909 release it is possible to decide between these options when maintaining the subsegment. (On previous releases the ‘Add. Contribution to Main Segment’ setting also triggered main segment level credit check.)
- The previously known credit account hierarchy or parent-child credit account setup is still possible with FSCM. The Business Partners can be assigned to each other via Relationships. FUKM001 category is used for the parent/higher-level/superordinate credit account and TUKM001 category is used for the child/lower-level/subordinate credit account. From the sales order the child account is triggering the credit check and on FSCM side the system reads the details of the relationship. To have a working setup the child account should have a different check rule, without credit limit check steps (010 Static, 030 Dynamic) assigned. The DCD is created for the child account.
- Credit check can be executed on sales orders even if credit master data is not maintained on the Business Partner. As SD side triggers the credit check, FSCM side creates the necessary master data from default settings - given that default check rule, risk class determination are maintained.
References:
KBA 2788718 - Configuration checklist for SAP Credit Management (FSCM)
KBA 2207394 - FSCM less credit checks in OVA8
KBA 2761313 - Maintain Credit Checks for SAP Credit Management (FSCM)
KBA 2818007 - Credit limit seasonal factor in FSCM Credit Management
SAP Note 2270544 - S4TWL - Credit Management
KBA 2801882 - Credit limit check with main segment and/or subsegment in SAP Credit Management (FSCM)
KBA 2706299 - Parent-child relationship of business partners for credit check in SAP Credit Management (FSCM)
KBA 3017134 - Automatic creation of credit segment
Available credit check steps
The following credit check steps are available in FSCM and can be assigned to check rules. Certain credit check steps can have settings maintained on credit segment level. If there is no segment level setting for a given credit segment then the overall settings per Check Step Level are valid.
010 Static Check of Credit Exposure (UKM_CHECK_010)
- The credit check is comparing the credit limit to the aggregated credit value of all exposure types (open orders, deliveries, billing documents, open items) + the credit value of the sales document being created.
- Static credit check ‘open orders’/’open deliveries’ exclusion flag no longer available, the whole credit exposure is used during the credit check.
- It is not advised to add both Static and Dynamic credit limit checks to the same check rule.
020 Check for Maximum Document Value (UKM_CHECK_020)
- The sales order or delivery value should not exceed the maximum value that is specified per credit segment. The value is stored in the currency of the credit segment.
- This type of credit check makes sense, for example, if you process orders for new customers whose credit limits have not yet been defined.
- The standard check step is not designed for a 0 (zero) value check.
030 Dynamic Limit Check with Credit Horizon (UKM_CHECK_030)
- If the credit exposure within the horizon is exceeding the credit limit the document is credit blocked.
- Only the open sales order items with delivery-related billing belong to the dynamic part based on the material availability date (VBEP-MBDAT). The sales documents with order-related billing are completely included in the dynamic credit limit check. The open deliveries, billing document and open items also belong to the static part.
- With FSCM the credit horizon is set in days and the end of the credit horizon is a specific date. 0 (zero) days are not advised as credit horizon, in that case from the dynamic part only the credit values up to the current date are used.
- Even the sales orders outside the credit horizon are credit checked and if the limit is already exceeded the credit status will be blocked.
100 Check for Maximum Dunning Level (UKM_CHECK_100)
- In this credit check you specify the highest dunning level you want to allow. The dunning level is tracked and stored in the credit data in the customer master record.
110 Check for Age of Oldest Open Item (UKM_CHECK_110)
- This check refers to the 'Vector' data, transferred from FI side with the UKM_TRANSFER_VECTOR report. The oldest open item must not be older than the number of days specified.
120 Check of Payment Behavior Index (UKM_CHECK_120)
- Credit check against Key figure DSO (= Days Sales Outstanding) specified. The open items may not be open for a longer period than specified as DSO (days sales outstanding).
Good to know
- The steps 100, 110, and 120 relate to key figures located in the credit segment data of a Business Partner. You find the key figures on the Payment Behavior Key Figures tab of UKM_BP, Credit Segment Data.
- The key figures on this tab are written by program UKM_TRANSFER_VECTOR. This program needs to be run regularly so that the key figures in the credit segment data are up to date, thereby enabling the above credit checks to be performed correctly.
130 Check for Overdue Open Items (UKM_CHECK_130)
- This step is related to the TIMESTAMP in the FSCM with which the documents are stored and written, mainly set with the ‘posting’ or ‘document’ date of the related items. The proportion of overdue open items (that exceed the specified number of days) in the total of open items should not exceed the percentage specified.
- SPRO > ... > Credit Exposure Update > Define Liability Categories >> Grid flag is needed so the relevant items flow into the evaluation.
- The percentage and day in credit segment level should be defined, otherwise the credit check result will be incorrect and just display as 0% (‘ ‘ days).
140 Check for Credit Limit Validity (UKM_CHECK_140)
- Checks if the credit limit is still valid according to the validity date maintained on Credit Segment level of Business Partner.
- The new check step was introduced with S/4HANA On-Premise/Private Cloud 2022. (S4CORE 107)
- On lower releases the credit limit is still used in credit checks, even if it has already expired.
Removed checks
- Credit check for ‘Critical fields’ is removed.
- The ‘Next review date’ check does not exist in previous form.
- The ‘User 1’, ‘User 2’, ‘User 3’ checks from OVA8 transaction are not directly available.
Logging
If any of the credit check steps assigned to the check rule fail, then the SAP Credit Management check fails and VBAK/LIKP-CMPS_CM will be set to ‘B’. To check which individual credit check step failed the below options exist:
- Log: Credit check details logging can be activated on the 'Check Rule' level, it is suggested to use the extensive logging. With active logging the system stores the checked credit value, credit limit, credit exposure, payment behavior key figures, maximum document, etc. The log can be checked from transaction UKM_LOGS_DISPLAY.
- Reason for blocked overall status: Transaction UKM_CASE/SCASE/UKM_MY_DCDS list the 'Documented Credit Decisions' created for sales documents. In the layout, columns showing which credit check step failed (e.g. column Static Check, Maximum Doc. Value Check, etc.) can be added. VKM* transactions can only show that 'SAP Credit Management' is causing the credit blocked status.
References:
KBA 2761313 - Maintain Credit Checks for SAP Credit Management (FSCM)
SAP Note 2561725 - Simplified functions in SAP Credit Management in SAP S/4HANA
KBA 2926009 - Credit check step per segment customizing in SAP Credit Management (FSCM)
KBA 3196063 - Credit check results and credit status of a sales document
KBA 2939371 - Dynamic Limit Check with Credit Horizon in SAP Credit Management (FSCM)
Credit check enhancements
Userexit credit checks
- Customized credit check steps can be created by implementing credit check steps in BAdI UKM_CHECK_STEP. Copying an existing credit check step and modifying it is advised. The BAdI can access data via the input parameter IO_ACCOUNT of class CL_UKM_ACCOUNT.
- The credit check step coding is executed on FSCM side, if more SD data is needed consider a custom implementation of BADI_SD_CM (Methods FSCM_CREDIT_CHECK_ORDER, FSCM_CREDIT_CHECK_DELVRY) or direct modification on FMs SD_ORDER_CREDIT_CHECK, SD_DELIVERY_CREDIT_CHECK.
- The custom credit check steps should no longer refer to S066, S067 and KNKK data.
- An alternative to ‘Critical Fields’ credit check could only be achieved by custom credit check logic.
References:
KBA 3427949 - FSCM alternative for User 1, User 2, User 3 credit checks
KBA 3454258 - Critical fields credit check on S/4HANA - FSCM
Credit check based on requested quantity
- This functionality is not available in the standard. The static and dynamic credit check calculates the credit value of the order being created by using the confirmed quantity. You could create a custom credit check step to modify the standard Static/Dynamic credit check. Alternatively, the credit value (LV_AMOUNT) sent from SD to FSCM in BADI_SD_CM -> Method FSCM_CREDIT_CHECK_ORDER could be adjusted by custom logic.
References:
KBA 3276107 - Credit check with order/requested quantity instead of confirmed quantity (FSCM)
Exclude values from Static credit check
- Custom credit check could be implemented based on the 010 check step, where you exclude values from the credit exposure that the system is pulling. Alternatively, if orders are to be generally excluded, then update group 15 could be used (Credit Control Area setting, transaction OB45). Or based on the requirement the liability categories could be switched to ‘Statistical’ (SPRO > ... > Credit Exposure Update > Define Liability Categories). Keep in mind that the configuration changes have a wider impact, not only relevant for one credit check step/credit segment.
References:
KBA 3460701 - Static credit check control flags not available with FSCM
Avoid credit checks (1) - Released documents are still unchecked
- When a sales order was already released further credit checks can be avoided. The release validity can be extended by OVA8 settings of ‘Deviation%’ and ‘Number of days’.
- To avoid the credit check during saving the following criteria has to be fulfilled: released credit value (VBAK/LIKP-AMTBL) is more or equal than momentary credit value AND release date (VBAK/LIKP-CMFRE) is valid on the day of new credit check
- Frequent cause for recheck after release: released credit value is not the full credit value of the sales document (e.g. ATP can’t confirm all items, PR not created due to missing data).
- If an order is released and delivered on the same day, the delivery is not rechecked again (LIKP-CMGST = 'D').
- On the day of release there is no new credit check (behavior can be changed by modification of FMs SD_ORDER_CREDIT_CHECK / SD_DELIVERY_CREDIT_CHECK, validity date check GT instead of GE)
References:
SAP Note 718260 - Released documents are still unchecked
Avoid credit checks (2) - Routine to bypass FSCM credit check
- The credit check can be deactivated through custom routine in OVA8, field ‘No credit check’.
- Do not directly use the 001, 002 routines, those are only examples.
- BYPASS-CREDIT_MANAGEMENT variable is to be set to true ('X') to skip the SAP Credit Management check.
- STATUS_RESET-CREDIT_MANAGEMENT variable is to be set to true ('X') to clear/reset the SAP Credit Management status (VBAK/LIKP-CMPS_CM).
- The routine runs during any credit check (except while credit release is still valid).
- If you skip the credit check (and there was previously also no credit check executed), then the overall credit status will be ‘Not performed’.
- The STATUS_RESET parameter is needed to clear the previous failed credit status (VBAK/LIKP-CMPS_CM), but it results in overall credit status as ‘Not performed’ (VBAK/LIKP-CMGST).
References:
KBA 2469457 - Bypass credit check in custom routine in SAP Credit Management (FSCM)
Credit check message details
- Reactions ‘C’ and ‘D’ have been deprecated. Warning messages about failed credit check appear as a pop-up showing the details. Error messages are displayed only as one-line text (VM010) informing the user that the credit check failed.
- The pop-up message and the error message could be modified in own BADI_SD_CM implementation by adjusting method FSCM_DISPLAY_CREDIT_MESSAGES. Variable I_MESSAGE_TYPE controls the reaction type.
References:
KBA 2871140 - Credit check result details not shown with error reaction - FSCM
The current blog discusses many useful information to setup credit checks with FSCM. Review the requirements with the business in detail and consider the described standard design. Before switching to SAP Credit Management (FSCM) consider the shared information in detail to be able to move from ECC classic credit management with the least effort. Keep in mind that modifications and own check steps are considered as custom code, hence you are required to implement and test in detail.
For further information feel free to ask questions on SAP Community.
7 Comments
