Pricing Conditions - Renumbering the Steps

[Former Member]

I recently had to completely renumber the steps on 2 pricing conditions that have been around since about 1997. the reason for the renumbering was that the originals were created in step increments of 1 (1,2,3 etc.) rather than 10's so it left no room for new steps in most cases. These specific pricing conditions are generally updated once a year and the update includes 2 to 6 new steps that have to be fit into the scheme.

In the above case I copied the old version (i.e. ZZRTLR to ZZRTL1), completely remodeled it, deleted the old (ZZRTLR) and renamed the copy (ZZRTL1) as the new version (ZZRTLR).

The new version works just fine for all current year requirements but we do have to reprint last year's invoices from time to time and that results in an invoice that no longer makes sense. In some cases it will insert values in the wrong line, miss lines, include values in the 'Subtotal before Tax' that shouldn't appear, etc. The reason for that is that the output looks to step # to find the value, if that step has been renamed then it will insert the value where it believes it belongs - or not. Unfortunately almost every step has either been renamed, renumbered or ceases to exist.

Question: is there a way of getting the output to appear on the appropriate line? What are my options?

[Shiva_Ram · Accepted solution]

deleted the old (ZZRTLR)

On any circumstance, you should not delete any pricing procedure in the system. You can leave as it is as this will not harm anything. Even the old documents in the system points to old pricing procedure. Hence my suggestion would be create the old pricing procedure again and leave it in the system (No need to assign to documents in SPRO). This could resolve your issue. I recommend this solution, because it looks you may face other problems also like pricing in the old documents.

Regards,

[Former Member]

Thanks for the help and confirmation of something that I'd thought of but was reluctant to try until I passed it by the community.

So, by the sounds of it I will need to rebuild the old version of the Pricing Condition, leave it unassigned and the old Invoices can be reprinted based on it. That will also mean that I will need to reassign the new version (with a new name) to all of the current year Customers so that the new version will pick up all of the revamped scheme. I'll give it a whirl in our sandbox and see what it does. Sounds simple.

Thanks again and I'll post the results when I'm done.

[Former Member]

Here's a brief update of my findings.

Recreating the old version of Pricing Condition worked but I found out a lot more about the way the old one was constructed than I wanted to! Modifications had been made in past years that added new lines, used old lines to subtotal values that weren't sub-totalled before and a host of other things. The end result was that no matter how I rebuilt the old version it would never reprint some old invoices accurately and even if I'd retained the old version the results would have been the same.

The end users aren't really happy about the reprint results but there really isn't much we can do about it.

The new renamed version will be put in place (that has the steps renumbered to enable easy modification and room for planned expansions every year. Eventually (probably 10 or 15 years) we'll run out of room but at that point a lot of things will have changed!

thanks again for the help.

[former_member184701]

dear friend,

the situation you described is really painful...

i would say - custom abap may do such trick

say, you need to update all 'old' invoices using the 'old' scheme

the criteria might be invoice type and posting date...

so, z-code will do it in background...

work with abaper to estimate the possible effort.

good luck!