Online Tutorials & Training Materials | STechies.com
Register Login

Use Report CHECK_CM

|| 0

Use Report CHECK_CM
Stechies

How to use report CHECK_CM?

  • A sales order or delivery passes the credit check unpredictably or is it blocked even if the customer credit limit has not exceeded.
  • During the processing of a sales document a message regarding a credit check or credit limit comes up and further clarification is required.
  • It is not clear how a sales document updates the credit data or a sales document is not updating the credit data as it is expected.

Solution

Report CHECK_CM was initially written to analyze the Customizing settings appropriate for credit management. It encompasses all credit management appropriate information of a particular document.

Goto SE38 -> enter Program:  CHECK_CM -> Execute (F8)

Settings for Credit Check:

This part entails the active customizing settings during the time of creating the document related to the credit check. 

Transaction OVAK: Credit check activation at sales order level

What types of credit check has been activated for the sales document type?

  • Sales document
  • Check credit
  • Credit group

In Check_cm -> Type of Credit Check:  TVAK-KLIMP =  D   Automatic Credit Check

Important Note: TVAK-KLIMP = 'A', 'B' or 'C' is for the simple credit check. This only has limited functions. SAP does not recommend for using this. The only reason it still persists in the R/3 standard system is because of R/3 compatibility.

Transaction OVAD: Credit check activation at delivery and/or goods issue level.

Which settings exist for the delivery type used? 

  • Delivery type: 
  • Credit group for delivery
  • Credit group for goods issue

Settings for defining the credit control area of a document:

  • Credit Control Area determined in the sales order: VBAK-KKBER =  0001         
  • Test: SD_DETERMINE_KKBER ->  0001

When report CHECK_CM is executed, function module SD_DETERMINE_KKBER functions in the background and compares the credit control area from the sales document with the present customizing settings (this is active at the time of Check_cm execution). 

User can view the field in green or red colour.

  • Green refers to the credit control area which was initially determined during the time of sales order creation (VBAK-KKBER)and matches with the actual customizing setting of the credit control area determination. 
  • Red means since the sales order creation the customizing setting for credit control area determination was modified with the current date a different credit control area would be determined for reflecting the customizing changes in existing sales documents, user is required to run the report RFDKLI20. 

Categories of Risk:

  • Transaction OB01: Definition of the risk category for each credit control area
  • Transaction FD32: Assignment of this risk category to a credit account = KNKK-CTLPC

The risk category found during sales order processing is stored in the field VBAK-CTLPC. When report CHECK_CM is executed, a test runs in the background for the field KNKK-CTLPC which reads the actual risk category from the master data (FD33).

Green refers to the risk category which was determined during the time of sales order creation (VBAK-CTLPC) corresponds with the actual risk category assignment in the credit master data (FD32/33).

Red means when sales order was initially created, risk category 'A' was maintained in FD33 for the relevant credit account. Since the sales order creation this setting for risk category was changed as with current date risk category = '001' would be determined. If user has not altered anything except the risk category, he can use the RFDKLI20 report, but it’s very large for this purpose. If the user changes the risk category, the RVKRED09 report is enough.  

Credit Group

  • 01 -> setting for Sales order in transaction OVAK
  • 02 -> setting for Delivery in transaction OVAD
  • 03 -> setting for Goods issue in transaction OVAD

Key Fields for Automatic Checking of Credit

User can verify here what is the appropriate combination for the sales order. With this information, the user can go to transaction OVA8 and view the customizing settings for the credit check activation.

If the entry under "Credit Status from Table VBUK" shows in red colour, this refers to the credit check failed.

Overall credit status (VBUK-CMGST) is determined from the individual credit check status. Incase, one of the check has a result 'Not OK', the overall status will be also 'Not OK' = Credit Blocked. 

Which one from the credit checks has been activated, user can see in transaction OVA8?

Note: in OVA8 with the field Status/Block the user can control that the executed credit check result is visible in the sales document also.  

If the overall status is released user will still see which check failed before getting releasing the document.

Settings for Credit Update:

Update of the credit values is needed for the limit check (static or dynamic credit limit check).

Transaction OMO1

For info structure S066 the credit values can be cumulated. Here the user can select the period split and the mode of the update.

Which type of update did the user select for structure S066?

  • In any case, "Synchronous update (1)" has to be selected as the kind of update. All other settings will ultimately lead to errors. 
  • In section "Key Fields for Credit Master Data" user can see for which customer and credit control area the values were modified.

Credit Account - KNKLI

If the credit account was altered since the sales document creation, user can view the field VBAK-KNKLI and KNKK-KNKLI in red. 

  • Incase the credit account was deleted since document creation, field KNKK-KNKLI is empty.
  • If the credit account was altered, the fields entail the various KNKLI numbers.
  • If there is no credit master data (FD33) for the customer, however the default data is maintained for the credit control area, the field VBAK-KNKLI can be determined, but in this case the KNKK-KNKLI is missing. 
  • In this case user required to run report RFDKLI20 for updating the open sales documents with this change. 

In the Fields from Table VBAP (ETTYP from Table VBEP) user can verify in one step if the customizing was done accurately at the time of document creation with respect to their credit value update. These are:

CMPNT : Update of the credit value should be active for the corresponding item type. This field corresponds to field "Active receivable" in Transaction VOV7.

FKREL: Depending on the "Relevant for Billing" setting the open order value or the open delivery value is updated in info structures S066/S067. The position should have a billing relevancy for updating the credit values. Incase an item is not appropriate for billing or relevant for pro-forma billing, then no update takes place..

CMPRE: Credit price per unit. Credit price has to be determined for the item. With zero credit price the credit value of the item will be zero also. In the pricing process utilized used for pricing, subtotal "A" should be entered in a line for determining the credit value (mark the pricing procedure and double click on "Control"). This way the system is determined for using this subtotal for credit pricing. 

It does NOT require to the same as the net value.

KBMENG: Confirmed quantity. For the credit value calculation and update a confirmed quantity should exist in the position. The credit value of an item is the credit management price (CMPRE) * confirmed quantity (KBMENG).