Parser EDI X12
Parser les documents EDI X12
EDI X12 est la norme nord-americaine pour l'echange electronique de documents commerciaux — bons de commande, factures et avis de paiement.
Qu’est-ce que l’EDI X12 ?
EDI X12 (Electronic Data Interchange, ANSI ASC X12) est la norme predominante pour l’echange electronique de documents commerciaux en Amerique du Nord. Developpee par l’Accredited Standards Committee X12 (initialement mandate par l’ANSI en 1979), elle definit des formats standardises pour les documents commerciaux courants tels que les bons de commande (850), les factures (810), les avis de paiement (820), les avis d’expedition avances (856) et des centaines d’autres.
L’EDI remplace les processus commerciaux papier par des messages electroniques structures pouvant etre traites automatiquement par des systemes informatiques. Au lieu d’envoyer par courrier un bon de commande papier qui doit etre saisi manuellement dans le systeme du fournisseur, le systeme ERP de l’acheteur genere un EDI 850 que le systeme du fournisseur peut ingerer directement — eliminant les erreurs de saisie, reduisant le temps de traitement de plusieurs jours a quelques minutes, et diminuant significativement les couts.
Malgre l’essor des API et des alternatives basees sur XML, l’EDI X12 reste profondement ancre dans les chaines d’approvisionnement, la sante, le transport et les services financiers. Les grands distributeurs (Walmart, Amazon, Target), les assureurs sante et les entreprises de logistique exigent de leurs partenaires commerciaux qu’ils communiquent via EDI.
Structure des messages
Chaque interchange EDI X12 utilise une structure d’enveloppe a trois couches — comme des boites imbriquees — qui assure le routage, le regroupement et l’organisation au niveau des transactions.
ISA/IEA (Interchange Control) est l’enveloppe la plus externe. Elle identifie l’emetteur et le destinataire, definit les delimiteurs et encapsule un ou plusieurs groupes fonctionnels. Le segment ISA fait toujours exactement 106 caracteres.
GS/GE (Groupe fonctionnel) regroupe les jeux de transactions lies. Un seul interchange peut contenir plusieurs groupes fonctionnels (par exemple, un groupe de factures et un groupe de bons de commande). Le segment GS identifie le type fonctionnel (IN = Facture, PO = Bon de commande).
ST/SE (Jeu de transactions) contient le document commercial proprement dit. Le segment ST identifie le type de jeu de transactions (810 pour une facture, 850 pour un bon de commande) et attribue un numero de controle. Le segment SE compte les segments et cloture la transaction.
Jeux de transactions courants
| Jeu | Nom | Direction | Description |
|---|---|---|---|
| 810 | Facture | Vendeur vers acheteur | Facturation de biens ou services livres |
| 850 | Bon de commande | Acheteur vers vendeur | Demande d’achat d’articles specifiques a des prix convenus |
| 820 | Ordre de paiement / Avis de reglement | Payeur vers beneficiaire | Instructions de paiement avec references de factures |
| 856 | Avis d’expedition avance (ASN) | Vendeur vers acheteur | Notification d’expedition avec details de conditionnement |
| 997 | Accuse de reception fonctionnel | Destinataire vers emetteur | Confirme la reception et l’exactitude syntaxique |
| 834 | Inscription aux avantages sociaux | Employeur vers assureur | Inscription et modifications de couverture sante |
| 835 | Paiement de sinistre sante | Assureur vers prestataire | Explication des prestations et details du paiement |
| 837 | Demande de remboursement sante | Prestataire vers assureur | Soumission de demande de remboursement medical |
EDI vs alternatives modernes
| Caracteristique | EDI X12 | API XML/JSON |
|---|---|---|
| Format | Positionnel fixe + delimite | Balisage hierarchique / objet |
| Lisibilite humaine | Difficile | Facile |
| Validation de schema | Guides d’implementation | XSD / JSON Schema |
| Transport | VAN, AS2, SFTP | HTTPS REST/SOAP |
| Adoption | Universelle dans la chaine d’approvisionnement | Croissante, non universelle |
| Temps reel | Generalement par lots | Capable de temps reel |
| Cout | Frais VAN par Ko | Couts d’hebergement API |
Cas d’utilisation courants
- Gestion de la chaine d’approvisionnement : Les bons de commande (850), factures (810) et ASN (856) automatisent le cycle achat-paiement entre distributeurs et fournisseurs
- Demandes de remboursement sante : Les transactions 837 (soumission), 835 (avis de paiement) et 834 (inscription) sont imposees par HIPAA pour les transactions de sante aux Etats-Unis
- Traitement des paiements : Les transactions 820 (ordre de paiement) et 823 (lockbox) automatisent les instructions de paiement B2B et le rapprochement de tresorerie
- Transport : Les transactions 204 (offre de chargement), 214 (statut d’expedition) et 210 (facture de fret) coordonnent la logistique entre expediteurs et transporteurs
- Conformite grande distribution : Les grands distributeurs exigent l’EDI pour toutes les transactions fournisseurs — la non-conformite entraine des penalites et des retenues
- Reporting financier : Les transactions 822 (analyse de compte client) et 821 (reporting d’information financiere) soutiennent les operations de tresorerie
Essayez ces exemples
Une facture EDI X12 810 valide encapsulee dans l'enveloppe standard a trois couches : ISA/IEA (interchange), GS/GE (groupe fonctionnel), ST/SE (jeu de transactions). La facture fait reference au bon de commande PO-2024-500, est expediee a ACME CORPORATION, contient deux lignes d'articles (100 widgets a 25,00 $, 50 gadgets a 42,50 $), et totalise 4 625,00 $ (segment TDS en centimes).
ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *240315*1200*U*00401*000000001*0*P*>~
GS*IN*SENDERID*RECEIVERID*20240315*1200*1*X*004010~
ST*810*0001~
BIG*20240315*INV-2024-001*20240310*PO-2024-500~
N1*ST*ACME CORPORATION*92*SHIP001~
IT1*1*100*EA*25.00**VP*WIDGET-A~
IT1*2*50*EA*42.50**VP*GADGET-B~
TDS*462500~
SE*8*0001~
GE*1*1~
IEA*1*000000001~ Cet interchange EDI est depourvu du segment GE (Functional Group Trailer) entre les segments SE et IEA. Le segment GE est obligatoire et doit contenir le nombre de jeux de transactions dans le groupe ainsi que le numero de controle du groupe correspondant a l'en-tete GS. Sans lui, le systeme recepteur ne peut pas valider l'integrite du groupe.
ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *240315*1200*U*00401*000000002*0*P*>~
GS*IN*SENDERID*RECEIVERID*20240315*1200*2*X*004010~
ST*810*0001~
BIG*20240315*INV-2024-002~
TDS*100000~
SE*4*0001~
IEA*1*000000002~