-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rounding errors in tax calculation #147
Comments
Mm yes, lovely JS floating point rounding issues. Definitely aware of the Math troubles here. I think the most robust solution would be to use a library specifically designed to handle these |
It's irrelevant that they're primarily for display purposes. If our customers see that we can't even calculate a simple sum like that correctly, they're hardly going to trust us with their money. The arithmetic is fundamentally wrong here - how can fixing that be considered an enhancement, rather than a bug? Isn't getting the math right a pretty basic expectation from a financial billing company? |
@davidgeary I agree with you -- it's a bug. As for my comments about type changes, that was simply an aside. The crux of the issue lies in using a more robust mathematical implementation than |
In order to address the issue at hand, I implemented truncation to the 6th decimal during tax summation. This should resolve the issue as described. I'd like to dog-ear a more robust solution involving a reliable BigDecimal (or similar) implementation. The commit closed this issue .. I'll be sure to add a note here once a version containing the fix has been released. |
This is in v3.0.6. As soon as that changes from pre-release to release, it will be available from our CDN. |
Hi! This patch has been deployed to our CDN. I will create a new issue shortly detailing planned efforts to clean up the way we treat decimal values. |
The inherently inexact nature of floating point numbers used for the pricing values is resulting in rounding errors in the calculation of the tax values for certain totals/tax rates.
For example, using a subtotal amount of 302.00 and a tax rate of 0.2 (for GB VAT), the calculation of the tax value at these lines is:
The following lines are commented as explicitly rounding partial cents up, but this also means that floating point rounding errors are rounded up. In the above example, the tax therefore becomes
60.41
which will be an obvious error to the end-user.(Performing all calculations in cents might be a more robust way to resolve this, though perhaps a pragmatic approach may simply be to truncate the tax value to, say, 4 decimal places before rounding up? This would still account for partial cents, but minimize the inclusion of floating point errors being included.)
The text was updated successfully, but these errors were encountered: