Possible Rounding Error When Applying Tax

Hi, I am closing this thread because it is a duplicate.

Thank you

There is a duplicate thread conflicting with this one. So I marked it as not resolved again.

• This reply was modified 4 years, 6 months ago by mbrsolution.

Hi, out of curiosity what if you set your value to 10.82 instead of 10.825? Does that help in any way?

Regards

Hi

Sorry for the delay in replying.

Bringing it down to 10.82 makes the total 12.98 after tax. I’ve tried playing around by increasing/decreasing the value to see if something like 10.8249 would resolve it but it doesn’t, it’s either 12.98 or 13.

Thanks

Hi

Just as another test, I set the product to 10.825 and then included shipping of 2.49 and I still get a similar issue:
Invalid payment amount received. Expected ￡15.48, got ￡15.49.

The same happens if the shipping becomes 2.50:
Expected ￡15.49, got ￡15.50.

Thanks

Hi.

Thank you for your report, I’ve reproduced the issue on my test server.

However, the issue is not in rounding, but rather in the fact that it’s not a good idea to set the price to something with more than 2 numbers after decimal point. So the only “fix” I see here is to force the code to floor all money-related values to 2 numbers after decimal point. In your example the price would become 10.82 no matter what you put after the .82 part.

Now the question is: what you want to achieve by setting your price to 10.825? As I understand, you want the final price with 20% tax to be 12.99?

We only support price amount upto 2 decimal places (which is standard for a price value). You need to edit your product price amount value and use a normal amount that is upto 2 decimal places (not 3).

Hi

Yes we’re trying to get 12.99 with 20% tax.

I understand rounding the price to 2 decimal places, but it seems strange that this is done before the final value is calculated. Doing it this way means there are values which people just can’t sell an item for. If I look at Germany’s 16% VAT as another example, they can’t sell an item for 15.99 as the base price would (accurately) need to be 13.7844827586.

I’ll probably just see if I can tweak it easily enough for my purposes or just push for a slight change in price, but hopefully you understand where I am coming from.

Thanks

Lets see if we can re-work something in the plugin.

Hi

So I’ve been looking at it further and I’ve found a solution, at least for my use case and a couple of test cases I looked at. Unfortunately I haven’t really been able to fully test it and not sure if I will get the chance. Part of that means I have made some changes but not 100% certain if it actually mattered to the end result as I haven’t had a chance to revert those changes.

Basically all I did was looked at any instance where you’re rounding a number and increased the precision on it, or removed rounding altogether (removing intval function calls). Whether those actions were needed, I’m not sure. The final action which actually showed a result was in /public/assets/js/pp-handler.min.js and making vars.data.amount=Math.floor(PHP_round(tAmount,2)) in the calcTotal function.

To be honest there’s still probably some inaccuracy in the calculation as the value is 1299.6 when it should just be 1299, but it seems to work in this instance and could potentially be a more robust solution? Again, more testing would be needed to see if it’s worth it.

Thanks

Altering plugin files directly isn’t a good idea. Your changes will be overwritten when plugin is updated.

In the upcoming plugin version we have fixed rounding inconsistency for prices with more than 2 numbers after decimal point. So there was rounding issue with that indeed, thank you for helping to nail it.

Regarding your requirements, I think there is a solution. We had discussion with our team on this and here is what we come to. Currently (after the fix in the upcoming update), all the amounts are rounded to 2 numbers after decimal point on each step of the calculations. So your price 10.825 becomes 10.83 + 20% = 12.996, which is rounded again to 13.00.

We will probably introduce new settings option. When enabled, it would only round final amount. So calculations would look like this: 10,825 + 20% = 12.99. Same applies to your other example: 13.7844827586 + 16% = 15.99. Without this upcoming option enabled, 13.7844827586 would be rounded to 13.78 + 16% = 15.9848, then rounded to 15.98.

I cannot currently give you any ETA on this, as this would require some global changes in calculations. But this will be worked on after version 2.0.36 release.

Was a fix ever implemented for this or is it still in the pipeline?