Improves stored tax rate precision

[sethobey]

Closes #221

During tax calculation, the TaxJar plugin correctly stores the location's rate from the TaxJar API, but then overwrites the stored rate when calculating cart and order line subtotals with a "reconstructed" $applied_rate that is reverse-engineered from the line total. Rounding line item tax amounts in previous steps can lead to a loss of float precision when reconstructing the tax rate.

This PR adds an additional check for the existence of line item tax directly on the tax detail object before attempting to reconstruct an applied rate from item totals.

Click-Test Versions

• [X] Woo 5.9

Specs Passing

• [ ] Woo 5.9

[welenofsky]

One thing I am wondering is if we can do away with the saving of tax rates in the function build_line_tax_from_rate all together. I can see 3 usages across the code base and 2 of those 3 seem to use a calculated rate based on the taxes applied to the line item. It seems that 2 of those calls we may not want the tax rate created in woo due, the 3rd I am not certain.

As a temporary patch I have added an optional param $prevent_save to the build_line_tax_from_rate method and passed that in through the instances where the tax rate is being reconstructed.

https://github.com/three29/taxjar-woocommerce-plugin/commit/23924cb10d6057716b7705751f844e263bd2cb8b

If this is an acceptable solution I could PR this.

[dallendalton]

@welenofsky I don't think that solution actually resolves the root issue. That change would prevent the plugin from creating any rates in the WooCommerce tax table except for the rates applied to fee items. While creating rates in the tax table does not actually affect the amount of tax applied to a cart/order, some customers do use it for reporting purposes. For those that don't want to create rates at all they can disable the save rates setting.

We are currently investigating changes that would not affect the amount applied to a line item but would resolve the root issue of a rate row being created with an incorrect rate %.

I misunderstood what this suggestion changed and after some more investigation it looks like it might be a possible solution. We are going to do some more testing on edge cases to make sure and will post an update after we know more.

Thanks again for submitting this issue and working with us to get it solved!