Possible regression, "Save Tax Rates" setting saves invalid rates for Postcode/ZIP/City
welenofsky opened this issue · 1 comments
I am not 100% if this is a bug but from what I can tell during a refactor in #203 it seems that this line
was added that saves the calculated rate, not the rate from the upstream API, to woocommerce. This causes the tax rates in Woocommerce to be set for the ZIP/Postcode for whatever the calculated rate is for that line item at the time of calculation. It also saves a invalidrate_percent
order item meta value to the order items.
In the screenshot above you can see the rates being saved are not correct for the areas that it is listed for. What I noticed is that it correctly gets the rate from the upstream api and then calculates the taxes for product/line item correctly. But after that it tries to recalculate the rate from the taxes applied and the total for the item which causes a loss of precision to occur and a less precise/invalid value to be stores as the tax rate.
If I use https://www.taxjar.com/sales-tax-calculator the tax jar sales tax calculator you can see at the time of writing this the rate for Orangevale, CA is 7.75%
Where this trips up my customer is that this tax rate is added by Woocommerce to the order/order items as the rate_percent
prop/order item meta key.
These values were being sent to a third party system and up until #203 were the right/precise values based on the API responses from TaxJar. Now this upstream system does not accept these values as valid as it uses a tax lookup service and the rates are not correct for the areas/zip codes of the order.
Please let me know if this doesn't make sense/if you need more information on this.
Thanks,
Justin Welenofsky
@welenofsky Thank you for submitting this issue as well as the additional context provided. We will investigate and follow-up with any additional questions or findings.
Thanks again!