Implementierer: 5 EDI-214-Segmente zum Erfassen und Zuordnen
Praxisreferenz für EDI-Implementierer: die fünf 214-Segmente erfassen, AT7-Statuscodes entschlüsseln, Sendungszustände in Ihr TMS abbilden und folgen...
Implementierer: 5 EDI-214-Segmente zum Erfassen und Zuordnen
Eine EDI 214 ist die ANSI X12-Nachricht zum Sendungsstatus im Transport: Spediteure senden sie, um Ereigniscodes (AT7), Daten, Zeiten und Orte zu einer Sendung zu melden. Sie enthält die Kennungen, die ein empfangendes System benötigt, um die Aktualisierung dem richtigen Auftrag zuzuordnen, und ihre AT7-Codes steuern die praktischen Ergebnisse, die zählen: aktuelle Transparenz, ETA-Neuberechnung, Lieferbestätigung und saubere Rechnungsabstimmung.
TL;DR:
- Die meisten Statusaktualisierungen von Spediteuren werden an Schlüsselpunkten wie Abholung, Ankunft am Umschlagpunkt, ETA-Änderung und endgültiger Zustellung ausgelöst, während Ausnahmeereignisse wie Zurückweisungen oder Stornierungen bei Bedarf auftreten.
- Die korrekte Zuordnung von Sendungskennungen wie SCAC und Frachtbriefnummer ist entscheidend für eine zuverlässige Datenintegration, wobei jedes AT7-Ereignis für eine detaillierte Nachverfolgung in der Regel separat erfasst wird.
- Konzentrieren Sie sich auf gängige Ereigniscodes wie AF für die Abholung, X4 und AR für Transit-Meilensteine sowie D1 für die Zustellung, und behandeln Sie Ausnahmecodes wie A7 und CA als manuelle Prüfauslöser.
- Die Häufigkeit der Stapelübertragung wirkt sich erheblich auf die Echtzeit-Transparenz aus, wobei ereignisgesteuerte Aktualisierungen genauere ETA- und Statusinformationen für operative Entscheidungen liefern.
- Das Parsen und Implementieren von 214-Daten erfordert die Validierung von Codelisten, die Pflege von Rohereignisverläufen und die Sicherstellung von Idempotenz, um doppelte Datensätze zu vermeiden.
Inhaltsverzeichnis
Was ist die EDI 214 und wann senden Spediteure sie?
Die 214 ist Teil des ASC-X12-EDI-Standards als Transportation Carrier Shipment Status Message und dient dazu, Sendungsereignisse, Daten, Zeiten, Orte, Routen und Transportdetails an denjenigen zurückzumelden, der den Auftrag vergeben hat. Sie ist die Hälfte eines Gesprächs, das mit einer Disposition beginnt und mit einer Rechnung endet.
Ein Spediteur sendet eine 214 typischerweise an mehreren natürlichen Meilensteinen im Lebenszyklus einer Sendung:
- Abholung am Ursprung abgeschlossen
- Ankunft an einem Zwischenlager oder einer Bahnrampe
- Änderung der voraussichtlichen Zustellzeit
- Endgültige Zustellung am Zielort
- Ein Ausnahmefall: Zurückweisung, Beschädigung, Verzögerung, Stornierung
Die 214 arbeitet nicht isoliert. Sie schließt einen Kreislauf, der üblicherweise mit einem EDI-204-Ladungsangebot beginnt, bei dem der Verlader die Sendung anbietet und der Spediteur sie annimmt. Die 214 meldet dann, was mit dieser Sendung im Transport passiert, und sobald die Zustellung bestätigt ist, schließt sich der Kreis normalerweise mit einer 210-Rechnung, die durch das Lieferereignis der 214 validiert wird. Ohne die 214 bleibt die Abrechnung eher Vertrauenssache als belegbar.
Die Version ist wichtiger, als viele Integratoren erwarten. Das Segmentset und sogar die Bedeutung bestimmter Qualifier ändern sich zwischen X12-Versionen, und die Version 4010 wird in Spediteursdokumentationen weiterhin häufig referenziert, während 4020 und spätere Versionen Felder hinzufügen, die einige Handelspartner verlangen. Bestätigen Sie die Version im Implementierungshandbuch Ihres Partners, bevor Sie einen Parser bauen, nicht erst wenn Dateien abgewiesen werden.
Die 214 lesen: Segmente und Felder, die sich zu erfassen lohnen
Jede 214 beginnt und endet mit dem standardisierten X12-Envelope: ISA (Interchange), GS (Functional Group) und ST (Transaction Set Header) am Anfang, mit den passenden Abschlusssegmenten am Ende. Diese rahmen die Nachricht ein und identifizieren Sender und Empfänger, doch die Sendungsdetails liegen im Inneren.
- B10 ist das Ankersegment. Es enthält die Sendungskennungen, Frachtbrief- oder Pro-Nummer und oft eine Bestellreferenz, und es ist das Segment, auf das die meisten empfangenden Systeme ihre Zuordnungslogik zuerst stützen.
- N1/N3/N4-Loops enthalten Parteien- und Adressinformationen, also Verlader-, Empfänger- oder Terminaldetails. Behandeln Sie diese als ergänzend; die Kennungen in B10 sind für die Zuordnung verlässlicher als frei eingegebener Adresstext.
- LX/AT7 ist das Arbeitspferd. Der LX-Loop nummeriert jedes Statusereignis, und das AT7-Segment enthält Ereigniscode, Grundcode, Datum und Uhrzeit, weshalb sich die meiste Parsing-Logik auf dieses Paar konzentriert.
- AT8 ergänzt Gewichts- und Mengenangaben zum Ereignis und ist hilfreich, um das Abgeholte mit dem Verglichenen abzugleichen.
- MS1/MS2/MS3-Segmente (falls vorhanden) tragen Routing-, Equipment- und Standortdetails und sind besonders nützlich bei intermodalen oder Bahnverkehren, bei denen das Transportmittel selbst wichtig ist.
Für Zuordnung und Speicherung sollten Sie auf den SCAC (Standard Carrier Alpha Code) plus die B10-Referenznummern indexieren, wobei die PO-Nummer als sekundärer Schlüssel dient. Speichern Sie jede AT7-Zeile als eigenen Ereignisdatenensatz statt sie zusammenzufassen, da eine einzelne Sendung vor dem Ziel leicht ein Dutzend oder mehr Statusaktualisierungen erzeugen kann.
AT7-Ereigniscodes entschlüsseln: was sie bedeuten und wie man darauf reagiert
Im AT7-Segment liegt der eigentliche Status, und das wichtigste Feld ist Data Element 1650, der Ereigniscode. Einige AT701-Werte signalisieren, dass die Sendung zugestellt wurde, während andere lediglich den Fortschritt im Transport markieren. Ihre Parsing-Logik muss also zwischen diesen beiden Kategorien unterscheiden, statt jeden Code als gleichwertig zu behandeln.
Einige wenige Codes decken den Großteil des Praxisaufkommens ab:
| Code |
Bedeutung |
Typischer Auslöser |
| AF |
Tatsächliche Abholung |
Fahrer übernimmt die Sendung am Ursprung |
| AB |
Termin vereinbart |
Zustell- oder Abholtermin wird gesetzt |
| X4 |
An Terminal angekommen |
Sendung erreicht ein Cross-Dock oder eine Rampe |
| AR |
Am Ziel angekommen |
Lkw erreicht den endgültigen Zustellort |
| D1 |
Zugestellt |
Sendung übergeben, POD folgt in der Regel |
| AG |
Voraussichtliche Zustellung |
ETA-Aktualisierung, noch kein physisches Ereignis |
| I1 |
Im Eingang (intermodal) |
Container fährt in eine Bahn- oder Hafenanlage ein |
| A7 |
Vom Empfänger verweigert |
Zustellversuch erfolgte, wurde aber abgelehnt |
| CA |
Storniert |
Sendung nach der Disposition storniert |
| NS |
Kein Status verfügbar |
Platzhalter oder Daten nicht verfügbar |
Erstellen Sie Ihr Zustandsmodell auf drei statt elf Zweigen:
- In-Transit-Codes (AF, X4, AR, AB, AG) aktualisieren Ort und ETA, ohne die Sendung abzuschließen.
- Terminal-Codes (D1) schließen die Sendung ab und sollten POD-Abruf und Abrechnungsworkflows auslösen.
- Ausnahmecodes (A7, CA, NS) benötigen einen Menschen im Entscheidungsprozess und keine automatische Statusänderung.
Spediteure senden gelegentlich Codes außerhalb Ihrer akzeptierten Liste, insbesondere während des Onboardings. Brechen Sie nicht die gesamte Datei ab. Protokollieren Sie den unbekannten Code, halten Sie die Sendung im zuletzt bekannten Zustand und geben Sie eine Warnung zur manuellen Prüfung aus, statt das Ereignis stillschweigend zu verwerfen oder seine Bedeutung zu erraten.
Wo 214-Integrationen in der Praxis scheitern
Die meisten 214-Fehler gehen auf einige wenige Wiederholungstäter zurück und nicht auf exotische Randfälle. Zuordnungsfehler führen die Liste an: Eine B10- oder PO-Referenz des Spediteurs stimmt nicht mit dem überein, was in der ursprünglichen 204-Dispo übermittelt wurde, oft wegen Formatunterschieden wie führenden Nullen oder uneinheitlichen SCAC-Codes. Gewichts- und Mengendifferenzen, Zeitzonenbehandlung und inkonsistente Datumsformate zwischen Handelspartnern verursachen den Rest.
Die Stapelungshäufigkeit ist ein stilleres Problem. Ein Spediteur, der 214er nur einmal täglich bündelt, liefert Ihnen zwar eine genaue Historie, aber schlechte Echtzeit-Transparenz, während ereignisgesteuerte Übermittlung, also bei jeder Statusänderung, das ist, was Live-ETA-Tracking tatsächlich unterstützt. Drängen Sie auf ereignisgesteuerte Sendungen, wo immer das System eines Partners es unterstützt.
Eine praktische Prüf- und Testreihenfolge:
- Bestätigen Sie, dass die Interchange- und Versionsqualifier in ISA/GS mit dem erwarteten Partnerprofil übereinstimmen.
- Erzwingen Sie Pflichtfeldprüfungen für B10, SCAC und mindestens eine AT7-Zeile, bevor Sie eine Datei annehmen.
- Pflegen Sie eine je Spediteur freigegebene Codeliste und markieren Sie alles außerhalb dieser Liste, statt es sofort abzulehnen.
- Tauschen und prüfen Sie 997 Functional Acknowledgements als Teil des Onboardings und nicht erst im Nachhinein.
- Simulieren Sie Ausnahmeszenarien (Zurückweisung, Storno, verzögerte ETA) vor dem Go-live und nicht erst, wenn der erste reale Fall eintrifft.
Pro-Tipp: Bitten Sie neue Spediteure um drei oder vier Beispiel-214-Dateien für Abholung, Transit und Zustellung, bevor Sie auch nur eine Zeile Zuordnungslogik schreiben. Echte Dateien zeigen Formatierungsbesonderheiten, die in Spezifikationsdokumenten nie erwähnt werden.
214-Ereignisse in Ihr TMS, WMS oder ERP abbilden
Speichern Sie 214-Ereignisse als Append-Only-Protokoll, statt einen einzelnen Sendungseintrag zu überschreiben. Wenn der aktuelle Status aus dem jüngsten Ereignis abgeleitet wird, bleibt der vollständige Verlauf erhalten und die Abstimmung sowie die Klärung von Reklamationen werden deutlich einfacher, als eine Zeitachse nachträglich rekonstruieren zu müssen.
Eine praktikable Zuordnung zwischen AT7-Codes und internen Zuständen sieht so aus:
- AF → „Abgeholt“ (startet die In-Transit-Uhr)
- X4/AR → „In Transit“ mit aktualisiertem Standort
- AG → ETA-Feld wird aktualisiert, Disposition und Empfangsteams werden benachrichtigt, keine Zustandsänderung
- D1 → „Zugestellt“, löst den POD-Abruf aus und schließt den Transportabschnitt
- A7/CA → „Ausnahme“, Weiterleitung an eine manuelle Bearbeitung statt automatischer Schließung
ETA-Aktualisierungen verdienen einen eigenen Verarbeitungsweg. Wenn ein AG-Ereignis eintrifft, aktualisieren Sie den Fahrplan und benachrichtigen Sie die Empfangsteams sofort, denn eine veraltete ETA ist für die Rampenplanung schlimmer als gar keine ETA.
Schützen Sie sich vor Duplikaten. Spediteure senden ein Ereignis gelegentlich nach einem Verbindungsfehler erneut. Verwenden Sie daher für Ihre Idempotenzprüfung die Kombination aus B10-Referenz, AT7-Code und Ereigniszeitstempel, bevor Sie einen neuen Datensatz schreiben. Bewahren Sie den Rohereignisverlauf so lange auf, wie es Ihr Reklamationsfenster für Rechnungen erfordert, und archivieren Sie ihn danach statt zu löschen.
Autorenperspektive: worauf es beim Skalieren wirklich ankommt
Bringen Sie zuerst die Zuordnungs-Schlüssel in Ordnung. SCAC plus Frachtbrief- oder Pro-Nummer decken Sie bei 90% der Sendungen ab; Adressparsing und freie Felder sind Ergänzung, nicht Grundlage. Ich würde lieber sehen, dass ein Team eine begrenzte Menge an Ereigniscodes sauber verarbeitet, als am ersten Tag jeden möglichen AT7-Wert abdecken zu wollen und an den Ausnahmen zu scheitern. Erweitern Sie die Abdeckung, sobald sich ein Spediteur stabil verhält, und nutzen Sie 214-Ereignisse gegen die 210-Rechnung, um Streitfälle mit Belegen statt mit Telefonaten zu klären.
— Vytautas
214-Daten in ein System bringen, das sie auch wirklich nutzt
Eine 214 korrekt zu parsen ist nur die halbe Arbeit. Die größere Aufgabe besteht darin, AT7-Ereignisse in etwas zu verwandeln, worauf Ihr Operativteam noch am selben Tag reagiert: eine ETA, die den Tracking-Link eines Kunden aktualisiert, ein Lieferereignis, das einen POD freigibt, oder eine Statusänderung, die eine zur Abrechnung bereite Sendung markiert. Logivo verarbeitet EDI-Feeds einschließlich 214-Statusaktualisierungen und ordnet sie den Sendungszuständen zu, mit denen Ihr Team bereits arbeitet, zusammen mit Live-Fahrerverfolgung und POD-Erfassung, die den Kreislauf schließt, wenn ein D1-Ereignis eintrifft.
Da diese Plattform auf nutzungsbasierter Preisgestaltung statt auf einem langen Vertrag basiert, können Sie Ihre eigenen Zuordnungsregeln während einer geführten 30-Tage-Testphase mit echtem Spediteursverkehr validieren, bevor überhaupt eine Sendung berechnet wird. Wenn die Abstimmung von 214-Ereignissen gegen Rechnungen der Bereich ist, der Ihnen den meisten Verwaltungsaufwand verursacht, dann ist genau dieser Arbeitsablauf der richtige zum Testen. Schauen Sie sich Logivos Transportmanagement-Plattform an und sehen Sie, wie sich Ihr eigener EDI-Feed darin verhält.
Quellen
- 214 | X12
- 214 - Transportation carrier shipment status (version 4010) - IBM Documentation
- EDI 214 Shipment Status Message | Understand the Transportation Carrier Shipment Status
FAQ
Was bedeuten die EDI-214-Grundcodes?
Grundcodes stehen neben dem AT7-Ereigniscode und erklären, warum ein Status eingetreten ist, etwa eine Verzögerungsursache oder der Grund für eine Zurückweisung; die genauen Codesätze werden meist pro Handelspartnervereinbarung definiert und sind nicht universell festgelegt.
Was ist ein EDI-214-Dokument?
Es ist die ANSI-X12-Nachricht zum Sendungsstatus im Transport, also eine elektronische Datei, die Spediteure senden, um Ereignisse wie Abholung, Fortschritt im Transport, Zustellung oder Ausnahmen zu einer bestimmten Sendung zu melden.
Was ist der Unterschied zwischen EDI 204 und EDI 214?
Die EDI 204 ist das Ladungsangebot, das ein Verlader sendet, um eine Sendung einem Spediteur anzubieten; die 214 ist die Antwort des Spediteurs und meldet, was mit dieser Sendung tatsächlich passiert, sobald sie unterwegs ist.
Welche EDI-Codes gibt es alle?
Es gibt keine einzelne universelle Liste; AT7-Ereigniscodes variieren je nach Spediteur und Branchensegment etwas, obwohl gängige Codes wie AF (Abholung), D1 (zugestellt) und CA (storniert) in den meisten Implementierungen vorkommen.
Wie hängt EDI-214-Tracking mit der Rechnungsstellung zusammen?
Ein Lieferereignis (D1) in der 214 liefert dem Empfänger den Nachweis, um die anschließende 210-Rechnung zu validieren, weshalb die Zuordnung der 214-Historie zu Rechnungen Zahlungsstreitigkeiten deutlich verkürzt.
Empfohlen