Neu PayPal-Meldung: XXX versendet nicht an diesen Ort. Verwenden Sie eine andere Adresse.

[css-umsetzung]

Interessanter weise ist das Feld "Vorausgewähltes Lieferland:" leer und kann auch nicht befüllt werden.

Hattest du vorher einen Shop 3 oder frühen Shop 4?

der Expresswarenkorb hat evtl. noch kein gültiges Lieferland in der Session.
Testweise mal unter "Standardansichten -> Registrierung" die Einstellungen für Standardrechnungsland und Standardlieferland ändern auf irgendwas → Speichern → Zurück ändern auf DE → Speichern. Danach alle Caches leeren und beobachten.

Ich habe bei meinem Kunden, wo das auch passiert ist direkt in die Datenbank geschaut, um sicherzugehen, ob der Wert bereits gespeichert und dadurch auch im Cache ist.
Also das könnte eventuell ein Mitgrund sein, aber trifft bei meinem Kunden nicht zu, das ist alles sauber konfiguriert.

Ich lasse seit einigen Tagen ein Log laufen, bin nur noch nicht dazu gekommen, das auszuwerten, da wir hier von sehr vielen Daten sprechen, die ich logge.
Ich habe bei dem betreffenden Shop darauf gehofft, dass sich ein Käufer meldet, der das Problem hat, damit ich das zeitlich eingrenzen kann, bisher gab es da keine Meldung.

 

[Blaumeise]

Ja wir haben irgendwann geupdatet.

 

[css-umsetzung]

Dann kann es sein, speziell wenn du vom 3er kommst, das diverse Einstellungen nicht richtig funktionieren weil sie in der Datenbank fehlerhaft oder doppelt stehen.
Das sollte mal überprüft werden.

Ist aber nur eine Vermutung.

 

[Sirko W.]

Interessanter weise ist das Feld "Vorausgewähltes Lieferland:" leer und kann auch nicht befüllt werden.

Das kann und darf so nicht sein, es sei denn, hier wird noch eine ältere Shopversion genutzt. Evtl. durch diesen Bug in der 5.5.1 ausgelöst.
https://issues.jtl-software.de/issues/SHOP-8798

 

[stage2]

Hi,

hat irgendwer evtl. herausgefunden woran es liegt? Bei uns hat sich auch eine Kunde gemeldet und so wie es aussieht wollte er auch über Paypal Express zahlen. Wir haben 8 Versandarten im Shop angelegt und unter Standardansichten -> Registrierung ist Deutschland ausgewählt. Die Lieferung soll nach Varel gehen.

JTL Shop 5.5.3 und JTL Paypal Checkout 2.2.0

 

[css-umsetzung]

Nein, über das tracken auf gut Glück war nichts zu sehen.
Ich hatte einen dabei, der hatte eine abweichende Adresse in PayPal.

Da wo ich Meldungen von anderen bekam, dass Sie das Problem nachvollziehen können mit Ihrem Account, da ging es beim Prüfen dann auch auf einmal wieder.

 

[golvreven]

Hallo zusammen,

bei uns tritt das Problem mittlerweile auch sporadisch auf. Könnte es nicht einfach daran liegen, dass es eine Adressabweichung beim Kunden gibt und PayPal es nicht zulässt, dass Kunden unter einer anderen als ihrer Standardadresse bestellen?

Viele Grüße
g.

 

[wo0dle]

Hallo, hatte heute auch zum ersten mal das Problem. Es lag am Kauf über den PP Express-Button - die Lieferadresse war falsch eingestellt im Kundenaccount. Wir haben einfach im Kunden PP Account die Lieferadresse richtig hinterlegt, ohne Schreibfehler. Danach ging der Kauf per Express-Button ohne Probleme.

Evtl. prüft PP nun Adressen auf Richtigkeit.

 

[badosan]

Bei uns tritt dieses Problem mittlerweile auch sehr gehäuft auf. Auch bei uns scheint PP Express das Problem zu sein. Der Kunde hat es dann ohne Klick auf "Direkt zu PayPal" versucht, dann hat es geklappt. Gibt es schon neue Erkenntnisse?

 

[LaLumex]

Wir hatten heute auch mal wieder eine Kundenrückmeldung dazu.
Offenbar gibt es hier immer noch keine wirkliche Lösung?

Bei sowas muss man sich zwangsläufig Sorgen um die Dunkelziffer machen. Nicht jeder Kunde wird sich melden, sondern manche werden eben einfach woanders kaufen.

 

[css-umsetzung]

Wer eine 2.2.1er Version hat sollte auch unbedingt das error_reporting aktivieren und dafür sorgen das die Einträge in einer log Datei festgehalten werden um das regelmäßig zu prüfen.
Ich habe bereits mehrere Fälle, wo das PayPal Plugin einen Fehler verursacht, wenn der Kunde die optionale Telefonnummer leer lässt, es kann auch andere Gründe geben, sie haben aber in jedem Fall etwas mit der Telefonnummernprüfung zu tun.

Die Fehlermeldung sieht dann ungefähr so aus und verhindert den Kauf:

PHP Fatal error: Uncaught Plugin\jtl_paypal_commerce\PPC\Order\InvalidPhoneException: national phone number is invalid
Ich rate jedem, das zu prüfen.

 

[LaLumex]

Und wie aktiviert man dieses error_reporting?

 

[css-umsetzung]

In der Regel schreibt der Webserver sein eigenes error_log in dem man das finden würde.
Wenn man sich noch nie damit beschäftigt hat oder es keines gibt, kann man das in den meisten Fällen selbst erstellen und sich aussuchen, wo das abgelegt wird.

Ich verwende hierfür meinen eigenen Codeschnipsel, hierfür schmeiße ich diesen Teil aus der config.JTL- Shop.ini.php im includes/ raus

//enables printing of warnings/infos/errors for the shop frontend
define('SHOP_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the dbeS sync
define('SYNC_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the admin backend
define('ADMIN_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the smarty templates
define('SMARTY_LOG_LEVEL', 0);
//excplicitly show/hide errors
ini_set('display_errors', 0);

und füge meinen Code ein:

$show_error = true; // true bedeutet, dass nur Fehler angezeigt werden
$strong = false;   // true bedeutet hier, dass alle Meldungen ausgegeben werden (Entwicklermodus)

if ($show_error) {
    date_default_timezone_set('Europe/Berlin');
    ini_set('display_errors', 1); // hier eine 0 setzen um die Anzeige auf dem Bildschirm zu unterbinden
    if ($strong) {
        define('SHOP_LOG_LEVEL', E_ALL);
        define('SYNC_LOG_LEVEL', E_ALL);
        define('ADMIN_LOG_LEVEL', E_ALL);
        define('SMARTY_LOG_LEVEL', E_ALL);
    } else {
        define('SHOP_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED & ~E_USER_DEPRECATED);
        define('SYNC_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED & ~E_USER_DEPRECATED);
        define('ADMIN_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED & ~E_USER_DEPRECATED);
        define('SMARTY_LOG_LEVEL', E_ALL & ~E_WARNING & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED & ~E_USER_DEPRECATED);
    }
    ini_set('error_log', PFAD_ROOT . 'jtllogs/phperror_' . date("d-m-Y") . '.log');
} else {
    //enables printing of warnings/infos/errors for the shop frontend
    define('SHOP_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the dbeS sync
    define('SYNC_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the admin backend
    define('ADMIN_LOG_LEVEL', 0);
    //enables printing of warnings/infos/errors for the smarty templates
    define('SMARTY_LOG_LEVEL', 0);
    //excplicitly show/hide errors
    ini_set('display_errors', 0);
}

dann kann ich tagesabhängig, im jtllogs Verzeichnis sehen, ob der Shop Fehler produziert.
Das sollte man nur aktivieren, wenn man gezielt nach Fehlern sucht oder den Shop, bzw. kritische Dinge aktualisiert oder geändert hat und dann ein paar Tage laufen lassen.

 

[css-umsetzung]

Es wurde dafür jetzt auch ein Ticket erstellt, laut dem Ticket kann man auch im Backend in den logs, den Fehler finden indem man nach

Routing error: national phone number is invalid

sucht.

Das Ticket dafür ist hier zu finden:
https://issues.jtl-software.de/issues/SHOP-9577

 

[LaLumex]

Da gerade wieder eine Kundenrückmeldung dazu rein kam, habe ich mal hier reingeschaut.
Das Ticket ist bereits erledigt, aber offenbar besteht das Problem immer noch.