VAT Module issues

[haylau]

I have had this issue before but forgot. I have updated the VAT module to latest release and there is a bug that has been there in previous releases also

I am not sure how widespread this is, but it is definitly an issue for UK based sellers with ES VAT business customers

When entering the ES (Spanish) VAT number we get an invalid number message

The problem is in vatnumber.php

 

Line 228 is

 $url = 'http://ec.europa.eu/taxation_customs/vies/viesquer.do?ms='.urlencode($prefix).'&iso='.urlencode($prefix).'&vat='.urlencode($vat);

I think this is an old PS issue also as I found the solution on the PS forum (http://forge.prestashop.com/browse/NM-824)

Changing that line to

 $url = 'http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode='.urlencode($prefix).'&number='.$vat.'&traderName=';

Makes the VAt number valid

Edited March 6, 2019 by haylau

[Traumflug]

Thanks for the heads up. Here's a preview version with this fix applied (which will go into v2.2.1 of this module):

vatnumber-master.zip

[haylau]

1 hour ago, Traumflug said:

Thanks for the heads up. Here's a preview version with this fix applied (which will go into v2.2.1 of this module):

vatnumber-master.zip

Thanks, I will test later

[haylau]

9 hours ago, Traumflug said:

Thanks for the heads up. Here's a preview version with this fix applied (which will go into v2.2.1 of this module):

vatnumber-master.zip

Did you only change that line or are there other changes? 

Why? Because it crashed my site with the dreaded 500 error. I tried a couple of times (upload from back office, and manual via ftp), so uninstalled for now and reverted back

[Traumflug]

Shame on me. Yes, I changed only this one line, but didn't set up the module for testing.

Error log (log/20190307_exception.log) should show the error.

[Traumflug]

Ha ha, my tools caught me. Copying this code here from the forum into the code editor also copied a Zero Width No-Break Space. Zero width means invisible, neither the code editor nor Gitk would show it. But good old vi on the command line did:

Anyways, here's a fixed version:

vatnumber-2019-03-08.zip

Tested for basic functionality, this time.

[DRMasterChief]

good old vi - tell this our generation smartphone  

sorry for ot

Edited March 8, 2019 by DRMasterChief

[haylau]

Still does  not work

$url = 'http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode='.urlencode($prefix).'&number='.$vat.'&traderName=';

 

I think the tradername part is missing?

 

[Traumflug]

Using the code from above, the traderName field is always empty, so it shouldn't matter. As this URL loads an ordinary HTML page, one can try in the browser:

http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=DE&number=171017618

http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=DE&number=171017618&traderName=

This VAT ID is my own, so it should be valid. However, the HTML page reads "Member State service unavailable. Please re-submit your request later." ... which the module recognizes as an invalid ID report.

[haylau]

I understand, it should work. But it does not without the tradename. Remember by initial post - it affected the spanish VAT number (ES)

 

Try these

 

http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=ES&number=B63622740&traderName=
http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=ES&number=B63622740

[Traumflug]

Hah, they're good at fooling developers 🙂 And thanks for your patience and testing.

Here's a third version, tested with this Spanish VAT ID as well:

vatnumber-2019-03-10.zip

[haylau]

I fear there is a deeper issue. ES numbers work, and IT numbers, and others But DE numbers do not. In fact your VAT number does not work on the VIES website at all

[Traumflug]

"Does not work", like this?

(I just clicked the link above)

This is starting to become a head scratcher. I also tried from the thirty bees server (which is located in Germany):

$ curl 'http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=DE&number=17101aderName=' | grep -i 'valid VAT number'  
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current  
                                 Dload  Upload   Total   Spent    Left  Speed  
100 13423    0 13423    0     0  50469      0 --:--:-- --:--:-- --:--:-- 50652  
                       <b><span class="validStyle">Yes, valid VAT number</span></b>

I'll also ask @lesley, he's outside the EC.

[haylau]

Really weird. Every thing now works. 

Last night I tried at least half a dozen Germany VAT codes that did not work. Now they do. 

Hmmmm

Anyway, all looks good at the moment. I will do some random checks over the next few days. Perhaps it is more a random VIES issue that the module

[lesley]

They all seemed to work for me, using the urls provided, except this one, http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=ES&number=B63622740

 

I wonder if the trader name argument has to be passed even if it is blank. 

[Traumflug]

Thanks for testing. Yes, Spanish VAT IDs need this blank trader name.

[Traumflug]

They indeed simply turn off this service without notice. Seeing all the trouble here I started implementing this request using the recommended SOAP protocol. Up to around 10:00PM the service worked just fine. Since then it just reports "Member state service unavailable". And it's not back online 2 hours later, at 00:15AM.

Welcome to the Internet, European Community!

Good news: the SOAP response can distinguish between a VAT number found to be invalid and a service not working.

Now I wonder what to do with a missing service response. Slapping this into the customer's face likely means a lost sale, as he can't get past this without accepting to pay VAT. Maybe the module should accept the number, but also send an email to the merchant, notifying him about the VAT number being unverified.

[haylau]

Anything to minimise disruption to the buyer - I agree. I almost lost a long standing customer because of this. So yes, I think an email to merchant. But also, if possible, change the order status to "Check VAT" or something similar?

[Traumflug]

Changing order status would get tricky, because a VAT number isn't part of an order, but part of an address. A customer can add an address without also doing an order.

Anyways, this snapshot of the improved module should explain how it works now:

And here's yet another preview, which has this implemented:

vatnumber-2019-03-13.zip

[haylau]

Thanks. I have installed that and will monitor progress. 

[RabbitZzZ]

Hi, 
I'm using this old thread to report that something doesn't seem to work right anymore with the module.
In one shop taxes were deduced from customers that have random stuff in the VAT ID address field and then I saw those errors in the logs:

VAT number [xxxx] could not get validated due to a validation web service outage (Server error: `POST http://ec.europa.eu/taxation_customs/vies/services/checkVatService` resulted in a `500 Internal Server Error` response: Error 500--Internal Server Error

Maybe the module can be updated as described here:
https://stackoverflow.com/questions/73443655/why-does-this-vat-number-validation-script-return-an-error

Cheers!

[e-com]

I have been doing tests of this EU VIES server using SoapClient.
This server is one big tragedy.
For some countries it sometimes returns a response and sometimes returns an error.
For some countries response times of more than 10 seconds.
It is better to disable this validation service in module, because it is not suitable for stores.

[RabbitZzZ]

Is there another suitable solution for the European VAT regulation? Maybe even with manual validation?

[datakick]

Indeed vies server is very unreliable. It often reply with transient error responses (like too many requests, try later), and sometimes with hard errors when their server just crashes. Current tb module handles these situation silently, with only a log entry inside Logs messages. Which can very easily lead to wrong taxes being applied and collected.

What we want to do is extend current module, and implement retry mechanism. Basically, when we fail to validate VAT number during checkout (caused by server issue), we would move the order into some special order status (like Pending VAT number validation), and try later. Module would try to validate missing VAT numbers on regular basis, and switch order to either 'VAT Validation Failed' status, or to normal status like 'Payment Accepted' or 'Awaiting Bank Wire Transfer'. Employee would have to manually handle the 'VAT Validation Failed' situation -- adjust order, and optionally request payment for missing VAT amount.

That's the plan. Now we need the time 🙂

[e-com]

2 hours ago, RabbitZzZ said:

Is there another suitable solution for the European VAT regulation? Maybe even with manual validation?

All stores have automatic validation disabled and for new customers they do manual validation:
https://ec.europa.eu/taxation_customs/vies/#/vat-validation
Manual validation is also Russian roulette 🙂 Sometimes you have to click several times before you get validation. Especially for Germany it is tragic.

[datakick]

New version of vatnumber module was released. The validation check now works again using SoapClient. You have to make sure that you have 'soap' extension installed and enabled in your php server.

There is also new tool in module configuration page to check if the validation works.