Lorsque le Paczkomat sélectionné n’apparaît pas dans la commande PrestaShop, suivez le même identifiant de point depuis la carte jusqu’à la lecture de la commande. Le simple affichage du nom à côté du bouton signifie seulement que l’interface a reçu la sélection. Il faut encore confirmer l’enregistrement côté boutique, le comportement après changement de mode de livraison ainsi que l’association des données au bon panier.
Ce guide s’adresse aux personnes qui gèrent les commandes et déploient les livraisons InPost. Il aide à rassembler des éléments concrets pour le diagnostic. Il distingue le problème de la carte, de l’enregistrement des données et de l’intégration du checkout ; il ne suppose pas que chaque absence de point provient d’une erreur du même module.
1. Enregistrez l’identifiant, pas seulement l’adresse du point
La rue, la ville et la description de l’emplacement aident le client, mais l’intégration a besoin d’un identifiant univoque. Dans les données du Geowidget, le champ name sert à cela ; l’adresse, le type et les coordonnées sont fournis séparément. La structure de ces données est décrite dans la documentation officielle PointInterface.
Dans l’exemple, nous utiliserons la désignation TEST-PUNKT-A. Il s’agit volontairement d’un identifiant fictif pour décrire le flux, et non d’un Paczkomat réel. Lors d’un test réel, choisissez un point disponible sur la carte et notez sa désignation réelle. N’inscrivez pas ce code d’exemple sur une étiquette de production.
Dans le signalement du problème, notez aussi la version de PrestaShop, du thème, du module InPost et du checkout. La version précise ainsi que les éventuelles modifications sont importantes. Le nom « one page checkout » décrit un type de processus, mais ne désigne pas une interface d’intégration unique.
2. Vérifiez les étapes successives de l’enregistrement
Le flux attendu peut être résumé simplement :
sélection du point sur la carte → réception des données par la page → requête d’enregistrement → enregistrement dans le panier → création de la commande → lecture du point par le service de traitement.
Chaque flèche correspond à un événement distinct. La documentation de l’API Geowidget décrit la sélection du point et la transmission des données à la fonction qui traite ce choix. C’est ensuite à l’application de la boutique d’utiliser correctement les informations reçues.
Fiche de diagnostic : le même point aux différentes étapes
Étape
Ce qu’il faut vérifier
Ce que signifie un écart
Carte
Vérifier si le callback ou l’événement de sélection contient l’identifiant du point sélectionné.
L’absence de données oriente le diagnostic vers le widget, les scripts et sa configuration.
Vue du checkout
Vérifier si le nom affiché correspond au point sélectionné, y compris après la fermeture de la carte.
Un autre point ou une ancienne description indiquent un problème de mise à jour de l’interface.
Requête vers la boutique
Vérifier si l’identifiant du point a été transmis au bon endpoint dans la session en cours.
L’absence de requête ou de données impose de vérifier l’intégration JavaScript.
Réponse et enregistrement
Vérifier si la réponse indique le succès de l’opération et si le point est enregistré dans le bon panier.
Un HTTP 200 avec une erreur applicative ne constitue pas un enregistrement correct.
Commande
Vérifier si la lecture pour le panier à l’origine de la commande renvoie le même point.
Un autre panier ou l’absence d’association oriente le diagnostic vers l’étape finale de l’achat.
Traitement de l’expédition
Vérifier si le panneau et l’expédition en préparation utilisent le même identifiant.
Un enregistrement correct avec un affichage erroné nécessite de contrôler la lecture ou l’intégration ultérieure.
3. Pourquoi le nom à l’écran et un HTTP 200 ne suffisent pas
Dans le navigateur, ouvrez l’onglet Network, sélectionnez un point et repérez la requête d’enregistrement. Vérifiez la réponse de l’application, et pas uniquement la couleur de la ligne. Le serveur peut parfaitement renvoyer un document JSON contenant une information d’échec d’enregistrement. Le statut HTTP concerne la réponse de transport ; son contenu explique le résultat de l’opération.
Dans les sources de InPost Paczkomaty Pro 2.8.7, les données du point sont enregistrées dans la table du module liée à id_cart. L’information pour la commande est lue via son panier. Il ne faut donc pas diagnostiquer l’absence du point uniquement en recherchant une colonne séparée pour le Paczkomat dans la table principale des commandes.
Dans la gestion examinée de Geowidget v5, l’interface affiche le point sélectionné avant même la fin de l’enregistrement. C’est pourquoi, lors de la réception de l’intégration, il faut aussi vérifier la réponse success, la valeur machine ainsi que la lecture ultérieure. Ne considérez pas le simple déverrouillage du bouton d’achat comme une preuve que la base a accepté la sélection.
Pour le diagnostic, vous pouvez conserver un extrait anonymisé de la réponse ainsi que l’heure de l’opération. Les fichiers HAR complets contiennent souvent des cookies, des adresses et des données de formulaires ; ne les publiez pas. La personne technique doit recevoir des éléments dont les secrets et les données personnelles ont été supprimés.
4. Répétez le test après changement de transporteur et d’adresse
Le flux « j’ai choisi un point et j’ai acheté immédiatement » n’est qu’un seul scénario. Le client peut changer de transporteur, revenir à l’adresse, se connecter ou recalculer la livraison. Chacune de ces étapes peut reconstruire une partie de la page et modifier les données du panier.
Dans la version 2.8.7, le hook de changement d’adresse examiné n’exécute pas de suppression automatique du point. La gestion du changement de transporteur supprime l’enregistrement lors d’un passage explicite vers un autre transporteur hors InPost ; une valeur transitoire zéro n’est pas traitée de manière identique. C’est une raison de vérifier les transitions concrètes, et non de supposer que chaque changement de ville imposera une nouvelle sélection.
Scénario de démonstration pour la réception de l’intégration — à exécuter sur une copie de la boutique
Étape
Exemple
Critère de réception
Sélection du point
Un visiteur choisit TEST-PUNKT-A dans un panier de démonstration.
La vue, la réponse d’enregistrement et les données associées contiennent le même identifiant.
Changement de transporteur
Le client bascule la livraison vers un transporteur hors InPost, puis revient.
La boutique n’associe pas par erreur la sélection précédente à un mode de livraison inadapté ; la sélection ultérieure reste univoque.
Changement d’adresse
Le client change de ville et consulte à nouveau les options de livraison.
L’interface affiche clairement le point actuel et permet de le corriger ; nous ne supposons pas une suppression automatique sans test.
Téléphone
Le client ouvre la carte, choisit un point et revient au checkout.
Il est possible d’utiliser la carte, de récupérer la sélection et de valider l’achat sans perdre le point.
Commande de test
Sur une copie de la boutique, nous terminons le processus après confirmation de l’enregistrement.
Le service de traitement lit bien le point réellement choisi dans la bonne commande, sans créer d’expédition de production.
Le tableau définit le déroulement attendu du test. Il ne constitue ni un rapport d’envoi de colis ni le résultat d’un test de tous les checkouts. Lors d’une réception réelle, remplacez les désignations fictives par un point du service et consignez le résultat de chaque étape.
5. Identifiez la couche à corriger avant de changer de module
Si la carte ne renvoie pas les données, commencez par sa configuration et les erreurs de script. Si la requête d’enregistrement est bien créée mais se termine par une erreur, vérifiez l’endpoint, la session du panier et la réponse du serveur. Si l’enregistrement est correct mais disparaît seulement au moment de l’achat, concentrez-vous sur la transition panier–commande ainsi que sur l’intégration du formulaire final.
Si le panneau affiche correctement le point, mais qu’un autre outil d’expédition ne le voit pas, vérifiez la manière dont cet outil récupère les données. Ne copiez pas manuellement un ID quelconque dans la commande sans confirmer quel point le client a indiqué.
Si vous prévoyez de changer de checkout, utilisez aussi la liste de contrôle one page checkout dans PrestaShop. Le point relais doit faire partie des critères de réception explicites, au même titre que le paiement, les adresses et les achats sur mobile.
Étape suivante : comparez les exigences de votre mode de livraison avec InPost Paczkomaty Pro. À votre demande d’intégration, joignez les versions, les étapes de changement de livraison et l’information indiquant à quelle étape l’identifiant cesse de correspondre.
Vérifié le 13.09.2026. Base : sources d’InPost Paczkomaty Pro 2.8.7 et documentation du Geowidget. Le scénario et les désignations sont fournis à titre de démonstration ; aucun envoi de production ni test de compatibilité de chaque checkout n’a été effectué.
Le module InPost Paczkomaty Pro a été conçu pour les personnes qui souhaitent envoyer des colis via les consignes automatiques ; grâce à la carte intégrée ainsi qu’au système complet de sélection dans la liste des consignes Paczkomaty, les clients pourront choisir facilement et rapidement les lieux de retrait de leur colis dans les consignes InPost.
Patryk Marek — propriétaire de PrestaDev.pl et développeur spécialisé dans PrestaShop. Depuis de nombreuses années, il se consacre à la création, au développement et à la maintenance de boutiques en ligne. Il associe le travail sur le code de la boutique et des modules à la configuration de l’environnement serveur dans lequel ces solutions fonctionnent.
Il conçoit et développe des modules PrestaShop, adapte les fonctionnalités existantes et prépare des intégrations avec des grossistes et des services externes. Il travaille sur l’importation et la mise à jour des données produits, l’automatisation de la gestion du catalogue, le processus de commande ainsi que les outils soutenant le travail quotidien du propriétaire de la boutique.
Son expérience comprend également les mises à jour et les migrations de boutiques, le diagnostic des erreurs, l’analyse des performances ainsi que la configuration des serveurs et des services nécessaires au fonctionnement de PrestaShop. Lors de la résolution des problèmes, il prend en compte les dépendances entre les modules, le thème, PHP, la base de données et les paramètres d’hébergement.
Sur le blog, il partage des connaissances issues de nombreuses années de pratique en programmation et de travail avec l’infrastructure technique des boutiques. Les guides se concentrent sur des problèmes concrets, les moyens de les vérifier et les limites des solutions décrites. Ils aident les propriétaires de boutiques ainsi que les profils techniques à préparer les changements, à en évaluer l’ampleur et à en vérifier le résultat.
commentaires (0)