I’m not an accountant or anything but I think this is an issue, especially if you have an accountant and they want all the numbers to match properly.
ItemX = $15.00
Purchase quantity 2.
Total Price $30.
Suppose the tax is 8.1%. Now you’d think the tax would be $30 * 0.081 = $2.43, but I’m getting a tax of $2.44
I think I know where the issue is coming from:
$15 * 0.081 = $1.215, rounding to 2 decimals: $1.22
$1.22*2 = $2.44
UC should store more decimal places on the backend, I’d say 4 would be enough to catch this issue. Though I have looked in the serialized items in the db and they are stored at about 32 decimal places (nuts huh).
I’m integrating the orders into a MS Dynamics GP server (no easy task) and issues like these give many errors.
It’s also rather confusing that when calling fn_get_order_info the subtotal includes tax, but on the page subtotal doesn’t include tax.
This has been discussed repeatedly over the years. At least ‘tax system improvements’ is now a planned item on the updated roadmap; the rounding errors should have been addressed a long time ago.
Bob
I just found another error in tax I believe:
subtotal: $30.00
shipping cost: $14.22
Including discount: $10.00
Order discount: $3.00
NV Tax (8.1%): $3.59
Note the tax is $3.59
shipping tax = 14.22 * 0.081 = 1.15
product tax: 30 * 0.081 = 2.43 -> 2.44 in their case
1.15 + 2.44 = $3.59
But what about the Order discount of $3
27 * 0.081 = 2.187 = 2.18
So the tax should be $3.33
That is a huge issue, much more significant than that rounding error issue.
[quote name=‘phazei’]I just found another error in tax I believe:[/QUOTE]
This has been reported in the following Bug Tracker post:
[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1532[/url]
Still MIA. I am guessing (hoping) it i part of the tax system improvements.
Bob