Tax applies to shipping even when not checked

[briansandall]

Create a tax rule for e.g. Alabama, US - sales tax applies to goods only, not to shipping.

Create an order for an address in Alabama; the correct tax rule is applied but it erroneously taxes shipping cost in addition to goods.

Tested on v6.2.1.

[abrookbanks]

I can't reproduce this. Ignore the zip code format and tax name as it shouldn't make a difference.

SUBTOTAL ONLY

SUBTOTAL & SHIPPING

[briansandall]

I tested it with the tagged v6.2.1 code base on an unmodified installation. I'll try again with the latest code.

[briansandall]

Still reproducing it with the latest code from 6.2.0-branch; I'm going to try again with a clean database install, though I don't believe that will make a difference.

[briansandall]

I've noticed that when the basket is calculating shipping tax, tax_id is 999999 and so it is using the inherited tax rules from Tax::productTax rather than those for shipping tax types.

Is there a setting somewhere for this, perhaps?

[briansandall]

Seems to be an issue with the shipping plugin setting the incorrect tax id - I can sort that on my end, but at least the UPS plugin may need an update.

[briansandall]

On second thought, wouldn't it be more reasonable for inherited tax rules to consider the possibility that it might be a shipping charge, rather than blindly adding tax?

I'm not sure how else a shipping plugin with tax settings set to Inherit should function - since the tax_id is unknown, how can we determine whether the tax should apply to shipping (see also #385). Any thoughts?

[briansandall]

@abrookbanks Can you reproduce the issue with the UPS module installed? It seems to be an issue with the way inherited tax rules are handled in combination with shipping modules.

[abrookbanks]

This has been added to the 6.2.4 milestone because more granular logging of tax has been added to 6.2.3. This means if this issue can be reproduced in 6.2.4 we should be able to see where it went wrong and finally put a nail in this coffin.

[abrookbanks]

I think this can be closed. There is a note here that explains how it works:
#385 (comment)

Essentially it takes a proportion tax rate against a mix of tax rates in the basket. It makes the best it can with what it has.

I's have thought in 99% o circumstances the actual tax rate can be set instead of having to inherit.

Please do reopen if you think I've missed the point or something.

[briansandall]

Thanks for responding, Al.

The issue I was raising is that since the tax_id(s) isn't available in the shipping module, the shipping module is unable to fetch the tax rule(s) to determine if they are applicable to shipping.

It's not just the rate itself, but the rule of "does not apply to shipping" that is my main issue here.

This issue can only be fixed by providing the actual tax_ids to the shipping module that were used by the basket contents, or perhaps by checking the tax rules in _getInheritedTax to exclude any from the algorithm that do not apply to shipping, thus allowing a 0% rate to be returned.

[abrookbanks]

UPS does have a tax rate setting? See below:

[briansandall]

Our store is set to Inherit; I believe I tried Standard Rate as well to see if the tax rules would apply, but I can't recall for sure.

I'll run some tests later on and let you know.