Hi Hussain,
For possible reason, you can refer to SAP KBA 1839892 and SAP note 12934.
Normally, without reproducible example, it will be very difficult to find out the root cause.
You can use report ZVINVOIC to identify double invoices and use VF11 to cancel second invoice.
I hope the information is helpful.
Best Regards,
Tao
Hi MAK,
You mentioned that there is restriction that there is only seven condition place in system?
May I know where you find this restriction? A screenshot will be helpful.
Best Regards,
Tao
Hi Imran Khan,
Please rebuild corresponding info structure table according to note 64636.
Best regards,
Tao
Dear Tao,
Will you please little elaborate it, and share the reason why is system doing like this.
regards,
Imran khan
It may be due to wrong configuration settings. Refer the PDF document provided in OSS 1600533 - Error analysis for incorrect data in information structures for error resolution.
Regards,
Hi Collegues,
I had similar requirement. In quote I had some billing type assigned ZXX with revenue account determination.
Client require to create quote and also proforma for their customer's hirearchy to approve. They pay advance against this proforma so we again create billing type ZABC from Quotation only. so I have billing type ZXX assigned to quote document type ZABC.
Customer pay advance money as per bill type proforma invoice.
Here I noticed strage that even though I had assigned billing type ZXX in quote, when I tried to create proforma invoice type F5, it was created. Although I maintained copy control and item category relavant for billing B type.
Can anyone tell why F5 could be generated eventhough I had assigned billing type only ZABC and not F5? Whether standard functionality allows to create F5 for any document types?
Thanks
Prakash
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
Did you check the OSS 456458 - FAQ: How does the report SDBONT06 work?
Regards,
Yes I did.
I run the program every night yet I still get this error on a lot of rebate agreements. I do not understand why.
Thanks Wink Young.
Your reply corrected my problem.
Hi SAP Expert,
We are facing a bizzare issue. There was an Invoice 123 whose Payer & Ship to Party was X. When User triggered output, then also "X" Payer & Ship to was displayed.
Later on, this data of Invoice 123 was transfered to other Invoice 456. i.e. whole data including Item details, Payer, Sold to Ship to & whatnot of Invoice 123 was visible in Invoice 456. And overview of Invoice 123 displayed some other data. Furthermore, now the system shows No Output for Invoice 123 whereas that output of Invoice 123 is visible in Invoice 456.
Could this issue be related to any System Restore or some Upgrade activity as the data of one document is transferred to other document.
We have checked Number Range as well but everything seem fine there.
Please advise.
Regards,
Prashant
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,
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
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
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
Hello Singh,
Are you sure on this??
if yes then delete/Remove entries by using below steps for the sales organisation EUR1 combination
1.Remove OVAZ all settings for EUR1
1.1 Assign Sales order types permitted for sales ares
1.2 Combine divisions
1.3 Combine distribution channels
1.4 Combine sales organizations
* we can control all sales transaction by removing document types
2.OVFL-Assign sales area to credit control area
3.OVX6--Assign sales organization - distribution channel - plant
4. OVXJ- Assign sales group to sales office
5.OVXM-Assign sales office to sales area
6.OVXG- sales area combination
7.OVXA-Assign division to sales organization
8.OVXK-Assign distribution channel to sales organization
9.OVX3-Assign sales organization to company code
10.Even though Master data is already existed for EUR1 sales organisation it will not work
11.if you want to delete sales document/Delivery/Billing document types you can delete it for the sales organisation EUR1 combination eventhough if you leave it also no impact on the other sales organisations.
Based on Approvals everything save in new transport request then move to testing client(SCC1) start testing.
Thanks,
Krishna.
Hi Expert Singh,
You may want to first remove all the assignments and then delete the Sales orgnaization. If you have data (sales orders, invoices, business partners, materials in this sales org, then am not sure about it.
Archive them, first and try the deletion.
Please have some helpful info in the below link
how to delete entire enterprise structure | SCN
Regards
Jobi
Thanks Krishna.
How should I take care of the data created against EUR1 in the DEvelopment - Unit testing client. Because I guess we first need to delete/archive the sales and billing/accounting documents before deleting the configurations? Isn't it?
How should we get rid of all the Sales/Billing and Accounting documents?
Thanks in advance