SDBONT06

[Former Member]

We are running SDBONT06 every night with a job with just sales org, distr ch and div specified.  It never seems to come back with any change information in the log from that nightly run.  But when we go into some rebates, we get the "The sales volume for agreement 10000nnnn is not current" message for rebates that were entered a month before.  I am reading through some oss notes and still not understanding why this is happening?

Any insight is appreciated.

Susan

[former_member131691 · Accepted solution]

Hi Susan,

If the agreement was processed by SDBONT06 in a real update run and it failed for any particular reason the details of the error or reason for the failed update should be written to the log. If you are not getting any log in your job I would suggest that the agreement with the 'sales volume ...... is not current" error was not selected for processing by the job variant. 

You should do a test directly in VBOF in test mode using only this one agreement. If you get no error
run it in live mode to see if there is a real valid reason fort he agreement not getting updated. As mentioned above the report is affected by changes to live pricing objects, conditions and access
sequences etc. It uses the VBOX index to select the conditions to be updated. If for example you had changed the access sequence of a rebate condition the system would no longer be able to find the
VBOX entry and the report would not update the condition in the agreement as a consequence. You should check if this could be the case here. If an access has been changed you would need to rebuild the VBOX table which can be a very time consuming task and would only be taken on if absolutely necessary.

In general you should never change an active price condition, access or pricing procedure. Copy your

existing set up and make whatever change is required then re-assign a completely new pricing procedure. This keeps the old and new separate and avoids follow on issues arising from productive changes. Perhaps also as a best practice when your users create a new agreement they should immediately run VBOF for the agreement to remove the retroactive flag(KONP-KSPAE) because as you know an agreement cannot be settled until  the retroactive flag is removed, I guess that's why you run SDONT06 every night.

Hope it helps further but to try to isolate the reason the agreement is not updated run it on it's own
through VBOF where you can more easily find the root cause.

Kind regards
Brian

[Former Member · Accepted solution]

Brian,
Last week I ran SDBONT06 with specific document numbers in it and I could see processing of some documents on the bottom of the screen although the log ultimately did not have any detail.  I then went into a random selection of those same docs and none had that sales volume message at all.  I ran through the agreements for this month and next month, and this time no documents were shown at the bottom of the screen and no notes in the log.  Again, random checking did not find the sales volume message.

I have a fairly new price condition but no new access sequence. So it sounds like I should copy the current price procedure to a new name and re-assign?

Thank you.

Susan

[former_member131691 · Accepted solution]

Hi Susan 

SDBONT06 will check the agreements that have a retroactive condition (KONP-KSPAE = X) it then checks the billing documents of the agreement by carrying out a new pricing with pricing type 'I'.. If it finds any difference in the billing document's condition value, with that of the agreement condition it will create a new FI posting for the difference between the 2 values and remove the retroactive flag (KONP-KSPAE = ' ') If it does not find any difference then there is nothing to post it will simply remove the  retroactive flag. In this case there would be no log in SDBONT06 you will only get a log when one of the previously posted values has been changed.    

If you create a new agreement now today with a start date of today the system automatically sets the retroactive flag on the condition. If there are no documents that would fit the criteria of the agreement

posted yet you can see what is described above. When you run VBOF for your new agreement the system will not generate a log it will simply remove the KONP-KSPAE flag in the agreement and you
will note that you no longer get 'sales volume for agreement xxxx is not current' in VBo3.

It doesn't seem as though there is any issue you have to check further.
Bear in mind there are several things that can cause the KONP-KSPAE to be set to X.
If a user changes details in the agreement for example. Also if you NEED to make configuration changes to your pricing or accesses to copy and re-assign. I does not seem that this is necessary here though.

In SAP Support we often see agreements that cannot be settled due to various errors in SDBONT06,
The cause is always changes that have been carries out to the conditions, accesses throughout the year and if the agreement is retroactive there is no chance to reconcile the situation.

If you users create an agreement they should run SDBONT06 immediately rather than waiting until it is to be settled a year later, likewise if they make a change to an agreement that resets the retro active flag they should run SDBONT06 straight afterwards to reset it.     

Hope it helps further
Kind regards

Brian

[Shiva_Ram]

Did you check the OSS  456458 - FAQ: How does the report SDBONT06 work?

Regards,

[Former Member]

Yes I did.

[Former Member]

I run the program every night yet I still get this error on a lot of rebate agreements.  I do not understand why.

[Shiva_Ram]

Have any changes made in the system like change of pricing procedure, rebate condition type/access sequence/condition records? You need to provide information on those. Can you take a look at OSS  105681 - Consulting: New rebate procedure for any additional guidelines?

Regards,

[lcastedoaafintl]

Hi Susan, did you get this resolved?  I think it calls for an OSS note.