How to debug credit value calculation
目录
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.
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)
