APERAK — Application Error and Acknowledgement Message (D.96A)

APERAK est l'acquittement applicatif : il informe l'émetteur d'un message que celui-ci a été reçu par l'application du destinataire, et soit accepté (acknowledgement), soit rejeté à cause d'une erreur métier détectée à l'exécution (application error).

Objet du message

Selon la définition fonctionnelle UN/CEFACT, APERAK remplit deux fonctions :

« to inform a message issuer that his message has been received by the addressee's application and has been rejected due to errors encountered during its processing in the application » ;
« to acknowledge to a message issuer the receipt of his message by the addressee's application ».

Le principe est explicite : un message est d'abord contrôlé au niveau système (CONTRL) pour détecter les erreurs de syntaxe et acquitter la réception, puis transmis à l'application pour traitement. Si une erreur est détectée au niveau applicatif, empêchant le traitement complet, un APERAK est renvoyé à l'émetteur avec les détails de l'erreur. Si aucune erreur n'est détectée et qu'un acquittement est nécessaire (quand aucun message de réponse dédié n'existe — pas d'ORDRSP pour un ORDERS, etc.), APERAK sert d'accusé de réception applicatif.

Structure segmentaire

APERAK D.96A est un message très court, sans Detail/Summary. Tout est défini dans aperak_s.htm (segment table) et aperak_d.htm (clarification).

Au niveau du header, les segments mandataires sont UNH M et BGM M . Les autres segments header sont conditionnels : DTM C , FTX C , et CNT C .

Groupes de segments

Quatre groupes de segments :

SG1 (C, ×9) — RFF + DTM : référence au message original acquitté (souvent RFF+ON pour Order Number, RFF+IV pour Invoice, etc.) et date de référence.
SG2 (C, ×9) — NAD + CTA + COM : parties prenantes (émetteur de l'APERAK, contact technique, etc.).
SG3 (C, ×999) — ERC + FTX + SG4 : la section des erreurs / acquittements. Le segment ERC M est obligatoire à l'intérieur du groupe : il porte le code d'erreur (ou d'acquittement) dans son composite C901. FTX donne le détail en clair.
SG4 (C, ×1, à l'intérieur de SG3) — RFF + FTX : référence précise dans le message original (numéro de ligne, segment fautif, position) et texte libre.

Le message se clôt par UNT M .

Obligatoire / conditionnel

Strictement mandataires dans tout APERAK D.96A :

UNH, UNT — encadrent le message.
BGM — type d'acquittement applicatif (qualifier 313 = application error notification, 312 = administrative message).
ERC (à l'intérieur de SG3) — code d'erreur ou d'acquittement, obligatoire si SG3 est instancié.

Au niveau standard, tout le reste est conditionnel. Mais en pratique : sans SG1 RFF qui pointe vers le message d'origine, le récepteur ne peut pas savoir quel message est acquitté ou rejeté ; sans SG3 ERC, le message n'apporte pas d'information utile. Les deux sont donc systématiquement présents en production.

Exemple réel

Acquittement d'erreur émis par un industriel (ACME SUPPLY GMBH) en réponse à un ORDERS reçu d'une centrale d'achat, avec deux erreurs applicatives détectées : un GLN acheteur inconnu et un GTIN obsolète sur une ligne.

edifact aperak-d96a-example.edi

UNB+UNOC:3+5410000000456:14+5410000000123:14+260513:1530+CTRL000200'
UNH+1+APERAK:D:96A:UN'
BGM+313+APERAK-2026-0099+9'
DTM+137:202605131530:203'
RFF+ON:ORDER789'
DTM+171:20260513:102'
NAD+EM+5410000000456::9++ACME SUPPLY GMBH'
ERC+ME010:::Unknown buyer GLN'
FTX+ABO+++GLN 5410000099999 NOT REGISTERED IN OUR MASTER DATA'
RFF+LI:1'
ERC+ME015:::GTIN not in catalogue'
FTX+ABO+++LINE 2: GTIN 3520000005678 SUPERSEDED ON 2026-04-01'
RFF+LI:2'
UNT+13+1'
UNZ+1+CTRL000200'

BGM+313+APERAK-2026-0099+9 — code 313 (application error notification), numéro APERAK-2026-0099, statut 9 (original).
RFF+ON:ORDER789 — référence à l'ORDERS rejeté (ON = Order Number). DTM+171 = date de référence.
NAD+EM — Message Issuer (qualifier EM = émetteur du message APERAK).
ERC+ME010 — première erreur, code applicatif propre à ACME (le standard impose le segment, pas le référentiel de codes — chaque éditeur publie son lexique).
FTX+ABO — Reason (qualifier ABO = Reason for adjustment) explicitant l'erreur en clair.
RFF+LI:1 — Line Item référence (LI = Line Identifier), précisant la ligne fautive (1 = header pour la première erreur, 2 pour la deuxième).
UNT+13+1 — 13 segments dans le message (UNH et UNT inclus).

APERAK vs CONTRL

La confusion APERAK / CONTRL est classique. La séparation est nette :

Aspect	CONTRL	APERAK
Niveau	Syntaxique / interchange	Applicatif / business
Quand	Dès réception, automatique	Après traitement par l'application
Détecte	UNH absent, UNT mismatch, mauvais segment, séparateur invalide	GLN inconnu, GTIN obsolète, stock insuffisant, prix hors marché
Émetteur	Translateur EDI (Sterling, Babelway, Stedi…)	Application métier (ERP, WMS, TMS…)
Action	Automatique côté translateur	Manuelle ou automatique selon le code d'erreur

Un même flux peut générer les deux dans l'ordre : d'abord CONTRL (acquittement syntaxique positif), puis APERAK plus tard (rejet métier).

Erreurs fréquentes

ERC sans référentiel partagé — le code dans ERC n'est pas normé. Si l'émetteur n'a pas publié son lexique, le récepteur de l'APERAK doit le traiter manuellement.
BGM+313 vs BGM+312 — 313 = application error (rejet), 312 = acquittement applicatif positif (généralement utilisé si pas de message de réponse dédié). Confondre les deux brouille la sémantique du flux.
RFF manquant en SG1 — sans référence au message d'origine (RFF+ON, RFF+IV, RFF+DQ…), l'APERAK est inexploitable : le récepteur ne sait pas quoi corriger.
ERC répété au header — ERC ne peut pas être instancié hors SG3. C'est une erreur fréquente côté ERPs qui mappent à plat.
Code retour ambigu — un APERAK applicatif n'implique pas systématiquement un rejet : un code ERC peut être un acquittement (success) ou un warning. La règle : BGM[1]+313 = erreur, BGM[1]+312 = ack.

Messages liés

APERAK répond à tout message EDIFACT. Quelques scénarios courants :

ORDERS D.96A reçu, GTIN inconnu → APERAK avec ERC + RFF+LI ligne.
INVOIC D.96A reçue, TVA invalide → APERAK avec détail FTX.
DESADV D.96A reçu, no de commande absent → APERAK demandant correction.
CONTRL D.96A — l'acquittement syntaxique préalable et complémentaire.

Équivalent JSON

Projection JSON pour intégration dans un EDI gateway ou portail B2B :

json aperak-d96a-equivalent.json

{
  "interchange": {
    "controlRef": "CTRL000200",
    "from": { "id": "5410000000456", "qualifier": "14" },
    "to": { "id": "5410000000123", "qualifier": "14" },
    "datetime": "2026-05-13T15:30:00Z",
    "syntax": { "id": "UNOC", "version": "3" }
  },
  "message": {
    "ref": "1",
    "type": "APERAK",
    "version": { "syntax": "D", "release": "96A", "agency": "UN" }
  },
  "applicationError": {
    "number": "APERAK-2026-0099",
    "function": "313",
    "status": "9",
    "issuedAt": "2026-05-13T15:30:00Z",
    "subjectMessage": { "type": "ORDERS", "number": "ORDER789", "date": "2026-05-13" },
    "issuer": { "qualifier": "EM", "gln": "5410000000456", "name": "ACME SUPPLY GMBH" },
    "errors": [
      {
        "code": "ME010",
        "description": "Unknown buyer GLN",
        "detail": "GLN 5410000099999 NOT REGISTERED IN OUR MASTER DATA"
      },
      {
        "code": "ME015",
        "description": "GTIN not in catalogue",
        "detail": "LINE 2: GTIN 3520000005678 SUPERSEDED ON 2026-04-01",
        "lineRef": 2
      }
    ]
  }
}

Fondamentaux

Standards

Messages phares

Outils