Recently I worked on a rebate issue which impressed me a lot. It makes me realize that the rebate function can be affected by such a special group of billing documents.
Actually this would be a quite common situation for any system with large data volume for sales & billing transactions, especially when there’re lots of rebate agreements being involved. You may have plan to perform the data volume management activities for the old historical transactional data in the near future, or you may have already performed such activities regularly. In any case, I hope the experience that I’m going to share could help you avoid the similar kind of problem in your system.
I got this issue which describes a problem regarding the data update in S060. Even though there was a change with the condition rate and accruals amount for rebate condition via T-cd: VBO2 (from -2% to zero), and VBOF (report SDBONT06) has been executed, there’re still unexpected accruals value appearing in S060 table. Note that this rebate agreement has not been settled yet.
Display the drill-down lists (after VBOF run), the accruals shows 0 there. -> This is what we expected: sum of accruals become zero.
But take a look at S060 (after VBOF run):
Why there’re still accruals value showing in S060?
It seems that S060 was not updated correctly during VBOF run. I was in the same doubt with customer at the beginning.
There’s an example with which I can use to simulate the rebate condition rate & accruals amount change then run VBOF:
During the analysis I didn’t run VBOF as it’ll be not easy to analyze S060 update in update debugging. It’s the last step that I want to try. Let’s take a look at data in S060 first (before VBOF run).
Compare this with the value displayed in the drill-down lists (before VBOF run):
The sum of RUWRT doesn’t equal to accruals displayed in drill-down list!
But when I take a closer look at the drill-down lists, sort by Month (before VBOF run):
I noticed that only lines with period 03.2015 are being displayed in the drill-down lists!
While in S060 for SPMON = 201503, RUWRT = 808.657- which is still different than sum of accruals in the drill-down: 342.811-
Based on customer’s description (also shown in the 2nd screenshot), after VBOF execution, RUWRT for 201503 will get updated to 465.846-.
Let’s make a calculation here:
808657 – 465846 = 342811 <<<< exactly the same amount as shown in the drill down list!
What does this mean?
After change the rebate condition rate & accruals amount from -2% to zero, and run VBOF, the line for 201503 in S060 will get updated from 808.657- to 465.846-, the subtracted part is the same as accruals amount 342.811- shown in the drill-down lists (before VBOF run).
In other words, the sum of accruals shown in the drill-down lists will get fully subtracted from line of 201503 in S060 after VBOF run.
So there’s no problem with S060 update during VBOF run at all!
I felt a bit of relief as there’s no need to make deeper check towards S060 update.
While the question now comes to where’re these value coming from?
Accruals value in S060 must got cumulated from somewhere (billings or manual accruals), considering difference of accruals amount 465.846- between S060 for 201503 & drill-down lists, I suspect only part of billings from 201503 appearing in the drill-down lists, where are those billings which not getting displayed in the drill-down lists going?
There’s another important table S136 in rebate, which stores the billing number if a rebate condition is present in the document.
Take a look at S136 and compare with drill-down lists:
The smallest billing number showing in the drill down lists is 7990034215 (sort by document number in the drill down lists):
However, comparing with data in S136 above, there’re so many billings before 7990034215 which are supposed to be appearing in the drill-down lists as well.
Pick any of the billing number before 7990034215 in S136 and try to display by VF03:
There’s entry in S136 for this number means that the billing used to exist in the system before, but now it’s got disappeared!
The only thing that I can figure out now is the data archiving. Take a check in T-code SARA:
OK. They do have multiple billing archiving deletion runs!!
Take some further look at the archive info system:
Here it is:
Finally the root cause has been identified!
It’s clear that all these missing billings have been archived and deleted before the close of the rebate agreement. After the billing archiving, the S060 data is still not touched, but the billing data (VBRK, VBRP, KONV) has gone. So during drill-down lists display, they cannot be read out, and during VBOF run there’s no chance to update these non-existing billings anymore. Therefore the cumulated accruals amount from these archived billings remains in the S060.
What to do with the current situation (an opened rebate agreement with archived billings being involved)?
I could figure out two options to settle the agreement:
- Reloading the invoices from archive and executing VBOF / settlement
(Regarding reloading archived invoices, this can be done by either removing the coding implemented with note 491506 or by copying report S3VBRKRL to
a customer own version in which the mentioned coding is removed.)
- If business can confirm there’s no need to take sales volume from those archived billings into account during rebate settlement, rebuild S060 then run VBOF and doing settlement.
Reading through the whole story until now, you may have the question that how could the billing archiving run not considering about the non-closed rebate agreements?
While SAP DO offer a solution for such kind of situation. Note 1426093 provides a standard report.
By using the report SDBONARCH, all billing documents that cannot be archived (as the rebate agreement is still not yet settled) receive an entry in the database (DB) table BONARCH. This table is read when billing documents are archived.
To have the data volume management activities such as data archiving not interfering the rebate processing, you should keep in mind about this SAP Note 1426093.
Execute the report from this note periodically then no need to care about the above long story anymore. 🙂