This triggers the availability check (ATP) for the entire document. You cannot tell which items are included in the availability check.
Solution
1. The confirmed quantities are usually reset when a credit block occurs for a sales document. This means a new availability check is triggered for the entire document when it is released from the credit block.
2. During the recheck, the system carries out an availability check before it runs the credit check, so the current confirmed quantities are available for the credit limit check.
A decision regarding whether to perform the availability check is made for each item.
The item does not have any confirmed quantities (VBAP-KBMENG = 0). -> The availability check is performed.
The item is confirmed either wholly or partially (VBAP-KBMENG > 0). -> The availability check is not performed.
The item is partially delivered and the confirmed quantity is higher than the delivered quantity (confirmed quantity - delivered quantity = 0). -> The availability check is performed.
The system carries out a product selection for the item. -> The availability check is performed.
The item belongs to a scheduling agreement with releases (component supplier). -> The availability check is performed.
If you want your system to behave differently from the standard logic, you can use the user exit USEREXIT_AVAIL_CHECK_CREDIT in the include MV45AFZF. With the user exit you can:
... Execute the availability check in all scenarios.
... Call the availability check in accordance with the standard logic, as described above (the default setting).
... Skip the availability check.
The user exit is processed for each item which means a decision can be made for each item. When a recheck takes place, the availability check is carried out before the credit check. Therefore, the new credit status is not yet available in USEREXIT_AVAIL_CHECK_CREDIT.
SAP Note: 1324433 - Availability check during credit block release
Blocked document is not listed in VKM1
Skip to end of metadata
Created by Former Member on Jan 07, 2015
Go to start of metadata
Symptom
The system does not display a document blocked by credit management in Transaction VKM1 (List 'Blocked SD documents').
Solution
Please read HERE which documents are listed in the VKM* transactions.
The document the system does not display is completed. In Transaction VKM1, the system displays only sales and distribution documents which do not have the overall processing status 'Completed' (VBUK-GBSTK = C).
Example: A sales order is credit blocked. Then you reject this sales order since it should no longer be fulfilled. Since the reason for rejection is set, the sales order receives the overall processing status 'Completed'. Then the system no longer displays the document in the 'Blocked SD documents' list.
Reason: Documents with the overall status 'Completed' are also completed from credit management point of view. It would be superfluous to release them again since with this status, no more subsequent functions are provided which should be prevented by a credit block.
SAP Note: 377029 - Blocked documents not in Transaction VKM1
Credit values are displayed in thousand
Skip to end of metadata
Created by Former Member on Jan 08, 2015
Go to start of metadata
Symptom
In the VKM* transactions you might think that some fileds shows incorrect amount or there is a decimal error.
Solution
In Transactions VKM1, VKM2, VKM3, VKM4 and VKM5, the system displays the following values divided by thousand:
Released credit amount of the document (AMTBL)
Open sales order credit value (schedule lines) (OEIKW)
Open delivery credit value (OLIKW)
Open billing document credit value (OFAKW)
Customer's credit limit (KLIMK)
These are the actual values in FD33:
This is what you see in VKM* transaction:
Field AWAER is available to show that the amounts are displayed in an abbreviated form. If the currency of the credit control area is, for example, EUR, this field contains the value TEUR. If required, a corresponding column should be added to the output list.
Related SAP Note: 413483 - VKM1-5: Display credit values in thousand
Display variant shows two lines
Skip to end of metadata
Created by Former Member on Jan 08, 2015
Go to start of metadata
Symptom
How do we change the default ALV display variant for this transaction so that the output doesn't show the extra fields?
In the output of VKM* duplicates are shown and some fields are displayed on a second line.
The ALV list from VKM3 in our prior system shows 83 fields on one line.
The ALV list from VKM3 in the upgraded system shows 96 fields.
Cause
An ALV conversion has been implemented. In order to make as many fields available as possible the list has been extended.
Solution
There are only a few steps necessary to make your settings available to ALL users. There is no need that every user creates an own variant. By using the variants you have the most flexibility. And there are also 3 variant already availble that need just one flag set in order to be used for all users at the same time. To create a variant and to set it as the default variant for all users, proceed as follows:
1. In the result list, select the path "Settings -> Display Variant -> Current". Select the fields that you want to appear in the display. Copy the selection and save the display variant. Make sure that the display variant is not flagged as user-specific.
2. Set the display variant as the default for all users. In the result list, select the path Settings -> Display Variant -> Administration. Set the variant that you want as default. Here, you can also select a standard variant as default and make it centrally default for all users.
Please read also following Notes:
SAP Note: 1785103 - Display list VKM1 VKM2 VKM3 VKM4 SAP Note: 300633 - General administration and setting information for ALV variant SAP Note: 121550 - User settings table control SAP Note: 551178 - FAQ: ALV layout
SAP KBA: 1866441 - VKM*: ALV default output display variant shows two lines
No confirmed quantity after sales order credit release
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
You release a sales order from the credit block and then cannot explain the confirmed quantities in the sales order.
Solution
If a sales order is released from the credit block, an availability check is run in the background for the sales order. In Customizing of Transaction OVZJ, you can set which outcome from the availability check is to be set in the sales order. Dependending on the sales area, you can make settings in the "Avail.check rule" field (TVTA-REVFP), concerning how the system is to behave during the transfer of the outcome from the availability check. During the credit release, the sales order is edited and saved in a background process. The availability check then also runs in the background ("batch"), therefore without the option for a user to have a controlling influence.
Example 1:
For the relevant sales area in Transaction OVZJ, you have set the indicator 'D' "Dialog box in the case of shortages (one-time dlv)".
You have a sales order item of 10 pieces. The sales order was blocked by the credit management. You release the sales order. During the release, the availability check runs in the background. The requested quantities can be confirmed for a later date, but not for the desired date.
The sales order does not receive any confirmed quantities.
Example 2:
For the relevant sales area in Transaction OVZJ, you set the indicator ' E' "Dialog box in the case of shortages (delivery proposal)".
You have a sales order item of 20 pieces. The sales order was blocked by the credit management.
You release the sales order. During the availability check during the release, the system cannot confirm the requested quantities for the desired date. However, 10 pieces can be confirmed immediately and 10 pieces for a later date.
Due to the setting 'E', the system transfers the delivery proposal - 10 pieces immediately and 10 pieces for a later date - to the sales order item.
SAP Note: 886038 - No confirmed quantity after sales order credit release
Performance problem in VKM* transactions
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
Performance problems in a VKM* transaction.
Analysis
For the solution please consider following SAP notes:
1003247 - Performance in transactions VKM1, VKM2, and VKM4
886035 - Documentation for the VAKCR_REBUILD report
26466 - VKM4: Credit limit, performance
696788 - Performance problems in transaction VKM1 or VKM4
No labels
Sales order is released but it is again displayed in the list of VKM3 or VKM4
Skip to end of metadata
Created by Former Member on Jan 08, 2015
Go to start of metadata
Symptom
You have a blocked order which you list and release in transaction VKM3 or VKM4. After release you execute the VKM3/4 transaction again and the document is still displayed in the list.
Solution
This is standard behaviour.
Transaction VKM3 (report RVKRED04): lists all sales orders, which credit status is either blocked, released or credit limit check was OK;
Transaction VKM4 (report RVKRED01): lists all credit management relevant document.
If you want to list only credit blocked documents, please use transaction VKM1.
Please read this also: Which documents are listed in the VKM* transactions
Relevant SAP Note: 586390 - Credit blocked sales order returned with VKM3
Scope of VKM* transactions
Skip to end of metadata
Created by Former Member on Jan 07, 2015
Go to start of metadata
Symptom
It is not clear which VKM* transaction displays which document.
Solution
VKM1 (report RVKRED02): lists only those open (Status: Open or Being processed) sales documents, which are blocked due to credit limit check;
VKM2 (report RVKRED03): lists only released sales documents;
VKM3 (report RVKRED04): lists all sales orders, which are blocked, released or credit limit check was OK;
VKM4 (report RVKRED01): all credit management relevant documents are listed;
VKM5 (report RVKRED05): lists all deliveries, which are blocked, released or credit limit check was OK.
I.e.: if a sales order is blocked due to credit limit check, it will appear in VKM1 (also in VKM3 and VKM4). Once you release the order, it disappers from VKM1 and will be listed in VKM2, VKM3 and VKM4.
Related notes:
SAP Note: 377029 - Blocked documents not in Transaction VKM1
SAP KBA: 1656221 - Scope of VKM* transactions - documents to be listed - Credit management
VKM*: Extend list with user-defined fields
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
You want to extend the lists displayed by Transactions VKM1 - 5 with user-defined fields.
Solution
Transactions VKM1 - 5 display lists with sales and distribution documents that are relevant for the credit management. Logical database KMV is used to select the document data. Also consider the documentation for program SAPDBKMV. The document data is collected in internal table XVBKRED. The internal table contains exactly one line for every document.
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.
Please note:
Consider the information about user exits in the SD contained in Note 381348.
Consider the performance aspects in connection with the programming of the user exit since a mass processing of document data is involved. When you consider this, you can avoid longer runtimes of Transactions VKM1 - 5.
Consider that the output list contains only one line per document, so that item or schedule line data cannot be represented.
Consider the explanations for the ALV field catalog in Note 122975 and if necessary run report BALVBUFDEL as described in the note.
Related SAP Notes:
SAP Note: 779389 - VKM*: Extend list with user-defined fields SAP Note: 381348 - Using user exit, customer exit, VOFM in SD SAP Note: 122975 - Resetting buffering of ALV field catalog
VKM*: Extend list with user-defined fields
Skip to end of metadata
Created by Former Member on Jan 09, 2015
Go to start of metadata
Symptom
You want to extend the lists displayed by Transactions VKM1 - 5 with user-defined fields.
Solution
Transactions VKM1 - 5 display lists with sales and distribution documents that are relevant for the credit management. Logical database KMV is used to select the document data. Also consider the documentation for program SAPDBKMV. The document data is collected in internal table XVBKRED. The internal table contains exactly one line for every document.
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.
Please note:
Consider the information about user exits in the SD contained in Note 381348.
Consider the performance aspects in connection with the programming of the user exit since a mass processing of document data is involved. When you consider this, you can avoid longer runtimes of Transactions VKM1 - 5.
Consider that the output list contains only one line per document, so that item or schedule line data cannot be represented.
Consider the explanations for the ALV field catalog in Note 122975 and if necessary run report BALVBUFDEL as described in the note.
Related SAP Notes:
SAP Note: 779389 - VKM*: Extend list with user-defined fields SAP Note: 381348 - Using user exit, customer exit, VOFM in SD SAP Note: 122975 - Resetting buffering of ALV field catalog
Sales orders are not blocking when they should
Skip to end of metadata
Created by Gerard Magorrian on Jul 31, 2012
Go to start of metadata
Purpose
This document was created to highlight some of the more common reasons why a Sales document is not blocked by the credit management system.
Overview
A failure within the credit check should result in a blocked status for the document (VBUK-CMGST – B). Under certain conditions the status of a sales document can remain unblocked. Here we discuss some common causes and solutions to this behaviour.
Overall Credit Status
The first step in the analysis is to check the header status of the sales document by accessing the following menu path: Goto > Header > Status.
Not Performed Status
Not Performed means that the document was not configured for checking. Go to the 'Sales' tab and get the document type. Go back to the Overview screen and go to Environment > Credit partner. This branches to FD33, the Credit Master. Here you will need the credit control area and the risk category. With this information, first check OVAK, the document type. Find your document type, and make sure that it is ‘D’ with a credit group assigned. Maybe, the ‘D’ is not set. If it is, go on to OVA8 and make sure that checking has been assigned for the credit control area/risk management/credit group combination.
If all this is fine, make sure that the following note is present on your system:
356364 - Sales orders are no longer blocked
Approved Status
Approved status is a little bit more complicated in this situation. The first check to make is on the item category of the sales order items (VBAP-PSTYV). Go to transaction VOV7 and make sure of the following:
item is relevant for billing
item is relevant for credit
the item does not have a check mark in ‘item relv for delv’. This is for text and value items which have no value in R/3 – see note 67748
the item is not statistical
If these are not configured correctly, the item will have no value.
Lastly, go to the sales order and make sure that the items have a Confirmed Schedule Line Quantity. Without a Confirmed Schedule Line Quantity the item will have no credit value. The credit value is calculated based on the Credit Price condition and the Confirmed Schedule Line Quantity. Without either of these the credit value of the item will be zero. After you have confirmed the quantity in the Schedule Line, check the pricing procedure. You can go to the analysis button to find out which pricing procedure is being used. When you have this information open transaction V/08 and go to the details level of the pricing procedure. Make sure that an ‘A’ is set in the ‘Sub to’ column for something reasonable like the total of the document.
Related Content
Related Documents:
Related Notes
377165 - Update open credit values for credit management
067748 - Update of open sales order values
18613 - Checklist for Credit Management
356364 - Sales orders are no longer blocked
With correct customizing settings for credit check
Skip to end of metadata
Created by Former Member on Jan 16, 2015
Go to start of metadata
Does the sales document has an open credit value?
YES
NO
Analysis
Please use report Check_cm to determine if the document has an open credit value.
In case it is about a delivery, search for the related sales order number in the document flow and check the sales order with the Check_cm report as all data relevant for this is copied from the sales order.
Report Check_cm or please 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 the credit value is calculated please read HERE.
Missing customizing settings for credit check
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Which customizing setting is missing in the document for the credit check?
Type of Credit check (TVAK-KLIMP) is empty: in this case credit check was not executed and the overall credit status (CMGST) is empty, 'Not performed'. Make the necessary setting in OVAK or OVAD and test the behaviour again with new document creation.
Credit control area is missing in the document: Please read HERE more about the credit control area determination. Make the necessary assignment of the credit control area and test the behaviour again with a new document. To reflect the customizing change in existing sales documents, you need to run report RFDKLI20. More on this report you can read HERE.
Risk category is missing in the document: Make the necessary assignment of the risk category in FD32 and test the behaviour again with a new document. To reflect the customizing change in existing sales documents, you can run report RFDKLI20, but if you only change the risk category, the report RVKRED09 report is sufficient. Further on this you can read HERE.
Credit account is missing in the document: please read HERE under section 'Credit account - KNKLI'.
Which setting is missing in the customizing for the credit check? (Transaction OVA8)
Relevant combination in OVA8 is missing (Credit control area-Risk category-Credit group): the combination of the key fields for automatic credit check is not entered in OVA8, so there can't be any credit check. Make the necessary entry here.
Flag for the relevant check is not set: please activate the credit check you want to perform by the system and test the behaviour again with new document creation.
Flag for Status /Block is missing: If this field is empty, the credit status will be always 'Not performed' even if the check itself is activated!!
Flag 'Open orders' and 'Open deliveries': This is relevant for the Static credit check. If you mark both flags in OVA8, the open sales values are also considered during static credit check. If you take the flag i.e. "open orders" off, only open deliveries/billing documents (that is S067) will be taken into account when determining the credit exposure for the Static Credit check. Same is relevant for the "open deliveries", in this case only open order value will be calculated into the credit exposure from the Sales value. If both are marked off, credit exposure containes only the values of Receivables and Special liabl. during credit check execution. This might end up in a situation that sales document is not credit blocked but based on FD33 situation it would be expected. More on this you can read HERE.
Usage of report CHECK_CM
Skip to end of metadata
Created by Former Member on Jan 16, 2015
Go to start of metadata
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.
After order is released, it will be blocked again
Skip to end of metadata
Created by Former Member on Jan 20, 2015
Go to start of metadata
Symptom
During order creation a sales order gets confirmed quantity.
When saving the order the credit check fails due to current credit situation and the confirmed quantity is set to zero. (This is standard, please read more about this HERE.)
After the order was released, confirmed quantity stays zero.
If the user change the quantity again in the order, the credit check is executed again and the order is blocked again. This causes a cycle.
Analysis
1. In the standard system if a sales order is credit blocked, confirmed quantity will be set to zero due to the requirement for subsequrnt function 101.
2. Once the sales order is released, a new availabilty check is performed based on the customizing settings. Here you can influence the result i.e. with the setting in transaction OVZJ. This is explained HERE.
886038 - No confirmed quantity after sales order credit release
3. Additionally you can set up the customizing in OVA8 for released documents under 'Released documents are still unchecked'. For this please read note: 718260 - Released documents are not checked If needed please read HERE how to debug the credit check.
4. Also you can use the possibilty to calculate the released credit value based on the i.e. requested quantity. An userexit is available which sets the quantity differently than the standard. For this please read following notes:
100861 - Release of blocked sales orders - loop check 149559 - Update of requested delivery quantity, credit
5. Also please read Released Sales documents are Rechecked.
Credit value check is needed based on requested quantity, not on confirmed quantity
Skip to end of metadata
Created by Former Member on Dec 04, 2014
Go to start of metadata
Symptom
Business requires to check the documents based on the requested quantity (or any other quantity) and not on confirmed quantity.
Solution
This is not possible in the standard system. Static and dynamic credit check is executed based on the updated credit values in S066 and S067. The update is done with the confirmed quantity. More about this you can read HERE.
How credit value is calculated you can read HERE.
How credit value is updated you can read HERE.
If you want to develop a different credit check logic, you can use the credit check userexits in OVA8: User 1, 2 and 3.
In the coding:
for the orders: SD_ORDER_CREDIT_CHECK -> LVKMPFZ1, LVKMPFZ2, LVKMPFZ3
for deliveries: SD_DELIVERY_CREDIT_CHECK -> LVKMPFZ1, LVKMPFZ2, LVKMPFZ3
See also SAP Note: 751044 - Credit check with requested instead of conf. qty
Pages
…
Credit check problem during document processing
Skip to end of banner
Go to start of banner
Customizing settings for Dynamic credit check
Skip to end of metadata
Created by Former Member on Jan 15, 2015
Go to start of metadata
Problem
You face a problem with the Dynamic credit check of a document. Customizing settings check is needed to find the root cause.
Analysis
The aim is to help checking the correct customizing settings for static credit check.
Please check HERE which settings needed to activate the credit check under 'Settings for credit check'.
For the Dynamic credit check goto to transaction OVA8 and check the necessary settings based on the business requirement of the credit check result: Flag Dynamic: To activate the check, mark the field 'Dynamic' Field Reaction: If you need a system reaction in case credit limit is exceeded, please choose the appropriate one needed. If you customize error message, please be aware of the standard behaviour in case of change mode of a document, read SAP Note 706034 - Warning instead of error message for credit check. Field Status/Block: mark this field if you need a credit status determination for the document. Only in this case table VBUK will be updated with status information. If this field is empty, the credit status will be always 'Not performed' even if the check itself is activated. Field Horizon: Credit exposure will be calculated only inside of the defined horizon. How all this works, please read SAP Note '379007 - Dynamic credit limit check'.
Customizing settings for static credit check
Skip to end of metadata
Created by Former Member on Jan 15, 2015
Go to start of metadata
Problem
You face a problem with static credit check of a document. Customizing settings check is needed to find the root cause.
Analysis
The aim is to help checking the correct customizing settings for static credit check.
Please check HERE which settings needed to activate the credit check under 'Settings for credit check'.
For the static credit check goto to transaction OVA8 and check the necessary settings based on the business requirement of the credit check result: Flag Static: To activate the check, mark the field 'Static'. Field Reaction: If you need a system reaction in case credit limit is exceeded, please choose the appropriate one needed. If you customize error message, please be aware of the standard behaviour in case of change mode of a document, read SAP Note 706034 - Warning instead of error message for credit check. Field Status/Block: mark this field if you need a credit status determination for the document. Only in this case table VBUK will be updated with status information. If this field is empty, the credit status will be always 'Not performed' even if the check itself is activated. Flag 'Open orders' and 'Open deliveries': with these flags you decide which value is considered during credit check. The credit exposure containes following values: + Receivables + Special liabl. + Sales value (Open orders + Open deliveries + Open billing doc.) Please see HERE how credit value is calculated and HERE how it is updated. _____________________________________ = SUM of these will be the credit exposure which is than compared to the credit limit If you mark both flags in OVA8, the open sales values are also considered during static credit check. If you take the flag i.e. "open orders" off, only open deliveries/billing documents (that is S067) will be taken into account when determining the credit exposure for the Static Credit check. Same is relevant for the "open deliveries", in this case only open order value will be calculated into the credit exposure from the Sales value. If both are marked off, credit exposure containes only the values of Receivables and Special liabl. during credit check execution. This might end up in a situation that sales document is not credit blocked but based on FD33 situation it would be expected.
SAP KBA: 1590569: OVA8 - 'Open Orders' flag is having no effect 1613989: OVA8 - 'Open Deliveries' flag is having no effect
Example needed to recreate the wrong credit check and identify the root cause
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Symptom
You have one or more sales documents, where the credit check result is not what is expected. You do not know how to determine the reason so that you can solve the problem.
Analysis
If problem can be recreated with an actual example, please follow the GUIDE for credit check.
If the sales documents are from the past and the same wrong situation can not be recreated, please consider following:
It is difficult to analyze incorrect credit check. Credit check is executed at the time of document saving (or when you enter the position and 'Item check' is activated in OVA8) based on that date's and time's actual credit situation. This situation is no longer known at a later time, so it is not possible anymore to verify the credit check result. Also FBL5N report or other FI reports can not reflect a credit situation on a previous data as Open Sales value calculation, which is part of the credit exposure, is a complicated calculation. How it is done, please read Credit value calculation of a document.
To determine the reason for the incorrect credit check and to recreate the error, proceed as follows:
Check the customizing settings (which also reflects current situation and not the state from the date and time of document creation): Customizing settings for Static credit check Customizing settings for Dynamic credit check
Report CHECK_CM might be useful to see which credit data was pulled into the document from customizing at the time of document creation. If there is a difference to current state, it can be seen in red and from this you might assume the root cause. More on this you can read HERE.
Find an example in the system to recreate the same wrong behaviour. Recreating the error in a (test)system is a basic prerequisite for analyzing and correcting these kind of problems. Credit check happens at the time of document saving. During saving it is possible to debug the credit check process. Once document is saved, the databases are already updated and it is not possible anymore to find out why the credit check had that result. After this it is not possible to find the reason of it.
Especially for these cases there is a credit check logging tool developed to log the credit situation at the time of the credit check. Please read this HERE.
Also please read KBA 2100078 - How to provide a reproducible example?
How to analyze credit check problems
Skip to end of metadata
Created by Former Member on Jul 23, 2015
Go to start of metadata
Problem
You would like to start to analyze credit check problem you face with a sales document.
What is the failure scenario?
Is the credit check not executed?
Is the result of the credit check different than expected?
Is the credit check executed too often?
Analysis
Credit check executed too often
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
After order is released, it will be blocked again - LOOP
No credit relevant data is changed in the document, but credit status changes again
Skip the credit check
After order is released, it will be blocked again
Skip to end of metadata
Created by Former Member on Jan 20, 2015
Go to start of metadata
Symptom
During order creation a sales order gets confirmed quantity.
When saving the order the credit check fails due to current credit situation and the confirmed quantity is set to zero. (This is standard, please read more about this HERE.)
After the order was released, confirmed quantity stays zero.
If the user change the quantity again in the order, the credit check is executed again and the order is blocked again. This causes a cycle.
Analysis
1. In the standard system if a sales order is credit blocked, confirmed quantity will be set to zero due to the requirement for subsequrnt function 101.
2. Once the sales order is released, a new availabilty check is performed based on the customizing settings. Here you can influence the result i.e. with the setting in transaction OVZJ. This is explained HERE.
886038 - No confirmed quantity after sales order credit release
3. Additionally you can set up the customizing in OVA8 for released documents under 'Released documents are still unchecked'. For this please read note: 718260 - Released documents are not checked If needed please read HERE how to debug the credit check.
4. Also you can use the possibilty to calculate the released credit value based on the i.e. requested quantity. An userexit is available which sets the quantity differently than the standard. For this please read following notes:
100861 - Release of blocked sales orders - loop check 149559 - Update of requested delivery quantity, credit
5. Also please read Released Sales documents are Rechecked.
No credit relevant data is changed in the document, but credit status changes again
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
You change a sales document, but no credit management relevant data is changed. This leads to a change in the credit status.
Solution
Whenever you change a sales document and you save it, the credit check function module is always executed. Based on the document processing status, customizing settings, etc. a new credit check might be performed. Based on the actual credit situation of the credit customer this can lead to a different credit status as before.
If you would like to know more about the credit check function module logic, please read HERE.
How you can skip the credit check, please read Skip the credit check.
Skip the credit check
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
Under special circumstances credit check execution is not needed. This can be for example:
No credit relevant data is changed in the document, but credit status changes again
After order is released, it will be blocked again
You have an own report (might be background also) where credit check execution is not needed
Solution
With customizing changes of the credit check activation, for example: - order type is not activated for the credit check - relevant combination in OVA8 is deleted / not created For the general customizing settings please read HERE. Missing customizing settings for credit check Customizing settings for Static credit check Customizing settings for Dynamic credit check Credit check is not activated but still it is executed
Also please consider that documents with status 'Completed' are not credit checked.
The credit check can be deactivated through an own routine in OVA8, field 'No credit check'. In the standard there are 2 options as an example available. This shouldn't be used but copied and enhanced in a way which fits the business requirements. In this case please ensure you use the right logic as it can cause misleading credit status determination in case i.e. only BYPASS flag is used here. Further on this please read following SAP Notes: SAP Note: 895630 - Use of the requirement "No check" SAP Note: 502930 - New credit status although 'No check' is programmed
Additionally you can set up the customizing in OVA8 for released documents under 'Released documents are still unchecked'. For this please read SAP note: 718260 - Released documents are not checked If needed please read HERE how to debug the credit check.
No credit relevant data is changed in the document, but credit status changes again
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
You change a sales document, but no credit management relevant data is changed. This leads to a change in the credit status.
Solution
Whenever you change a sales document and you save it, the credit check function module is always executed. Based on the document processing status, customizing settings, etc. a new credit check might be performed. Based on the actual credit situation of the credit customer this can lead to a different credit status as before.
If you would like to know more about the credit check function module logic, please read HERE.
How you can skip the credit check, please read Skip the credit check.
Credit check not executed
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Does the document have a credit status?
YES
NO
Analysis
Please check the credit status (CMGST) of the document to determine if the check was really not executed. You can do this in following ways:
Use report CHECK_CM, further on this please read HERE.
Goto to the sales document header -> Status tab
Goto SE16, table VBUK: enter the sales document number, execute -> check the field CMGST
Missing credit status
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
Credit check is not executed as credit status is missing.
Analysis
Possible cause can be a missing customizing. To determine if the customizing is done correctly, please proceed as follows:
With the sales document number please check the customizing settings with help of report Check_cm, please read further on this HERE.
Necessary customizing setting for Static Credit Check is explained HERE.
Necessary customizing setting for Dynamic Credit Check is explained HERE.
About missing customizing please read: Missing customizing settings for credit check . It might be that you activated the credit check itself but without a Status/block indicator.
Also it can be an effect of using an own routine in the field 'No credit check' in OVA8. In this case please ensure you use the right logic as it can cause misleading credit status determination in case i.e. only BYPASS flag is used here. Further on this please read following SAP Notes: SAP Note: 895630 - Use of the requirement "No check" SAP Note: 502930 - New credit status although 'No check' is programmed
Check the SD userexits if you modify the status somewhere else (i.e. MV45AFZZ in sales, SAP Note 415716 - User exits in delivery processing).
If problem can be recreated, you might need to debug the credit check. For that please read How to debug the credit check.
Result of the credit check is different than expected
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata