Wenn der ausgewählte Paketautomat in der PrestaShop-Bestellung nicht erscheint, verfolgen Sie dieselbe Punkt-ID von der Karte bis zum Auslesen der Bestellung. Allein die Anzeige des Namens neben der Schaltfläche bedeutet nur, dass die Benutzeroberfläche die Auswahl übernommen hat. Zusätzlich muss noch die Speicherung auf Shop-Seite, das Verhalten bei Änderung der Versandart sowie die Verknüpfung der Daten mit dem richtigen Warenkorb bestätigt werden.
Der Leitfaden richtet sich an Personen, die Bestellungen bearbeiten und InPost-Lieferungen implementieren. Er hilft dabei, konkretes Material für die Diagnose zu sammeln. Er trennt das Problem der Karte, der Datenspeicherung und der Checkout-Integration; er geht nicht davon aus, dass jeder fehlende Punkt auf einen Fehler desselben Moduls zurückzuführen ist.
1. Speichern Sie die Kennung, nicht nur die Adresse des Punkts
Straße, Stadt und Standortbeschreibung helfen dem Kunden, aber die Integration benötigt eine eindeutige Kennung. In den Geowidget-Daten dient dazu das Feld name; separat liegen Adresse, Typ und Koordinaten vor. Die Struktur dieser Daten beschreibt die offizielle PointInterface-Dokumentation.
Im Beispiel verwenden wir die Bezeichnung TEST-PUNKT-A. Das ist absichtlich eine fiktive Kennung zur Beschreibung des Ablaufs, kein funktionierender Paketautomat. Wählen Sie im realen Test einen verfügbaren Punkt auf der Karte und notieren Sie seine tatsächliche Bezeichnung. Tragen Sie keinen Beispielcode in ein produktives Versandlabel ein.
Notieren Sie in der Problemmeldung auch die Version von PrestaShop, des Themes, des InPost-Moduls und des Checkouts. Wichtig ist die konkrete Version sowie eventuelle Änderungen. Die Bezeichnung „One Page Checkout“ beschreibt die Art des Prozesses, verweist aber nicht auf eine einzige Integrationsoberfläche.
2. Prüfen Sie die einzelnen Schritte der Speicherung
Der erwartete Ablauf lässt sich einfach notieren:
Auswahl des Punkts auf der Karte → Übernahme der Daten durch die Seite → Speicheranfrage → Speicherung am Warenkorb → Erstellung der Bestellung → Auslesen des Punkts durch die Bearbeitung.
Jeder Pfeil steht für ein separates Ereignis. Die API-Dokumentation des Geowidgets beschreibt die Auswahl des Punkts und die Übergabe der Daten an die Funktion, die die Auswahl verarbeitet. Die Shop-Anwendung muss die erhaltenen Informationen anschließend korrekt verwenden.
Diagnosekarte: derselbe Punkt an den aufeinanderfolgenden Stellen
Schritt
Was zu prüfen ist
Was eine Abweichung bedeutet
Karte
Ob der Callback oder das Auswahlereignis die Kennung des markierten Punkts enthält.
Fehlende Daten lenken die Diagnose auf das Widget, die Skripte und dessen Konfiguration.
Checkout-Ansicht
Ob der angezeigte Name dem ausgewählten Punkt entspricht, auch nach dem Schließen der Karte.
Ein anderer Punkt oder eine alte Beschreibung weisen auf ein Problem bei der Aktualisierung der Benutzeroberfläche hin.
Anfrage an den Shop
Ob die Punktkennung an den richtigen Endpoint in der aktuellen Sitzung übergeben wurde.
Fehlende Anfrage oder fehlende Daten erfordern eine Prüfung der JavaScript-Integration.
Antwort und Speicherung
Ob die Antwort den Erfolg des Vorgangs bestätigt und der Punkt beim richtigen Warenkorb gespeichert ist.
HTTP 200 mit einem Anwendungsfehler ist keine korrekte Speicherung.
Bestellung
Ob das Auslesen für den Warenkorb, aus dem die Bestellung entstanden ist, denselben Punkt zurückgibt.
Ein anderer Warenkorb oder eine fehlende Verknüpfung lenken die Diagnose auf die Endphase des Einkaufs.
Versandbearbeitung
Ob das Panel und die vorbereitete Sendung dieselbe Kennung verwenden.
Eine korrekte Speicherung bei fehlerhafter Ansicht erfordert eine Kontrolle des Auslesens oder der weiteren Integration.
3. Warum der Name auf dem Bildschirm und HTTP 200 nicht ausreichen
Öffnen Sie im Browser die Registerkarte Network, wählen Sie einen Punkt aus und suchen Sie die Speicheranfrage. Prüfen Sie die Antwort der Anwendung und nicht nur die Farbe der Zeile. Der Server kann korrekt ein JSON-Dokument liefern, das Informationen über eine fehlgeschlagene Speicherung enthält. Der HTTP-Status betrifft die Transportantwort; deren Inhalt erklärt das Ergebnis des Vorgangs.
In den Quellen von InPost Paczkomaty Pro 2.8.7 werden die Punktdaten in der Modultabelle gespeichert, die mit id_cart verknüpft ist. Die Information für die Bestellung wird über deren Warenkorb ausgelesen. Das Fehlen des Punkts sollte daher nicht ausschließlich dadurch diagnostiziert werden, dass in der Haupttabelle der Bestellungen nach einer separaten Spalte für den Paketautomaten gesucht wird.
In der geprüften Verarbeitung von Geowidget v5 zeigt die Benutzeroberfläche den ausgewählten Punkt bereits vor Abschluss der Speicherung an. Prüfen Sie daher bei der Abnahme der Integration auch die Antwort success, den Wert machine sowie das spätere Auslesen. Betrachten Sie die bloße Freigabe der Kaufschaltfläche nicht als Beleg dafür, dass die Datenbank die Auswahl übernommen hat.
Für die Diagnose kann ein anonymisierter Ausschnitt der Antwort und die Uhrzeit des Vorgangs aufbewahrt werden. Vollständige HAR-Dateien enthalten oft Cookies, Adressen und Formulardaten; veröffentlichen Sie diese nicht öffentlich. Die technische Person sollte Material mit entfernten Geheimnissen und personenbezogenen Daten erhalten.
4. Wiederholen Sie den Test nach Änderung des Versanddienstleisters und der Adresse
Der Ablauf „Ich habe einen Punkt gewählt und sofort gekauft“ ist nur ein Szenario. Der Kunde kann den Versanddienstleister ändern, zur Adresse zurückkehren, sich anmelden oder den Versand erneut berechnen. Jeder dieser Schritte kann einen Teil der Seite neu aufbauen und die Daten des Warenkorbs ändern.
In Version 2.8.7 führt der geprüfte Hook für die Adressänderung keine automatische Löschung des Punkts aus. Die Verarbeitung der Versanddienstleister-Änderung entfernt die Speicherung bei einem expliziten Wechsel zu einem anderen Versanddienstleister außerhalb von InPost; ein vorübergehender Wert null wird nicht identisch behandelt. Das ist ein Grund, konkrete Übergänge zu prüfen, statt anzunehmen, dass jede Änderung der Stadt eine neue Auswahl erzwingt.
Demonstrationsszenario für die Abnahme der Integration — in einer Shop-Kopie auszuführen
Schritt
Beispiel
Abnahmekriterium
Punktauswahl
Ein Gast wählt TEST-PUNKT-A in einem Demonstrations-Warenkorb.
Ansicht, Speicherantwort und verknüpfte Daten enthalten dieselbe Kennung.
Änderung des Versanddienstleisters
Der Kunde wechselt den Versand zu einem Dienstleister außerhalb von InPost und kehrt dann zurück.
Der Shop ordnet die vorherige Auswahl nicht versehentlich der falschen Versandart zu; die weitere Auswahl ist eindeutig.
Adressänderung
Der Kunde ändert die Stadt und sieht sich die Versandoptionen erneut an.
Die Benutzeroberfläche zeigt den aktuellen Punkt klar an und erlaubt seine Korrektur; wir gehen ohne Test nicht von einer automatischen Löschung aus.
Telefon
Der Kunde öffnet die Karte, wählt einen Punkt und kehrt zum Checkout zurück.
Die Karte lässt sich bedienen, die Auswahl auslesen und der Kauf ohne Verlust des Punkts bestätigen.
Testbestellung
In einer Shop-Kopie schließen wir den Prozess nach bestätigter Speicherung ab.
Die Bearbeitung liest den tatsächlich gewählten Punkt aus der richtigen Bestellung aus, ohne eine produktive Sendung zu erstellen.
Die Tabelle definiert den erwarteten Ablauf des Tests. Sie ist kein Bericht über ein versendetes Paket und auch kein Testergebnis aller Checkouts. Ersetzen Sie bei einer realen Abnahme die fiktiven Bezeichnungen durch einen Punkt aus dem Dienst und dokumentieren Sie das Ergebnis jedes Schritts.
5. Benennen Sie die zu korrigierende Schicht, bevor Sie das Modul ändern
Wenn die Karte keine Daten übergibt, beginnen Sie mit ihrer Konfiguration und den Skriptfehlern. Wenn die Speicheranfrage entsteht, aber mit einem Fehler endet, prüfen Sie den Endpoint, die Warenkorb-Sitzung und die Serverantwort. Wenn die Speicherung korrekt ist, aber erst beim Kauf verschwindet, konzentrieren Sie sich auf den Übergang Warenkorb–Bestellung sowie auf die Integration des abschließenden Formulars.
Wenn das Panel den Punkt korrekt anzeigt, ein anderes Versandtool ihn aber nicht sieht, prüfen Sie die Art und Weise, wie dieses Tool die Daten abruft. Kopieren Sie nicht manuell irgendeine zufällige ID in die Bestellung, ohne zu bestätigen, welchen Punkt der Kunde angegeben hat.
Bei einer geplanten Änderung des Warenkorbs nutzen Sie auch die Checkliste für One Page Checkout in PrestaShop. Der Abholpunkt sollte eines der expliziten Abnahmekriterien sein, neben Zahlungen, Adressen und mobilen Einkäufen.
Nächster Schritt: Vergleichen Sie die Anforderungen Ihrer Versandart mit InPost Paczkomaty Pro. Fügen Sie der Integrationsmeldung die Versionen, die Schritte der Versandänderung und die Information hinzu, in welchem Schritt die Kennung nicht mehr übereinstimmt.
Geprüft am 13.09.2026. Grundlage: Quellen von InPost Paczkomaty Pro 2.8.7 sowie die Geowidget-Dokumentation. Szenario und Bezeichnungen sind demonstrativ; es wurde weder ein produktiver Versandauftrag noch ein Kompatibilitätstest jedes Checkouts durchgeführt.
Das Modul InPost Paczkomaty Pro wurde für Personen entwickelt, die Pakete über Paketautomaten versenden möchten. Dank der integrierten Karte sowie dem System zur vollständigen Auswahl der Liste der Paketautomaten können Kunden auf einfache und schnelle Weise den Abholort ihrer Sendung aus den InPost-Paketautomaten auswählen.
Patryk Marek — Inhaber von PrestaDev.pl und Entwickler mit Spezialisierung auf PrestaShop. Seit vielen Jahren beschäftigt er sich mit der Erstellung, Weiterentwicklung und Wartung von Onlineshops. Er verbindet die Arbeit am Shop-Code und an Modulen mit der Konfiguration der Serverumgebung, in der diese Lösungen betrieben werden.
Er entwirft und entwickelt PrestaShop-Module, passt bestehende Funktionen an und erstellt Integrationen mit Großhändlern und externen Diensten. Er arbeitet an dem Import und der Aktualisierung von Produktdaten, der Automatisierung der Katalogverwaltung, dem Bestellablauf sowie an Werkzeugen, die die tägliche Arbeit des Shop-Inhabers unterstützen.
Seine Erfahrung umfasst auch Shop-Updates und -Migrationen, die Diagnose von Fehlern, die Analyse der Leistung sowie die Konfiguration von Servern und Diensten, die für den Betrieb von PrestaShop erforderlich sind. Bei der Lösung von Problemen berücksichtigt er die Abhängigkeiten zwischen Modulen, dem Theme, PHP, der Datenbank und den Hosting-Einstellungen.
Im Blog teilt er Wissen, das aus langjähriger Programmierpraxis und der Arbeit mit dem technischen Hintergrund von Shops resultiert. Die Anleitungen konzentrieren sich auf konkrete Probleme, Möglichkeiten zu deren Prüfung und die Einschränkungen der beschriebenen Lösungen. Sie helfen Shop-Inhabern und technischen Fachkräften, Änderungen vorzubereiten, deren Umfang zu bewerten und das Ergebnis zu überprüfen.
Kommentare (0)