Is the document credit blocked but it shouldn't be?
Is the document approved by the credit check but it should be blocked?
Credit check is not activated but still it is executed
Credit check is not activated but still it is executed
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
There is a sales document which was credit checked but the check itself is not activated.
Solution
Please check following:
With help of report CHECK_CM you can see which data was imported from the customizing to the document at the time of document creation. There might be a situation that the credit check deactivation happened only after document creation. More on this you can read HERE. This containes all possible customizing change problem.
If there is i.e. no credit master data for the credit account maintained, you expect that there is no credit check. About this you can read more HERE.
The credit check is deactivated through an own routine in OVA8, field 'No credit check'. But still sales document has a credit status determined. 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 Also if needed read HERE how to debug the credit check.
More on skipping the credit check, please read Skip the credit check.
Document credit blocked but shouldn't be
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Symptom
You created or changed a sales order, but it was credit blocked (CMGST=B).
Is the customizing for credit check setup correctly?
YES
NO
Analysis
If you display the header Credit status (VA02/03: Goto Header -> Status, field CMGST), it is 'Blocked'. According to the credit situation in FD33, the order should not be credit blocked, i.e.:
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.
Credit blocked document with correct customizing
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Situation
Sales document is credit blocked blocked, but based on the credit situation it shouldn't be. Customizing is set up correctly.
Analyis
Check the credit value of the document. This might be so high that with it's value it exceeds the credit limit. How it is calculated, please read Credit value calculation of a document.
If problem can be recreated, you need to debug the credit check. For that please read How to debug the credit check.
Check the SD userexits if you modify the status somewhere else (i.e. MV45AFZZ in sales, SAP Note 415716 - User exits in delivery processing).
Please check if you use an own routine in OVA8, in the field 'No credit check'. 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
Credit blocked document with correct customizing
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Situation
Sales document is credit blocked blocked, but based on the credit situation it shouldn't be. Customizing is set up correctly.
Analyis
Check the credit value of the document. This might be so high that with it's value it exceeds the credit limit. How it is calculated, please read Credit value calculation of a document.
If problem can be recreated, you need to debug the credit check. For that please read How to debug the credit check.
Check the SD userexits if you modify the status somewhere else (i.e. MV45AFZZ in sales, SAP Note 415716 - User exits in delivery processing).
Please check if you use an own routine in OVA8, in the field 'No credit check'. 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
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.
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
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.
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.
Correct customizing settings with open credit value for credit check
Skip to end of metadata
Created by Former Member on Jan 16, 2015
Go to start of metadata
Is the document an actual example?
Did you find a document with wrong credit check in the system from the past?
Current document created just now
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
If problem can be recreated, it needs to be debugged. This can be done with a breakpoint in the relevant function module:
Sales order: SD_ORDER_CREDIT_CHECK Delivery: SD_DELIVERY_CREDIT_CHECK Goods issue: SD_DELIVERY_CREDIT_CHECK
How credit check can be debugged, you can read HERE. With this you can find out why the credit status is either not performed or approved.
Also please check if you use an own routine in OVA8 in the field 'No check'. This can cause possible problems related to the credit status. More 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
No labels
Missing credit value for credit check
Skip to end of metadata
Created by Former Member on Jan 16, 2015
Go to start of metadata
Situation
Sales document is not credit blocked blocked, customizing is set up correctly and document has no open sales credit value
Credit limit is already exceeded, so it doesn't really matter if the document has an open credit value or not, it should be blocked anyhow
Credit limit would be exceeded with current sales document value, so it should be blocked
Credit limit is already exceeded, so it doesn't really matter if the document has an open credit value or not, it should be blocked anyhow
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Situation
Sales document is not credit blocked. Customizing is set up correctly but document has no open sales credit value. In this case open credit value of the document is not relevant as credit limit is already exceeded. Based on this credit situation document should be blocked.
Analysis
In case of Static credit check make sure that the flags in OVA8 for 'Open orders' and 'Open deliveries' are marked. If they are marked off, system does not consider open Sales values from FD33 during credit check, only Receivables + Special liabl. These might not cross the credit limit so document will be approved. More on this please read HERE.
If problem can be recreated, it needs to be debugged. This can be done with a breakpoint in the relevant function module:
Sales order: SD_ORDER_CREDIT_CHECK Delivery: SD_DELIVERY_CREDIT_CHECK Goods issue: SD_DELIVERY_CREDIT_CHECK
How credit check can be debugged, you can read HERE. With this you can find out why the credit status is either not performed or approved.
Also please check if you use an own routine in OVA8 in the field 'No check'. This can cause possible problems related to the credit status. More 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
Exceed with current document
Skip to end of metadata
Created by Former Member on Jan 15, 2015
Go to start of metadata
Analysis
If a sales order does not have any credit value, there is either no confirmed quantity (KBMENG) and/or the credit price (CMPRE) is zero.
Also check with report RVKRED88 if it is correct that the document does not have any open credit value. More on this you can find HERE.
So with zero credit value document can not exceed the credit limit. It needs to be found why it is zero.
Missing credit value due to zero credit price:
How the credit value is calculated please read HERE.
How credit value is determined in the sales order please read HERE.
Missing credit value due to zero confirmed quantity:
Check the availabilty of the item, select the line and 'Check item availability', if it can not be confirmed, this belongs to the component SD-BF-AC.
If the quantity can be confirmed during document processing, but confirmed quantity will be deleted at the time of document saving: check if you use standard requirement for subsequent functions. Transaction VOFM: Requirements - Subsequent functions - Reqs.availability. 101 is the standard one which deletes the confirmed quantity only in case a sales order is credit blocked. More on this you find HERE.
How to debug the credit check
Skip to end of metadata
Created by Former Member on Jan 19, 2015
Go to start of metadata
Problem
You have one or more sales documents, where the credit check result is not what is expected. There is an example available for the same wrong credit check. With that the problem can be recreated so it is possible to debug the credit check to find out why it is not the same as expected.
Analysis
You might find the root cause also by using the GUIDE for credit check.
Also with help of report CHECK_CM you might identify the problem.
Customizing settings for Static credit check
Customizing settings for Dynamic credit check
Solution
Set a breakpoint in the relevant function module:
Sales order: SD_ORDER_CREDIT_CHECK Delivery: SD_DELIVERY_CREDIT_CHECK Goods issue: SD_DELIVERY_CREDIT_CHECK
This will be demonstrated through a sales order.
Enter all transactional data in VA01 or make the necessary change in VA02 and save the order. Ensure that you are at the right call stack to analyse the credit check:
You can press F6 till you achieve the required point where it needs to be checked deeper. This is the logic of the credit check module (focus is only on the most important steps in the coding, if you need it more detailed you can go with F5 in the code and check every single step):
Completed documents are not checked:
Credit master data information is filled from KNKK - PERFORM credit_master_get or if there is no KNKK (FD33) data for the credit account, system reads here the default data from the credit control area. More on this please read HERE.
Customizing settings from OVA8 are imported - table T691F:
In case you change a released sales order, the settings in OVA8 are checked: "Released documents are still unchecked". For this please read note: 718260 - Released documents are not checked: If the change lies inside the predefined deviation, the field no_check will be set to 'X' and none of the credit checks will be executed.
Credit check deactivation with an own routine. This is customized also in OAV8, in the 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
Only after this the individual credit checks are performed. If you have a problem with one of these check, you can set a breakpoint directly here also. Fields no_check (from the deviation checking) and the bypass-flag (from the own routine) is checked. If one of them is filled, the check itself won't be executed. Processing the PERFORM xxxx_credit_check with F6 you can see the credit check result from the CHANGING rkvbuk-cmpsA (for static) or - cmpsB (for dynamic), etc. This will be the individual check status later in the VBUK table:
Status determination from the individual status into the overall credit status (CMGST) happens at the end of the coding:
If you have a problem with an individual credit check, you need to go inside the code with F5 to the PERFORM xxxxx_credit_check part and see how the values are calculated. For the static and dynamic credit check an open credit value of the document is calculated. In case of problem with that: How the credit value is calculated you can read HERE. How you can debug the calculation you can read HERE.
Logging the credit situation at the time of the credit check
Skip to end of metadata
Created by Former Member on Jan 15, 2015
Go to start of metadata
Problem
Credit limit check is activated (static or dynamic). Since the credit situation at the time of the credit check (sales document saving) is no longer known at a later time, it may be difficult to explain the outcome of the credit check result. Due to the credit situation, you did not expect certain documents to be blocked - or not blocked. If the cases are sporadic and cannot be recreated, it is not possible to determine why the result turned out the way it did.
Solution
The attachment of the SAP Note '2055633 - Logging results of credit check' provides an example of a logging tool that logs the most important data during the static check for each document. This tool can also be adjusted easily for other credit checks, such as the dynamic credit check. Among other things, for example, the current credit limit used, the credit limit, and the checked credit value are logged. These logs can then be evaluated using the report Z_READ_CREDIT_LOG.
In this log, the credit situation at the time of the credit check should be clear, and information about the result of the check is available.
Released Sales documents are Rechecked
Skip to end of metadata
Created by Gerard Magorrian on Aug 08, 2012
Go to start of metadata
Purpose
In this document we discuss the two most common causes for the re-blocking of released sales orders.
Overview
In certain cases sales documents that have already been 'Released' by a credit representative can become re-blocked by the credit mamangement system. Here we discuss the possible reason and the steps that can be taken to overcome this unwanted behaviour.
Maintenance of Automatic Credit Contol
The most frequent cause for the re-blocking is due to incorrect customizing settings. The field ‘Number of days’ of the release configuration options in SPRO, transaction OVA8, is used to determine the number of days allowed before a released document must be rechecked.
A recheck will not occur if the number of days, together with the date of last release is not greater than the current system date. Additionally, if the current value of the document is less than or equal to the approved/released value, a credit recheck will not be executed.
Open OVA8:
Check the entry in - ‘Released documents go unchecked.’ If the number of day’s field is blank, then any change to a released document on any day other than the date it was released will cause a re-check. For more information on this see note -718260 ‘Released documents are not checked’.
Availabilty Check
Another frequent trigger for the re-blocking of sales orders is the availability check.
Whether or not the schedule lines are fully confirmed at the time of release can cause problems regarding the release value of the document (VBAK-AMTBL). The release value will be used to determine whether a higher quantity is to be delivered than was originally released. Note that the release value will be less than the document value if the schedule lines are not fully confirmed at the time of release.
The credit value of a sales order is calculated based on the confirmed schedule line quantity multiplied by the per item condition value as set in the pricing procedure - transaction code V/08 (shown in the screenshot below).
For analysis:
Go to transaction SE17 for table VBAK (the header sales view).
Enter in the sales order number; 10 digits with leading zeros, then find the fields called ‘Net value’ and ‘Credit value’ and put an ‘x’ in the small box on the right on the line with these fields.
Execute.
If the credit value field (VBAK-AMTBL) on the released document is zero or less than the net value (keep in mind that delivered items will be in the net value but not in the released value by design), then another credit check can be expected.
The solution to this scenario can be found in note 100861 with userexit RMCS1US1. The userexit utilises the requested quantity to calculate the credit value instead of the confirmed schedule line quantity.
Related Content
Related Documents
Related Notes
718260 - Released documents are not checked
100861 - Release of blocked sales orders - loop 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.
Credit Management in Delivery
693 Views
Follow
RSS Feed
Hi People,
Is there any solution to avoid multiple credit checks at delivery level:
Process: Delivery creation = Next release the delivery to create the picking transfer order thru VKM1 (1) = Create and confirm transfer order= Again release the delivery thru VKM1= Next do the packing.
Now step 2 be avoided... whenever the picking process is completed system is again setting the credit block VBUK-CMGST= changes from A to B.
There is no setting in configuration as such I am not sure ... how while only doing the picking activity the delivery is getting blocked.
I have searched the forum there is no perfect answer to this question, where the actual control likes and how to solve this....Please answer if you have faced the same issue.
Add a Comment
Alert Moderator
Assigned Tags
SD (Sales and Distribution)
SAP ERP
Similar Questions
Credit Control at Delivery Level
Rajkumar ReddyApr 16, 2008
Sales Documents.
Former MemberAug 30, 2007
3 Answers
Sort by:
Votes
Newest
Oldest
Best Answer
Vote up1Vote down
Former Member
May 22, 2012 at 04:01 AM
Hi,
As you aware this is not possible in the standard.I too came across this kind of situation and here i am attaching the logic,might be useful for your requirement..
Logic:
Partial delivery : if sy-tcode = 'VL01N'.
data : l_KLIMG type KLIMG,
l_skfor type skfor,
l_vbeln type VBELN_VL.
select single KLIMG from knka into l_KLIMG where kunnr = vbak-kunnr.
if sy-subrc = 0.
select single skfor from knkk into l_skfor where kunnr = vbak-kunnr.
if l_skfor > l_klimg.
if cvbuk-LFSTK = 'B' or cvbuk-LFSTK = 'A' .
loop at xvbuk where vbeln = cvbak-vbeln.
xvbuk-cmgst = 'B'.
modify xvbuk.
endloop.
endif.
endif.
endif.
endif.
STATUS CHANGE:
Enhancment spot.
Include : FV50XF0B_LIEFERUNG_SET_GET_SET
ENHANCEMENT 212 ZCREDIT_CHECK.
*
if sy-tcode = 'VL01N'.
data : l_KLIMG type KLIMG,
l_vbeln type VBELN_VL,
lv_per type VBKRED-KLPRZ.
select single KLIMG from knka into l_KLIMG where kunnr = vbak-kunnr.
if sy-subrc = 0.
CALL FUNCTION 'CREDIT_EXPOSURE'
EXPORTING
KKBER
= vbak-KKBER
KUNNR
= vbak-kunnr
* DATE_CREDIT_EXPOSURE
= '99991231'
IMPORTING
* CREDITLIMIT
=
* DELTA_TO_LIMIT
=
* E_KNKK
=
KNKLI
=
OPEN_DELIVERY
=
OPEN_INVOICE
=
OPEN_ITEMS
=
OPEN_ORDER
=
OPEN_SPECIALS
=
PERCENTAGE
= lv_per
* SUM_OPENS
=
* OPEN_ORDER_SECURE
=
* OPEN_DELIVERY_SECURE
=
* OPEN_INVOICE_SECURE
=
* CMWAE
=
.
if lv_per ge 100.
if cvbuk-LFSTK = 'B' or cvbuk-LFSTK = 'A' .
loop at xvbuk where vbeln = cvbak-vbeln.
xvbuk-cmgst = 'B'.
modify xvbuk.
endloop.
endif.
endif.
endif.
endif.
ENDENHANCEMENT.
*
*
*
*
*
*
Hope this logic suits your requirement.
DVNR.
Add a Comment
Alert Moderator
Share
| Table S066: | Open sales order value |
|---|---|
| OEIKW | Open sales order credit value (schedule lines) |
| Table S067: | Open delivery and invoice values |
| OLIKW | Open delivery credit value |
| OFAKW | Open billing credit value |
| Update group | Update group | Remark |
|---|---|---|
| No update from SD documents | ||
| 000012 | Open order value on time axis, delivery and billing doc value | Update of S066 and S067 |
| 000015 | Open delivery and billing document value | Only S067 will be updated |
| 000018 | Open delivery value for sales order, open billing doc value | Only S067 will be updated |
| LMCS1F10 - Sales Order | LMCS1F10 - Sales Order | LMCS1F10 - Sales Order |
|---|---|---|
| form offene_werte_eint | OEIKW | FORM cmpre_calculate (SAPLVKMP) |
| from offene_werte_erm | OLIKW | FORM cmpre_calculate (SAPLVKMP) |
| from offene_werte_erm | OLIKWAU | FORM cmpre_calculate (SAPLVKMP) if open delivery value in sales order is used (update group 000018) |
| This coding might be passed 4 times for each schedule line: old credit value (with SUPKZ = ' ' or '1') new credit value (with SUPKZ = '2' or '3') old for MC30 (with SUPKZ = ' ' or '1') new for MC30 (with SUPKZ = '2' or '3') | This coding might be passed 4 times for each schedule line: old credit value (with SUPKZ = ' ' or '1') new credit value (with SUPKZ = '2' or '3') old for MC30 (with SUPKZ = ' ' or '1') new for MC30 (with SUPKZ = '2' or '3') | This coding might be passed 4 times for each schedule line: old credit value (with SUPKZ = ' ' or '1') new credit value (with SUPKZ = '2' or '3') old for MC30 (with SUPKZ = ' ' or '1') new for MC30 (with SUPKZ = '2' or '3') |
| LMCS5F10 - Delivery | LMCS5F10 - Delivery | LMCS5F10 - Delivery |
| form offene_werte_eint | OEIKW | FORM cmpre_calculate (SAPLVKMP) |
| form offene_werte_lips | OLIKW | FORM cmpre_calculate (SAPLVKMP) |
| form offene_werte_lips | OLIKWAU | FORM cmpre_calculate (SAPLVKMP) |
| form offene_werte_erm | ||
| erlmenge_l (sum of delivered quantity) erlmenge_f (sum of invoiced quantity - substract from sales order value if fkrel=order related and substract from delivery value if fkrel=delivery related) faklmeng (invoiced delivery quantity) | erlmenge_l (sum of delivered quantity) erlmenge_f (sum of invoiced quantity - substract from sales order value if fkrel=order related and substract from delivery value if fkrel=delivery related) faklmeng (invoiced delivery quantity) | erlmenge_l (sum of delivered quantity) erlmenge_f (sum of invoiced quantity - substract from sales order value if fkrel=order related and substract from delivery value if fkrel=delivery related) faklmeng (invoiced delivery quantity) |
| LMCS6F10 - Invoice | LMCS6F10 - Invoice | LMCS6F10 - Invoice |
| form offene_werte_vbrp | open del. value | FORM cmpre_calculate (SAPLVKMP) ... changing owv_mcvbrp-olikw |
| form offene_werte_vbrp | open invoice value | FORM cmpre_calculate (SAPLVKMP) ... changing owv_mcvbrp-ofakw |
| form offene_werte_vbrp | open item (FI) | FORM cmpre_calculate (SAPLVKMP) ... changing xmcvbrp (xmcvbrp-cmpre) |