Class Dutchento\Vatfallback\Console\Command\Validate does not exist
while installing
on M2 2.2.2
Any ideas on what might be wrong?

Add feature to change the customer group based on successful validation of the VAT number

All API calls fail while Vatfallback is active

The error:
"message": "Class "array" does not exist. Please note that namespace must be specified.",
The Fix:

--- a/app/code/Dutchento/Vatfallback/Api/CompanyLookupInterface.php
+++ b/app/code/Dutchento/Vatfallback/Api/CompanyLookupInterface.php
@@ -20,7 +20,7 @@ interface CompanyLookupInterface
      *
      * @api
      * @param string $vatNumber vatnumber
-     * @return array Company data
+     * @return string[] Company data
      */
     public function byVatnumber(string $vatNumber): array;
 }

Seems like http://ec.europa.eu/taxation_customs/vies/viesquer.do does not exist anymore. If you go to

https://ec.europa.eu/taxation_customs/vies/#/vat-validation

A form can be seen which will post to

https://ec.europa.eu/taxation_customs/vies/rest-api/ms//vat/?requesterMemberStateCode=&requesterNumber=

Could you check if the module must be updated for this.

Upgrading a shop from 2.4.3 to 2.4.4 (yes, I know it is late) and m2_vatfallback from 1.6.4 to ^2.0 I get the following error:
unexpected ')', expecting variable (T_VARIABLE) upon setup:upgrade.

Since I've seen the error before I just had to find out in what extension (added an echo to composer...ClassLoader) and found your great module. So what is the issue?

In Dutchento\Vatfallback\Service\Validate\Vies it is the contruct:

public function __construct(
        ConfigurationInterface $configuration,
        Client                 $client, <------------------------ has a comma
    ) {
        $this->configuration = $configuration;
        $this->client        = $client;
    }

Not sure why Composer makes such a big deal of it but there you go.
Next up is Dutchento\Vatfallback\Service\Vies\Client with the following construct:

public function getViesResponse(
        string $countryIso,
        string $vatNumber,
        int    $timeout = 1,   <------------- has a comma
    ): mixed {

I guess there may have been a line below both comma's and the comma's were just left behind...

Thanks though, for this great module, it is a total live saver :-)

Heya,
The validation methods are currently wrong, because validation has 3 possible results in stead of just the "VALID" and "INVALID".
After all, a validation endpoint can be offline or unavailable/unreachable, in which case the validation result should be IGNORED.
And not cause an erroneous INVALID.

This can be reproduced quite easily: Dont configure VATLAYER + Disable VIES; and voila: you will always receive the message that the VAT number is invalid, from VatLayer; After all, VATLAYER is disabled OR has no API key, so that method will ALWAYS return INVALID.

Finally, shouldn't we validate a VAT number like this?:

1.) Validate Regex (and remember result)

(1) Regex says valid? -> Validate via 2.) VIES
(1) Regex cannot validate? -> Validate via 2.) VIES (and remember as INVALID)
(1) returns FALSE? -> VAT number invalid

(2) Returns valid? -> VAT is valid
(2) Returns invalid? -> VAT number invalid
(2) Returns unknown? -> validate using 3.) VatLayer

(3) Returns valid? -> VAT Valid
(3) Returns invalid? -> VAT invalid
(3) Returns unknown? -> use result of step (1) if valid, otherwise return INVALID
...Or do we have no guarantee that all valid VAT numbers will at least pass Regex validation?

Hi, I get always No validation took place. Where is my issue?
Also with your example bin/magento vat:validate NL NL133001477B01

Heya,
Considering how the VIES service requires a VAT number to be supplied WITHOUT country code and this module's method, the current implementation is broken. After all, it FORCES the countrycode to be appended to the VAT number.
The following are the required changes for me to get it to return a VALID on a VALID VAT number:

diff -urw ../vendor/dutchento/m2-vatfallback/Service/Validate/Vies.php vendor/dutchento/m2-vatfallback/Service/Validate/Vies.php
--- ../vendor/dutchento/m2-vatfallback/Service/Validate/Vies.php        2018-12-23 10:51:46.000000000 +0100
+++ vendor/dutchento/m2-vatfallback/Service/Validate/Vies.php   2019-01-22 15:38:43.213693882 +0100
@@ -62,7 +62,7 @@
                 'query' => [
                     'ms' => $countryIso2,
                     'iso' => $countryIso2,
-                    'vat' => $countryIso2 . $vatNumber,
+                    'vat' => $vatNumber,
                     'requesterMs' => $this->getMerchantCountryCode(),
                     'requesterIso' => $this->getMerchantCountryCode(),
                     'requesterVat' => $this->getMerchantVatNumber(),
@@ -73,6 +73,8 @@
             throw new FailedValidationException("HTTP error {$error->getMessage()}");
         }
 
+	$responseBody = $response->getBody()->getContents();
+
         // did we get a valid statuscode
         if ($response->getStatusCode() > 299) {
             throw new FailedValidationException(
@@ -82,7 +84,7 @@
         }
 
         // body of API contains a valid flag
-        return (false !== strpos($response->getBody()->getContents(), 'Yes, valid VAT number'));
+        return (false !== strpos($responseBody, 'Yes, valid VAT number'));
     }
 
     /**

Note: strpos() also always returned FALSE on getContents(), so I had to first put the value into a variable.

The following line is completely broken, referencing a variable object that does not exist:

From this, I can deduct that the entire method stripAndValidatePattern does not work, which again leads to the method convert of the same class does not work, which leads to the conclusion that the entire class is not used either. This class is used again as a dep of Reader in the same directory.

Before starting to fix a bubble, does anyone now what went wrong here?

Hello,
is there a way to show a message to the customer if entered a not valid VAT during checkout?

Thanks

Hi, Unfortunately, the module does not want to install on Magento 2.2.5 Open Source.

Tried to fix the errors I ran into as they occurred, but still stuck.

To fix this first error,
in Model/VatNumber/Config.php, I replaced DataInterface with Data (because that one does exist)

namespace Dutchento\Vatfallback\Model\VatNumber;

use Dutchento\Vatfallback\Model\VatNumber\Config\Data;

class Config implements ConfigInterface
{
    /** @var Data  */
    private $dataSource;

    /**
     * Config constructor.
     * @param Data $dataSource
     */
    public function __construct(Data $dataSource)
    {
     	$this->dataSource = $dataSource;
    }

    /**
     * @inheritdoc
     */
    public function get(): array
    {
     	return $this->dataSource->get();
    }
}

next, in Model/VatNumber/Config/Reader.php, there is a bad reference:
string $domDocumentClass = \Dom::class,
I removed the backslash and added the following use:
use Magento\Framework\Config\Dom;

Next, we then run into an error on the include:

 [Magento\Framework\Config\Dom\ValidationSchemaException]
  Processed schema file: <M2_DIR>/vendor/dutchento/m2-vatfallback/etcvat_numbers.xsd
  Call to user entity loader callback '' has failedFailed to load external entity "NULL"

To fix this, I edited Model/VatNumber/Config/SchemaLocator.php on line 29 and added a path separator.

Finally, I run into the following error during setup:upgrade that I have as of yet been unable to fix.

[20-Dec-2018 10:11:22 UTC] PHP Fatal error:  Uncaught Error: Call to a member function getNamedItem() on null in <M2_DIR>/vendor/dutchento/m2-vatfallback/Model/VatNumber/Config/Converter.php:51
Stack trace:
#0 <M2_DIR>/vendor/magento/framework/Config/Reader/Filesystem.php(171): Dutchento\Vatfallback\Model\VatNumber\Config\Converter->convert(Object(DOMDocument))
#1 <M2_DIR>/vendor/magento/framework/Config/Reader/Filesystem.php(130): Magento\Framework\Config\Reader\Filesystem->_readFiles(Object(Magento\Framework\Config\FileIterator))
#2 <M2_DIR>/vendor/magento/framework/Config/Data.php(104): Magento\Framework\Config\Reader\Filesystem->read()
#3 <M2_DIR>/vendor/magento/framework/Config/Data.php(92): Magento\Framework\Config\Data->initData()
#4 <M2_DIR>/vendor/dutchento/m2-vatfallback/Model/VatNumber/Config/Data.php in <M2_DIR>/vendor/dutchento/m2-vatfallback/Model/VatNumber/Config/Converter.php on line 51

Apparently, something now parses the XML file wrongly, so in stead of iterating over the multiple EU VAT regexes, it can only find a bad node containing only spaces and a newline.

I have a couple of dutch VAT codes that fail to verify correctly.
Do you also have this issue?

I currently have enabled:

• VIES and Regular Expressions
• VatLayer is disabled

Unfortunately I don't have time atm to properly verify things, but I suspect you did not fix the VIES response parser since 1.3, that I proposed?
If you did not, then the unofficial VIES Validation step is broken and cannot return VALID.

  [Exception]                                                                                                                                                                      
  Warning: preg_match(): No ending delimiter '^' found in vendor/dutchento/m2-vatfallback/Service/Validate/Regex.php on line 39

I get this error when running the following command:
mag vat:validate de d1111111

possible fix:

+++ vendor/dutchento/m2-vatfallback/Service/Validate/Regex.php	2019-01-29 10:21:00.936167458 +0100
@@ -35,5 +35,5 @@
     {
         // as fallback use a pattern that always validates
-        $regex = $this->vatPatternMap[$countryIso2] ?? '.*' ;
+        $regex = $this->vatPatternMap[$countryIso2] ?? '#^.*$#' ;
 
         return (bool)preg_match($regex, $vatNumber);```

I today ran into some odd behaviour in regards to the response object from Magento\Customer\Model\Vat::checkVatNumber, this seem to be caused by the Dutchento\Vatfallback\Plugin\Magento\Customer\Model\Vat plugin.

In the original data object the request_message is returned as a Magento\Framework\Phrase, but as soon as the aforementioned plugin interferes with this data object, it becomes a string.

When using static return types this is an issue. I want to use a single return type for a method, but need to return string|Magento\Framework\Phrase through the PHPDoc to support this behaviour. Or I need to check whether it is a string and create a Magento\Framework\Phrase from it, or vice-versa.

Steps to Reproduce

• Put a breakpoint in Dutchento\Vatfallback\Plugin\Magento\Customer\Model\Vat after $gatewayResponse is assigned
• Take not of the type of the request_message property within the data object (which is a Magento\Framework\Phrase)
• Put a breakpoint at the start of Dutchento\Vatfallback\Plugin\Magento\Customer\Model\Vat::createGatewayResponseObject
• Take note of the type of the $message argument (which is now a string, and will make request_message be a string)

To improve availability, validation service results should be cached. The ttl should be discussed.

when vatlayer validation is used and out of request, the module throws an error which causes the checkout to not work anymore. There should be some checks to avoid errors and just do no validate and log about it.