Skip to Content
Author's profile photo Alex Zheng

One SD Rebate customizing setting that MUST NOT be changed

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:

rebate 1.png

In the drill-down screen:

rebate 2.png


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:



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




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!




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!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Maria Du
      Maria Du

      thank you for sharing the experience.

      it was really a puzzle.... 🙂

      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Thank you Maria, it's an interesting case. 🙂

      Author's profile photo Jobi Sebastian
      Jobi Sebastian

      Hi Alex,

      Thanks a lot for sharing this valuable information. The effort you put for making this document is very commendable.


      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Hi Jobi,

      Thanks very much for your feedback!. I'm glad to share my experience and interesting information via blog posting.



      Author's profile photo Former Member
      Former Member

      Thank you for sharing.Great

      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Thank you NIGIL, I'm glad to know that you like this sharing. 🙂

      Author's profile photo Lakshmana Srini
      Lakshmana Srini

      Alex, The Information you shared is pretty useful and important. I bet every SD consultant and an ABAPer would surely come across this kindof issue atleast once in their professional career. Your blog clears it all with simple explanation

      Best Regards,


      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Hi Lakshman,

      Thanks a lot for your comments! That's the purpose of my sharing, hope the others could avoid the similar kind of issue.

      Best regards,


      Author's profile photo Amitesh Anand
      Amitesh Anand

      Hi Alex,

      Just one word... 'Wow'

      Best Regards,


      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Hi Amitesh,

      Thank you for your comments! Hope my sharing is helpful for you. 🙂

      Best regards,


      Author's profile photo Typewriter TW
      Typewriter TW

      Great work!

      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Hi TW,

      Thanks for your feedback!

      Best regards,


      Author's profile photo Mehmet Ozgur Unal
      Mehmet Ozgur Unal

      Hi  Alex Zheng,

      Well explained document, thanks.

      This process is as same as S4HANA, isnt it ? Could you inform us ?


      M.Ozgur Unal

      Author's profile photo Alex Zheng
      Alex Zheng
      Blog Post Author

      Hi M. Ozgur Unal,

      Thanks for your feedback.

      For SD rebate, the same logic applies in S4HANA as in ERP.

      Best regards,



      Author's profile photo Mehmet Ozgur Unal
      Mehmet Ozgur Unal

      Hello  Alex Zheng ,

      I wanna implement Extended rebate processing. Could you share referance document ?

      Best Regards.

      M.Ozgur Unal

      Author's profile photo Sankar b
      Sankar b

      Hi Alex

      Can you please advise on the below issue? We are creating the created Rebate agreement through an external interface .

      While running the VBOF transaction, Rebate condition type got added to the Billing document however the accrual value is zero.  While analyzing, we observed the Condition currency for the Rebate agreement was blank. As a result of this, in the billing document though the rebate condition type exist , accrual value is zero. Also in S060, condition currency is not updated.

      As a correction, can we follow the below steps ? Please advise.

      a) Update the condition currency for all the Rebate agreements.(we found a fix and did that)

      b) Run SDS060RB so to update the condition currency at the S060 level from Sales org perspective.

      c) Run VBOF again for the rebate agreements . 

      can the above update the Accrual values in the existing billing documents where the rebate condition type is already present but with Zero value?





      Author's profile photo Archana Pawara
      Archana Pawara

      Hello Team,


      Need your suggestion and help to understand behavior of Rebate processing.


      I have Rebate Agreement valid for 1 month, rebate condition record maintain with settlement material.


      Once create Sales order, delivery and invoice rebate condition getting apply in posted correctly in accounting.


      after that if i am trying to make rebate settlement i am getting an error "The sales volume for agreement is not current"


      once error is occurring running VBOF but once run VBOF its deleting condition record from original invoice and accounting posting update reversal.


      later i have cancelled invoice and created newly with rebate condition record.


      now this time without running VBOF for same agreement i am not getting an error for Sales volume and its allowing to post rebate credit memo for partial, manual and final settlement.


      I have check OMO1 S060 and S136 - have Synchronized.


      Rebate condition, Rebate agreement is maintain correctly but the behavior SAP while settlement not coming correctly