I am building a Prestashop plugin, and i have stumbled on to this tax calculation issue.
The program flow is as follows:
A person places an order at the eCommerce website, the order is accepted, the order details such as items, prices, taxes, discounts etc is send to an external invoice API service.
An example of an order could be:
(These prices include taxes)
1x T-shirt 20.64
1x Shipping 125
1x Discount -18.58 (In this particular test case, the discount is 90% off the product, the math is simple 20.64 * 0.90 = 18.58)
Order total after tax is applied: 127.06
This is all fine, but, when i send the details off to the API, the order is saved as the following:
(These prices are saved without tax applied, the tax rate being 25%)
1x T-shirt 16.51
1x Shipping 100
1x Discount -14
Order total after tax is applied: 128.14
As you see, the order totals do not mach, the difference is 1.08, i am thinking this a discount & tax issue.
Its worth noting that the external site does its own math on the values sent, e.g products, tax etc. I cannot influence the way the external invoicing site does its calculations. I think the issue occurs in the order of which the operations are performed on the different platforms.
Its also worth mentioning that the code works perfectly fine when there is no discount present.
What can i do prior to sending the values, so that i end up with the same values both places.
The total they compute is indeed (100 + 16.51 - 14) x 1.25 = 128.1375
However their computation of taxless discount is wrong, 18.58 / 1.25 = 14.864 not 14.
Is there a rule that discount should be rounded (or floored or ceiled) to an integer value ?
If not that means they divide the discount by 1.32714285714, thus considering there is 32.71...% taxes on discounts. This would be strange and unlikely, since when adding the discount again they use the normal 25%
Check your prestashop documentation, local laws or whatever to find out if this is real, and whether the value is for example 33% or 32.7% Since I reverse-engineered the value from the tax value they stored, it could be distorted by the rounding to 2 decimals.
Then, to get the correct result, replace the discount by discount * 1.32714285714 / 1.25, that is, replace your expected tax rate by the one they apply.
If the taxless discount does have to be an integer, we can modify it so that it is on our side as well, since I guess what matters most is the final price. So use this algorithm to send in a discount that will finally be an integer:
% get taxless prices
price_notax = price / 1.25
discount_notax = discount / 1.25
% transfer decimal part of discount into price reduction
discount_int = floor(discount_notax)
price_compensated = price_notax - (discount_int - discount_notax)
% re-add tax to get values to send
discount_send = discount_int * 1.25
price_send = price_compensated * 1.25
The sum of values should be the same : price - discount == price_send - discount_send
Update to the latest version, look up their bug tracker or contact them. File a report if there isn't one.
One of the workarounds above will work for now, but if it's a bug that gets fixed and you use the first one, you will be billing wrong amounts again.