I think my explanation was not very clear. What I tried to say is that is doesn't matter if you calculate the discount before or after tax is applied, in the end, the total value is correct. And that I AGREE WITH YOU that this should be changed on the invoice prints. Hence my last line in my previous post:
linkXperts wrote:
I'm with you on the fact that you need to change the VAT amount on your invoice. So this should be changed.
I was hoping 1.8 would have fixed the 1.7 tax/discount bug, it kind of has but also seems to have introduced a new one - hoping for a patch for this prior to the next release...
I served it all fixed and working on a plate. All the Team had to do was implement the code into their upgrade path. I wont do any modification until i get my hands on VS2010 and then start again making logic out of their tax calculation mess.
It is not only for presenting to accurate calculation to the customers, but also for the tax offices in your country. If they will notice this kind of vaults in you invoices boy!.... I do not even want to go there.
I don't know about discounts on categories or product variants... but I have a fix for discounts that fall under the total/subtotal. It may work for the other discounts, but I'm not sure - I have only tested it on shipping and the subtotal one.
What I did was take the order subtotal and used the applied discount to figure out how much of the order subtotal should be taxed:
and I multiplied the different taxes (item, shipping, checkout attribute) by that number and it comes out perfect (after a rounding change in GetPrice) every time.
It requires a boolean flag in GetPrice and GetCheckoutAttributePrice because sometimes you want to round the price, and sometimes you don't - like situations where you are trying to figure the correct tax.
I can try to explain in detail or post the files somewhere if anyone wants.