Sometimes the problem we get from customer just like a puzzle, no similar issue reported by other customer which can be taken as reference, no obvious clue we can grab for the logical analysis, customer has no idea about how does the problem happen therefore impossible to make debugging analysis. But the problem is already there and it keeps reoccurring irregularly. We may feel headache about it and it’s the same to the customer. While it’s just because the answer is unknown, such puzzle-like issue somehow looks more interesting, and it’s worthy to take some effort for a try to find out the answer.
Recently I've got an issue from customer regarding rebate processing.
They’ve met problem that the rebate accruals displayed in the sales volume is different than the value displayed in the drill-down in rebate agreement:
In the sales volume screen:
In the drill-down screen:
Here we can see there’s a difference of 68 EUR. What’s has caused such difference? Such statistics will lead to the wrong payment when doing rebate settlement.
For new rebate processing in SD, there’re 2 important structures:
S060 is the info structure which contains accumulated values from the rebate-relevant invoices,
When displaying sales volume in rebate agreement, all the values are read from S060
S136 is the index structure which is updated with the billing document numbers when the rebate condition is present in the billing.
When displaying drill-down list in agreement, system will go through the data entries (billing numbers) in S136, then get the rebate condition value from the billing to be displayed.
I have to find out the rebate condition record number if I want to check the data in these 2 tables:
So I go to SE16: KONP -> enter in agreement number field KNUMA_BO = 91 as the selection criteria -> then I got the rebate condition record number KNUMH = 0000035339
Now I’m able to check the data in S060 & S136:
S060:
Important fields:
KNUMH - number of the condition record
SPMON - Month to which the sales volume belong
STWAE - local currency
AUWRT - paid rebate value in local currency
RUWRT - accruals in local currency
RRWRT - reversed accruals in local currency
KAWRT_K - cumulated condition base in condition currency
KSTBS - Scale base in Scale units
KWAEH - condition currency
AUWRT_K - paid value in condition currency
RUWRT_K - accruals in condition currency
RRWRT_K - reversed accruals in condition currency
S136:
Important fields:
KNUMH - condition record number
KOBLNR - document number
KNUMV - document condition number (key of KONV)
Based on the entries in S136, I’ve taken a look at the rebate condition value in all the included billing documents via table KONV:
Comparing this result with the drill-down screen displayed in rebate agreement, I could see they match very well. Therefore I could say there’s no problem with the data in S136, also no problem with the rebate condition present in all these billings!
Now the problem falls into data in S060.
How could the wrong value getting updated into S060?
As next step, I used T-code: MCVV to check the statistic update for all the billings and found it shows that correct value could be updated into S060!
++++++++++++++++++++++++++++++++++++++++++++++++++
Result:
Info structure
S060 Day Document no. 0090038209
Update Group 3 Event Billing document
0005 Condition value 24.00- New 10 BO03
0006 Condition base value 300.00 New 10 BO03
++++++++++++++++++++++++++++++++++++++++++++++++++
This means if we try to perform the statistics update again for S060 for all the involved billings, there should be no problem with the S060 data.
So till now, as least I could provide the solution about how to correct the existing problematic data by suggesting customer to use standard report SDS060RB to rebuild S060.
But this report has to be executed very carefully, any incorrect execution would cause the situation to be even worse. SAP Note 1060629 explains about how to use this report in details.
============================================================================
However, it’s still unclear about what caused such kind of inconsistency. Customer also shows their extremely concern towards the reoccurring of such kind of problem as they’ve found several other rebate agreements having the same situation.
What else can I do without a concrete reproducible example? I cannot debug, I’m sure that SAP standard has no known system error towards S060 update.
The only thing that I can do is to take a further look at the existing data again, and try to dig out more hints/useful info.
I checked rebate agreement change log, billing change log, noticed some strange points in S060:
SPTAG gets filled while SPMON is blank!! For some lines in S060, the condition base value field is 0!!
In standard SD rebate processing, one IMPORTANT thing is period unit for the relevant info structures MUST be set to month, this MUST not be changed!
Take a look at OMO1 setting:
OK, so period unit setting for S060 has problem.
But this still doesn’t explain about how did the incorrect value get updated into S060, as I could see from the MCVV testing that correct value should get updated. Could this be due to the customizing change of period unit for S060? I highly suspect about it.
I started to speculate about what had happened on customer system by checking the change log and pricing data.
Two Billing created on the same date 27.04.2015: 90038209 & 90038210, they're corresponding to the 1st line data of S060. Both of the billings have the same price.
Change log in billing document:
Change log in rebate agreement via VBO3 enter inagreement number -> Environment -> Changes -> Change report, execute:
Rebate condition details in the billing document:
Condition base 300 * (Current rebate accruals rate 8% - Old rebate accruals rate 5%) = 9 EUR,
Two billing with same price on the same date, 9 * 2 = 18 EUR got updated into first S060 line for date 27.04.2015.
So these 2 billings were with rebate accruals rate 5%, then accruals rate change happened in the rebate agreement from 5% to 8%, then customer ran VBOF to update all the billings (including these 2).
The correct behavior should be:
KAWRT_K = 600, RUWRT = 30 were updated in S060 when these 2 billing got created.
After rebate accruals change and VBOF run, as correct behavior S060 should be updated as:
KAWRT_K = 600, RUWRT = 48
VBOF run should only update the “changed” part of value into S060 entry, so from this point of view, we could say the VBOF run itself is quite OK. Because the only change made in rebate agreement is the accruals rate, the affected accruals value change of 18 EUR has been updated into S060 well.
Now the problem comes to be why the original value updated from billing creation get missing?
The only answer I can figure out is the customizing change of period unit for S060!
The change of period unit for S060 would cause the data in S060 gets initialized. Afterwards, if you run VBOF to update these billings after you adjust the accruals rate in rebate agreement, system will calculate the value changes caused by the agreement change, then update the “changed” part into S060 lines.
So the truth of the story is like this:
Customizing setting of period unit for S060 was correct at the beginning, customer created rebate agreement with accruals rate 5%, several billings were generated, S060 was updated correctly. Afterwards, customer made a dangerous customizing change of S060 period unit from M to D. At this time point, all the data in S060 got initialized!! Then a change with rebate agreement happened due to business required: accruals rate changed from 5% to 8%, subsequently a VBOF run is necessary to get all the billings created before this accruals rate change to be updated. The system calculated the value change and found the accruals value should be increased by 18 EUR, therefore updated this 18 EUR into RUWRT field of S060, since all the fields in S060 are initial now, we could only see RUWRT gets updated with this 18 EUR after VBOF run. Finally when we display the sales volume from VBO3 the system would just read data from S060 -> an incorrect sales volume data gets displayed.
To correct the situation, customer will have to change the period unit back to M for S060 then rebuild S060, if there’re lot of billings which are relevant for rebate, it’ll be a quite time consuming task, and it has to be done in a very careful way.
There's a SAP Note 1060629 explains in details about how to make use of the standard report to rebuild statistics in S060/S469, but it's always recommended to contact SAP support before you take any action to rebuild S060/S469.
Finally the root cause has been inferred from personal experience & analysis towards existing data!
As a conclusion, please bear in mind that for rebate processing (new rebate processing or enhanced/extended rebate processing), in OMO1 the period unit has to be set as M for S060 (new rebate processing) & S469 (extended rebate processing), this setting MUST not be changed. Otherwise, it’ll easily cause data inconsistency like this case, and the standard coding for rebate settlement is relying on it, you’ll have problem when doing rebate settlement as well!
- SAP Managed Tags:
17 Comments
