Implementerare: 5 EDI 214-segment att fånga och mappa
Praktisk referens för EDI-implementerare: fånga de fem 214-segmenten, tolka AT7-statuskoder, mappa sändningsstatusar i ditt TMS och följ en...
Implementerare: 5 EDI 214-segment att fånga och mappa
En EDI 214 är ANSI X12:s transportörsmeddelande för sändningsstatus: transportörer skickar det för att rapportera händelsekoder (AT7), datum, tider och platser för en sändning. Det innehåller de identifierare som ett mottagande system behöver för att matcha uppdateringen till rätt last, och AT7-koderna driver de praktiska resultat som spelar roll: visibilitet i realtid, ETA-omräkning, leveransbekräftelse och korrekt fakturamatchning.
TL;DR:
- De flesta statusuppdateringar från transportörer utlöses vid nyckelpunkter som upphämtning, ankomst till terminal, ETA-ändring och slutleverans, medan avvikelsehändelser som vägran eller avbokning sker vid behov.
- Att matcha sändningsidentifierare som SCAC och fraktsedelsnummer korrekt är avgörande för tillförlitlig dataintegration, och varje AT7-händelse registreras vanligtvis separat för detaljerad spårning.
- Fokusera på vanliga händelsekoder som AF för upphämtning, X4 och AR för transitmilstenar och D1 för leverans, och behandla avvikelsekoder som A7 och CA som signaler för manuell granskning.
- Hur ofta meddelanden skickas i batch påverkar visibiliteten i realtid avsevärt, medan händelsestyrda uppdateringar ger mer korrekt ETA och statusinformation för operativa beslut.
- Att tolka och implementera 214-data effektivt kräver validering av kodlistor, bevarande av rå händelsehistorik och idempotens för att förhindra dubbletter.
Innehållsförteckning
Vad är EDI 214 och när skickar transportörer det?
214 ligger i ASC X12 EDI-standarden som Transportation Carrier Shipment Status Message och är byggd för att rapportera sändningshändelser, datum, tider, platser, rutt och transportmedelsdetaljer tillbaka till den som tenderade lasten. Det är transportörens ena halva i en dialog som börjar med en tender och slutar med en faktura.
En transportör skickar vanligtvis en 214 vid flera naturliga kontrollpunkter i en sändnings livscykel:
- Upphämtning genomförd vid ursprung
- Ankomst till en mellanliggande terminal eller järnvägsramp
- En ändring av beräknad leveranstid
- Slutleverans vid destination
- En avvikelse: vägran, skada, försening, avbokning
214 fungerar inte ensam. Den sluter en kedja som vanligtvis börjar med en EDI 204 load tender, där avsändaren erbjuder lasten och transportören accepterar den. 214 rapporterar sedan vad som händer med lasten under transport, och när leveransen bekräftas avslutas cykeln vanligtvis med en 210-faktura, där 214:s leveranshändelse hjälper till att validera den. Hoppar du över 214 återstår fakturering på förtroende snarare än bevis.
Version spelar större roll än många integratörer förväntar sig. Segmentuppsättningen och till och med innebörden av vissa kvalificerare ändras mellan X12-versioner, och version 4010 refereras fortfarande ofta i transportörsdokumentation, även om 4020 och senare versioner lägger till fält som vissa affärspartners kräver. Bekräfta versionen i din partners implementationsguide innan du bygger en parser, inte efter att den börjar avvisa filer.
Läsa 214: segment och fält som är värda att fånga
Varje 214 öppnas och avslutas med standardiserade X12-kuvert: ISA (interchange), GS (funktionell grupp) och ST (transaktionssetets rubrik) överst, med motsvarande avslutare längst ned. Dessa ramar in meddelandet och identifierar avsändare och mottagare, men sändningsdetaljerna finns inuti.
- B10 är ankarsegmentet. Det innehåller sändningsidentifierare, fraktsedelsnummer eller pro-nummer och ofta en referens till inköpsorder, och det är segmentet som de flesta mottagande system använder först för sin matchningslogik.
- N1/N3/N4-looper innehåller part- och adressinformation, avsändare, mottagare eller terminaluppgifter. Se detta som kompletterande; identifierarna i B10 är mer tillförlitliga för matchning än fri adress-text.
- LX/AT7 är arbetshästen. LX-loopen numrerar varje statushändelse, och AT7-segmentet innehåller händelsekod, orsakskod, datum och tid, vilket är varför det mesta av parserlogiken kretsar kring just denna kombination.
- AT8 lägger till vikt- och kvantitetsdata kopplade till händelsen, användbart för att stämma av vad som hämtades mot vad som tenderades.
- MS1/MS2/MS3-segment (där de finns) innehåller rutt-, utrustnings- och platsdetaljer, användbart för intermodala eller järnvägsflöden där själva transportmedlet är viktigt.
För matchning och lagring, indexera på SCAC (Standard Carrier Alpha Code) plus B10-referensnumren, med PO som sekundär nyckel. Spara varje AT7-rad som en egen händelsepost i stället för att slå ihop dem, eftersom en enda sändning kan generera ett dussin eller fler statusuppdateringar innan den når destinationen.
Tolka AT7-händelsekoder: vad de betyder och hur du agerar på dem
AT7-segmentet är där den faktiska statusen finns, och det viktigaste fältet är Data Element 1650, händelsekoden. Vissa AT701-värden signalerar att sändningen har levererats, medan andra bara markerar framsteg under transport, så din parserlogik behöver skilja mellan dessa två kategorier i stället för att behandla varje kod som likvärdig.
Ett fåtal koder täcker det mesta av verklig trafik:
| Kod |
Betydelse |
Typisk utlösare |
| AF |
Faktisk upphämtning |
Chauffören hämtar lasten vid ursprung |
| AB |
Bokad tid |
Leverans- eller upphämtningsavtal bokat |
| X4 |
Anlände till terminal |
Lasten når en cross-dock eller ramp |
| AR |
Anlände till destination |
Lastbilen når den slutliga leveransplatsen |
| D1 |
Levererad |
Lasten överlämnad, POD följer vanligtvis |
| AG |
Beräknad leverans |
ETA-uppdatering, ingen fysisk händelse ännu |
| I1 |
In-gate (intermodalt) |
Container går in i en järnvägs- eller hamnanläggning |
| A7 |
Vägrad av mottagaren |
Leverans försökt men avvisad |
| CA |
Avbruten |
Sändningen avbröts efter tender |
| NS |
Ingen status tillgänglig |
Platshållare eller data saknas |
Bygg din tillståndsmaskin kring tre grupper i stället för elva separata grenar:
- In-transit-koder (AF, X4, AR, AB, AG) uppdaterar plats och ETA utan att stänga sändningen.
- Terminalkoder (D1) stänger sändningen och bör trigga POD-hämtning och faktureringsflöden.
- Avvikelsekoder (A7, CA, NS) behöver en människa i loopen, inte en automatisk statusändring.
Transportörer skickar ibland koder utanför din accepterade lista, särskilt under onboarding. Missa inte hela filen. Logga den okända koden, håll sändningen i sin senast kända status och skapa en avisering för manuell granskning i stället för att tyst kassera händelsen eller gissa dess betydelse.
Var 214-integrationer faktiskt går sönder
De flesta 214-fel beror på ett fåtal återkommande orsaker snarare än ovanliga specialfall. Referensavvikelser toppar listan: en transportörs B10- eller PO-referens matchar inte det som skickades i den ursprungliga 204-tendern, ofta på grund av formateringsskillnader som inledande nollor eller inkonsekventa SCAC-koder. Avvikelser i vikt och enheter, tidszons-hantering och inkonsekventa datumformat mellan affärspartners står för resten.
Batchfrekvens är ett mer diskret problem. En transportör som skickar 214:or en gång per dag ger korrekt historik men dålig visibilitet i realtid, medan händelsestyrd överföring, skickad varje gång status ändras, är det som faktiskt stöder live-ETA-spårning. Driv på för händelsestyrda sändningar där partnerns system stödjer det.
En praktisk sekvens för validering och testning:
- Bekräfta att interchange- och versionskvalificerarna i ISA/GS matchar vad din partnerprofil förväntar sig.
- Tillämpa kontroll av obligatoriska fält för B10, SCAC och minst en AT7-rad innan en fil accepteras.
- Underhåll en godkänd kodlista per transportör och flagga allt utanför den i stället för att avvisa direkt.
- Utbyt och verifiera 997-funktionella bekräftelser som en del av onboarding, inte som en eftertanke.
- Simulera avvikelsescenarier (vägran, avbokning, fördröjd ETA) före go-live, inte efter att den första verkliga händelsen kommer.
Proffstips: Be nya transportörer om tre eller fyra exempel på 214-filer som täcker upphämtning, under transport och leverans innan du skriver en enda rad mappningskod. Verkliga filer avslöjar formateringsdetaljer som specifikationsdokument aldrig nämner.
Mappa 214-händelser i ditt TMS, WMS eller ERP
Förvara 214-händelser som en append-only-logg i stället för att skriva över en enda sändningspost. Att härleda aktuell status från den senaste händelsen bevarar hela historiken och gör avstämning och tvistlösning betydligt enklare än att försöka återskapa en tidslinje i efterhand.
En fungerande mappning mellan AT7-koder och interna statusar kan se ut så här:
- AF → ”Upphämtad” (startar in-transit-klockan)
- X4/AR → ”Under transport” med uppdaterad plats
- AG → uppdatering av ETA-fältet, schema- och mottagningsteam informeras, ingen statusändring
- D1 → ”Levererad”, triggar POD-hämtning och stänger transportbenet
- A7/CA → ”Avvikelse”, skickas till en mänsklig kö i stället för att stängas automatiskt
ETA-uppdateringar förtjänar sin egen hanteringsväg. När en AG-händelse kommer in, uppdatera schemat och skicka en avisering till mottagningsteamet direkt, eftersom en gammal ETA är värre än ingen ETA alls för dockplanering.
Skydda dig mot dubbletter. Transportörer skickar ibland samma händelse igen efter ett anslutningsförsök, så bygg din idempotenskontroll på kombinationen av B10-referens, AT7-kod och händelsetidsstämpel innan du skriver en ny post. Behåll rå händelsehistorik så länge din tvistperiod för fakturor kräver, och arkivera sedan i stället för att radera.
Författarperspektiv: vad som faktiskt spelar roll när du skalar detta
Få matchningsnycklarna rätt först av allt. SCAC plus fraktsedel- eller pro-nummer räcker för 90% av sändningarna; adressparsing och fria fält är komplettering, inte grund. Jag skulle hellre se ett team acceptera en smal uppsättning händelsekoder korrekt än försöka hantera varje möjlig AT7-variant dag ett och köra fast i undantagen. Utöka täckningen i takt med att varje transportör visar stabilitet, och använd 214-händelser mot 210-fakturan för att lösa tvister med bevis i stället för telefonsamtal.
— Vytautas
Få in 214-data i ett system som faktiskt använder den
Att tolka en 214 korrekt är bara halva jobbet. Den svårare delen är att göra AT7-händelser till något som ditt operationsteam faktiskt agerar på samma dag, en ETA som uppdaterar kundens spårningslänk, en leveranshändelse som frigör en POD, en statusändring som markerar en last redo för fakturering. Logivo tar emot EDI-flöden inklusive 214-statusuppdateringar och mappar dem till sändningsstatusar som ditt team redan arbetar utifrån, tillsammans med liveförarspårning och POD-fångst som sluter loopen när en D1-händelse kommer in.
Eftersom plattformen har användningsbaserad prissättning i stället för ett långt avtal kan du validera dina egna mappningsregler mot verklig transportörstrafik under en guidad 30-dagars provperiod innan någon last debiteras. Om avstämning av 214-händelser mot fakturor är det som tar mest administrationstid, är det det flödet som är värt att testa först. Ta en titt på Logivos transporthanteringsplattform och se hur ditt eget EDI-flöde beter sig i den.
Källor
- 214 | X12
- 214 - Transportation carrier shipment status (version 4010) - IBM Documentation
- EDI 214 Shipment Status Message | Understand the Transportation Carrier Shipment Status
FAQ
Vad betyder EDI 214:s orsakskoder?
Orsakskoder ligger tillsammans med AT7-händelsekoden och förklarar varför en status uppstod, till exempel en orsaksfördröjning eller en vägran; exakta koduppsättningar definieras vanligtvis per affärspartneravtal snarare än att vara universellt fastställda.
Vad är ett EDI 214-dokument?
Det är ANSI X12:s transportörsmeddelande för sändningsstatus, en elektronisk fil som transportörer skickar för att rapportera händelser som upphämtning, transportframsteg, leverans eller avvikelser för en specifik sändning.
Vad är skillnaden mellan EDI 204 och EDI 214?
EDI 204 är den load tender som en avsändare skickar för att erbjuda en sändning till en transportör; 214 är transportörens svar som rapporterar vad som faktiskt händer med lasten när den väl är i rörelse.
Vad är alla EDI-koder?
Det finns ingen enda universell lista; AT7-händelsekoder varierar något mellan transportörer och branscher, även om vanliga sådana som AF (upphämtning), D1 (levererad) och CA (avbruten) förekommer i de flesta implementationer.
Hur kopplas EDI 214-spårning till fakturering?
En leveranshändelse (D1) i 214 ger mottagaren det underlag som behövs för att validera den efterföljande 210-fakturan, vilket är varför matchning av 214-historik mot fakturor förkortar fakturatvister avsevärt.
Rekommenderat