Comment lire un message EDIFACT rejeté
- min de lecture
- 8 min de lecture
- Publié le
- Publié le
- Mis à jour le
- Mis à jour le
- Écrit pour :
- Intégrateurs EDI, équipes SI et responsables ADV qui reçoivent des rejets sans documentation exploitable.
Réponse courte
Comment identifier la cause d’un message EDIFACT rejeté ?
Pour identifier la cause d'un rejet EDIFACT, il faut partir du message brut réellement transmis et non de son affichage dans l'outil d'intégration, puis lire l'accusé technique — un CONTRL, lorsqu'il est envoyé, nomme généralement le segment et l'élément fautifs. On confronte ensuite ce segment à la spécification en vigueur du partenaire, et on détermine si l'écart vient du mapping (la donnée existe mais est mal placée ou mal codée) ou de la donnée source (le mapping est correct mais reçoit une valeur erronée). Ces deux cas se corrigent à des endroits différents.
Étape 1 — Récupérer le message brut
L'affichage d'un message dans une interface d'intégration est une reconstitution. Elle masque presque toujours des détails décisifs : séparateurs, éléments vides, longueurs réelles, encodage.
Le seul artefact qui compte est le fichier réellement transmis. C'est celui que le partenaire a évalué, et c'est le seul sur lequel un écart peut être démontré.
Étape 2 — Lire l’accusé technique
Quand le partenaire en émet un, l'accusé technique (CONTRL dans le monde EDIFACT) indique le niveau auquel l'erreur a été détectée : interchange, groupe, message, segment ou élément de données.
Un rejet au niveau segment ou élément est une bonne nouvelle : il pointe l'endroit exact. Un rejet au niveau interchange indique plutôt un problème d'enveloppe, d'identifiants d'échange ou de structure globale.
Étape 3 — Confronter à la spécification en vigueur
Un message EDIFACT est conforme à la norme et néanmoins refusé, parce que chaque partenaire publie un sous-ensemble avec ses propres obligations : segments requis, qualifiants imposés, longueurs restreintes, jeux de codes fermés.
La question n'est jamais « ce message est-il valide ? » mais « ce message est-il conforme à ce que ce partenaire attend, dans la version en vigueur aujourd'hui ? ».
Étape 4 — Isoler le segment fautif
- Comparer le dernier message accepté et le premier message rejeté, ligne à ligne. L’écart est souvent unique et minuscule.
- Vérifier les qualifiants avant les valeurs : un code correct dans le mauvais qualifiant est la cause la plus banale et la plus difficile à voir.
- Contrôler les segments conditionnels : ils deviennent obligatoires selon le contexte, et ce contexte change avec le type de transaction.
- Regarder les éléments vides transmis explicitement, qui ne sont pas équivalents à des éléments absents.
Étape 5 — Distinguer erreur de mapping et erreur de donnée
Si la valeur attendue existe dans l'ERP mais arrive mal placée, mal codée ou tronquée, c'est le mapping qu'il faut corriger.
Si le mapping transporte fidèlement une valeur qui est déjà fausse en amont, corriger le mapping revient à masquer le défaut : il ressortira sur un autre flux. La correction appartient au processus qui produit la donnée.
Cette distinction détermine qui corrige, où, et si le problème réapparaîtra ailleurs. C'est la seule conclusion vraiment utile de l'analyse.
Les messages où ces rejets se manifestent le plus
| Message | Rôle | Effet d’un rejet |
|---|---|---|
| ORDERS | La commande, début de la chaîne. | L’erreur se propage jusqu’à la facture : le symptôme apparaît loin de sa cause. |
| DESADV | L’avis d’expédition, avant l’arrivée des marchandises. | Peut bloquer physiquement une réception à quai. |
| INVOIC | La facture. | Effet direct sur la trésorerie : le délai de paiement ne court pas. |
| CONTRL | L’accusé technique. | Son absence prive de tout diagnostic : le message part sans retour exploitable. |