Usage of Report CHECK - CM

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

Source - https://wiki.scn.sap.

com/wiki/display/SD/Usage+of+report+CHECK_CM
Report CHECK_CM was written to analyze the Customizing settings relevant for credit management. It
containes all credit management relevant information of a particular document.
Goto SE38 -> enter Program:  CHECK_CM -> Execute (F8)

Enter sales order number and execute:

Settings for credit check:


This part containes the active customizing settings at the time of document creation related to credit check.
The necessary settings are explained in SAP note 18613:
 Transaction OVAK: Credit check activation at sales order level
Which type of credit check is 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

*Remark: TVAK-KLIMP = 'A', 'B' or 'C' is for the simple credit check. This has only has limited functions. SAP does not
recommend to use this, the only reason it still exists in the R/3 standard system is the compatibility of R/3.  Please see these
notes on that:
SAP Note: 370785 - Simple credit check, open claims duplicate
SAP Note: 424086 - Delivery block 01 disappears after order change
 Transaction OVAD: Credit check activation at delivery and/or goods issue level
Which settings do exist for the delivery type used? 
Delivery type: 
Credit group for delivery: 
Credit group for goods issue:
 Settings for determining the credit control area of a document:
Please read here more about the credit control area determination.
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 runs in the background and
compares the credit control area from the sales document with the current customizing settings (active at
the time of Check_cm execution). 
You can see the field either in green colour or in red: 
Green means that the credit control area which was determined at the time of sales order creation (VBAK-
KKBER) 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
changed as with current date a different credit control area would be determined. 
To reflect the customizing changes in existing sales documents, you need to run report RFDKLI20. Please
read here in which cases RFDKLI20 might not update sales documents. 
 Risk category
Transaction OB01: Definition of the risk category for each credit control area
Transaction FD32: Assignment 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 means that the risk category which was determined at the time of sales order creation (VBAK-CTLPC)
matches with the actual risk category assignment in the credit master data (FD32/33).
Red means: When sales order was 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 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. Further
on this you can read HERE. 
 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 Credit Check
You can check here what is the relevant combination for the sales order. With this information you can go to
transaction OVA8 and see the customizing settings for the credit check activation.

Credit Status of the document:

Overall credit status (CMGST) is determined from the individual credit check status. If 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 is
activated, you can see in transaction OVA8.
Note: in OVA8 with the field Status/Block you can control that the executed credit check result is reflected in
the sales document too.
If you release a document, the overall credit status (CMGST) will be 'D' - Released, but the previous
individual status remains:
Settings for Credit Update:

Update of the credit values is required for the limit check (static or dynamic credit limit check). The
necessary settings are explained in SAP note 18613.

 Transaction OMO1
For info structure S066 the credit values can be cumulated. Here you can choose the period split and the
mode of the update.
Which kind of update did you choose for structure S066? In any case, "Synchronous update (1)" has to be
chosen as the kind of update. All other settings will lead to errors. See also SAP Note: 426202 - Incorrect
update of credit values during V2 update
 Credit account - KNKLI
If the credit account was changed since the sales document creation, you can see the field VBAK-KNKLI and
KNKK-KNKLI in red. 
If the credit account was deleted since document creation, field KNKK-KNKLI is empty.
If the credit account was changed, the fields containes different KNKLI numbers.
If there is no credit master data (FD33) for the customer, but default data is maintained for the credit control
area, the field VBAK-KNKLI can be determined, but here KNKK-KNKLI is missing. Further on this you can
read HERE.
In this case you need to run report RFDKLI20 to update open sales documents with this change. Further on
this you can read HERE.

 With the section "Fields from Table VBAP (ETTYP from table VBEP)" you can check in one step if the
customizing was done correctly at the time of document creation with regard to their credit value update.
These are:
FKREL: billing relevancy - the position must have a billing relevancy in order to update the credit values. If
an item is not relevant for billing or relevant for pro forma billing, no update occurs. If the field billing
relevancy is empty but update is needed, you can proceed the same way as described HERE.
CMPNT: Update of the credit value must be active for the corresponding item type. This field corresponds to
field "Active receivable" in Transaction VOV7. If this was changed, please read THIS.
CMPRE: credit price needs to be determined for the item. With zero credit price the credit value of the item
will be zero also. In the pricing procedure used for pricing, subtotal "A" must be entered in a line for
determining the credit value (mark the pricing procedure and doubleclick on "Control"). This way the system
is determined to use this subtotal for credit pricing. 
KBMENG: for the credit value calculation and update a confirmed quantity must exists in the position. 
How the credit value is calculated you can read HERE. 
How credit update works you can read HERE. 
 For the MRP settings, how this can be interpreted, you can read HERE.

  

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy