Plugin doesn’t seem to work

In the settings page, you should enter the VAT number without the country prefix. The plugin will add it automatically. It should add them only once, though. We haven’t received reports of the prefix being added twice, I will ask to check that part.

Regarding the validation, if the requester VAT number is not saved, most likely it’s because it could not be validated. A response of “null” indicates that the VIES service didn’t send a response or could not be reached. If the requests are not sent, then most likely some server settings are stopping them. If the requests are sent, but blocked by VIES. the VIES support team should be able to check why.

Once you know where the block is, it will be easier to fix it.

I think it’s blocked on the server.
Are there any specific services or ports used for the connection?
And can u also mention what domain/ip it’s trying to connect to?

Thanks in advance

The URL of the service is https://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl. The port is the standard HTTP port 80.

whitelisting their ip doesn’t change anything.

The weird thing is also that every setting change i try todo from the admin won’t get saved.

Any other suggestions?

This is the only plugin that does this

We’re still looking into the issue of the settings not being saved, but I believe that it’s connected to the failing validation. When you save the settings, the requester VAT number needs to be validated using the VIES service. If that call throws an error, then that could affect the saving of other settings.

The difficulty is that we can’t reproduce the issue on any of our test systems. The call to the VIES system is correct and it works fine on all of them (each call returns a response).

One thing you could do would be enabling the debug mode in the plugin and attempt a validation. That should generate a log entry saying something like “VAT number validation complete”. That log should contain the raw response returned by the VIES service, which could help finding out what the issue could be.
A cross-check could be performed by cloning the whole site on another server, separate and independent from the one you’re using at the moment, and see how that goes.

Technical information
The call to the VIES service is performed using a 3rd party library, called nusoap. It’s initialised by taking the WSDL from https://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl, then the client makes the call. We don’t control how, exactly, the call is made, or how the server should be configured for that to work.

Have you managed to fix this? I ran into this as well and could not get it fixed (have reported it here too)

@drksecret if you’re experiencing the same issue, the recommendation would be to check with your hosting provider if the calls to the VIES service go through. As indicated above, a response of null means that either the call failed because the server where the site runs blocked it, or it was rejected by the VIES service.

Unfortunately, both cases are outside the control of the plugin, hence the need to check with the hosting provider and the VIES support team.

Hi There,

I’m trying to figure this VIES problem afor over 2 months now on a pre-production site, but can’t get it working either.

The support answer to enable the Debig mode is quit funny, because (as has been written by rm04 (@rm04) in the initial support request) The plugin doesn’t save anything when the VAT numer is not verrified by VIES.

I’m running our site from a DPS that’s totaly controlled by us and can’t find the wrong execution of the VIES request because of server limitations.

René

@longwise as of today, we haven’t been able to reproduce the issue on any of our test sites. In all our tests, the validation request is sent correctly and, when the VAT number is valid, it’s saved along all other settings. This worked on brand new sites (clean, nothing else installed) as well as more “complicated” ones, with dozens of other plugins active.

We’re still trying to find the cause of this issue. It would be easier if we could reproduce it consistently, but that’s not the case.

In the meantime, one of our clients informed us of a workaround that worked for them. They saved the settings once, without the requester VAT number, then entered the number after the page loaded, and saved the settings again.

This is not ideal, because all the settings should be saved correctly the first time, but, since it’s a once-off operation, it can be used to get started, while we keep investigating.

As a further note, if someone has a staging site on which the issue can be reproduced consistently, we would be happy to have a look. That could considerably speed up the investigation and solution. Thanks. ??

@daigo75

Same problem here ??

When I enter VAT number from the requester WITHOUT countrycode, it returns fail.
if I add countrycode BE, it fails too
if I try a second time, it returns failed for BEBExxxxxxx

Your plugin duplicates the countrycode

The plugin was working fine for 3+ years on most of my client websites, and now since ~3 or 4 weeks I think it’s problems all over the place with VAT validation.
Agree, if the VIES service fails, it’s not your plugin fault. I notice they have big issues since some time.

But still, I think some items might be plugin related.
When I see that simply saving the options page already fails and the plugin is acting weird with double country codes…. I wonder if that problem is related to any of the validations in the checkout.
Perhaps it fails VAT number not because of the customer his VAT ID but due to the requester VAT? Since saving the options already returns this error, I can only assume it also runs into same problem during a checkout.

Is there an option to disable VIES validation in the checkout? But not hide the field or anything. I still want customers to be able to enter the VAT ID so merchant can validate it manually at some point but still remove the VAT from the order total.
If the customer his VAT was already validated 6 months ago, I don’t see the point why it needs to be validated for every single order, every day, over and over.
Because now, we only get angry, frustrated clients because they loose turnover due to VAT validation problems.
And the plugin is not flexible to allow us to disable the validation service while keeping the fields in place.

Any thoughts Diego on how to get this back working stable or at least have a workaround option from the plugin settings so my clients can enable/disable some thing themselves fast when service issues with VIES?
Working with code changes and snippets is not possible at those moments, my clients must be able to tick a box themselves immediately if they notice issues with VIES.

Thanks.

@7grafix
Although I understand the logic behind the reasoning, the conclusion is slightly incorrect. I can confirm that the VAT number validation logic is sound and works as it always did. Nothing has changed in that validation, in a long time. It didn’t “break” recently, and there are no “problems all over the place”.
I would also add that we originally developed this solution for internal use, and we have been running it ourselves since its first release. We made it available to the public for the simple reason that we wanted to offer a cheap solution to an issue introduced by the tricky VAT MOSS regulations. If the EU VAT Assistant had a critical feature, such as the VAT number validation, broken, we would be the first ones interested in fixing it, as it would affect us before anyone else.

That’s just to clarify that the EU VAT Assistant is still reliable, and there aren’t validation issues “all over the place”.

As of today, the glitch we are dealing with is with the validation of the requester VAT number on the settings page.

To reiterate what I wrote last time, we haven’t found a way to reproduce the issue with the validation of the requester VAT number. I personally tried on a dozen different setups, and it worked right away. As I suggested in my last reply, if someone can give temporary access to a staging site where the glitch occurs, that can greatly speed up the troubleshooting. If you have a site where the glitch is currently occurring, that could be a good place to investigate and get to the bottom of the issue. Otherwise, it’s going to be trial and error until we can finally find the actual root cause.

Troubleshooting VAT validation at checkout
The requester VAT number is not saved when it’s not validated. When it’s not saved, it can’t be sent during the checkout validation, either. Due to that, it’s unlikely that it could be the cause of the validation at checkout.

It’s not necessary to make assumptions or speculations about the reasons for a failed validation at checkout. When the debug option is enabled (you can save the settings without a requester VAT number, if that keeps throwing an error), the validation logic logs every step of the process, showing what data is sent and what data is returned. That can show the exact cause of a validation error, making it easier to solve it.

Disabling the VAT number validation
I don’t think that allowing to disable the VAT number validation is not necessarily a good idea. The EU VAT Assistant caches the result of a successful validation for 24 hours. However, storing it for months would be incorrect. Companies can shut down or go bust at any time, and assuming that a VAT number is still valid after months is risky. I came across several instances where a Revenue Office raised objections about the validity of a number used just a week earlier. It turned out that the number was valid at the time, but the company de-registered a few days later the purchase, making the same number invalid from that moment on.
The bottom line is that the VAT number must be validated “over and over”, to ensure compliance with the regulations.

I don’t see a “skip validation” option as being very useful either, as it would defeat the purpose of having the validation in the first place. The idea behind the validation logic is to apply an exemption only when it’s absolutely certain that it should be applied. If one starts making exceptions, such as:
– Skip the validation entirely.
– Validate the number, but take it as valid anyway if the error is X, Y, or Z.
– Assume that a number that was valid months ago is still valid today.

That means taking a significant risk. It’s possibly to do so with fairly simple custom code, but I don’t think it’s a good idea to give an easy option to merchants. In my opinion, enabling a “skip validation” option carelessly, or forgetting it enabled, could lead to tax compliance issues.

We’re aware that having to enable or disable custom code is not as easy as ticking an option (although it can be as easy as wrapping it into a mini-plugin and enabling it), but it’s safer. Tax compliance is a serious matter, but not every merchant has a competent tax consultant, or an agency, to help them. We don’t to “facilitate” serious mistakes that could expose merchants to tax compliance investigations.

@7grafix
One more note, to speed things up. Since it’s not the best idea to share the details of test sites here, you can use our contact form to access our support portal: https://aelia.co/contact. I left a note so that the request will go through, even if that portal is normally used only for premium services.

@longwise, @7grafix @rm04 I’m following a step-by-step debug process, from the top to the bottom of the validation process, to find the source of the issue with the validation of the requester number. If you would like to help by running a quick test and send us some feedback, that could help greatly. As before, you can use our contact form to get in touch: https://aelia.co/contact. Thanks.

@longwise, @7grafix @rm04, @drksecret Sorry if it sounds like an odd question: did any of you encounter the validation error after entering a requester OR customer VAT number from Belgium or the Netherlands? I might have spotted a pattern, and I’m trying to verify if it’s the right track.