I would like to keep the Credit Status Block on a Sales Order when it is created and over the credit limit and at the same time be able to Confirm the Order Quantity (if inventory is available) on the Schedule Line.
In the IMG --> Sales and Distribution --> Basis Functions --> Credit Management/Risk Management --> Credit Management --> Define Automatic Credit Control --> If I remove the Status/Block indicator the schedule line does confirm the sales order quantity but the sales order is not blocked and a delivery can be created.
Answer:
Please go to IMG -> Sales and Distribution -> Basis Functions -> Transfer of requirements -> Maintain requirements for Transfer of Requirements and remove the 101 Routine number so that when credit block on order, still the quantity is confirmed to sales order. Because of this Routine it is removing the reservation while in credit block.
I have tested it and it is working. I have similar scenario and it is working fine.
Other Suggestion 1:
There are two ways to block the sales order - one is to not confirm the Schedule line i.e. block delivery... block further action that can be taken. The second is to not let the person save the sales order.
Another option is to get Just a warning message, that the credit limit has been exceeded, but able to save the sales order with a confirmed schedule line.
The setting will be in OVA8.
For the Document Value you make the setting C or A. and make sure the block is not set.
Don't worry about the Open order or open delivery unless you want the system to perform a credit check considering the orders that are already existent. Same with open delivery. It will take into account all the cost of the orders that are open for delivery.
Now here some options:
Either consider a 'warning' by the system good enough and still be able to confirm the schedule line.
(ii) Put in a Delivery Block in the Sales Document Types, in the Shipping tab. That way, you will be able to save the sales doc. but not be able to deliver it.
(iii) Put a Billing Block in the Sales Doc type, in the Billing tab. You will be able to deliver but not bill.
(iv) Create a new routine (with the help of an ABAP guy) and place it in the auto credit check, 'Reaction' field where it will place a Delivery Block.
Other Suggestion 2:
Another option is that you go to SPRO -> Sales and Distribution -> Basic Functions -> Availability check and Transfer of Requirements -> Transfer of Requirements -> Block Quantity Confirmation in Delivery Blocks
Select Deliveries: Blocking reasons/Criteria
Now here you can either create a new entry or go with 01- Credit limits.
There will be Conf. with a check mark on it. Remove that. And to make sure that the sales order is not printed, check mark where it says 'Print' and 'DDueList' (so system won’t create delivery automatic).
This way, the sales order will be saved with a confirmed schedule line, but picking or automatic delivery creating won’t happen. It will need to be manually processes further on.
Notes:
Please also see OSS Note 886038 - No confirmed quantity after sales order credit release
Credit value update problem
Skip to end of banner
Go to start of banner
Possible causes of inconsistencies
Skip to end of metadata
Created by Former Member on Jan 26, 2015
Go to start of metadata
Symptom
You determined that there are inconsistent credit values in the system. How this can be done you can read HERE.
You would like to know why this happens.
Analysis
To avoid that problem is caused by a program error please check the support package level of your system (Menu: System -> Status: SAP System Data, Product version, open the Components with the loop and search for SAP_APPL). With that please search for program errors in the component SD-BF-CM and implement these notes.
Check which update type is used for the info structure S066. For that goto transaction OMO1: 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 The update modes V1 (synchronous) and V2 (asynchronous) work as follow: V1: If there are problems that result in the termination of statistics, the original documents are NOT saved. V2: With this update type, the document update is made separately from the statistics update. A termination of the statistics update has NO influence on the document update. That means, with the V2 update it is possible, that update of statistics values (e.g. credit values) terminates, but the document is updated. So the credit values are not updated in such a case. When using the V1 update, this can not happen. In V1 update, when statistics update terminates, the document is not saved. That's the reason why it is very important to choose the V1 update for credit values.
In most of the cases the wrong updates are caused by customer modification of the field UPDKZ in userexits. Please read SAP Notes 178328 and 208010 and review your userexits (especially MV45AFZZ and for LE please see note 415716 - User exits in delivery processing). There is an analysis tool also available with regard to userexit modification effects on credit values, please see these notes 1612842 and 1606681 and ensure all related notes are implemented too. Further on this please read here: UPDKZ modification
It can be caused by incorrect customizing. especially with batch subitems. For that please read these notes: 77414 - Billing during batch split 860621 - Negative open delivery value with batch after billing doc 1714643 - RVKRED77: Incorrect values for batch and FKREL = "H"
There are some special cases when RVKRED77 does not correct the values or it calculates an incorrect open credit value. Please read HERE more about that.
Confirmed quantity is present in the order, but there is no updated credit value
Skip to end of metadata
Created by Former Member on Nov 24, 2014
Go to start of metadata
Symptom
Sales order is credit blocked, VBUK-CMGST = B;
Standard requirement 101 is used for the follow-on function 'Reqs/availability';
Even though the confirmed quantity is not deleted;
As a result, you expect the system to update an open credit value (S066-OEIKW) based on the confirmed delivery that is still to be delivered.
Analysis
The condition 101 for the follow-on function requirement/availability is not valid for items that are not relevant for requirements and therefore are not MRP-relevant. How you can determine this, you can read HERE. In case of a non-MRP material, the system does not remove the confirmed quantity if there is a credit block (VBUK-CMGST = 'B').
Please check if the Transfer of requirement is deactivated (-BEDSD = ' ') for the relevant items either in schedule line category (TVEP) or in the requirements class (T459K). How you can check this, please read HERE.
If the transfer of requirement is deactivated for the non-MRP materials, even though there is a confirmed quantity in case of a credit block, no credit value update occurs. During the update of open credit values, these items behave in the same way as an item that is relevant for requirements and ATP-relevant.
For these items the credit value is updated once the sales document is released.
Please read SAP Note: 914627 - No open credit value despite confirmed quantity
Credit value calculation of a document
Skip to end of metadata
Created by Former Member on Jan 15, 2015
Go to start of metadata
You would like to know how is the credit value of a document calculated.
For the necessary customizing settings please read note 18613. Also you can use report CHECK_CM to check sales documents with regard to their credit management information in one step. You can read more about this HERE.
For the credit price calculation following needs to be determined in the sales order:
Credit price - CMPRE: Transaction V/08 - In the pricing procedure used for pricing, subtotal "A" must be entered in a line for determining the credit value. Usually, the net value plus taxes is used. This way the system is determined to use this subtotal for credit pricing. The credit price is stored in field VBAP-CMPRE and used for update and credit check. You can find the used pricing procedure of the order under "Item -> Condition -> Analysis". Than go to V/08, Pricing procedure, select the corresponding one, mark the pricing procedure and doubleclick on "Control". Search for the line with subtotal = 'A'
Confirmed quantity - KBMENG: If an item has no confirmed quantity (VBEP-BMENG), the system does not calculate nor update an open sales order value. This also occurs for documents that are blocked by the credit check. As a result of the credit block, the confirmed quantities are deleted so that an open sales order value can no longer be updated. You can use requirements to delete confirmed quantities in credit blocked sales orders. These requirements are defined in transaction VOFM under the menu path 'Requirements -> Subsequent functions -> Reqs.availability'. The system asks you for a credit status in the respective user requirement. If this is set to 'Blocked', the system cancels the confirmed quantity. In the standard the requirement 101 is used for this purpose. You may want the system to behave differently. If this is the case, you can store a separate requirement which does not cancel the confirmed quantity. As a result, the sales order item has a confirmed quantity again and consequently, it updates the open sales order value although the document is credit blocked.
When the credit value is calculated (in the background at the time of document saving or when entering the positions if the flag 'Item check' is marked in OVA8), the open schedule line quantity (VBEPD-OLFMNG) is multiplied with the item credit price (VBAP-CMPRE). The open schedule line quantity is the confirmed quantity of the schedule line that is still open for delivery. VBEPD-OLFMNG is calculated dynamically during sales order processing, this can not be seen on database level.
You can calculate the open credit values of a document in following ways:
If the sales order has the status 'Open' - means there is no subsequent document - the open schedule line quantity is the same as the confirmed quantity: VBEPD-OLFMNG = VBEP-BMENG = VBAP-KBMENG, this you can multiply with the credit price (CMPRE) of the position.
If the sales order has subsequent delivery, you need to calculate the open schedule line quantity 'manually': - take the confirmed quantities either from the schedule lines, or from the report CHECK_CM; - check the Document flow - Status Overview: here you can see how many is delivered; - Subtract the delivered quantity from the confirmed quantity and this you can multiply with the credit price (CMPRE) of the position.
You can use report RVKRED88, this simulates the correct open credit values of the documents and displays them by document number: If a sales order and it's subsequent documents are closed, it does not have an open credit value anymore. Please note:
Credit blocked documents do not have open credit values! But there are exceptions, please read notes: 393304, 674112, 914627.
More on this you can read also in note 377165.
Credit value update 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 update the credit values based on the requested quantity (or any other quantity) and not on confirmed quantity.
Solution
This is not possible in the standard system. Credit value calculation is a complex process which is used in many transactions, programs, reports hence it can not be influenced only by a userexit. How it is calculated you can read HERE.
The only possibility to influence this logic is at the time of a sales order release. With that:
the released credit value is calculated according the ordered quantity and stored in VBAK-AMTBL (RMCS1US1) and
sales order updates open credit values during releasing according to the ordered quantity (RMCS1US3).
Both exit should be activated together. Further on this you can read in these SAP Notes:
SAP Note: 100861 - Release of blocked sales orders - loop check
SAP Note: 149559 - Update of requested delivery quantity, credit
Determination of inconsistent credit values
Skip to end of metadata
Created by Former Member on Jan 13, 2015
Go to start of metadata
Symptom
You assume that the open credit values are incorrect. You would like to determine if they are really inconsistent. You also would like to determine the inconsistency for a wider range, i.e. if it happens for more credit accounts in a credit control area. (Please read below: Determination for groups of credit accounts or for a whole credit control area)
Analysis
Manual determination for individual credit accounts:
Goto FD33 and enter the credit account and credit control area, select 'Status' tab under Credit control area data: You will see this:
In Menu goto Extras -> Sales value: This are the open credit values which were updated in the credit info structures at the time of sales documents saving. How credit update works you can read HERE. These values are determined here in this transaction dynamically from the info structures S066 and S067. More on this you can read HERE. So you can check the existing values in SE16 also:
These values needs to be compared with the result of report RVKRED88. Goto SE38, enter RVKRED88, execute: Enter selection criteria and execute: You get a list with document numbers and the related open credit values:
If RVKRED88 does not delivery anything, the output is empty, means there is no open credit value for the selected credit account in the selected credit control area:
If the values match with FD33/S066-S067, the open credit values are consistent.
If the values don't match, the open credit values are inconsistent.
This is the right method to determine inconsistencies related to credit management values. Values in transactions like VA05, VKM4, etc. does not deliver the correct result as they do not work with the open credit value calculation. Open credit value calculation is a complex process, further on that you can read HERE.
Determination for groups of credit accounts or for a whole credit control area:
If you need to check the credit values for more credit accounts, or for a credit control area, you can use report Z_CREDIT_VALUE_COMPARE. (Report Z_CREDIT_VALUE_COMPARE is not a standard report and is not maintained by SAP Support. The implementation is your own responsibility.)
The report simulates in the first step the recreation of open credit values (in accordance with report RVKRED88) and afterwards compares the results with the values that are currently in the database (S066 and S067 - same as displayed in FD32/33 under Sales value). The result returns a list with credit customers for whom there are incorrect open credit values. The incorrect values are highlighted in the list.
With this report the above manual steps are executed automatically in the background.
BUT! If this report runs for a longer period (i.e. for hours) and in the meantime sales documents are posted in SD, the comparison won't show correct results at the end either. You need to run Z_CREDIT_VALUE_COMPARE in a period without any SD activities, updates or you need to build smaller groups of credit accounts and execute in a period when no update occurs for these customers.
Related notes:
SAP KBA 1756125 - Wrong credit values - identify and correct
SAP KBA 1850357 - Z_CREDIT_VALUE_COMPARE - incorrect results
SAP Note 501240 - RVKRED88 does not generate output for some customers
SAP Note 400311 - RVKRED77: Reorganization credit data, new documentation
SAP Note 666587 - Check for incorrect open credit values
Credit value update problem
Skip to end of banner
Go to start of banner
Example needed to recreate the wrong update and identify the root cause
Skip to end of metadata
Created by Former Member on Jan 12, 2015
Go to start of metadata
Symptom
Incorrect open credit values exist. For example, you have an open sales order value for a credit customer even though no open sales orders currently exist for this customer. How to determine the inconsistency exactly you can read HERE.
You do not know how to determine the reason so that you can solve the problem.
Analysis
It is difficult to analyze incorrect open credit values:
The open credit values are updated in Sales Information System (SIS) structures. The structures cumulate values due to common characteristics. Due to the cumulation, you cannot find out subsequently which documents caused the values. More on this please read: I would like to know which documents updated the values in S066/S067
The system generates and reduces open credit values in the SD document chain. The system posts the credit value to the SIS structure and clears it later. This may cause differences between the posted value and the cleared value.
To determine the reason for the incorrect open credit values and to recreate the error, proceed as follows:
Please read HERE how credit value is calculated.
Please read HERE how credit update works.
Please read HERE how wrong values can be corrected.
Please read HERE how credit value update can be tracked/logged.
Please read HERE for possible reasons for inconsistencies.
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 value update happens at the time of document saving. During saving it is possible to debug the credit value calculation and the update process. Once document is saved, the info structures are already updated and it is not possible anymore to find out why a wrong value was calculated or updated. After this it is only possible to determine the inconsistency, but not possible to find the reason of it. To find an example here are some hints: Monitor the open credit values to find out when incorrect values occur. To do this, compare the sales values in transaction FD32/FD33 with the results of the report RVKRED88 again. More on this you can read HERE. Identify the documents that were created or changed since the last run of the correction report RVKRED77 in accordance with Note 389377. One of these documents must have caused the incorrect credit values. Try to determine which document caused these values. To recreate the problem on your system, use the same data as in the document that caused the incorrect values. Use the credit value logging possibilities: transaction MC30 and report SD_VKMLOG_SHOW. More on this you can read HERE.
If you could identify the scenario for wrong updates, please read HERE how you can debug the credit value calculation.
For further information on this topic please also use the GUIDE for inconsistencies.
Also please read KBA 2100078 - How to provide a reproducible example?
Correction report for wrong credit values - RVKRED77
Skip to end of metadata
Created by Former Member on Jan 06, 2015
Go to start of metadata
Symptom
There are inconsistent credit values in the system, you determined this by using the right method. You would like to know how to correct these wrong entries.
Solution
RVKRED77 is a correction report of the credit management for the updated open sales values (the open credit values in SD), that is, for the information structures S066 and S067 with the open order values (S066-OEIKW), the open delivery values (S067-OLIKW) and the open billing document values (S067-OFAKW).
You need to use the report if:
errors occurred in the updating of these sales values (ideally if the cause of the errors has been eliminated so that you can continue afterwards with correct values without errors);
if the update group (T014-STAFO, Transaction OB45) was changed in a credit control area (more on this you can read HERE);
in larger intervals to remove zero entries from table S066: The open order values (S066-OEIKW) are stored in time periods (monthly, weekly or daily, Transaction OMO1) in table S066. At some stage, the entries in the older periods become zero and are then also read each time you read the open order values (for example during the check of the credit limit used). To improve the performance, delete these entries in larger intervals by using RVKRED77;
in larger intervals to remove minimum elementary amounts (for example 1 cent) which, due to rounding problems, remained despite the completion of the respective processes. For more details refer to Note 406608.
For the following reasons the report is no suited for frequent use:
To ensure an error-free run of RVKRED77, it is necessary to completely block tables VBAK, LIKP and VBRK. As a result, the run of the report is not possible during the current operation.
Depending on the selection, a program run of RVKRED77 can last a few hours, in extreme cases you may even experience a runtime of a few days.
Help with runtime problems:
Note 363343 provides detailed instructions for the parallel processing of RVKRED77 and Note 755395 for background execution:. SAP Note: 363343 - Parallel processing of RVKRED77 if the runtime is too long SAP Note: 755395 - Parallel processing RVKRED77 for background processing
If you identified more credit accounts with incorrect credit values (i.e. with report Z_CREDIT_VALUE_COMPARE, read HERE how) you can build groups of credit accounts which you can run by parallel processing. With that you can reduce the time frame needed for reconstruction.
Additional information:
RVKRED88 simulates report RVKRED77. However, it does not block tables VBAK, LIKP or VBRK as does RVKRED77 as a result, differences may occur in the result if relevant documents are changed during the run or if new documents are created. It is very well suited to estimate the runtime of RVKRED77, and thus to determine suitable selections.
This is included in SAP Note: 400311 - RVKRED77: Reorganization credit data, new documentation
Further information
How is the credit value of a document calculated?
How does the credit update work?
RVKRED77 is locking the tables, no SD activity is possible
Business runs 24*7, it is not possible to block the tables, how can we correct the values
More information related to RVKRED77 and RVKRED88
How does the credit update work
Skip to end of metadata
Created by Former Member on Jan 10, 2015
Go to start of metadata
Symptom
You would like to know how credit update works.
Analysis
For the necessary customizing settings please read note 18613. Also you can use report CHECK_CM to check sales documents with regard to their credit management information in one step. You can read more about this HERE.
How the credit value is calculated, you can read HERE.
The open credit values are updated in the info structures S066 and S067 when you save the document. These are:
Open sales order credit value (S066-OEIKW)
Open delivery credit value (S067-OLIKW)
Open billing document credit value (S067-OFAKW)
With the update group (maintained in transaction OB45 for the relevant credit control area) you control at which point of time in the process flow the credit value should be updated.
There are 3 possible entries for that: 12, 15 and 18.
The default setting is '12' - Update with update group 12:
Update for sales orders:
The open sales order values are updated in the information structure S066. When the credit value is calculated, the open schedule line quantity (VBEPD-OLFMNG) is multiplied with the item credit price (VBAP-CMPRE). The open schedule line quantity is the confirmed quantity of the schedule line that is still open for delivery. The credit price is defined in accordance with the settings in the pricing for the item. The material availability date of the schedule line (VBEP-MBDAT) defines the period in which the open sales order value is updated. You use transaction OMO1 to define the period unit for the information structures. If an item has no confirmed quantity (VBEP-BMENG), the system does not update an open sales order value. This also occurs for documents that are blocked by the credit check. As a result of the credit block, the confirmed quantities are deleted so that an open sales order value can no longer be updated. When sales orders with a credit block are released (for example, using transaction VKM1), a new availability check is performed. If the availability check can confirm the quantities, an open sales order value is updated accordingly. Conclusion: Credit blocked documents do not increase the open credit values. There are exceptions to these rules: 1. Sales order items which are not relevant for delivery and do not have schedule lines relevant for delivery are not updated to S066 ('Open sales order credit value') rather to S067 ('Open delivery credit value'). You can find further information about this in Note 361637. 2. You can use requirements to delete confirmed quantities in credit blocked sales orders. These requirements are defined in transaction VOFM under the menu path 'Requirements -> Subsequent functions -> ...'. The system asks you for a credit status in the respective user requirement. If this is set to 'Blocked', the system cancels the confirmed quantity. You may want the system to behave differently. If this is the case, you can store a separate requirement which does not cancel the confirmed quantity. As a result, the sales order item has a confirmed quantity again and consequently, it updates the open sales order value although the document is credit blocked. For NON-MRP materials (materials without requirements planning), the system does not cancel the confirmed quantity despite a corresponding condition, as described in Note 393304. For further information about this, refer to Notes 674112 and 914627. 3. A delivery block in the sales order affects the update of open credit values. For more information, see Note 741980.
Update for deliveries:
The open delivery values are updated in S067. The update does not occur in time units. There is only one entry in S067 for each credit control area and credit customer. If you create a delivery with reference to a sales order, the system clears the open sales order value in accordance with the delivery quantity (from S066) and posts the open delivery value for the delivery (to S067). Deliveries with credit lock also write open values of goods to be delivered. Here, it is not possible that a credit-blocked document does not create an open credit value (as in the order). This is also correct from a business view, because the delivery already blocks the goods, and the value of the goods is therefore already consumed for the credit customer.
Update for billing documents:
The open billing document values are also updated in S067. Also in this case, only one entry exists for each credit control area and credit customer. If you create the billing document with reference to a preceding document, the system clears the open credit value in accordance with the invoiced quantity for the preceding document and posts the open billing document value for the billing document (to S067). If you transfer the billing document to accounting, the system clears the open billing document value (from S067). Now the value has been transferred to the open items and occurs as a receivable from the viewpoint of credit management. If the incoming payment occurs, the receivable is met and the consumption of the credit limit is reduced.
Update with update group 15:
Order: No posting is done to open order values. The order is placed after the delivery is created. Delivery: increases open delivery value (S067-OLIKW) Invoice: reduces open delivery value (S067-OLIKW) and increases open invoice value (S067-OFAKW) Accounting Document: reduces open invoice value (S067-OFAKW) and increases open items
This type of update group is used for orders without schedule lines – service items or orders with schedule lines that are not relevant for delivery.
Update with update group 18:
No posting to open order values, only open delivery values (table S067) are updated Sales order: increases open delivery value Invoice: reduces open delivery value and increases open invoice value Accounting Document: reduces open invoice value and increases open items (accounts receivable)
This update group will be always used by order items that are not relevant for delivery (for example, service items or value items) or for items that are billed as order-related (for example, for billing plans). In the following cases update group 18 is always set dynamically as opposed to the update group of the credit control area. This ensures that, in the case of these exceptions, the update occurs in the open delivery values (S067) and not in the open order values (S066). The update group is determined in the program LMCSBF10 in the form KREDIT_AKTIV:
1. Debit memo request: In the debit memo check, the items are not relevant for delivery and are billed as order-related. The customer has already received the goods to be billed - therefore, they have already been delivered. The order value is updated in the open delivery values.
2. Third-party order processing: You do not make a delivery to a third-party item yourself (item type TAS in the standard SAP system). The delivery is made by a third party. Therefore, you have no further influence on the delivery. The order value is also updated in the open delivery values.
3. Order items with billing plan: Billing according to the billing plan is order-related billing. The order values are also updated in the open delivery values.
4. Further examples are value items and service items for which there is no supply and which are also billed as order-related.
You can find further information about this in Note 361637.
If you change the update group in OB45, you need to rebuild the credit values. For that please read HERE.
Further information:
I would like to track the credit value updates GUIDE for inconsistencies
How to debug credit value calculation
Skip to end of metadata
Created by Former Member on Jul 23, 2015
Go to start of metadata
Problem
You determined that there are inconsistent credit values in the system. How this can be done you can read HERE. There is an example available for the same wrong update. With that the problem can be recreated so it is possible to debug the credit value calculation to find out why it is not the same as expected.
Analysis
Please read HERE how credit value is calculated.
Please read HERE how credit update works.
Please read HERE how wrong values can be corrected.
Please read HERE how credit value update can be tracked/logged.
Please read HERE for possible reasons for inconsistencies.
Solution
Technical background:
Update groups:
The update group is maintained for the Credit Control Area (transaction OB45).
The Update group can be dynamic changed by the system - more on this HERE. This is done in program LMCSBF10.
Relevant Coding SD:
The credit value calculation is done in the Form CMPRE_CALCULATE (SAPLVKMP).
Set a breakpoint in the Form inside so it stops every time when the calculation is called. This you can do either via SAPLVKMP or SAPDBKMV:
Goto SE38: enter SAPLVKMP or SAPDBKMV
Display the Source Code
Search for cmpre_calculate:
Click on the blue line (doesn't matter which one), it will jump to the form. Here in SAPDBKMV the form is called with a perform, double click on the form cmpre_calculate, and inside the form set a breakpoint:
Go ahead and create the sales order with the example data. Enter sold-to party, material and quantity. Ensure that credit price and confirmed quantity is present in the items so there will be a credit value calculation for sure (HINT: if possible, ensure that only one schedule line exists in the item to understand the debugging better for the first times).
Credit value calculation happens:
either when you save the document or
when you enter a position, in case the flag 'Item check' is marked in OVA8 for the relevant combination:
When you save a document the calculation is called several times. The main function module:
sales order: MCV_STATISTICS_ORDER
delivery: MCV_STATISTICS_DELIVERY
invoice: MCV_STATISTICS_INVOICE
The process is explained through a sales order creation. MCV_STATISTICS_ORDER will call the credit value calculation in following cases:
first there will be an update simulation for the activated credit check (static or dynamic): SD_ORDER_CREDIT_CHECK -> ... -> MCV_STATISTICS_ORDER -> MCV_STATISTICS_DIALOG_ORDER As the breakpoint is set inside the CMPRE_CALCULATE form, it will stop in this call at least 3 times (for every schedule line in every position), at every possible credit value calculation (OLIKW, OLIKWAU and OEIKW). In this case normal procedure is used (update group 12 with delivery related invoicing) so the open sales order credit value will be calculated and updated into S066-OEIKW. So make sure you are at the right credit value calculation by pressing F7 and checking which calculation is called exactly. For the OEIKW this is done in from OFFENE_WERTE_EINT: If this position has 2 schedule lines, it will stop for both lines: If open delivery value is used in the sales order (update group 18), the field OLIKWAU will be calculated. Please read HERE more about this. In this case CMPRE_CALCULATE is called from the form OFFENE_WERTE_ERM:
The same will be called again if the statistic update logging is activated beforehand for the MC30 transaction. How this can be done, please read HERE. In this case the above is called again from STATISTIK_UPDATE -> MCV_STATISTICS_ORDER -> MCV_STATISTICS_LOG_ORDER: If logging for MC30 is not active, this step is not executed.
As least for the statistic update the calculation is called again: STATISTIK_UPDATE -> MCV_STATISTICS_ORDER -> MCV_STATISTICS_DIALOG_ORDER: The values calculated in this step will be updated into S066 and S067. If there is no modification in the system with userexits or enhancements which influences the values, the values from the above 3 call stacks should be the same.
Based on the above make sure you are at the right call at the correct CMPRE_CALCULATE form to investigate further. When you stop at the breakpoint inside the form -> press F7 to come out -> scroll up to see at which credit value field calculation you are. When you are at the right one, in this example at OEIKW calculation, check the fields, with that the perform CMPRE_CALCULATE was called:
CMPRE: is the credit price handed over from the pricing result into VBAP. This should have a value.
OLFMNG: is the open schedule line quantity, the confirmed quantity of the schedule line that is still open for delivery. OLFMNG is calculated dynamically during sales order processing. If it is zero, it needs to be invetsigated further why. In this example the position has 2 schedule lines and the confirmed quantity is present in the second schedule line:
The SD tables in the statistic calculations starts with XMC*, if you need to check something there.
The LOOP for the XMCVBEP on the schedule lines you can find one step outside in the call stack hierarchy, in the form MCINF_UPDATE_ALL:
Also here a bit more above in the coding you can find the loop at XMCVBAP if you have more positions, you can set a breakpoint here also:
If a field contains a different value as expected, you can set breakpoints in the call stack and with a watchpoint on the field find the place where the value for the affected field is determined.
Also please pay attention to the field SUPKZ. This decides if a value is booked into the statistics or booked out from the statistics. SUPKZ has a strong relationship with the UPDKZ field in the X-tables. In most of the cases inconsistent credit values are updated due to a modification of the field UPDKZ. More on this you read HERE.
If you change i.e. a sales order, in the above example there will be 4 lines in the XMCVBAP table, two lines with SUPKZ = 1 and two lines with SUPKZ = 2:
If you change a sales document, statistic update is always done. Depending on which fields were changed, the updated values might be changed. If a non credit management relevant field is changed, the values which are booked out are the same as the booked in, so basically the open credit value did not change, just technically there is a book in and a book out. This you can see also with MC30:
If you create a delivery or invoice, you proceed the same way as above and ensure that you check the right values at the right place.
How to start analyzing credit value update 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 value update problem you face with a sales document.
Is customizing for the update setup correctly?
YES
NO
Analysis
To check if it is done correctly, you have 2 options:
please use SAP Note 18613 - Checklist for Credit Management;
you can use report CHECK_CM to see sales documents with regard to their credit update information in one step. Please read HERE under 'Settings for Credit Update' further necessary information about this.
On header level of the document following fields must be filled correctly:
KKBER: credit control area
CTLPC: risk category
KNKLI: credit account
On item level following fields should be filled for the document from the customizing:
FKREL: billing relevancy
CMPNT: credit active flag
CMPRE: credit price
KBMENG: confirmed quantity
All these data is determined in the sales order. It is than copied to the subsequent documents. In the delivery and invoice there is no determination of these information to ensure data consistency through the document flow.
Credit value update - Customizing problem
Skip to end of metadata
Created by Former Member on Jan 13, 2015
Go to start of metadata
On header level of the document following fields must be filled correctly:
KKBER: credit control area
CTLPC: risk category
KNKLI: credit account
Does the credit control area in the document differs from what is customized? -> YES: please read HERE
Does the risk category in the document differs from what is customized? -> YES: please read HERE
Was the update group changed? -> YES: please read HERE
Is the credit account incorrect? -> YES: please read HERE, section 'Credit account - KNKLI'
On item level following fields should be filled for the document from the customizing:
FKREL: billing relevancy
CMPNT: credit active flag
CMPRE: credit price
KBMENG: confirmed quantity
Was the update flag (CMPNT) changed in the customizing -> YES: please read HERE
Is any of the above item fields empty? -> YES: please read HERE, section "Fields from Table VBAP (ETTYP from table VBEP)"
Also you can check further information here:
RFDKLI20 does not update new credit master data in SD documents
Customizing and Master Data problems in SD-BF-CM
I would like to know which documents updated the open credit sales values in S066 and S067
Skip to end of metadata
Created by Former Member on Dec 18, 2014
Go to start of metadata
Symptom
You want to identify which documents updated the credit values in the info structures S066 and S067.
Analysis
The credit values are updated to the info structures cumulated. In case of S066 you have the possibility to define the time period by which the credit values are cumulated. This can be done in transaction OMO1. Here you can choose the period split and the mode of the update:
In SE16 you can see the updated credit values by this time period cumulated:
For S067 the values are cumulated by credit control area and credit account in one amount:
Solution
As the values are cumulated, it is not possible to determine which document updated which value.
There is a possibility to execute report RVKRED88. This simulates the correct credit values. With that you can check which open document has still an open credit value. Please read more about this HERE.
I would like to know which documents updated the open credit sales values in S066 and S067
Skip to end of metadata
Created by Former Member on Dec 18, 2014
Go to start of metadata
Symptom
You want to identify which documents updated the credit values in the info structures S066 and S067.
Analysis
The credit values are updated to the info structures cumulated. In case of S066 you have the possibility to define the time period by which the credit values are cumulated. This can be done in transaction OMO1. Here you can choose the period split and the mode of the update:
In SE16 you can see the updated credit values by this time period cumulated:
For S067 the values are cumulated by credit control area and credit account in one amount:
Solution
As the values are cumulated, it is not possible to determine which document updated which value.
There is a possibility to execute report RVKRED88. This simulates the correct credit values. With that you can check which open document has still an open credit value. Please read more about this HERE.
I would like to know which documents updated the open credit sales values in S066 and S067
Skip to end of metadata
Created by Former Member on Dec 18, 2014
Go to start of metadata
Symptom
You want to identify which documents updated the credit values in the info structures S066 and S067.
Analysis
The credit values are updated to the info structures cumulated. In case of S066 you have the possibility to define the time period by which the credit values are cumulated. This can be done in transaction OMO1. Here you can choose the period split and the mode of the update:
In SE16 you can see the updated credit values by this time period cumulated:
For S067 the values are cumulated by credit control area and credit account in one amount:
Solution
As the values are cumulated, it is not possible to determine which document updated which value.
There is a possibility to execute report RVKRED88. This simulates the correct credit values. With that you can check which open document has still an open credit value. Please read more about this HERE.
Sales order is blocked by credit, but it has confirmed quantities
Skip to end of metadata
Created by Former Member on Nov 24, 2014
Go to start of metadata
Symptom
Sales order is credit blocked, VBUK-CMGST = B.
Standard requirement 101 is used for the follow-on function 'Reqs/availability'
You expect that the confirmed quantity is deleted when sales order is saved, but it isn't.
Analysis
The condition 101 for the follow-on function 'Reqs/availability' is not valid for sales order items that do not transfer requirements and therefore are not relevant for requirements (non-MRP Materials).
CASE 1 - Transfer of requirement is not active
For these items, the system could not set up a new confirmation during the credit release and a new availability check. As a result, the confirmation is not allowed to be cancelled earlier. The transfer of requirements is activated in the requirements class and in the schedule line category. If both switches are active for an item, the item is relevant for requirements. In this case, the two fields VBEP-BDART and VBEP-PLART are filled in the schedule line.
You can determine this in the following way:
Goto VA03 -> Procurement tab -> you need the 'Schedule line category' and 'Requirement type' information:
With the Schedule line category - in this example CP - goto "Maintain schedule line category" in transaction VOV6 and check the flag 'Req./Assembly' (TVEP-BEDSD). This needs to be marked to transfer of requirements:
Also check the Requirement class customizing. From the Requirement type you can see as follows how to determine the requirement class:
In this example the requirement type is 041. Goto the transaction OVZH, here you can see what is the assignment of requirement class to the requirement type:
The requirement class is also 041 in this case. Now you can goto the transaction OVZG and check the flag Req. transfer:
Also this needs to be activated.
If both flag is activated, the item is relevant for transfer of requirements (MRP Material). In this case the fields in the sales order VBEP-BDART and VBEP-PLART are filled. You can check it either in SE16 or report CHECK_CM is suitable for this too. More on this report you can read HERE.
If these fields are filled you can determine the Requirement class much more easier. Combine BDART and PLART into one number:
BDART PLART -> Requirement class 04 1 -> 041
If one of the flags is not activated, the item is not relevant for requirements. In this case even the sales order is credit blocked, the confirmed quantity is not deleted. Please read also SAP Note 393304 - Confirmed quantity not cancelled in spite of block.
CASE 2 - Materials without an availability check
This is the case if you have deactivated the availability check for the check group in the material master (MARC-MTVFP). In the standard system, the check group is "No Check" for which there is no ATP check (TMVF-VERPN = 'X'). The check group from the material master is copied into the order item (VBAP-MTVFP).
Material Master -> MRP3 view:
If you have set a credit block for a sales order (VBUK-CMGST = 'B'), the system does not remove the confirmed quantity in items with materials without an availability check.
You can read on that SAP Note 674112 - Updating of credit values in spite of credit block.
Sales order is created, but open order value is not updated into S066, instead it is done into S067
Skip to end of metadata
Created by Former Member on Nov 24, 2014
Go to start of metadata
Symptom
Sales order is created
Update group 12 is used
Sales order value is expected to be updated into S066 but it is done into S067
Analysis
Please use report CHECK_CM to see which billing relevancy was determined for the sales order items. More on this report you can read HERE.
How credit update works you can read HERE more.