Jūrų krovinių sekimo API: konteinerių įvykiai, ETA duomenys ir atrankos kriterijai

Vandenynų krovinių sekimo API turėtų susieti konteinerių judėjimą, transportavimo etapus ir ETA atnaujinimus su siunta, kurią valdo jūsų komanda. Krovinių ekspeditoriams, importuotojams ir integravimo komandoms pasirinkimo kriterijus yra tai, ar sistema gali patikimai nustatyti tinkamą konteinerio kelionę, atskirti faktinius įvykius nuo prognozių ir pateikti pakankamai konteksto operaciniams sprendimams priimti. Bendros siuntos būsena arba nepaaiškinta atvykimo data nėra pakankama vandenynų kroviniams valdyti.

Šiame vadove paaiškinama, kokių duomenų prašyti, kaip interpretuoti konteinerių įvykius ir atvykimo įverčius bei kaip įvertinti integraciją prieš perduodant jai gamybinį srautą ar skiriant pirkimo biudžetą.

Pradėkite nuo siuntos modelio, o ne nuo sekimo ekrano

Vandenynų krovinių sekimas apima kelis susijusius objektus: komercinę siuntą, jos transporto dokumentus, vieną ar daugiau konteinerių ir transportavimo etapus, kuriais jie gabenami. Šie ryšiai svarbūs, nes vienas užsakymas gali apimti kelis konteinerius, o vienas konteineris gali būti gabenamas keliais laivais, per terminalus ir sausumos transporto etapus.

Naudinga integracija turėtų išsaugoti šiuos ryšius, o ne viską sujungti į vieną būseną. Jei du tos pačios siuntos konteineriai juda skirtingai, sistema turėtų leisti operatoriui matyti skirtumą, o ne pateikti iš pažiūros išsamų siuntos lygio etapą.

Prieš vertindami API, nustatykite nuorodas, kurias jūsų įmonė iš tikrųjų gauna:

• Konteinerio numeris: identifikuoja įrangą, tačiau turėtų būti susietas su atitinkama siunta ar kelione, nes konteineriai naudojami pakartotinai.
• Vežėjo užsakymo nuoroda: gali susieti sekimo užklausą su užsakymu, atsižvelgiant į šaltinio sistemos paieškos reikalavimus.
• Transporto dokumento nuoroda: gali identifikuoti siuntą jūrų vežėjo lygmeniu. Patikrinkite, ar API priima jūsų komandos turimas dokumentų nuorodas.
• Vidinis siuntos ID: susieja išorinius sekimo įrašus su jūsų transporto valdymo sistema, ERP ar ekspedijavimo programine įranga.

Nelaikykite savaime suprantamu dalyku, kad ekspeditoriaus išduota namų važtaraščio nuoroda gali būti naudojama visur, kur reikia jūrų vežėjo dokumento nuorodos. Išbandykite tikslius identifikatorius, prieinamus jūsų užsakymų ir dokumentų tvarkymo procesuose.

Kokius konteinerių įvykius turėtų pateikti API?

Digital Container Shipping Association „Track & Trace“ standartai yra naudinga nuoroda aptariant vandenynų siuntų duomenis. DCSA skiria siuntos, transportavimo ir įrangos įvykius. Šios kategorijos padeda atskirti administracinę eigą, transporto judėjimą ir fizinio konteinerio tvarkymą.

Teikėjas neprivalo naudoti jūsų pageidaujamų laukų pavadinimų, kad būtų naudingas, tačiau turėtų paaiškinti, kaip jo įvykių modelis susiejamas su jums reikalingais operaciniais etapais.

Įrangos įvykiai: kas nutiko konteineriui

Atitinkami įrangos etapai gali apimti įvažiavimą į terminalą, pakrovimą, iškrovimą, išvažiavimą iš terminalo ir tuščių konteinerių judėjimą. Prieinamumas priklauso nuo kelionės, šaltinio ir produkto. Reikalaukite pavyzdinių įrašų, o ne manykite, kad kiekviename terminale prieinamas kiekvienas įvykis.

Šie skirtumai turi praktinių pasekmių. Laivo atvykimas neįrodo, kad konkretus konteineris buvo iškrautas. Iškrovimas neįrodo, kad konteineris išleistas arba paruoštas atsiimti. Išvažiavimo iš terminalo įrašui taip pat reikia vietos ir konteksto: išvažiavimas iš perkrovimo objekto nėra toks pats verslo rezultatas kaip atsiėmimas galutiniame importo terminale.

Transportavimo įvykiai: kur yra laivas arba transportavimo etapas

Atvykimo ir išvykimo įvykiai apibūdina transportavimo veiklą. Norint juos interpretuoti, sistemai reikia susietos vietos, transporto rūšies ir etapo. Jei prieinami, laivo ir reiso identifikatoriai padeda atskirti planuotą reisą nuo kito judėjimo tarp tų pačių uostų.

Perkrovimo krovinių atveju išsaugokite tarpines stoteles. Sumažinus maršrutą iki kilmės ir paskirties vietos, gali būti paslėptas praleistas susisiekimas arba maršruto pakeitimas. Operacinė laiko juosta turėtų leisti matyti, kuris etapas baigtas, o kuris tebėra tik numatomas.

Siuntos įvykiai: administracinė eiga nėra fizinis judėjimas

Dokumentų ir siuntos apdorojimo įvykiai gali būti naudingi ekspedijavimo procesuose, tačiau juos reikia atskirti nuo konteinerio judėjimo. Dokumento etapas nepatvirtina, kad krovinys fiziškai pajudėjo, o judėjimo įvykis nepatvirtina, kad įvykdyti visi komerciniai ar reguliavimo reikalavimai.

Kiekvienam įvykiui prašykite įvykio tipo, atitinkamo objekto, vietos, įvykio laiko, informacijos apie laiko juostą, šaltinio ir nuorodos, ar įvykis yra suplanuotas, numatomas ar faktinis. Taip pat prašykite stabilaus įvykio identifikatoriaus ir taisymo elgsenos, kad pasikartojantys atnaujinimai nesukurtų pasikartojančių etapų.

ETA duomenims reikia paskirties vietos, reikšmės ir istorijos

ETA yra numatomas atvykimo laikas konkrečiame taške. Tai savaime nėra pažadas, kad krovinį bus galima atsiimti. Vandenynų krovinių sekimo API turėtų aiškiai nurodyti paskirties etapo reikšmę, o ne grąžinti neaiškų lauką, pavadintą tik eta.

Pavyzdžiui, atvykimo įvertis gali reikšti apsilankymą uoste, terminalą, sausumos objektą ar kitą apibrėžtą paskirties vietą. Prieš naudodami jį sunkvežimių planavimui ar atsargų prieinamumui žadėti, tiksliai nustatykite, ką reiškia ši laiko žyma.

Atskirkite įverčio šaltinį nuo jo būsenos

Vežėjo pateiktas įvertis ir teikėjo sugeneruota prognozė yra skirtingi duomenų produktai. Nė vienas iš jų neturėtų būti pateikiamas kaip faktinis atvykimas. Išsiaiškinkite, ar atsakyme nurodoma įverčio kilmė, jo apskaičiavimo arba paskelbimo laikas ir vieta ar įvykis, kurį jis prognozuoja.

Jei teikėjas siūlo prognozuojamą ETA, paprašykite jo metodikos ir validavimo būdo. Naudingi klausimai: kuris etapas prognozuojamas, kiek laiko iki atvykimo vertinamas tikslumas ir ar rezultatai skiriasi jūsų naudojamuose maršrutuose. Bendrą tikslumo teiginį sunku pritaikyti, kai neapibrėžtas tikslinis įvykis ir matavimo laikotarpis.

Išsaugokite ETA pakeitimus, o ne juos perrašykite

Naujausias ETA padeda planuoti šiandien, o pakeitimų istorija paaiškina, kas pasikeitė. Išsaugokite ankstesnį įvertį, naują įvertį, susietą etapą, šaltinį ir laiką, kada jūsų sistema gavo pakeitimą.

Ši istorija leidžia operacijų komandai atskirti reikšmingą vėlavimą nuo formatavimo pataisos ar su kitu uosto apsilankymu susijusio pakeitimo. Ji taip pat leidžia retrospektyviai vertinti situaciją neapsimetant, kad galutinis įvertis buvo žinomas anksčiau kelionės metu.

Laiko juostas reikia aiškiai išbandyti. Išsaugokite šaltinio laiko žymą ir jos poslinkį, jei jis pateiktas, normalizuokite laiko žymas skaičiavimams ir, kai tinka, rodykite vietos operacinį laiką. Jei šaltinis pateikia tik datą, nepaverskite jos tyliai tiksliu atvykimo pažadu vidurnaktį.

Vertinkite aprėptį įvykio lygmeniu

Vien vežėjo buvimas aprėpties sąraše neįrodo, kad prieinamas kiekvienas konteinerio etapas. Aprėptį reikia tikrinti pagal vežėjus, maršrutus, siuntų nuorodas ir jūsų verslui svarbius operacinius įvykius.

Sudarykite vertinimo matricą pagal realius reikalavimus. Kiekvienai tipinei siuntai patikrinkite, ar API gali išspręsti nuorodą, grąžinti teisingą maršrutą, pateikti reikalingus etapus ir išlaikyti atnaujinimus per tą kelionės dalį, kurią valdote.

• Tiesioginis gabenimas jūra: ar galite nustatyti išvykimą iš kilmės vietos, atvykimą į paskirties vietą ir svarbius konteinerio tvarkymo įvykius?
• Perkrovimo maršrutai: ar matomi tarpiniai etapai ir ar atskirai judantys konteineriai išlieka atskiriami?
• Sausumos etapai: jei jūsų paslauga juos apima, ar API pateikia svarbius geležinkelio, baržų ar sunkvežimių etapus, ar matomumas baigiasi uoste?
• Išimtys: kaip pateikiami trūkstami įvykiai, pakeisti maršrutai, nesutampančios nuorodos ir šaltinio sutrikimai?
• Užbaigtos siuntos: ar jūsų komanda gali gauti pakankamai istorinių duomenų klientų ginčui ištirti arba operaciniam įrašui suderinti?

Nepasiekiamus duomenis laikykite atskirai nuo neigiamų įvykių. Iškrovimo įrašo nebuvimas neįrodo, kad iškrovimas neįvyko. Naudinga integracija skiria aiškią operacinę būseną nuo matomumo spragos.

API elgsena yra tokia pat svarbi kaip įvykių sąrašas

Net ir gausus įvykių srautas gali būti sunkiai valdomas, jei neaišku, kaip jie pristatomi. Įvertinkite, kaip jūsų programa gauna atnaujinimus, tvarko pataisas ir atsigauna po sutrikimo.

Apklausos, žiniatinklio kabliai ir atkūrimas

Apklausos leidžia jūsų programai prašyti atnaujinimų pagal savo tvarkaraštį. Žiniatinklio kabliai leidžia teikėjui siųsti atnaujinimus į jūsų valdomą galinį tašką. Nė vienas mechanizmas pats savaime neužtikrina naujumo: net iš karto pristatytame žiniatinklio kablio pranešime gali būti vėlai gautas šaltinio įvykis.

Jei įmanoma, prašykite atskirų šaltinio įvykio laiko, teikėjo gavimo laiko ir pranešimo laiko apibrėžimų. Naudodami žiniatinklio kablius patvirtinkite autentifikavimą arba parašo tikrinimą, pakartotinius bandymus, pasikartojančių pristatymų elgseną ir galimybę pakartoti nepavykusius pranešimus. Naudodami apklausas patikrinkite puslapiavimą, spartos ribojimus, prieauginių duomenų gavimą ir istorinių pataisų tvarkymą.

Normalizavimas neprarandant įrodymų

Normalizuotos būsenos palengvina skirtingų vežėjų procesus, tačiau per didelis supaprastinimas pašalina naudingą kontekstą. Pirmenybę teikite modeliui, leidžiančiam išsaugoti normalizuotą įvykį kartu su originaliu šaltinio aprašu ar kodu, kai tai prieinama.

Neapdorotus gaunamus įrašus saugokite atskirai nuo verslo taisyklių, kurios juos paverčia skydelio būsenomis. Taip galėsite pakeisti susiejimą neprarasdami pirminių įrodymų. Tai taip pat palengvina klientams skirtos būsenos tyrimą, kai ji skiriasi nuo operacijų komandos interpretacijos.

Komerciniai ir valdymo patikrinimai

Prašykite rašytinio atsiskaitymo vieneto paaiškinimo. Prenumerata, sekama siunta, konteineris, API užklausa ir pranešimas nėra lygiaverčiai matavimo vienetai. Išsiaiškinkite, kaip kainą veikia pakartotiniai bandymai, pasikartojančios registracijos, istorinės paieškos ir iš naujo suaktyvintos siuntos, o ne manykite, kad taikomas konkretus kainodaros modelis.

Taip pat peržiūrėkite duomenų saugojimą, prieigos kontrolę, kredencialų keitimą, leidžiamą tolesnį naudojimą, palaikymo eskalavimą ir paslaugų įsipareigojimus. Sutartines garantijas vertinkite atskirai nuo produktų demonstracijų ir rinkodaros teiginių.

Nelaikykite, kad bendroji sekimo API atitinka vandenynų krovinių reikalavimus

Sekimo API reikėtų rinktis pagal patikrintą duomenų modelį, o ne pagal kategorijos pavadinimą. Siuntų pristatymo atnaujinimai ir vandenynų konteinerių matomumas gali būti skirti skirtingiems procesams, net jei abu vadinami siuntų sekimu.

Jei 17TRACK jau yra jūsų integracijos kandidatų sąraše, pradėdami reikalavimų patikrą naudokite jo oficialų Tracking API puslapį ir API dokumentaciją. Prieš laikydami bet kokią bendrą sekimo integraciją vandenynų krovinių sprendimu, patvirtinkite tikslias jūsų programai reikalingas vandenynų nuorodas, konteinerių įvykius, transportavimo etapus ir ETA laukus. Šis vadovas nepatvirtina, kad 17TRACK turi šias konkrečiai vandenynų kroviniams skirtas galimybes.

Tas pats priėmimo standartas turėtų būti taikomas bet kuriam kandidatui: pademonstruokite reikalingus duomenis naudodami tipines siuntas ir paaiškinkite apribojimus. Platesnis vežėjų sekimo procesas gali būti naudingas kitur tiekimo grandinėje, tačiau nepakeičia specializuoto konteinerių įvykių srauto.

Vykdykite bandomąjį projektą, orientuotą į operacinius sprendimus

Geriausias bandomasis projektas prasideda nuo sprendimų, kuriuos turi priimti jūsų komanda, o ne nuo skydelio demonstracijos. Pasirinkite tipines savo veiklos siuntas, įskaitant nesudėtingus reisus ir sudėtingus atvejus, dėl kurių atsiranda rankinio darbo.

1. Apibrėžkite priėmimo kriterijus. Prieš bandymus nurodykite reikiamas nuorodas, įvykius, vietas, laiko žymų reikšmes ir priimtiną trūkstamų duomenų tvarkymą.
2. Patvirtinkite tapatybę. Įsitikinkite, kad kiekvienas rezultatas priklauso numatytai siuntai ir konteinerio kelionei. Kai aktualu, įtraukite pakartotinai naudojamą įrangą ir užsakymus su keliais konteineriais.
3. Palyginkite su šaltinio įrašais. Palyginkite grąžintus etapus su prieinamais vežėjo ar terminalo įrašais, atsižvelgdami į atnaujinimų laiko skirtumus.
4. Išbandykite pakeitimus ir gedimus. Išbandykite pasikartojančius pranešimus, ne eilės tvarka gaunamus įvykius, pataisytas laiko žymas, nepasiekiamus šaltinius ir galinių taškų sutrikimus.
5. Pakartokite verslo procesą. Patikrinkite, ar duomenys padeda atlikti numatytą veiksmą, pavyzdžiui, peržiūrėti vėluojantį susisiekimą arba atnaujinti gaunamų atsargų įvertį.
6. Peržiūrėkite neišspręstas spragas. Užregistruokite, ar kiekvieną spragą sukėlė pagrindinis šaltinis, teikėjo apdorojimas ar jūsų integracija. Prieš plėsdami naudojimą susitarkite dėl sprendimo.

Testuodami ETA, išsaugokite kiekvieną prognozę ją gavę ir palyginkite su galutiniu faktiniu to paties etapo įvykiu. Nevertinkite uosto atvykimo prognozės pagal atvykimą į sandėlį ir nejunkite prognozių, sudarytų labai skirtingu išankstiniu laikotarpiu, į vieną nepaaiškintą balą.

Pasirinkimo taisyklė paprasta: rinkitės integraciją, kuri įrodomai palaiko jūsų reikalingus sprendimus, pateikdama atsekamus įvykius, suprantamus įverčius ir atkuriamą pristatymo elgseną. Jei atsiėmimo planavimui taip pat reikia terminalo prieinamumo, išleidimo būsenos ar vizitų, patikrinkite šiuos duomenis atskirai, o ne darykite išvadas pagal laivo atvykimą.

DUK

Ar galiu sekti vandenynų siuntą naudodamas tik konteinerio numerį?

Tai priklauso nuo duomenų šaltinio ir API. Kai kuriems procesams taip pat gali reikėti vežėjo identifikatoriaus, užsakymo nuorodos arba transporto dokumento nuorodos. Kadangi įranga naudojama pakartotinai, patvirtinkite, kad grąžinti įvykiai priklauso numatytai kelionei, o ne pasikliaukite vien konteinerio numeriu.

Ar faktinis laivo atvykimas reiškia, kad mano konteinerį galima atsiimti?

Ne. Laivo atvykimas, konteinerio iškrovimas, krovinio prieinamumas ir leidimas atsiimti yra atskiri operaciniai faktai. Priklausomai nuo siuntos, atsiėmimui taip pat gali reikėti išleidimo informacijos ir terminalo vizito. Patikrinkite atitinkamas sąlygas su už jas atsakingomis šalimis.

Ar AIS laivų sekimas pakeičia konteinerių sekimą?

Ne. AIS susijusi su laivo identifikavimu ir judėjimo informacija; ji pati nepatvirtina konkretaus konteinerio pakrovimo, iškrovimo, išleidimo ar išvažiavimo iš terminalo būsenos. Laivo judėjimas gali suteikti konteksto, tačiau konteinerio susiejimą su reisu vis tiek reikia patvirtinti.

Kaip dažnai turėtų būti atnaujinama vandenynų sekimo API?

Visiems procesams nėra vieno naudingo intervalo. Reikalavimus nustatykite pagal tai, kaip greitai jūsų komandai reikia veikti, kai tampa prieinama svarbi šaltinio informacija. Šaltinio delsą matuokite atskirai nuo API pristatymo delsos ir išsiaiškinkite, kas nutinka, kai šaltinis nepaskelbia naujo įvykio.

Ar sekimo įvykiai gali apskaičiuoti demurrage arba detention mokesčius?

Įvykiai gali padėti sudaryti laiko juostą, tačiau jie neapibrėžia viso mokesčio skaičiavimo. Taip pat reikia taikomų sutarties sąlygų, nemokamo laiko taisyklių, kalendoriaus taikymo ir autoritetingų pradžios bei pabaigos sąlygų. Nemėginkite mokėtinų sumų apskaičiuoti vien pagal bendruosius etapus.

Šaltiniai

• DCSA: „Track & Trace“ standartai — informacinė sistema siuntų, transportavimo ir įrangos įvykiams konteinerių gabenime.
• DCSA: OpenAPI specifikacijų saugykla — techninė nuoroda į DCSA API apibrėžimus ir įvykių struktūras. Kurdami integraciją patikrinkite taikomą specifikacijos versiją.
• Tarptautinė jūrų organizacija: automatinės identifikavimo sistemos — pagrindinė informacija apie AIS ir jos teikiamą laivų informaciją.
• 17TRACK: Tracking API ir oficiali API dokumentacija — pradžios taškai produkto tinkamumui tikrinti; tai nėra įrodymas, kad palaikomi vandenynų konteinerių įvykiai ar prognozuojamas ETA.