Reaction: Error when checking out with Tax enabled

[zenweasel]

Issue Description

Receive the following error when checking out with Tax enabled

Client provided total price 28.979 for group with index 0, but actual total price is 28.978999999999996

Steps to Reproduce

I am not completely sure which of these are the critical steps but i can reproduce this error following these steps.

1. Reset database
2. Enable Stripe and Example Payment
3. Enable all Flat Rate shipping methods
4. Enable tax rate at 10% for the state of California
5. As an anonymous user add one red "Basic Reaction Product" to your cart (because the price is $19.99)
6. Checkout and choose "Flat Rate - Priority"
7. Checkout with either the Example or Stripe payment methods
8. Observe the error

Possible Solution

There's a rounding error happening somewhere. Tax is stored on the item at 1.999. Not sure if that's correct or not.

Versions

Reaction: 2.0.0-rc1

I hate making stuff critical that no one else has run into, but it seems like making something X.99 is probably as pretty common case for pricing.

[zenweasel]

One other note is that if you do the 10% discount on a $19.99 product the discount amount shows as $2.00 which I also don't think is correct.

[aldeed]

You stated in the other PR where this was found:

We probably shouldn't be storing currency values with a greater than cents accuracy.

I agree with that, but we will first have to agree upon and document:

• At what points should rounding occur and how (floor/ceil/nearest)? E.g., does each item's tax get rounded to nearest and then totaled to get total tax? Or does tax get totaled and then rounded? These will yield slightly different amounts for total tax. Same question for discounts.
• What does "nearest cent" mean? There might be differences in which decimal place we should round to per currency? And some currencies do not have cents, but these could end up being fractional if cut in half by a discount or multiplied by a non-integer sales tax percentage.

[zenweasel]

@aldeed Yes agreed. I didn't mean to make it sound like it was a trivial issue to solve. Possibly our currency entries could have something that indicates how the rounding needs to occur.

I expect that tax and discounts may need to have different rules, or at least how exactly you calculate tax may have legal ramifications, whereas with discounts you can make up whatever rule you want as long as you are clear about it.

Also to clarify that this is probably not a new issue and may have been around as long as taxes and discounts have been around and that extra check that is happening there is just surfacing the issue.

[aldeed]

I believe we can solve the immediate issue here by rounding the grand total to the proper precision, using the precision value from the currencies list, in both client and server math. Then the larger question of when and how to round taxes and discounts properly can be tackled in a separate issue.

[spencern]

This is an important issue for us to solve.
@aldeed I agree with your approach here of solving the problem where the client and server numbers are different and having a deeper discussion on how to solve the larger question of taxes and discounts.