Implémentateurs : 5 segments EDI 214 à capturer et mapper
Référence pratique pour les implémentateurs EDI : capturez les cinq segments 214, décodez les codes de statut AT7, mappez les états d’expédition dans votre TMS et suivez un...
Implémentateurs : 5 segments EDI 214 à capturer et mapper
Un EDI 214 est le message ANSI X12 de statut d’expédition transporteur : les transporteurs l’envoient pour signaler des codes d’événement (AT7), des dates, des heures et des lieux associés à une expédition. Il contient les identifiants dont un système récepteur a besoin pour rattacher la mise à jour au bon envoi, et ses codes AT7 pilotent les परिणामats pratiques qui comptent : visibilité en temps réel, recalcul de l’ETA, confirmation de livraison et rapprochement propre des factures.
TL;DR :
- La plupart des mises à jour de statut transporteur sont déclenchées à des points clés comme l’enlèvement, l’arrivée en terminal, le changement d’ETA et la livraison finale, avec des événements d’exception comme les refus ou les annulations selon les besoins.
- Faire correspondre correctement les identifiants d’expédition comme le SCAC et le numéro de bordereau est essentiel pour une intégration fiable des données, chaque événement AT7 étant généralement enregistré séparément pour un suivi détaillé.
- Concentrez-vous sur les codes d’événement courants comme AF pour l’enlèvement, X4 et AR pour les jalons de transit, et D1 pour la livraison, tout en traitant les codes d’exception comme A7 et CA comme des déclencheurs de revue manuelle.
- La fréquence d’envoi par lot a un impact important sur la visibilité en temps réel, les mises à jour déclenchées par événement fournissant des informations ETA et de statut plus précises pour les décisions opérationnelles.
- Le parsing et l’implémentation des données 214 nécessitent de valider les listes de codes, de conserver l’historique brut des événements et d’assurer l’idempotence pour éviter les doublons.
Table des matières
Qu’est-ce que l’EDI 214 et quand les transporteurs l’envoient-ils ?
Le 214 s’inscrit dans la norme EDI ASC X12 en tant que Transportation Carrier Shipment Status Message, conçu pour renvoyer à l’expéditeur ou au donneur d’ordre les événements d’expédition, dates, heures, localisations, itinéraires et détails de transport. C’est la moitié transporteur d’une conversation qui commence avec une prise en charge et se termine avec une facture.
Un transporteur envoie généralement un 214 à plusieurs jalons naturels du cycle d’une expédition :
- Enlèvement effectué au départ
- Arrivée à un terminal intermédiaire ou à un faisceau rail
- Modification de l’heure de livraison estimée
- Livraison finale à destination
- Une exception : refus, avarie, retard, annulation
Le 214 ne fonctionne pas seul. Il complète une boucle qui commence généralement par un EDI 204 de prise en charge, où l’expéditeur propose le transport et le transporteur l’accepte. Le 214 décrit ensuite ce qui arrive à cet envoi pendant le transit, et une fois la livraison confirmée, le cycle se termine généralement par une facture 210, que l’événement de livraison du 214 aide à valider. Sans le 214, vous facturez sur la confiance plutôt que sur la preuve.
La version compte davantage que la plupart des intégrateurs ne l’imaginent. L’ensemble des segments et même la signification de certains qualificateurs changent selon les versions X12, et la version 4010 reste largement citée dans la documentation des transporteurs, bien que les versions 4020 et ultérieures ajoutent des champs exigés par certains partenaires commerciaux. Vérifiez la version dans le guide d’implémentation de votre partenaire avant de développer un parseur, pas après que les fichiers aient commencé à être refusés.
Lire le 214 : segments et champs à capturer
Chaque 214 s’ouvre et se ferme avec l’enveloppe X12 standard : ISA (interchange), GS (groupe fonctionnel) et ST (en-tête du jeu de transactions) en haut, avec les segments de fin correspondants en bas. Ils encadrent le message et identifient l’émetteur et le destinataire, mais le détail de l’expédition se trouve à l’intérieur.
- B10 est le segment pivot. Il contient les identifiants de l’expédition, le numéro de bordereau ou numéro pro, et souvent une référence de bon de commande ; c’est le segment sur lequel la plupart des systèmes récepteurs fondent d’abord leur logique de rapprochement.
- Boucles N1/N3/N4 : elles transportent les informations de partie et d’adresse, expéditeur, destinataire ou détails du terminal. Traitez-les comme des éléments complémentaires ; les identifiants du B10 sont plus fiables pour la correspondance que le texte d’adresse libre.
- LX/AT7 est le segment central. La boucle LX numérote chaque événement de statut, et le segment AT7 contient le code d’événement, le code de raison, la date et l’heure, ce qui explique pourquoi la plupart des logiques de parsing se concentrent sur ce duo.
- AT8 ajoute des données de poids et de quantité liées à l’événement, utiles pour rapprocher ce qui a été enlevé de ce qui avait été annoncé.
- MS1/MS2/MS3 (lorsqu’ils sont présents) portent des détails d’acheminement, d’équipement et de localisation, utiles pour les mouvements intermodaux ou ferroviaires lorsque le moyen de transport lui-même compte.
Pour le matching et le stockage, indexez sur le SCAC (Standard Carrier Alpha Code) plus les numéros de référence B10, avec le PO comme clé secondaire. Enregistrez chaque ligne AT7 comme un événement distinct plutôt que de les regrouper, car une seule expédition peut générer une douzaine de mises à jour de statut ou davantage avant d’atteindre sa destination.
Décoder les codes d’événement AT7 : leur signification et la manière d’agir dessus
Le segment AT7 est l’endroit où se trouve le statut réel, et le champ qui compte le plus est l’élément de données 1650, le code d’événement. Certaines valeurs AT701 signalent que l’expédition a été livrée, tandis que d’autres marquent simplement une progression en transit ; votre logique de parsing doit donc distinguer ces deux catégories au lieu de traiter tous les codes comme équivalents.
Quelques codes couvrent la majorité du trafic réel :
| Code |
Signification |
Déclencheur habituel |
| AF |
Enlèvement réel |
Le chauffeur prend en charge la marchandise au départ |
| AB |
Rendez-vous planifié |
Rendez-vous de livraison ou d’enlèvement fixé |
| X4 |
Arrivé au terminal |
La marchandise atteint un cross-dock ou un quai rail |
| AR |
Arrivé à destination |
Le camion atteint le point de livraison final |
| D1 |
Livré |
La marchandise est remise, le POD suit généralement |
| AG |
Livraison estimée |
Mise à jour de l’ETA, sans événement physique |
| I1 |
Entrée en zone (intermodal) |
Le conteneur entre dans une installation rail ou portuaire |
| A7 |
Refusé par le destinataire |
Livraison tentée mais refusée |
| CA |
Annulé |
Expédition annulée après la prise en charge |
| NS |
Aucun statut disponible |
Valeur de remplacement ou données indisponibles |
Construisez votre machine d’état autour de trois catégories plutôt que de onze branches distinctes :
- Codes en transit (AF, X4, AR, AB, AG) : ils mettent à jour la localisation et l’ETA sans clôturer l’expédition.
- Codes terminaux (D1) : ils clôturent l’expédition et doivent déclencher les workflows de récupération du POD et de facturation.
- Codes d’exception (A7, CA, NS) : ils nécessitent une intervention humaine, pas un changement d’état automatique.
Les transporteurs envoient parfois des codes hors de votre liste acceptée, surtout pendant l’onboarding. Ne faites pas échouer tout le fichier. Journalisez le code inconnu, conservez l’expédition dans son dernier état connu et déclenchez une alerte pour revue manuelle plutôt que d’ignorer silencieusement l’événement ou d’en deviner le sens.
Où les intégrations 214 se cassent réellement
La plupart des échecs 214 proviennent d’une poignée de causes récurrentes plutôt que de cas limites exotiques. Les incohérences de référence arrivent en tête : la référence B10 ou PO d’un transporteur ne correspond pas à celle envoyée sur le 204 d’origine, souvent à cause de différences de format comme les zéros non significatifs ou des codes SCAC incohérents. Les écarts de poids et d’unités, la gestion des fuseaux horaires et les formats de date incohérents entre partenaires commerciaux expliquent le reste.
La fréquence de lot est un problème plus discret. Un transporteur qui regroupe les 214 une fois par jour vous donne un historique exact mais une faible visibilité en temps réel, tandis qu’un envoi déclenché par événement, à chaque changement de statut, est ce qui permet réellement un suivi d’ETA en direct. Encouragez les envois pilotés par événement chaque fois que le système du partenaire le permet.
Une séquence pratique de validation et de test :
- Vérifiez que les qualificateurs d’interchange et de version dans ISA/GS correspondent à ce qu’attend le profil de votre partenaire.
- Imposez des contrôles de champs obligatoires sur B10, SCAC et au moins une ligne AT7 avant d’accepter un fichier.
- Maintenez une liste de codes acceptés par transporteur et signalez tout élément hors liste au lieu de refuser immédiatement.
- Échangez et vérifiez les accusés de réception fonctionnels 997 dans le cadre de l’onboarding, pas en second temps.
- Simulez les scénarios d’exception (refus, annulation, ETA retardée) avant la mise en production, pas après l’arrivée du premier cas réel.
Astuce : Demandez aux nouveaux transporteurs trois ou quatre fichiers 214 d’exemple couvrant l’enlèvement, le transit et la livraison avant d’écrire une seule ligne de logique de mapping. Les fichiers réels révèlent des particularités de format que la documentation de spécification ne mentionne jamais.
Mapper les événements 214 dans votre TMS, WMS ou ERP
Stockez les événements 214 dans un journal en append-only plutôt que d’écraser un seul enregistrement d’expédition. Dériver le statut courant à partir de l’événement le plus récent conserve tout l’historique et rend le rapprochement ainsi que la résolution des litiges beaucoup plus simples que de devoir reconstituer un calendrier a posteriori.
Une cartographie exploitable entre les codes AT7 et les états internes ressemble à ceci :
- AF → « Pris en charge » (démarre le compteur de transit)
- X4/AR → « En transit » avec localisation mise à jour
- AG → mise à jour du champ ETA, notification des équipes de planning et de réception, sans changement d’état
- D1 → « Livré », déclenche la récupération du POD et clôt la tournée
- A7/CA → « Exception », orienté vers une file humaine plutôt que clôturé automatiquement
Les mises à jour d’ETA méritent un traitement dédié. Lorsqu’un événement AG arrive, mettez à jour le planning et notifiez immédiatement les équipes de réception, car une ETA obsolète est pire qu’aucune ETA pour la planification des quais.
Protégez-vous contre les doublons. Les transporteurs renvoient parfois le même événement après une nouvelle tentative de connexion ; basez donc votre contrôle d’idempotence sur la combinaison de la référence B10, du code AT7 et de l’horodatage de l’événement avant d’écrire un nouvel enregistrement. Conservez l’historique brut des événements aussi longtemps que l’exige votre fenêtre de litige de facturation, puis archivez au lieu de supprimer.
Point de vue de l’auteur : ce qui compte vraiment quand vous passez à l’échelle
Commencez par sécuriser les clés de rapprochement. Le SCAC plus le numéro de bordereau ou le numéro pro couvrent 90 % des expéditions ; le parsing des adresses et les champs libres sont un enrichissement, pas une base. Je préfère voir une équipe accepter proprement un ensemble restreint de codes d’événement plutôt que d’essayer de gérer toutes les valeurs AT7 possibles dès le premier jour et de se bloquer sur les exceptions. Élargissez la couverture à mesure que chaque transporteur montre sa stabilité, et utilisez les événements 214 avec la facture 210 pour résoudre les litiges avec des preuves plutôt qu’au téléphone.
— Vytautas
Faire entrer les données 214 dans un système qui les exploite vraiment
Parser correctement un 214 n’est que la moitié du travail. Le défi plus difficile consiste à transformer les événements AT7 en actions concrètes pour votre équipe opérations le jour même : une ETA qui met à jour le lien de suivi d’un client, un événement de livraison qui libère un POD, une mise à jour de statut qui signale une expédition prête à être facturée. Logivo ingère des flux EDI, y compris les mises à jour de statut 214, et les mappe vers des états d’expédition que votre équipe utilise déjà, aux côtés du suivi conducteur en direct et de la capture POD qui referme la boucle lorsqu’un événement D1 arrive.
Comme cette plateforme fonctionne sur un modèle de tarification à l’usage plutôt que sur un long contrat, vous pouvez valider vos propres règles de mapping à partir de trafic transporteur réel pendant un essai guidé de 30 jours, avant qu’un seul envoi ne soit facturé. Si le rapprochement des événements 214 avec les factures est la partie qui vous coûte le plus de temps administratif, c’est ce flux de travail qu’il faut tester en premier. Découvrez la plateforme de gestion du transport Logivo et voyez comment votre propre flux EDI s’y comporte.
Sources
- 214 | X12
- 214 - Transportation carrier shipment status (version 4010) - IBM Documentation
- EDI 214 Shipment Status Message | Understand the Transportation Carrier Shipment Status
FAQ
Que signifient les codes de raison EDI 214 ?
Les codes de raison accompagnent le code d’événement AT7 et expliquent pourquoi un statut est survenu, par exemple une cause de retard ou une raison de refus ; les jeux de codes exacts sont généralement définis par accord entre partenaires commerciaux plutôt que fixés de manière universelle.
Qu’est-ce qu’un document EDI 214 ?
C’est le message ANSI X12 de statut d’expédition transporteur, un fichier électronique que les transporteurs envoient pour signaler des événements comme l’enlèvement, la progression en transit, la livraison ou des exceptions sur une expédition donnée.
Quelle est la différence entre EDI 204 et EDI 214 ?
Le EDI 204 est la prise en charge qu’un expéditeur envoie pour proposer une expédition à un transporteur ; le 214 est la réponse du transporteur indiquant ce qui se passe réellement une fois que la marchandise est en mouvement.
Quels sont tous les codes EDI ?
Il n’existe pas de liste unique et universelle ; les codes d’événement AT7 varient quelque peu selon le transporteur et le segment d’activité, même si des codes courants comme AF (enlèvement), D1 (livré) et CA (annulé) apparaissent dans la plupart des implémentations.
Comment le suivi EDI 214 se relie-t-il à la facturation ?
Un événement de livraison (D1) dans le 214 fournit au destinataire la preuve nécessaire pour valider la facture 210 suivante, ce qui explique pourquoi rapprocher l’historique 214 des factures réduit considérablement les litiges de facturation.
Recommandé