DHL Express : une facture imprimée à la place de l’étiquette

Le poste logistique reçoit un PDF, le fichier s’ouvre et l’impression fonctionne. Pourtant, le préparateur tient une facture au lieu de l’étiquette attendue. Le blocage se situe au poste de préparation, même si le fichier reçu est techniquement lisible. Relancer la création DHL ne corrige pas nécessairement cette erreur : le bon document peut déjà se trouver dans la même réponse. Il faut d’abord examiner la façon dont le WMS choisit un élément de la collection documents, puis le profil documentaire qui a produit ses pages.

La sélection doit couvrir le rôle déclaré du document, son format, son rattachement à l’envoi et les options de regroupement. Prendre documents[0] parce que son contenu se décode ne démontre aucun de ces points. Ce diagnostic s’appuie sur MyDHL REST 3.3.4, vérifié le 17 octobre 2026. Il distingue la réponse de création d’expédition d’autres opérations DHL ; leurs propriétés voisines ne forment pas automatiquement un modèle documentaire interchangeable.

Un exercice Python reproduit une mauvaise sélection sur des PDF entièrement fictifs, puis compare vingt cas et les limites de ses propres contrôles. Aucune expédition ni impression réelle n’est exécutée. Pour reprendre le passage entre réponse transporteur et poste de préparation, notre accompagnement en intégration DHL qualifie le contrat utilisé ; notre expertise en intégration API relie ensuite ce choix aux dossiers ERP, OMS et WMS concernés.

Pour qui : un incident documentaire au poste logistique

Le fichier est disponible, mais sa destination est mauvaise

Le sujet concerne les équipes qui récupèrent les documents DHL depuis un connecteur, puis les remettent à une interface opérateur ou à une file d’impression. Le symptôme peut suivre une évolution des options demandées, l’ajout d’une facture ou un changement du mapping de réponse. Le signal faible est précis : l’opérateur retrouve plusieurs fichiers utilisables, mais ne peut pas expliquer pourquoi celui affiché comme « étiquette » a été retenu.

La priorité consiste à retrouver une réponse enregistrée et la demande qui l’a produite. Une capture du papier sorti ne suffit pas : elle ne montre ni les autres documents disponibles ni les paramètres de regroupement. Associez ce dossier au poste, à l’expédition et au moment de la sélection. Vous pourrez alors distinguer le mauvais fichier choisi d’un bon fichier envoyé au mauvais équipement, sans modifier le service de transport vendu au client.

Ne pas demander une nouvelle expédition pour réparer un affichage

Une étiquette absente de l’écran n’implique pas qu’aucune expédition n’a été créée. Le document peut être dans la réponse conservée, dans le stockage du middleware ou en attente de restitution au WMS. La recherche doit suivre ces étapes avant toute nouvelle demande de création. Le coût caché d’un mauvais diagnostic est une reprise qui ajoute un second dossier transport alors que le défaut initial concernait seulement la sélection du fichier.

Si l’incident porte plutôt sur une adresse refusée, un produit indisponible ou un document douanier incomplet, changez de diagnostic. Le sélecteur PDF ne résout pas ces causes. De même, si le fichier correct est identifié mais que le poste ne sait pas traiter son format, l’enquête revient vers le consommateur et sa configuration. Un statut unique « problème DHL » empêcherait de transmettre le dossier à la bonne équipe.

Lire la collection de documents de la bonne opération

Le rôle et le format répondent à deux questions

Dans le contrat officiel MyDHL REST 3.3.4, la réponse de création décrit une collection documents avec notamment typeCode, imageFormat et content. Le rôle peut désigner une étiquette ou une facture ; le format indique comment lire le fichier. Un PDF ne devient donc pas une étiquette par son extension. La sélection proposée utilise le rôle explicite, sans attribuer un sens métier à la position zéro.

Le premier scénario fictif place une facture devant l’étiquette. La sélection par position prend le premier contenu, le décode et obtient un PDF lisible. Le correctif sélectionne le document déclaré label. Si la collection contient deux candidats, il renvoie une revue pour le profil local retenu, plutôt que choisir arbitrairement le premier. Cela ne signifie pas qu’une réponse DHL avec plusieurs documents de ce type serait invalide : un autre parcours peut demander un découpage différent.

Ne pas partager aveuglément les modèles entre opérations

La réponse Get Image du même contrat décrit encodingFormat, alors que la création utilise imageFormat. Un adaptateur commun qui renomme ces propriétés sans conserver l’opération d’origine peut lire une valeur au mauvais endroit. Le programme limite volontairement sa sélection au résultat de création. Il classe un autre parcours ou une autre forme de réponse en revue ; il ne prétend pas valider l’ensemble des opérations documentaires DHL.

Le modèle interne doit donc garder l’opération, la version d’interface et le rôle natif avant une éventuelle normalisation. Un champ interne « format » peut être pratique, à condition que sa provenance reste retrouvable. La même précaution concerne les documents liés aux pièces : une propriété packageReferenceNumber demande un rapprochement adapté au parcours par colis. Elle ne doit pas disparaître pour faire entrer la réponse dans un lecteur prévu pour un document global.

Un document déclaré label peut contenir plusieurs usages

Relire les options enregistrées avec la demande

La documentation de allDocumentsInOneImage prévoit un fichier regroupant plusieurs documents, dont étiquette, waybill, reçu et facture commerciale lorsque cette option est activée. D’autres options règlent leur séparation ou leur regroupement. Avant de corriger la boucle de sélection, retrouvez donc les paramètres effectivement envoyés. La référence MyDHL sert à identifier ce périmètre ; le nom d’un booléen ne suffit pas à qualifier toutes ses interactions avec les autres choix.

Dans le deuxième scénario fictif, le fichier regroupe une page marquée LABEL et une page marquée INVOICE. Le PDF est lisible. Lorsque le profil de demande déclare le regroupement, notre sélection l’arrête pour revue documentaire. Si ce profil est absent, elle refuse également de deviner. Ces décisions sont des garde-fous locaux pour le poste étudié ; elles ne décrivent pas une erreur retournée par DHL ni une interdiction générale d’utiliser des PDF combinés.

Séparer le nombre de fichiers du nombre de colis

Un fichier peut contenir plusieurs pages et une réponse plusieurs documents. Ces cardinalités ne prouvent pas à elles seules le nombre de colis préparés. Le mode de liaison par pièce présenté dans le contrat ajoute son propre contexte. Si votre demande utilise ce parcours, qualifiez les références de pièces et les documents attendus avant d’adapter la sélection. Le démonstrateur signale ce profil ; il ne distribue pas ses PDF aux contenants physiques.

Pour la recette réelle, gardez la configuration du document, l’envoi, les références de colis et les sorties observées sur le compte concerné. Faites vérifier le fichier complet sur le poste prévu, y compris ses pages supplémentaires. Une première page correcte peut masquer une facture dans la suite du même fichier. Corriger seulement le titre affiché ou envoyer uniquement la première page au hasard déplacerait la décision sans prouver le document autorisé.

Atelier : vingt cas fictifs sans imprimer ni appeler DHL

Reproduire une facture lisible envoyée vers la mauvaise destination

Le programme dhl_document_selection.py crée ses fichiers avec ReportLab et les lit avec pypdf. Les documents portent des mentions de démonstration et aucun code-barres DHL utilisable. Dans le choix naïf, la destination locale s’appelle label_queue, mais le premier document est déclaré facture. La lecture du PDF réussit ; aucune tâche n’est toutefois envoyée à une imprimante. Voici l’observation produite par cet essai.

{
  "claimedDestination": "label_queue",
  "declaredType": "invoice",
  "pdfFirstLine": "INVOICE - FIXTURE",
  "pdfReadable": true
}

Le seuil de recette de la sélection corrigée est une égalité vérifiable : lorsque facture et étiquette échangent leur position dans nos deux réponses fictives, le fichier retenu doit conserver l’empreinte du PDF d’étiquette. Le programme vérifie cette égalité. Il contrôle aussi l’absence de candidat, les candidats multiples, un autre envoi, le profil par pièce, un format différent, un Base64 incorrect et un PDF illisible. Ces résultats qualifient l’exercice local, sans certifier une réponse distante.

Relancer pypdf et ReportLab dans un environnement isolé

L’exécution vérifiée utilise Python 3.14.8, pypdf 6.0.0 et ReportLab 4.4.3, sans modifier ces bibliothèques. Les vingt cas passent 55 assertions. Le lecteur PDF est appelé dix fois : neuf lectures réussissent et un fichier volontairement incomplet produit le rejet attendu. Le nombre d’appels au lecteur ne représente ni dix documents DHL récupérés ni un taux de couverture du service transporteur.

python3 -m venv .venv-dhl-documents
.venv-dhl-documents/bin/python -m pip install \
  pypdf==6.0.0 reportlab==4.4.3 pillow==11.3.0 charset-normalizer==3.4.3
.venv-dhl-documents/bin/python dhl_document_selection.py
# checksPassed: 55 ; cases: 20 ; nativePdfReads: 10
# networkConnectionAttempts: 0 ; dhlApiCalls: 0
# printerJobs: 0 ; erpWrites: 0

Ajoutez --fixture-directory demonstration-documents pour enregistrer les trois PDF de comparaison sur votre machine. Le cas de page blanche reste construit en mémoire. Le programme interdit les connexions réseau et ne contient aucune opération d’expédition ou d’impression. La documentation Python de Base64 explique le contrôle de caractères employé ; réussir ce décodage ne démontre toujours pas que les octets forment le document attendu.

Garder visibles les limites que les cas négatifs révèlent

Contre-intuitivement, notre page blanche reste lisible comme PDF et devient un candidat pour revue quand ses métadonnées annoncent label. Un autre témoin annonce label sur les octets d’une facture ; un troisième cache deux usages derrière ce même rôle. Ils ne sont pas présentés comme des réponses capturées chez DHL. Ils montrent pourquoi la sortie du programme s’appelle candidate_for_document_review et ne comporte aucune autorisation d’impression.

La référence de PdfReader 6.0.0 documente le lecteur utilisé. La lecture du PDF et les informations extraites ne valident ni le code-barres, ni la mise à l’échelle, ni l’association au carton. La priorité, avant d’activer le poste, est donc une recette du profil et du fichier réellement fournis pour ce parcours, avec la logistique. Le démonstrateur expose précisément ce qu’il laisse à cette vérification.

Plan d’action : reprendre le document sans recréer l’expédition

Retrouver les octets et leur provenance

Sur le dossier concerné, retrouvez la demande de création, ses options documentaires, l’identifiant d’envoi, la réponse et le fichier stocké. Comparez ensuite l’empreinte du fichier affiché au poste avec celle des documents disponibles. Cette lecture permet de localiser un mauvais index, un rôle ignoré, une confusion de format ou une ancienne réponse réutilisée. Conservez la première observation : remplacer le fichier sans sa provenance rendrait la cause plus difficile à expliquer.

Dans le middleware, séparez le mapping de réponse du worker qui remet un document au consommateur. Le premier conserve l’opération, le rôle natif, le format, les références et le profil de demande. Le second reçoit un identifiant de document qualifié pour son usage. La queue d’impression ne doit pas retrouver ce fichier en relisant simplement le premier élément du payload initial ; elle doit pouvoir expliquer quel document du dossier a été retenu.

Choisir une reprise documentaire plutôt qu’un nouveau transport

Un retry de restitution peut reprendre un fichier déjà conservé, après vérification de son identité et du poste destinataire. Un timeout après une demande de création pose une autre question : l’expédition existe peut-être déjà. Le runbook doit distinguer ces étapes. L’idempotence proposée pour un travail documentaire appartient à votre application ; elle ne prouve aucune clé d’idempotence native DHL et n’autorise pas une seconde création d’expédition.

Le connecteur garde la responsabilité de la provenance : en entrée, la réponse enregistrée et le profil de demande ; en sortie, le document retenu, son empreinte et son usage soumis à revue. Le logiciel du poste doit conserver son propre statut de restitution. Cette séparation permet au monitoring de différencier document manquant, sélection ambiguë et remise non confirmée. Si le spooler accepte un travail, conservez cet événement séparément de la confirmation opérateur : le programme fourni ne teste ni ce spooler ni la pose du papier. Les critères d’ouverture du poste doivent être validés sur le parcours physique concerné.

• À corriger d’abord : la sélection dont la provenance démontre qu’elle a retenu une facture alors qu’un document label qualifié était disponible.
• À différer : le passage automatique au poste lorsque les options de regroupement, le découpage par pièce ou le format attendu restent à qualifier.
• À conserver en attente : une création transport dont l’issue est inconnue ; retrouver son résultat avant toute demande susceptible de créer un autre envoi.

Erreurs fréquentes entre réponse REST et impression

Faire porter au lecteur PDF une décision qu’il ne connaît pas

Le lecteur reconnaît une structure et permet d’examiner des pages. Il ne connaît pas le poste de préparation, la commande ou le profil d’étiquette configuré dans votre application. Une lecture réussie doit rester une observation technique. La renommer « prêt à expédier » ferait perdre le contrôle du document et du contenant au moment même où l’équipe cherche une preuve plus précise.

• Nommer tous les fichiers reçus « label.pdf » avant de lire leur rôle dans la réponse.
• Copier la propriété de format d’une autre opération DHL sans qualifier son modèle.
• Supposer qu’un document global correspond forcément à un seul colis ou à une seule page.
• Découper le PDF à la première page sans vérifier ce que demande le profil documentaire.
• Relancer la création d’expédition pour résoudre une erreur de restitution d’un fichier déjà disponible.

Tester la bonne granularité avant d’élargir le poste

Composez votre recette avec le compte et les modèles de documents réellement utilisés, puis faites varier les options que votre application permet de choisir. Incluez une demande avec plusieurs documents et une autre avec plusieurs colis lorsque ce parcours appartient au périmètre. L’équipe doit identifier les fichiers attendus, expliquer leur association et traiter une réponse ambiguë sans inventer une impression réussie. Les cas synthétiques préparent ces questions ; ils ne remplacent pas ces essais autorisés.

La reprise doit aussi garder le contexte du destinataire technique : poste logistique, vue de consultation ou archivage documentaire. Le même PDF peut être utile au support et inadapté à la file d’étiquettes. Conserver cette distinction évite de faire dépendre l’ERP d’un libellé générique « document reçu », alors que le WMS attend encore le fichier utilisable pour sa préparation.

Projets liés : la chaîne documentaire CHL Logistics

Séparer création transport, stockage et remise au système métier

La référence CHL Logistics et son middleware API transport présente une chaîne où la création DHL, le stockage du label et sa restitution au MDM constituent des étapes distinctes. Les échanges rattachés à l’expédition restent consultables dans le back-office. Cette organisation donne un point d’appui concret pour rechercher si l’écart se situe dans la réponse, le fichier conservé ou sa remise au logiciel consommateur.

Pour un chantier comparable, le cadrage doit identifier l’étape propriétaire du document et les données nécessaires à sa reprise. Le fichier doit rester rapprochable avec la demande qui l’a produit. L’exercice PDF ci-dessus travaille un contrôle de sélection à cette frontière ; la référence projet montre comment replacer cette frontière dans une orchestration plus large, avec des responsabilités distinctes pour le connecteur et le système métier.

Lectures complémentaires après la sélection du fichier

Retrouver le contenant auquel le document appartient

L’analyse des identifiants de cartons et des étiquettes Amazon FBA porte sur l’association avec le contenant physique. Elle traite un autre contrat, mais aide à séparer deux contrôles : choisir le document utile et savoir à quel carton le remettre. Un PDF sélectionné dans la bonne réponse ne prouve pas à lui seul cette seconde relation.

Pour le flux DHL, faites conserver la référence interne du contenant lorsque votre parcours exige une restitution par pièce. Le mainteneur peut alors expliquer l’association au préparateur sans réordonner des listes à la main. Les paramètres Amazon ne doivent pas être transposés à MyDHL : le rapprochement reste qualifié dans le contrat et le mode documentaire de chaque service.

Continuer le suivi sans confondre les destinataires de la remise

Le diagnostic d’un retour DHL annoncé livré au client examine un autre décalage de sens dans le SI : la remise peut terminer un trajet différent de celui imaginé par la commande. Il prolonge la lecture après l’étape documentaire, lorsque le support doit comprendre à qui le colis a réellement été remis.

Gardez les deux dossiers séparés dans le run : un mauvais document au poste ne démontre pas un statut de livraison erroné, et un retour transport ne justifie pas une nouvelle génération d’étiquette par défaut. La continuité utile consiste à conserver la même expédition tout en sachant quelle observation autorise l’action suivante, depuis le fichier jusqu’à la réponse apportée au client.

Conclusion : choisir le document avant de qualifier son impression

Le mauvais document peut s’ouvrir sans erreur. Le premier scénario le reproduit avec une facture placée avant le label ; la sélection par rôle retrouve ensuite le même fichier d’étiquette lorsque l’ordre change. Cette preuve locale aide à corriger un index fragile, tout en conservant le contrat de l’opération qui a produit la réponse.

Les regroupements de pages et les modes par pièce demandent une décision supplémentaire. Les vingt cas et les dix appels au lecteur PDF rendent également visibles les limites : une page blanche ou un contenu mal déclaré peut rester lisible. Le résultat du démonstrateur prépare une revue documentaire ; il ne valide aucune étiquette réelle, aucun code-barres et aucune impression.

Notre accompagnement pour relier DHL à votre préparation logistique peut reprendre la demande, les options et la restitution avec vos équipes. Le premier objectif est de localiser la sélection fautive et de qualifier le profil attendu, afin de réparer le document sans lancer une nouvelle expédition par réflexe.

Dawap peut cadrer cette correction dans une intégration API adaptée à vos flux documentaires, puis recetter la continuité jusqu’au logiciel qui reçoit le document et au poste de préparation. Vous devez pouvoir retrouver pourquoi un fichier a été choisi, quelle utilisation a été validée et quelle reprise reste possible sur le dossier déjà créé.