În supply chain-ul multimodal, mesajul EDI IFTSTA este coloana vertebrală a notificărilor de status: confirmă ridicări, încărcări, transbordări, sosiri, eliberări și excepții, în timp real, între transportatori, freight forwarderi, expeditori și sisteme TMS/ERP. Valoarea lui EDI IFTSTA depinde direct de guvernanța de date și de rigoarea codificărilor: UN/LOCODE pentru locații, UN/CL pentru listele de coduri EDIFACT și SCAC/BIC pentru identificarea transportatorilor și echipamentelor. Într-o piață în care top transportatori precum Maersk, MSC, CMA CGM, Hapag-Lloyd sau ONE trimit zilnic milioane de actualizări, o singură abatere de cod poate genera costuri de demuraj, întârzieri în vamă sau reconciliere manuală în ERP.
Guvernanță de date pentru EDI IFTSTA: cine deține ce și cum se validează
O implementare EDI IFTSTA robustă începe cu un model clar de guvernanță:
- RACI: cine deține master data (transportator, forwarder, beneficiar), cine aprobă mapările și cine operează schimbările.
- Catalog de date: definiții pentru segmentele IFTSTA (ex. STS, EQD, LOC, TDT, NAD, RFF), calitatea așteptată și regulile de validare.
- Versionare: blocarea versiunii EDIFACT (ex. D.96A, D.01B, D.14B) și a versiunilor de liste UN/CL folosite de EDI IFTSTA.
- MDM/Mastering: mapări autoritative între UN/LOCODE, coduri interne de depozite, BIC Facility Code și SMDG Terminal Codes, acolo unde e cazul.
UN/LOCODE: fundamentul locațiilor în EDI IFTSTA
UN/LOCODE, întreținut de UNECE/UN/CEFACT, este un cod din cinci caractere (ex. NLRTM pentru Rotterdam, CNSHA pentru Shanghai) care identifică locații comerciale și de transport la nivel global. Directorul este actualizat, de regulă, de două ori pe an și conține peste 100.000 de locații în aproape toate țările și teritoriile. În EDI IFTSTA, segmentele LOC și NAD se bazează pe UN/LOCODE pentru a exprima locația evenimentului sau a părților implicate.
Practici cheie:
- Validați la ingestie că UN/LOCODE există în ultima versiune aprobată; blocați evenimente cu “ZZZZZ” sau coduri provizorii fără aprobare.
- Evitați ambiguitățile oraș-port: exemplu, pentru terminale specificați și facility via FTX/LOC sau un cod de terminal standardizat (vezi BIC Facility Code).
- Guvernați alias-urile: “Constanța Sud Agigea” vs “Constanta South” trebuie să trimită la același UN/LOCODE (ROCND), altfel EDI IFTSTA va produce duplicate în ERP.
UN/CL (UN/EDIFACT Code Lists): coerența semantică a statusurilor
EDI IFTSTA folosește listele UN/CL pentru a standardiza tipurile de status, motivele și calificatorii (de ex. pentru STS – categorie de status, tip de eveniment; pentru DTM – calificatori de dată; pentru RFF – tipuri de referințe). Aliniați-vă la codurile oficiale UN/CL și documentați excepțiile de industrie (maritim, rutier, aerian).
Ce recomandă industria:
- Blocați statusuri “liber text”. Impuneți UN/CL și folosiți FTX doar pentru clarificări.
- Mapați setul de evenimente la referențialele DCSA Track & Trace, care sunt aliniate la modelele UN/CEFACT multimodale, pentru a asigura interoperabilitatea între transportatori diferiți.
- Congelați versiunile: când un partener trece la o nouă ediție UN/CL, rulați un ciclu de test cu EDI IFTSTA pe un mediu sandbox înainte de producție.
SCAC și BIC: identitatea transportatorilor și a echipamentelor
În America de Nord, identificarea transportatorilor în EDI IFTSTA și în documentația vamală (ex. ACE) se face prin SCAC (Standard Carrier Alpha Code), administrat de NMFTA. SCAC este, de regulă, un cod de 2–4 litere (ex. “MSCU” pentru MSC în anumite fluxuri SUA). Directorul SCAC este licențiat și actualizat frecvent; validați periodic ca SCAC-urile din TDT/NAD să fie active.
Pentru echipamente, standardul ISO 6346 definește numărul de container (ex. MSCU 123456 7), iar BIC (Bureau International des Containers) gestionează registrul de coduri de proprietar (BIC Codes) și BIC Facility Code Directory. Directorul BIC Facility Code a depășit în ultimii ani pragul de zeci de mii de facilități codificate la nivel global, fiind folosit de transportatori și terminale pentru a evita confuziile de locație. Integrarea acestor coduri în EDI IFTSTA (ex. în FTX/LOC) reduce substanțial erorile legate de terminale.
Cine folosește la scară EDI IFTSTA și ce câștigă
Marile linii maritime (Maersk, MSC, CMA CGM, Hapag-Lloyd, ONE), forwarderi globali (Kuehne+Nagel, DB Schenker, DSV), precum și platforme de vizibilitate (project44, FourKites, Descartes) distribuie evenimente operaționale prin EDI IFTSTA către TMS/ERP (SAP TM, Oracle OTM, Blue Yonder). Rezultatele tipice raportate în industrie: reducerea cu peste 70% a “check calls”, reconciliere automată a milestone-urilor, scăderea costurilor de excepție și facturare mai rapidă.
În Europa, EDI IFTSTA rămâne standardul pentru track & trace EDIFACT, în timp ce în SUA echivalentul X12 214 coexistă. Organizații precum DCSA au armonizat evenimentele de status cu modelele UN/CEFACT, accelerând interoperabilitatea între transportatori și clienți enterprise.
Reguli tehnice care fac diferența în EDI IFTSTA
- Consistență TDT/NAD: operatorul raportat în TDT trebuie să fie același cu “carrier” în NAD, cu SCAC sau cod de companie coerent.
- Validare container: EQD + număr ISO 6346 valid (inclusiv check digit). Respingeți EDI IFTSTA cu prefix inexistent în registrul BIC.
- Ancore temporale: DTM cu fus orar explicit; păstrați UTC intern și afișați local doar în UI.
- Locații: LOC cu UN/LOCODE obligatoriu; când e necesară granularitate de terminal, adiționați BIC Facility Code.
- Referințe: RFF pentru legătura cu booking/bill of lading; mențineți mapări stabile (de ex. RFF+BN:… pentru booking, RFF+BM:… pentru B/L).
- Transport multimodal: segmentați evenimentele pe “leg”-uri (maritim, rutier, feroviar) și păstrați coerența între STS și TDT.
- Transport securizat: transmiteți EDI IFTSTA via AS2/AS4 cu non-repudiere; corelați corecțiile prin BGM și numere UNH unice.
Procese operaționale și calitatea datelor
Implementați un “data quality firewall” în gateway-ul EDI: validare UN/LOCODE, verificare SCAC activ, verificare prefix BIC, liste UN/CL obligatorii, precum și aliniere între STS și evenimentul business. Logging-ul granular pe fiecare EDI IFTSTA și un tabloul de bord care măsoară rata de reject/accept pe partener sunt esențiale pentru îmbunătățire continuă.
În România, unii furnizori integrează EDI IFTSTA ca parte a platformelor lor. De exemplu, EDIconnect.ro (ca modul în CRMconnect) oferă rutare, validări de codificări și mapare către ERP, util pentru implementări rapide la retaileri și distribuitori cu fluxuri internaționale.
Concluzie
EDI IFTSTA rămâne standardul de facto pentru status operațional multimodal. Cheia nu este doar “a trimite un fișier”, ci a construi o guvernanță de date care face codificările UN/LOCODE, UN/CL și SCAC/BIC coerente, verificabile și versionate. Într-o lume a volumelor tot mai mari și a cerințelor de vizibilitate în timp real, organizațiile care tratează EDI IFTSTA ca pe un produs de date – cu proprietari, SLA-uri și controale automate – câștigă viteză operațională, reduc costurile și cresc încrederea în lanțul lor logistic digital.