das SW-Plugin in der V2.0.4 treibt uns hier gerade in den Wahnsinn. Mal wieder ein Kunde, der seine VAT-Nr nicht erfolgreich im Kundenstamm hinterlegen kann. Wie immer prüft man ja erstmal die Angaben des Kunden: VAT-Nr, Firmenname, alle Details der Anschrift. Sowohl im DE-Portal als auch danach im EU-Portal. Screenshot gemacht.
Dann auf ins Backend, den Kunden aufgerufen und Firmenname hinterlegt, Anschrift geprüft, VAT-Nr. eingetragen und - „Validierung Fehler vatId:“ <Schließen>. Danke fürs Gespräch.
Logfiles gechecked, Community durchsucht, gemeinsam Fehleransatz überlegt. Feststellung: wenn wir die Prüfung in der Konfiguration auf „Erweitert“ stellen, dann kommt diese nichtsnützige Fehlermeldung. Stellen wir auf „Einfach“, wird die VAT-Nr. abgespeichert.
In der Konfig haben wir unsere ID-Nr eingetragen (selbe wie im Portal), Prüfung auf Erweitert, Bestätigung auf JA und keine Ausnahmen eingetragen. Der Kunde ist in BE.
Preisfrage: warum macht die Abfrage über das Plugin Zicken, wenn es in EU- als auch im DE-Portal problemlos funktioniert?
Hey, habt ihr schon das Plugin-Update auf Version 2.0.6 gemacht?
Wenn ja. Besteht das Problem immer noch?
Wenn ja. Könntet ihr ein Ticket dazu anlegen mit einer genauen Beschreibung und ggf. die Ust.Id’s mit angeben… So kann ich versuchen das Problem nachzustellen und zu fixen…
Hallo,
das Update war erfolgt, aber es war bisher kein Test erfolgt und deswegen war auch die Option „Erweitert“ im Plugin weiterhin von uns nicht genutzt.
Wir haben es jetzt bei einem Kunden ausprobiert und es hat hier keine Fehler (mehr) gegeben. Insofern gehe ich mal davon aus, dass es behoben wurde.
Wenn der nächste Kunde vor einem Problem steht, so melde ich mich ansonsten wieder.
Beste Grüße!
Hallo zusammen,
dass ich mich melde wird einen Grund haben: richtig, es gibt es Problem. Und zwar immer, wenn eine USt-ID verwendet wird, erhält der Kunde einen 500er-Fehler. Das sollte nicht sein - wenn es einen Fehler gibt, dann sollte auch eine sinnvolle Fehlermeldung ausgegeben werden.
Was sagt das Log dazu?
2021/07/01 17:05:35 [error] 1036#1036: *193907 FastCGI sent in stderr: „PHP message: PHP Fatal error: Uncaught Error: Class ‚SoapClient‘ not found in /var/www/html/schafi/custom/plugins/SwagVatIdValidation/Components/Validators/MiasVatIdValidator.php:59
Stack trace: #0 /var/www/html/schafi/custom/plugins/SwagVatIdValidation/Components/ValidationService.php(346): SwagVatIdValidation\Components\Validators\MiasVatIdValidator->check() #1 /var/www/html/schafi/custom/plugins/SwagVatIdValidation/Components/ValidationService.php(226): SwagVatIdValidation\Components\ValidationService->validateWithApiValidator() #2 /var/www/html/schafi/custom/plugins/SwagVatIdValidation/Bundle/AccountBundle/Constraints/AdvancedVatIdValidator.php(73): SwagVatIdValidation\Components\ValidationService->validateVatId() #3 /var/www/html/schafi/vendor/symfony/validator/Validator/RecursiveContextualValidator.php(828): SwagVatIdValidation\Bundle\AccountBundle\Constraints\AdvancedVatIdValidator->validate() #4 /var/www/html/schafi/vendor/symfony/validator/Validator/RecursiveContextualValidator.php(652):“ while reading response header from upstream, client: xxxxxxxxxx, server: ###.de, request: „POST /register/saveRegister/sTarget/checkout/sTargetAction/confirm HTTP/2.0“, upstream: „fastcgi://unix:/var/run/php/php7.4-fpm.sock:“, host: „###.de“, referrer: „https://###/checkout/confirm“
Hat jemand eine Idee, warum die Kunden so unschön „fliegen“?
Super - vielen Dank für den Hinweis. Wir haben das sofort geprüft und festgestellt, dass offenbar in der php7.4 soap bei Debian nicht mehr, wie in den Vorversionen, im standard-package mit enthalten war, sondern separat zu installieren war.
Jetzt klappt alles - sowohl die einfache Validierung als auch die erweiterte Validierung. Vielen Dank!
Beste Grüße
