ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

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.

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).

edifact contrl-d96a-ack-example.edi
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) :

edifact contrl-d96a-reject-example.edi
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 exactement UNB[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 UNH d'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 :

É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.

json contrl-d96a-equivalent.json
{
  "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": []
  }
}