VAT not included in order total

In further debugging - I added a drupal_set_message to check if it ever found a tax lineitem in uc_vat_line_item_tax - and it only finds the fee lineitem (handling).

I think they are. I didn't notice it right away, so I might have "done something else" - but I don't know what.

The "odd" thing is that the items in the cart (and on the site) is shown with VAT added - and it also is in the line_item with the product.

I don't see any way that I could configure it to NOT include the VAT in the total - but still have VAT added to the product price - that would simply not make sense (as you can see the total is all wrong) - so I must have hit a bug somehow, so that it does this, which it should IMHO never do.

If you could hint me as to where it figures out if it needs to add the VAT line_item - because I think that's what's missing.

I found the problem (with help from longwave) - uc_vat didn't properly handle conditional actions, based on delivery_country - so it didn't add VAT in the checkout - when delivery_country wasn't set yet.

I've attached a patch, which fixes this, by setting a default country code (currently 208 - denmark) - we should add an option somewhere to select default country - perhaps in the countries list - or perhaps just as simple as a text field in VAT admin.

The patch also adds a uc_vat.ca.inc - which has the condition of determining if the delivery_country is inside EU (as of 2010).

This makes it a lot easier to setup a shop which is located in the EU - and has customers outside of the EU.

The patch also includes my i18 fixes from earlier, where I send variables to t() which is "frowned upon" - but as I can't find an "official" solution as to how to translate user-entered text - I see no other way. it works like a charm for me.

I'll be adding support for ip2cc ( to automaticly set the visitors country - and thus automaticly figureing out if they should be shown prices with or without VAT) later today - and will gladly add support for other ip->country modules - if asked.

I added ip2cc support - and set default country to '208' if the IP is within RFC1918 range (ie. local - invalid internet address).

AFAIK vat is applied, based on the delivery country - not on the billing country. So to calculate if the price needs to have VAT applied - you may ONLY use the delivery country.

I have written a patch (based on others work, with a config option added) for ubercart - which automaticly checks "billing adress is same as delivery address) checkbox - so I don't bother 99% of my customers with having to check this :)

http://www.ubercart.org/project_issue/added_option_check_billing_address... - so perhaps I just see the problem because of that? AFAIK billing address will be set to same default country in checkout as delivery address is.

I'm not quite sure, why there would need to be a module, to use a module? Especially when it only seems to waste lines.

The implementation of ip2cc in uc_vat is at max 10 lines - I see no benefit of putting that in a module.

If it's the ip RFC1918 test part - then that is probably already handled in ip2cc - I just didn't check how they did it - and if they don't - it should probably still be handled ip2cc - so uc_vat (and other users of ip2cc) know when an "invalid" ip for country lookup was used - so they can decide to use whatever they want (like uc_store_country ).

But that's just my 2 cents :)

I see what you mean. This requires there's some default place to set it, before an order object is created.. - where all modules happen to look. Or that you create a global order object immediately - if thats how it's "supposed" to be done.

the shipping quote "blob" could use it as well.