DPD SOAP : un poids multiplié par dix dans un XML valide

Votre ERP annonce un colis de 1,25 kg. Le connecteur transmet 1250 à DPD, le XML passe la validation et personne ne voit immédiatement le problème : dans le contrat SOAP étudié ici, cette valeur représente 12,5 kg. La multiplication par dix peut donc entrer dans le flux sans erreur de type. Le diagnostic doit commencer par l’unité exacte du champ envoyé et la masse du colis effectivement préparé, avant d’attribuer l’écart à la balance ou au transporteur.

Le diagnostic porte sur DPD Allemagne, ShipmentService 3.2, avec sa documentation de 2017 et son schéma XML officiel. Il ne décrit ni un contrat DPD France ni la version 4.5 présentée dans le portail allemand actuel. Sur cette interface ancienne, weight et mpsWeight utilisent des unités de 10 grammes : 300 correspond à 3 kg. Un entier valide ne démontre donc pas que le poids du colis est juste.

Vous allez reproduire l’erreur avec le schéma fournisseur complet, différencier une faute de format d’une faute de conversion, puis contrôler un envoi de deux colis dont le total paraît correct. L’exercice reste hors ligne : aucune expédition, aucune étiquette et aucune écriture ERP. Pour reprendre un connecteur en service, notre accompagnement entre DPD et votre préparation logistique replace ces champs dans le contrat réellement souscrit ; le périmètre plus large relève de notre expertise en intégration API.

Pour quels flux ce contrôle de poids est-il utile ?

Un connecteur ancien dont la conversion reste peu visible

Le lecteur concerné est le responsable de l’interface ERP ou WMS qui alimente encore ce service allemand. Le symptôme peut apparaître après un changement de balance, une nouvelle colonne d’export ou une reprise de middleware : une donnée nommée « poids » circule, mais son unité n’accompagne plus sa valeur. Le développeur voit un entier, la logistique voit des kilogrammes et la recette vérifie surtout la présence du document. Ces trois lectures peuvent sembler cohérentes sans désigner la même masse.

Avant de tester une conversion, relevez l’URL et le namespace réellement utilisés, la version du contrat, le pays de l’interface et l’endroit où le poids est produit. Un abonnement DPD ou un logo commun ne suffit pas à identifier le service. Si votre connecteur utilise une passerelle transport, c’est d’abord le contrat de cette passerelle qu’il faut lire : elle peut déjà convertir les kilogrammes avant d’appeler le fournisseur. Ajouter une seconde conversion à cet endroit reproduirait le défaut que vous cherchez à corriger.

Le poids préparé doit pouvoir être retrouvé par colis

Une masse catalogue ne remplace pas automatiquement une masse de colis emballé. La somme des produits peut exclure carton, calage ou répartition entre deux emballages. Pour l’exercice, nous disposons d’un manifeste local fictif approuvé après colisage : il associe une référence de colis à une masse exprimée explicitement en kilogrammes. Cette source sert de référence au contrôle ; elle n’est ni une réponse DPD ni un modèle de document imposé par le transporteur.

Si l’équipe ne sait pas expliquer d’où vient cette masse, la priorité consiste à rétablir sa provenance. Comparer deux champs issus de la même conversion erronée peut produire un rapprochement parfait et inutile. Une mesure préparateur, une pesée enregistrée ou un manifeste validé peut fournir un autre point de comparaison, à condition d’en conserver l’origine et le périmètre. Le contrôle informatique détecte un écart entre représentations ; il ne certifie pas l’étalonnage d’une balance.

Lire deux champs voisins sans confondre leur portée

Le même facteur de conversion, deux niveaux différents

La référence DPD Allemagne ShipmentService 3.2 décrit generalShipmentData.mpsWeight page 16 et parcel.weight page 23. Le premier porte le poids de l’envoi ; le second celui d’un colis. Pour les masses exactes choisies ici, la conversion depuis les kilogrammes est donc valeur_kg × 100. Depuis les grammes, elle correspond à une division par dix. Transmettre directement 1 250 grammes dans le champ ne signifie pas transmettre 1,25 kg.

La documentation parle d’un poids arrondi en unités de 10 grammes, mais ce passage ne fixe pas à lui seul le sens d’arrondi applicable à toutes vos opérations. L’exercice évite de l’inventer : il accepte uniquement les masses positives qui sont déjà des multiples exacts de 10 grammes. Une entrée de 1,251 kg part en revue locale. Ce choix de conception rend le manque de règle visible ; il ne constitue pas une règle d’arrondi DPD.

Ce que le schéma peut réellement refuser

Dans le XSD officiel complet de cette version, weight repose sur xs:int et mpsWeight sur xs:long, avec une borne maximale de 99 999 999 et une occurrence minimale à zéro. Le schéma refuse notamment notre valeur décimale 1.25 dans le champ entier et notre valeur supérieure à la borne. Il n’exprime pas, dans ces restrictions, la correspondance avec une pesée de votre entrepôt.

Autre résultat à garder dans la recette : sur le document fictif construit ici, une valeur négative passe cette validation XSD, tout comme l’omission du poids. Cela ne rend ces demandes ni admissibles en exploitation ni acceptées par un serveur DPD. Les champs étudiés n’ont simplement pas de borne minimale positive dans ce schéma. L’acceptation par l’API, les limites commerciales et les contraintes propres aux produits demandent d’autres contrôles. Une borne technique à huit chiffres n’est pas une capacité de transport autorisée.

Exercice : faire passer un mauvais poids au vrai validateur XML

Un schéma intact, quinze documents fictifs

Le programme dpd_weight_contract.py charge une copie locale du XSD DPD, vérifie son empreinte SHA-256 et la compile avec lxml.etree.XMLSchema. Le schéma n’est ni raccourci ni réécrit pour accepter les exemples. Chaque cas crée le corps storeOrders avec les éléments nécessaires à sa validation, dont des adresses fictives et un produit CL. L’enveloppe SOAP, l’authentification et une réponse serveur ne font pas partie du test.

Le premier scénario fictif reproduit la faute de conversion. Le manifeste attribue 1,25 kg au colis P-01, tandis que le document construit contient 1250 pour son poids et celui de l’envoi. La validation contre le schéma fournisseur accepte la forme. Le seuil de contrôle local est l’égalité avec les 125 unités attendues du manifeste : il refuse donc la poursuite. Les deux verdicts ne répondent pas à la même question.

{
  "case": "grams_in_wire_field",
  "nativeXsdValid": true,
  "localDecision": "parcel_mass_mismatch"
}

L’exécution vérifiée emploie Python 3.14.8 et lxml 6.0.1, une version publiée le 22 août 2025. Les quinze validations portent sur le XSD complet téléchargé depuis DPD ; les 47 contrôles incluent aussi les restrictions des deux champs, la conversion locale et les verdicts attendus. Ce résultat démontre une reproduction hors ligne, sans appel au service de création d’expédition.

Relancer sans envoyer de demande de transport

La commande ci-dessous prépare un environnement isolé, récupère le schéma public puis lance le programme fourni. Le téléchargement du XSD nécessite un accès web ; le programme, lui, lit ce fichier local et interdit les connexions réseau. S’il ne reconnaît pas l’empreinte du fichier, il s’arrête : examinez le nouveau document avant de modifier l’empreinte attendue. Ne remplacez pas cette vérification par un accord donné à toute réponse HTTP.

python3 -m venv .venv-dpd-weight
.venv-dpd-weight/bin/python -m pip install lxml==6.0.1
curl --fail --location \
  'https://public-ws.dpd.com/services/ShipmentService/V3_2/?xsd=ShipmentService-Public_3_2.xsd' \
  --output ShipmentService-Public_3_2.xsd
.venv-dpd-weight/bin/python dpd_weight_contract.py \
  ShipmentService-Public_3_2.xsd
# checksPassed: 47 ; nativeSchemaRuns: 15
# networkConnectionAttempts: 0 ; externalWrites: 0

Le programme construit ses documents en mémoire, compile le schéma sans accès réseau et ne possède aucune opération d’envoi. Les noms et adresses de démonstration servent uniquement à satisfaire les éléments XML nécessaires au test. Ne les utilisez pas pour une expédition. Pour comprendre ce que prouve validate() et consulter ses erreurs, la documentation de validation lxml distingue la lecture XML du contrôle par schéma. Ni l’une ni l’autre ne pèse le colis.

Comparer les verdicts sans les fusionner

Contre-intuitivement, retirer le poids laisse notre document valide au regard du XSD, alors que le contrôle du manifeste bloque l’émission dans le périmètre choisi. Ajoutez à vos résultats trois colonnes distinctes : validation du contrat XML, comparaison avec le colis préparé, puis réponse effective du service si une demande autorisée est émise ensuite. Un seul indicateur « OK » effacerait précisément le défaut que l’exercice expose.

Un total juste peut cacher deux colis faux

Répartir 4,25 kg ne signifie pas recopier 425

Le deuxième scénario fictif contient P-01 à 2 kg et P-02 à 2,25 kg. Le manifeste attend respectivement 200 et 225 unités, pour un total de 425. Si le mapping recopie mpsWeight=425 dans chaque bloc colis, l’envoi conserve un total apparemment rassurant, mais les deux masses individuelles sont fausses. Le XSD valide aussi ce document : il ne compare pas ces champs entre eux dans le test réalisé.

La correction ne consiste pas à diviser uniformément le total par le nombre de colis. Cette opération fabriquerait deux colis de même poids sans savoir ce qui a été emballé. Reprenez le manifeste issu du colisage et associez chaque masse à sa référence stable. Un calcul exact sur de mauvaises entrées reste faux. En l’absence de masses par colis, le connecteur doit signaler cette information manquante plutôt que produire une répartition dont personne ne peut expliquer l’origine.

Rapprocher les références avant d’additionner

L’exercice inverse aussi les deux masses : 225 sur P-01 et 200 sur P-02. La somme reste 425, le schéma passe, mais les deux associations sont incorrectes. À l’inverse, changer seulement l’ordre des blocs XML conserve un résultat cohérent quand les références suivent leurs masses. Le contrôle local utilise donc les références de colis ; une comparaison fondée uniquement sur la position dans une liste échouerait dès qu’un tri diffère entre le WMS et l’export.

Une référence dupliquée ou un colis manquant doit arrêter ce rapprochement avant le contrôle du total. Dans le programme, un doublon renvoie duplicate_parcel_reference, tandis qu’un ensemble de colis différent du manifeste renvoie parcel_set_mismatch. Ces libellés appartiennent à notre diagnostic local. Ce ne sont pas des codes d’erreur DPD. Leur intérêt est de transmettre au préparateur une anomalie précise plutôt que l’instruction peu exploitable « refaire le poids ».

Plan d’action : corriger le mapping avant toute émission

Garder la valeur d’origine jusqu’à la sortie XML

Commencez par un dossier dont le colisage est connu. Conservez la valeur ERP, son unité déclarée, la référence du colis, la transformation appliquée et l’entier présent dans le XML produit. Recalculez ensuite la masse représentée par cet entier selon le contrat identifié. Cette lecture aller-retour distingue trois causes : mauvaise unité à l’entrée, mauvaise conversion dans le middleware ou mauvaise affectation entre colis. Modifier uniquement le champ de sortie peut masquer la première cause et déplacer l’erreur vers un autre transporteur.

Dans le worker d’expédition, placez le contrôle après la constitution du colisage et avant l’opération d’envoi. Son entrée doit contenir un manifeste stabilisé et le document qui sera réellement soumis ; sa sortie autorise le passage à l’étape suivante ou renvoie un motif local de blocage. La validation XSD précède l’interprétation numérique des champs, afin qu’une valeur invalide ne soit pas traitée comme un entier exploitable. La file conserve le dossier et le motif ; elle ne renvoie pas automatiquement le même document inchangé.

Une correction de poids ne justifie pas un nouvel affranchissement aveugle

Si aucune demande n’est partie, corrigez la transformation puis reconstruisez le document depuis le manifeste approuvé. Si une demande a déjà été envoyée, ou si sa réponse manque après un timeout, le problème change de nature : une étiquette peut déjà exister. Retrouvez d’abord l’état de l’expédition par les moyens réellement disponibles dans votre contrat et vos journaux. Le présent exercice ne qualifie ni une procédure d’annulation ni une clé d’idempotence native DPD ; il ne permet donc pas d’autoriser une seconde création.

Pour la mise en œuvre, journalisez la version du mapping et la référence de la préparation qui a servi au calcul. Un retry technique doit conserver le même dossier de contrôle ; une nouvelle pesée ou un nouveau colisage exige une décision distincte, datée et relisible. Le monitoring utile expose les conversions bloquées, les références non rapprochées et les demandes dont l’émission demeure incertaine. Les durées d’attente et les destinataires d’alerte doivent être fixés avec l’exploitation, à partir de son heure de départ et de sa capacité de reprise.

Le runbook doit permettre de retrouver le payload XML associé à une préparation, sans émettre de nouvelle demande. Pour cet incident, l’observabilité doit conserver le détail par colis : si P-01 reçoit 1250 au lieu de 125, une alerte portant uniquement sur le total ne suffit pas à expliquer la correction. Le mainteneur doit retrouver la version qui a produit cet entier, tandis que le préparateur vérifie la masse et la référence du contenant concerné.

• À corriger avant émission : la conversion démontrée fausse, puis le document reconstruit depuis les masses approuvées de P-01 et P-02.
• À différer : la conversion d’une masse qui exige un arrondi tant que le sens de cet arrondi n’a pas été décidé pour le contrat utilisé.
• À conserver en attente après un timeout : le dossier de création dont l’issue reste incertaine, afin de retrouver l’expédition éventuelle avant toute nouvelle demande.

Erreurs fréquentes lors de la reprise d’un flux DPD

Transformer une convention technique en règle générale

Le portail allemand de documentation DPD présente désormais ShipmentService 4.5. Cela confirme qu’il faut identifier un ancien contrat avant de le diagnostiquer ; cela ne démontre pas que tous les champs, produits ou modes d’authentification sont restés identiques. La référence 3.2 ne justifie pas non plus d’imposer sa convention aux services français, à une API REST différente ou à un agrégateur. Pour un nouveau projet, qualifiez l’interface proposée par votre interlocuteur DPD avant de choisir une version.

• Supprimer le séparateur décimal de « 1,25 » sans convertir une unité explicitement connue.
• Appliquer deux fois la conversion parce que l’ERP et la passerelle prétendent chacun livrer le poids prêt à envoyer.
• Valider seulement la somme, alors que les masses sont inversées entre deux références de colis.
• Déduire une autorisation de transport ou de facturation de la seule borne maximale du schéma XML.
• Réémettre une demande déjà partie pour corriger le poids sans rechercher ce qui a été créé.

Choisir une sortie explicable pour la logistique

Un message d’échec doit montrer ce que l’équipe peut vérifier : « P-01, manifeste 1,25 kg, valeur XML 1250, masse représentée 12,5 kg ». Il doit aussi indiquer si l’envoi est encore bloqué avant émission ou s’il existe une incertitude sur une demande déjà transmise. Ces situations n’appellent pas le même geste. Évitez d’afficher une adresse complète ou d’autres données destinataire dans ce diagnostic de poids : elles ne sont pas nécessaires pour expliquer le facteur dix.

Pour ouvrir le flux corrigé, faites relire un dossier à un préparateur et un autre au mainteneur du connecteur. Ils doivent retrouver les deux masses, l’unité et la référence sans recalculer une valeur à partir d’une capture d’écran. Les cas négatifs de l’exercice servent de critères de recette : mauvaise unité bloquée, masses inversées détectées, ordre différent accepté, poids manquant explicitement refusé localement. Leur réussite ne remplace pas les essais autorisés avec DPD sur votre contrat réel.

Guides complémentaires pour élargir le contrôle aux colis

Lorsque le contenant et son contenu se désaccordent

Une masse correctement convertie peut encore appartenir au mauvais carton. L’analyse de la hiérarchie carton et palette dans un DESADV traite l’association entre un emballage et son contenu. Il complète ce diagnostic lorsque l’ERP, le WMS et le message d’expédition ne découpent pas la préparation de la même manière. La convention de poids DPD ne doit pas être transposée à ce message EDI : chaque contrat garde ses unités et ses règles.

Pour un envoi de deux colis, demandez au WMS de retrouver P-01 et P-02 derrière les lignes d’emballage avant de comparer les masses. Si les références décrivent une palette d’un côté et un carton de l’autre, le facteur de conversion ne réparera pas ce rapprochement. La recette doit d’abord porter sur les mêmes contenants.

Lorsque le chiffre représente un volume plutôt qu’une masse pesée

Le diagnostic du poids volumétrique après une mauvaise conversion du volume traite une autre grandeur : un volume ne reçoit pas le facteur d’une longueur. Il concerne les calculs commerciaux du vendeur, avec leurs coefficients de service à vérifier. Ici, nous contrôlons une masse de colis préparé dans un champ DPD. Si le chiffre contesté vient d’un volume ou d’un tarif, suivez ce dossier séparément ; convertir correctement le champ SOAP ne démontre aucun poids facturé ni aucune économie.

Lorsqu’une facture indique un poids différent, conservez séparément la pesée d’entrepôt, la masse envoyée à DPD et la base de calcul portée par les pièces de transport. Le premier rapprochement vérifie le mapping ; le second examine les conditions du service. Leur confusion ferait corriger une valeur mesurée pour tenter de compenser un tarif.

Conclusion : rapprocher une masse, une unité et un colis

Sur DPD Allemagne ShipmentService 3.2, le facteur dix n’est pas une panne du validateur XML. Le schéma contrôle un entier conforme à ses restrictions ; le manifeste de préparation permet de vérifier si cet entier décrit le bon poids. L’exercice reproduit cette séparation avec quinze documents, dont des valeurs incorrectes qui restent valides au regard du XSD. C’est cette comparaison supplémentaire qui rend l’erreur visible avant émission.

Le contrôle doit conserver sa précision lorsque l’envoi contient plusieurs colis : références rapprochées, masses individuelles comparées, total vérifié et règle explicite lorsque la donnée manque. Un total égal ne corrige pas deux masses inversées. Un arrondi non décidé ne doit pas être caché dans une conversion. Et le résultat « prêt pour revue avant envoi » du programme ne signifie jamais qu’une demande a été acceptée par DPD.

Pour corriger un flux existant, notre équipe d’intégration DPD peut cadrer les unités, le colisage, le mapping et les contrôles du contrat que vous utilisez réellement. La première pièce à apporter est un dossier rapprochable entre préparation et XML, accompagné de sa version d’interface, afin de décider où intervenir sans créer une nouvelle expédition par erreur.

Quand le défaut traverse plusieurs logiciels, notre accompagnement en intégration API sur mesure permet de cadrer la correction à sa source, puis d’organiser une recette commune avec vos équipes ERP et logistiques. L’objectif concret est qu’une masse de 1,25 kg reste identifiable comme telle jusqu’au document transmis, même lorsque chaque système l’exprime différemment.