Tax not calculated on Products, only on Shipping

What do you have for General > Default customer address?

I left it at the default from when Woocommerce was installed:
“Geolocate Address”

I changed it to “Shop Base Address” and it didn’t make any difference.

I can’t figure out how to test if geolocation is working.

OK, so if the default customer address = shop base address = Location: US – Washington, (NB no zip code setting for the shop base address), then is there a catch-all zip codes wild card line in the Tax standard rates table? I think this has to be on the last line.

Out of interest, does tax vary by zip code in WA?

I turned the geolocation off for now.

I don’t think that setting has anything to do when the customer is logged in with their account and an address is set up, though. We don’t have guest checkouts enabled, so the address that shows up in the cart should be the address that is used for the tax calculation. Somehow, the system does not seem to be identifying the zip code of the customer properly or something. The tax does get calculated properly on the shipping (we’re using the WooCommerce Table Rate Shipping plugin – I’ve disabled it and it still doesn’t calculate the tax on the Product).

I’ve tried disabling some other plugins that MAY have something to do with the checkout, but nothing has changed as far as the Product tax calculation goes – it just doesn’t do it.

The tax rate does vary by zip in WA – it’s a pretty large list with 698 entries!

Did you try a catch all line in the Standard rates table:
* * * * 20.000
If this works and does show tax it would confirm that the customer’s address is not being recognized.

You might also have a look at the usermeta database table. For your test user, are the shipping_zip / state / country correctly set?

I’ll try the catch all line tomorrow.

I had a quick look at the usermeta table and the fields shipping_postcode / shipping_state / shipping_country are all populated with the proper data. I didn’t see a “shipping_zip” field though. Is that what it’s supposed to be?

Thanks for your help so far… to be continued tomorrow.

Sorry: shipping_postcode.

So I tried the catchall line and it didn’t change anything at all. It still only calculates the tax on the Shipping. It completely ignores the tax calculation on the product.

Any other ideas?

I think your cache plugin is behind this. With something in the cart, no tax is shown. But change the cart url to:
https://www.alvanequip.com/cart/?x=99
where x doesn’t matter except it forces a proper page refresh, then tax is shown. Does your cache plugin allow you to exclude the cart page from caching?

OK, I think you may be right. I’m using W3 Total cache and I remember excluding those pages from the caching during setup. However, they have put a notice that as of WC 1.4.2+, that it sets the DONOTCACHEPAGE for those pages.

We did recently change hosts and they have another optimized caching plugin for their setup that was installed at the time. I didn’t think to check to exclude the cart, checkout and account pages at the time. I’ve excluded them now.

I’m going to do some more testing because right now the tax is showing properly in Chrome, but not Firefox… argggh.

Anyways, I’ll continue pursuing this avenue and see if that fixes it and let you know tomorrow.

OK, well, I thought I’d post my results here after a completely crazy journey this past week.

After our discussions here, and after some further testing, it turned out that the problem wasn’t related to any type of caching issues, because it continued to exhibit the same problems (even though it looked at first like this was causing the problems).

Being at the end of my rope, I decided to hire an Elancer to have a look and see if they could find the problem. Well, after a few days of trying different things I think we have found what the original problem was.

At first it looked like there was an issue with the products missing a custom field “total_sales” meta data, that Woocommerce seems to use/create if you click on “Update” for a product (without changing anything else about the product). So I created that field for all the products and filled it with the default value of “0”. However, on further extensive testing, it turned out that didn’t have anything to do with it.

Next, it looked like there was a problem with the “Tax class” field which appeared to be set to Standard for all the products. However, it somehow wasn’t “assigned” to the product. I used the “Woocommerce CSV Import” plugin by Mensonides (using the purchased Add-ons) to import all of our products from a CSV and I had set one of the field headers “tax_class” and filled all of the products with the value “standard”. This appears to have been my mistake. I should have left the field empty, because the document mentions that you can use the field IF you have any additional tax classes (but doesn’t mention to keep it blank if you don’t). Somehow if you fill this field on the import it completely messes up the tax calculation and the tax won’t get calculated on the product (tax on shippoing still works, though because that’s a separate calculation.

I could fix the problem by going into each product individually and clicking on “Update” and that would get the tax calculating properly on the product by somehow setting the proper association. However, I fixed the whole database of products by using the “Woocommerce Advanced Bulk Edit” by George Iron and resetting the Tax Class field for all products. I’ve been doing some more extensive testing and this seems to have fixed the problem now.

This has been a very time-consuming and difficult task to pinpoint what the problem was and I sure hope this doesn’t happen to anyone else. Hopefully this can help someone if they run into the same problem!

Bottom line is if you’re using the “Woocommerce CSV Import” plugin by Mensonides, make sure to leave the “tax_class” header field out unless you’ve set up some additional tax classes.