VAT tax code for EU countries

[Guest]

Hi,

My UK based client has just highlighted that "VAT is due on all sales to the public in EU countries."

However in BC Tax Codes, as far as I can work out, tax codes are only applicable by country that you have a domain setup for. That means that on a standard UK domain setup I can't setup a single VAT Tax Code for EU countries, only for the UK.

Does anyone know a way of assigning a tax code to multiple countries without having to buy and setup a domain for each country??? (there are 27 in the EU!!)

[tmikaeld]

1. Add every country you want to apply VAT to as a subdomain.
2. Add the Tax Codes for every country
3. Change the shipping module to: {tag_shippingoptions,true,false}

[FraserMcCulloch]

In the following video, I demonstrate how we created a web app for selling digital products which took into account VAT rules for EU countries.

If Adobe developers got in touch with us, we would be more than willing to give them our code to implement this solution for the e-commerce module.

http://www.platonik.co.uk/platonik-blog/how-to-sell-digital-reports-online-to-differently-taxed-coun...

[Luc_Laurent]

Your web app would be a great short cut. For information, the official position about VAT integration is:

Hi Luc,

as explained in our previous post we did take note of your requests, but unfortunately these features are not a priority on the list for the beginning of 2014. I cannot comment on later plans, but will keep you updated in case they make the list for a future release.

Magda Neagu (Adobe Business Catalyst Support) - Jan 27 11:38

I guess the more pressure the partners put, the sooner BC engineering and product development will react. (I was told to be the first one ever asking to settle the VAT implementation...)

[Eworks-WSI]

Luc,

you are certainly not the first asking to have this issue settled.

Mario confirmed already on July 5th 2012 that he submitted a ticket to the development team concerning this issue. The problem is  known for 2 years but totally ignored by BC.

During the last townhall meeting it was mentioned that partners should move more sites to BC to support the platform, but how can they expect us doing so if the basics are wrong and, more importantly, these issues are not corrected for years.

[klara78]

Hi, thank you for all the answers.

My solution looks now like this:

For Germany and Austria, where the Shop charges no shipping fees, I hide the whole {tag_shippingoptions}. It shows the VAT on the prices. Perfect.

VAT EU-COUNTRIES

Then there was the problem with the EU-Countries that should show VAT, but every country has a different shipping fee and if selected, the VAT (19% Mwst) on the prices disappears. So I've got the option above to make a subdomain for every country, define the VAT and shipping and at some stage the customer has to choose the country. But to define 17 subdomains however seems a very complicated solution for such a common request. So I decided to make one subdomain (ES) for all European countries, what I can do, when I offer only one shipping fee. So I have two flags at my site German and EU, and user can choose between, with EU he gets the ES-shopping-cart with VAT and one shipping fee for all.(www.flex-sport-samy.de)

Not the best solution, but its working now.

Luc: I was also very disappointed of the list for future releases. I think they don't care about european Partners. I've asked the support several times with the VAT question, but....no solution in sight....

INVOICE-EMAIL

There is another problem, that's not compliant with EU E-Commerce-rules. When a customer makes an order he should get an order receipt per Email, but not the Invoice. BC sends an automatic-Invoice-Email to the customer. Does anybody know how to prevent this?

I could change the system invoice email to an order receipt, but then I loose the invoice, I need to print out with the order. Is there any solution out there?

[klara78]

Hi eworks,

I love this suggestion:

{tag_shippingoptions,true,false,CY;US;CA;DK 19;ES 19;IE 19;FR 20;RU;UA;CN,false,false}

That would be a great solution. Anyone of BC is looking/listening?

[Eworks-WSI]

Hi Klara,

I am glad that you found a workaround for your site. I supose that overall you are not exceeding the yearly export volumes per EU country, since in that case you'd need to apply the receiving EU countire's VAT and BC does not cater for this.

From what I saw, you site has a limited number of products on it, so it is managable manually. Some of our clients have several thousands of products (i.e. http://survivalbuddies.com with approx 3000, http://laboitealire.com with 7000, etc) and it'll not be working for them.

We are facing today the following problems:

- one of our clients had a tax inspection and got fined for disregarging the EU VAT rules on his BC site, 

- another one moved to a different system that handles the VAT parameters very easily,

- in Cyprus the Chamber od Commerce or some government schemes subsidize SMBs when they create e-commerce sites under the consition that the proposed e-commerce system respects loacl and EU rules.

Consequence: We do not propose BC anymore to local businesses that intend to do EU wide e-commerce as we just would be blacklisted.

It is a shame that Adobe is just ignoring this issue (that's on the table for years now), but I think there's no European Partner on the PAB, and more importantly, the decisions of the current BC priorities seem to be taken to favoir the members of the PAB and their personal businesses and not the entire BC community. Adobe BC will be history in Europe if they don't get the basics (what they call the core) right (I mean up to level with other programs) and compliant. It is very surprising as the BC is European, they should understnd the implications better.

Hartmut

[tmikaeld]

It have been mentioned that e-commerce will be a part of webapps with advanced modules for purchasing webapps, but since BC Open Platform was introduced, i am unsure where this stands now as Adobe is very quiet about it.

Other e-commerce systems in europe solve multi-language and multi-currency by introducing taxonomy and grouping of fields/pages.

"Quick" fix suggestion:

- Fields with multiple languages (Description, title, seo etc) could be tabs and output as layout tags in the templates.
This is already the default for many shop layout templates (shipping_cart-DE.html , shipping_cart-GB.html etc), it would only make sense to follow the pattern!

- Multi-currency is already in place in the system, but having multiple products for each language makes it completely unmanageable, the above solution would solve that.

- VAT works well if setup lf setup for every country that should charge any tax, just like for US states.
For countries this is done by adding a subdomain for each contry and adding all countries that should charge VAT tax to the tax codes.

Then in the cart, we just use this shipping options tag:
{tag_shippingoptions,true,false,AT;BE;BG;DK;EE;FI;FR;DE;HU;IS;IE;IT;LV;LI;LT;LU;NO;PL;PT;RO;RS;SI;ES;SE;CH;GB}
The above is for EU Members + Nordic countries as an example.

Example admin choice of language:

[tmikaeld]

It's also possible using javascript to automatically choose VAT based on the selected country in the cart, so it is transparent to the visitor.

[FraserMcCulloch]

One thing you are all missing, how would BC validate the VAT number of the business ?

If I am based in France and I sell to a VAT registered business in Germany, VAT will only be deducted if the business owner in Germany can validate his VAT number with the website/purchase.

Magento do it, Shopify doesn't

http://www.magentocommerce.com/magento-connect/eu-vat-enhanced.html

[tmikaeld]

We validate VAT via the API, the VAT Number is copied to a custom field in the checkout.
Then when BC notify our bridge - we check the VAT and set the value if it is correct or not.

[FraserMcCulloch]

So your API is checking the VAT number against the European VAT Information Exchange System so businesses aren't entering bogus VAT numbers?

http://ec.europa.eu/taxation_customs/vies/

[tmikaeld]

Yes, there is a free API you can use here: http://isvat.appspot.com

Although, there are more services out there that also check blacklisted companies but they cost a bit.

[FraserMcCulloch]

ok, cool. So basically a solution is being hacked together but BC don't see this or EU partners as priority !

thanks for your wisdom on this tmikaeld, appreciated

[tmikaeld]

I'm quite sure that e-commerce in general is a priority - it is a huge market after all, Adobe's problem for quite a while is the legacy code-base.
But it's now been removed, so they should be able to focus on the future.

You are welcome, i wish i could be more involved with the BC community but all the work is hampering the time i can commit.

[tmikaeld]

If you wan't to do this in the Cart however - it is a quite complicated process, we do this for factoring systems already and thus choose the right shipping choice for the client transparently. The process is - the fields get filled in and a JSON request is passed to a server that does the check and then returns the answer. Of course, this should always be validated in the backend since the form can be manipulated.

[FraserMcCulloch]

As everyone on this thread has been saying for years, BC should provide this out of the box if they were being helpful to partners and clients.

[tmikaeld]

Yes, i pointed this out in 2009 and many many times since then.

Let's just hope this will be a year of great change for the better, sure seems like it.

[Eworks-WSI]

Hi tmikaeld,

This could be a good workaround but we have tried this approach with several developers and it seems that you can't target the corresponding elements (in the shopping cart they are only part of the class 'productitemcell') and even if their content is modified, the modification is not taken over to the payment module.

If you have found a different solution, we would be happy if you could share your ideas.

Thanks in advance 

[tmikaeld]

Eworks-WSI wrote:

Hi tmikaeld,

This could be a good workaround but we have tried this approach with several developers and it seems that you can't target the corresponding elements (in the shopping cart they are only part of the class 'productitemcell') and even if their content is modified, the modification is not taken over to the payment module.

If you have found a different solution, we would be happy if you could share your ideas.

Thanks in advance 

The changes are not that easy, we have +800 lines of jQuery and have made the following changes:

• We monkeypatch the current javascript functions so that our functions are re-run after any ajax update is executed (Easy to make loops by mistake here).
• We have one-page checkout by having the checkout form on the cart page that save input field data to cookies or localstorage if available, so that we can re-fill input fields after any cart changes.
• The checkout form had to be on the cart because we integrate factoring via JSON API to our bridge, so in the cart we can set the corresponding costs associated with factoring when the visitor chooses to pay with it.
• We added some hacks to HTTPS enable the cart since we don't want to post anything unencrypted (HTTPS is also required for sending url parameters to the checkout page)
• On the checkout page we have the same form as in the cart and then fill it in from cookie values and validate it a second time.
• When the form is sent, we clear the cookies that have sensitive information - the rest is saved for when the client wan't to make their next order.

[Eworks-WSI]

I like the idea Ref - VAT works well if setup lf setup for every country that should charge any tax, just like for US states.

This would work well if BC finally (proposed a few years ago) consented to set up a country (for e-commerce purposes only ) called 'EU' that can be configured in the same way as the country 'US' and would allow us to define tax rates per shipping EU country.

And as an added bonus the ridiculous 'shipping state' dropdown (that you can't get switch off today) would make sense for EU sites.

Attn BC: Please add the entity 'EU', just replicate the 'US' with the European + Nordic member countries: no programming required, a solution right out of the box (as BC!)

Cheers

[Eworks-WSI]

It looks like the {tag_shippingoptions} is not available anymore through the 'Toolbox / Data' tab under Module templates / Online shop / shopping cart.

Perhpas a sign that BC may be working on it, I remain optimistic.....

[Eworks-WSI]

The last sentecne should read:

It is very surprising as the BC developer team is Europe based, they should understand these implications better.