CONTRL — Syntax and Service Report Message (D.96A)
Le message CONTRL est l'accusé technique automatique d'EDIFACT : il acquitte ou rejette, avec indication d'erreur, un interchange, un groupe fonctionnel ou un message reçu.
Objet du message
Le message CONTRL « a pour but d'acquitter syntaxiquement ou de rejeter, avec
indication d'erreur, un interchange, un groupe fonctionnel ou un message reçu ».
Il fonctionne à deux modes : accusé de réception (l'interchange
est arrivé) ou rapport d'erreur (l'interchange a été parsé mais
contient des défauts syntaxiques). C'est l'analogue du 250 OK /
5xx Error du protocole SMTP, transposé en EDIFACT.
CONTRL est généré automatiquement par les contrôleurs syntaxiques (Mendelson, OFTP2, AS2, plateformes Generix/Tradeshift). Il n'est jamais émis manuellement et ne contient aucune information métier — seulement la conformité au standard ISO 9735.
Structure segmentaire
CONTRL D.96A a une structure plate : Header minimal, puis une
séquence de segments UCI → groupes SG1 → SG3 (UCM, UCF). Pas de section
Summary séparée — le message se termine simplement par
UNT.
Header
Le header se réduit à : UNH M , puis UCI M .
Le segment UCI est la clé de voûte : il porte le numéro d'interchange
acquitté (qui doit correspondre à UNB[4] de l'original), les identifiants
expéditeur et destinataire de l'interchange acquitté (inversés par rapport à
l'original — l'émetteur du CONTRL est l'ancien récepteur), et le code d'action (4 =
interchange rejeté avec erreurs, 7 = interchange acquitté sans erreur, 8 = acquitté
partiellement).
Detail (UCI / UCM / UCS / UCD / UCF)
Après UCI, deux structures de rapport coexistent — selon que l'interchange d'origine portait des messages individuels ou des groupes fonctionnels.
SG1 — boucle répétable jusqu'à 999 999 fois : un UCM M par message acquitté. Chaque UCM peut contenir SG2 (répétable 999 fois) : UCS M et son UCD C .
SG3 — boucle répétable jusqu'à 999 999 fois, alternative à SG1 quand l'interchange utilisait UNG/UNE : un UCF M par groupe. UCF peut contenir un SG4 (jusqu'à 999 999 UCM ), lui-même contenant un SG5 avec UCS + UCD pour le détail erreur.
En pratique, SG3/UCF est rare dans les flux modernes (les groupes fonctionnels UNG/UNE sont peu utilisés en B2B retail). La plupart des CONTRL portent un seul UCI suivi d'un ou plusieurs UCM.
Summary
CONTRL ne possède pas de section Summary distincte ni de segment UNS. Le
message se termine directement par :
UNT M .
Obligatoire / conditionnel
Trois segments sont strictement mandataires dans tout CONTRL D.96A :
UNH— ouvre le message, porte la version sans identifiant d'association.UCI— identifie l'interchange acquitté et son statut. Sans UCI, le CONTRL est invalide.UNT— ferme le message, déclare le nombre de segments.
Si l'interchange acquitté contient au moins un message, alors UCM ou
UCF doit également apparaître. En cas d'erreur, UCS et
UCD précisent le segment et l'élément fautifs avec un code d'erreur tiré
de la liste D.E. 9968 (1 = champ obligatoire manquant, 5 = erreur de syntaxe générale,
13 = erreur de structure de message, etc.).
Exemple réel
Un acquittement positif : le récepteur (acheteur GLN 5410000000123) confirme avoir correctement parsé l'interchange ORDERS de l'exemple ORDERS de référence (numéro CTRL000001, émis par le fournisseur GLN 5410000000456).
UNB+UNOC:3+5410000000123:14+5410000000456:14+260513:1445+CTRL-ACK-001'
UNH+1+CONTRL:D:96A:UN'
UCI+CTRL000001+5410000000456:14+5410000000123:14+7'
UCM+1+ORDERS:D:96A:UN:EAN008+7'
UNT+4+1'
UNZ+1+CTRL-ACK-001' UNH+1+CONTRL:D:96A:UN— message CONTRL en version D.96A. Notez l'absence de l'identifiant d'association (pas de:EAN008).UCI+CTRL000001+5410000000456:14+5410000000123:14+7— référence l'interchange CTRL000001, identifie l'émetteur et le récepteur d'origine, code d'action 7 (interchange acquitté sans erreur).UCM+1+ORDERS:D:96A:UN:EAN008+7— confirme que le message ORDERS de référence « 1 » a été correctement parsé, code 7 (message acquitté).UNT+4+1— 4 segments dans le message (UNH, UCI, UCM, UNT), référence « 1 » en cohérence avec UNH.
À l'inverse, un acquittement négatif avec rapport d'erreur — l'envoi d'un interchange CTRL000099 qui contenait un message ORDERS avec une erreur sur le segment 15 (DE 3055, code d'erreur 5) :
UNB+UNOC:3+5410000000123:14+5410000000456:14+260513:1450+CTRL-ACK-002'
UNH+1+CONTRL:D:96A:UN'
UCI+CTRL000099+5410000000456:14+5410000000123:14+4+12'
UCM+1+ORDERS:D:96A:UN:EAN008+4+13'
UCS+15+12'
UCD+12+3055+1+5'
UNT+6+1'
UNZ+1+CTRL-ACK-002' UCI+...+4+12— action 4 (interchange rejeté), code d'erreur 12 (erreur de syntaxe).UCM+1+ORDERS:D:96A:UN:EAN008+4+13— message rejeté, code 13 (erreur de structure).UCS+15+12— segment n°15 fautif, code d'erreur 12.UCD+12+3055+1+5— élément 3055 fautif (code d'organisation responsable du code), erreur 5 (valeur invalide).
Erreurs fréquentes
- Inversion sender/receiver dans UCI — l'émetteur du CONTRL est le récepteur de l'interchange acquitté, et inversement. Une inversion crée un mismatch de routage côté plateforme EDI.
- Référence UCI[1] divergente — la référence d'interchange portée dans
UCI[1]doit matcher exactementUNB[4]de l'interchange acquitté. Toute divergence fait que l'émetteur d'origine ne peut pas lier le CONTRL à son envoi. - Codes d'action invalides — UCI[5] (action) accepte 4 (rejected), 7 (acknowledged), 8 (partially accepted). Tout autre code crée une ambiguïté côté plateforme.
- UNH avec association id — contrairement aux messages trade, le
UNHd'un CONTRL ne porte pas d'association (pas de:EAN008). Beaucoup de générateurs naïfs en ajoutent par mimétisme. - CONTRL non émis — la plupart des plateformes EDI exigent un CONTRL par interchange reçu, dans un délai (généralement 15 minutes). L'absence de CONTRL est interprétée comme un échec de parsing.
Messages liés
CONTRL est l'enveloppe d'acquittement de tous les autres messages EDIFACT :
- ORDERS D.96A — la commande, dont chaque interchange déclenche un CONTRL.
- ORDRSP D.96A — la réponse à commande, idem.
- INVOIC D.96A — la facture, idem.
- DESADV D.96A — l'avis d'expédition, idem.
- APERAK D.96A — acquittement applicatif (niveau métier, complémentaire à CONTRL syntaxique).
Équivalent JSON
Projection JSON correspondant à l'exemple d'acquittement positif. Ce mapping n'est pas normatif : c'est une convention ediverse pour faciliter l'intégration en TypeScript / Python.
{
"interchange": {
"controlRef": "CTRL-ACK-001",
"from": { "id": "5410000000123", "qualifier": "14" },
"to": { "id": "5410000000456", "qualifier": "14" },
"datetime": "2026-05-13T14:45:00Z",
"syntax": { "id": "UNOC", "version": "3" }
},
"message": {
"ref": "1",
"type": "CONTRL",
"version": { "syntax": "D", "release": "96A", "agency": "UN" }
},
"controlReport": {
"subject": {
"interchangeRef": "CTRL000001",
"from": { "id": "5410000000456", "qualifier": "14" },
"to": { "id": "5410000000123", "qualifier": "14" }
},
"interchangeAction": "7",
"interchangeActionLabel": "Acknowledgement that the interchange has been received and is acceptable",
"messages": [
{
"ref": "1",
"type": "ORDERS",
"version": "D:96A:UN:EAN008",
"action": "7",
"actionLabel": "Message acknowledged, no syntax errors"
}
],
"errors": []
}
}