Faqja kryesoreBlogAPI për gjurmimin e transportit detar: Ngjarjet e kontejnerëve, të dhënat e ETA-së dhe kriteret e përzgjedhjes

API për gjurmimin e transportit detar: Ngjarjet e kontejnerëve, të dhënat e ETA-së dhe kriteret e përzgjedhjes

17TRACK

Një API për gjurmimin e transportit detar duhet të lidhë lëvizjet e kontejnerëve, etapat e transportit dhe përditësimet e ETA-së me dërgesën që menaxhon ekipi juaj. Për agjentët e transportit, importuesit dhe ekipet e integrimit, testi i përzgjedhjes është nëse mund të identifikojë me besueshmëri udhëtimin e duhur të kontejnerit, të dallojë ngjarjet faktike nga parashikimet dhe të ofrojë kontekst të mjaftueshëm për të mbështetur vendimet operacionale. Një status i përgjithshëm i dërgesës ose një datë mbërritjeje e pashpjeguar nuk mjafton për menaxhimin e transportit detar.

Të dhënat e ngjarjeve të kontejnerëve dhe ETA-së për API-në e gjurmimit të transportit detar dhe përzgjedhja

Ky udhëzues shpjegon të dhënat që duhen kërkuar, mënyrën e interpretimit të ngjarjeve të kontejnerëve dhe vlerësimeve të mbërritjes, si dhe mënyrën e vlerësimit të një integrimi përpara se të angazhoni trafikun e prodhimit ose buxhetin e prokurimit.

Filloni me modelin e dërgesës, jo me ekranin e gjurmimit

Gjurmimi i transportit detar përfshin disa objekte të lidhura: një dërgesë tregtare, dokumentet e saj të transportit, një ose më shumë kontejnerë dhe segmentet e transportit që i bartin. Këto marrëdhënie kanë rëndësi sepse një rezervim i vetëm mund të përfshijë disa kontejnerë, ndërsa një kontejner mund të kalojë nëpër disa anije, terminale dhe segmente tokësore.

Një integrim i dobishëm duhet t'i ruajë këto marrëdhënie, në vend që t'i sheshojë të gjitha në një status të vetëm. Nëse dy kontejnerë nën të njëjtën dërgesë lëvizin ndryshe, sistemi duhet t'i lejojë operatorit ta shohë ndryshimin, në vend që të paraqesë një etapë në dukje të plotë në nivel dërgese.

Përpara se të vlerësoni një API, identifikoni referencat që biznesi juaj merr realisht:

  • Numri i kontejnerit: Identifikon pajisjen, por duhet të lidhet me dërgesën ose udhëtimin përkatës, sepse kontejnerët ripërdoren.
  • Referenca e rezervimit te transportuesi: Mund ta lidhë kërkesën e gjurmimit me një rezervim, në varësi të kërkesave të kërkimit të sistemit burimor.
  • Referenca e dokumentit të transportit: Mund ta identifikojë dërgesën në nivelin e transportuesit detar. Konfirmoni nëse API pranon referencat e dokumenteve që disponon ekipi juaj.
  • ID-ja e brendshme e dërgesës: Lidh regjistrimet e jashtme të gjurmimit me sistemin tuaj të menaxhimit të transportit, ERP-në ose softuerin e agjentit të transportit.

Mos supozoni se një referencë e faturës së shtëpisë të lëshuar nga një agjent transporti mund të përdoret kudo ku kërkohet referenca e dokumentit të një transportuesi detar. Testoni identifikuesit e saktë që disponohen në rrjedhat tuaja të rezervimit dhe dokumenteve.

Cilat ngjarje të kontejnerit duhet të ekspozojë një API?

Standardet Track & Trace të Digital Container Shipping Association ofrojnë një referencë të dobishme për diskutimin e të dhënave të dërgesave detare. DCSA dallon ngjarjet e dërgesës, transportit dhe pajisjes. Këto kategori ndihmojnë në ndarjen e përparimit administrativ, lëvizjes së transportit dhe trajtimit të kontejnerit fizik.

Një furnizues nuk duhet domosdoshmërisht të përdorë emrat e fushave që preferoni ju për të qenë i dobishëm, por duhet të shpjegojë se si modeli i tij i ngjarjeve lidhet me etapat operacionale që ju nevojiten.

Ngjarjet e pajisjes: çfarë i ndodhi kontejnerit

Etapat përkatëse të pajisjes mund të përfshijnë hyrjen në portë, ngarkimin, shkarkimin, daljen nga porta dhe lëvizjet e kontejnerit bosh. Disponueshmëria varet nga udhëtimi, burimi dhe produkti. Kërkoni regjistrime shembull në vend që të supozoni se çdo ngjarje është e disponueshme në çdo terminal.

Këto dallime kanë pasoja praktike. Mbërritja e anijes nuk provon se një kontejner i caktuar është shkarkuar. Shkarkimi nuk provon se kontejneri është liruar ose është gati për marrje. Një regjistrim i daljes nga porta gjithashtu kërkon vendndodhje dhe kontekst: dalja nga porta e një objekti transbordimi nuk është i njëjti rezultat biznesi si marrja nga terminali përfundimtar i importit.

Ngjarjet e transportit: ku ndodhet anija ose segmenti i transportit

Ngjarjet e mbërritjes dhe nisjes përshkruajnë aktivitetin e transportit. Për t'i interpretuar ato, sistemi juaj ka nevojë për vendndodhjen përkatëse, mënyrën e transportit dhe segmentin. Kur janë të disponueshëm, identifikuesit e anijes dhe udhëtimit ndihmojnë në dallimin e lundrimit të synuar nga një lëvizje tjetër që shërben të njëjtat porte.

Për ngarkesat e transborduara, ruani ndalesat ndërmjetëse. Reduktimi i itinerarit vetëm në origjinë dhe destinacion mund të fshehë një lidhje të humbur ose një ndryshim itinerari. Një afat kohor operativ duhet të mundësojë të shihet se cili segment ka përfunduar dhe cili mbetet i vlerësuar.

Ngjarjet e dërgesës: përparimi administrativ nuk është lëvizje fizike

Ngjarjet e dokumenteve dhe përpunimit të dërgesës mund të jenë të dobishme për rrjedhat e punës së agjentëve të transportit, por duhet të mbeten të dallueshme nga lëvizja e kontejnerit. Një etapë dokumentacioni nuk vërteton se ngarkesa ka lëvizur fizikisht dhe një ngjarje lëvizjeje nuk vërteton se të gjitha kërkesat tregtare ose rregullatore janë përmbushur.

Për çdo ngjarje, kërkoni llojin e ngjarjes, objektin përkatës, vendndodhjen, vulën kohore të ngjarjes, informacionin e zonës kohore, burimin dhe një tregues nëse ngjarja është e planifikuar, e vlerësuar apo faktike. Kërkoni gjithashtu një identifikues të qëndrueshëm të ngjarjes dhe mënyrën e korrigjimit, në mënyrë që përditësimet e përsëritura të mos krijojnë etapa dublikate.

Të dhënat e ETA-së kanë nevojë për një destinacion, kuptim dhe histori

ETA është koha e vlerësuar e mbërritjes në një pikë të përcaktuar. Ajo nuk është vetvetiu një premtim se ngarkesa do të jetë e disponueshme për t'u marrë. Një API për gjurmimin e transportit detar duhet ta bëjë të qartë etapën e destinacionit, në vend që të kthejë një fushë të paqartë të etiketuar vetëm eta.

Për shembull, një vlerësim mbërritjeje mund t'i referohet një ndalese në port, një terminali, një objekti tokësor ose një destinacioni tjetër të përcaktuar. Përpara se ta përdorni për planifikimin e kamionëve ose për të premtuar disponueshmërinë e inventarit, përcaktoni saktësisht se çfarë përfaqëson ajo vulë kohore.

Ndani burimin e vlerësimit nga statusi i tij

Një vlerësim i ofruar nga transportuesi dhe një parashikim i krijuar nga furnizuesi janë produkte të ndryshme të të dhënave. Asnjëri nuk duhet të paraqitet si mbërritje faktike. Pyetni nëse përgjigjja identifikon origjinën e vlerësimit, kohën e llogaritjes ose publikimit të tij dhe vendndodhjen ose ngjarjen që parashikon.

Nëse një furnizues ofron ETA parashikuese, kërkoni metodologjinë dhe mënyrën e vërtetimit. Pyetjet e dobishme përfshijnë se cila etapë parashikohet, sa kohë përpara mbërritjes matet performanca dhe nëse rezultatet ndryshojnë ndërmjet linjave që përdorni. Një pretendim i gjerë për saktësinë është i vështirë të zbatohet kur ngjarja e synuar dhe dritarja e matjes nuk specifikohen.

Mbani rishikimet e ETA-së në vend që t'i mbishkruani

ETA-ja më e fundit mbështet planifikimin e sotëm; historia e rishikimeve shpjegon çfarë ndryshoi. Ruani vlerësimin e mëparshëm, vlerësimin e ri, etapën përkatëse, burimin dhe kohën kur sistemi juaj e mori ndryshimin.

Kjo histori i lejon ekipit të operacioneve të dallojë një vonesë të konsiderueshme nga një korrigjim formatimi ose një ndryshim në një ndalesë portuale të palidhur. Ajo gjithashtu mbështet vlerësimin retrospektiv pa pretenduar se vlerësimi përfundimtar ishte i njohur më herët gjatë udhëtimit.

Zonat kohore duhen testuar shprehimisht. Ruani vulën kohore të burimit dhe zhvendosjen e saj kur ofrohet, normalizoni vulat kohore për llogaritje dhe shfaqni kohën lokale operacionale kur është e përshtatshme. Nëse burimi ofron vetëm një datë, mos e shndërroni në heshtje në një premtim të saktë mbërritjeje në mesnatë.

Vlerësoni mbulimin në nivel ngjarjeje

Prania e një transportuesi në një listë mbulimi nuk vërteton vetvetiu se çdo etapë e kontejnerit është e disponueshme. Mbulimi duhet të testohet kundrejt transportuesve, linjave, referencave të dërgesave dhe ngjarjeve operacionale që kanë rëndësi për biznesin tuaj.

Ndërtoni një matricë vlerësimi me kërkesat tuaja reale. Për çdo dërgesë përfaqësuese, kontrolloni nëse API mund ta zgjidhë referencën, të kthejë itinerarin e saktë, të ekspozojë etapat që kërkoni dhe të ruajë përditësimet gjatë pjesës së udhëtimit që menaxhoni.

  • Lëvizjet e drejtpërdrejta detare: A mund të identifikoni nisjen nga origjina, mbërritjen në destinacion dhe ngjarjet përkatëse të trajtimit të kontejnerit?
  • Lëvizjet e transbordimit: A janë të dukshme segmentet ndërmjetëse dhe a mund të mbeten të dallueshëm kontejnerët që lëvizin veçmas?
  • Segmentet tokësore: Nëse shërbimi juaj i përfshin, a ofron API etapa përkatëse hekurudhore, lumore ose të kamionëve, apo dukshmëria përfundon në port?
  • Përjashtimet: Si paraqiten ngjarjet që mungojnë, itineraret e ndryshuara, referencat e pakrahasueshme dhe ndërprerjet e burimit?
  • Dërgesat e përfunduara: A mund të marrin ekipet tuaja të dhëna të mjaftueshme historike për të hetuar një mosmarrëveshje me klientin ose për të rakorduar një regjistrim operacional?

Mbajini të dhënat e padisponueshme të ndara nga ngjarjet negative. Mungesa e një regjistrimi shkarkimi nuk provon se shkarkimi nuk ka ndodhur. Një integrim i dobishëm dallon një status të qartë operacional nga një boshllëk në dukshmëri.

Sjellja e API-së ka po aq rëndësi sa lista e ngjarjeve

Edhe një burim i pasur ngjarjesh mund të bëhet i vështirë për t'u operuar nëse sjellja e dorëzimit nuk është e qartë. Vlerësoni mënyrën se si aplikacioni juaj merr përditësimet, trajton korrigjimet dhe rikuperohet pas një ndërprerjeje.

Polling-u, webhook-et dhe rikuperimi

Polling-u i lejon aplikacionit tuaj të kërkojë përditësime sipas orarit të vet. Webhook-et i lejojnë një furnizuesi të dërgojë përditësime në një endpoint që operoni ju. Asnjë mekanizëm nuk garanton vetë freskinë: një webhook i dorëzuar menjëherë mund të përmbajë ende një ngjarje burimore të marrë me vonesë.

Kërkoni përkufizime të ndara për kohën e ngjarjes burimore, kohën e marrjes nga furnizuesi dhe kohën e njoftimit kur janë të disponueshme. Për webhook-et, konfirmoni autentikimin ose verifikimin e nënshkrimit, riprovimet, sjelljen ndaj dërgesave dublikatë dhe nëse njoftimet e dështuara mund të riluajhen. Për polling-un, kontrolloni faqëzimin, kufijtë e shpejtësisë, marrjen në mënyrë inkrementale dhe trajtimin e korrigjimeve historike.

Normalizimi pa humbur provat

Statuset e normalizuara i bëjnë rrjedhat ndërmjet transportuesve më të lehta, por thjeshtimi i tepërt heq kontekst të dobishëm. Preferoni një model që ju lejon të ruani ngjarjen e normalizuar së bashku me përshkrimin ose kodin origjinal të burimit kur është i disponueshëm.

Ruani veçmas regjistrimet hyrëse të papërpunuara nga rregullat e biznesit që i shndërrojnë ato në statuse të panelit. Kjo ju lejon të rishikoni një hartëzim pa humbur provat origjinale. Gjithashtu e bën më të lehtë hetimin e një statusi të paraqitur te klienti kur ai ndryshon nga interpretimi i ekipit operacional.

Kontrollet tregtare dhe të qeverisjes

Kërkoni një shpjegim me shkrim të njësisë së faturimit. Një abonim, dërgesë e gjurmuar, kontejner, kërkesë API-je dhe njoftim nuk janë masa të këmbyeshme. Sqaroni se si ndikojnë riprovimet, regjistrimet dublikatë, kërkimet historike dhe dërgesat e riaktivizuara te tarifat, në vend që të supozoni një model të caktuar çmimi.

Rishikoni gjithashtu ruajtjen e të dhënave, kontrollet e aksesit, rotacionin e kredencialeve, përdorimin e lejuar në sistemet pasuese, përshkallëzimin e mbështetjes dhe angazhimet e shërbimit. Trajtojini garancitë kontraktore veçmas nga demonstrimet e produktit dhe deklaratat e marketingut.

Mos supozoni se një API e përgjithshme gjurmimi i plotëson kërkesat e transportit detar

Një API gjurmimi duhet të zgjidhet për modelin e verifikuar të të dhënave, jo për etiketën e kategorisë. Përditësimet e dërgesave të pakove dhe dukshmëria e kontejnerëve detarë mund të shërbejnë për rrjedha të ndryshme pune, edhe kur të dyja përshkruhen si gjurmim dërgesash.

Nëse 17TRACK është tashmë në listën tuaj të ngushtë të integrimeve, përdorni faqen zyrtare të Tracking API dhe dokumentacionin e API-së si pika fillestare për kontrollin e kërkesave. Konfirmoni referencat e sakta detare, ngjarjet e kontejnerëve, segmentet e transportit dhe fushat e ETA-së që kërkon aplikacioni juaj përpara se ta trajtoni një integrim të përgjithshëm gjurmimi si zgjidhje për transportin detar. Ky udhëzues nuk përcakton këto aftësi specifike detare për 17TRACK.

I njëjti standard pranimi duhet të zbatohet për çdo kandidat: demonstroni të dhënat e kërkuara me dërgesa përfaqësuese dhe shpjegoni kufizimet e tij. Një rrjedhë më e gjerë gjurmimi të transportuesve mund të jetë e dobishme diku tjetër në zinxhirin tuaj të furnizimit, pa zëvendësuar një burim të specializuar ngjarjesh të kontejnerëve.

Kryeni një provë koncepti rreth vendimeve operacionale

Prova më e fortë e konceptit nis me vendimet që duhet të marrë ekipi juaj, jo me demonstrimin e një paneli. Zgjidhni dërgesa përfaqësuese nga operacionet tuaja, duke përfshirë udhëtime të drejtpërdrejta dhe rastet e vështira që krijojnë punë manuale.

  1. Përcaktoni kriteret e pranimit. Specifikoni referencat, ngjarjet, vendndodhjet, kuptimin e vulave kohore dhe trajtimin e pranueshëm të të dhënave që mungojnë përpara testimit.
  2. Vërtetoni identitetin. Konfirmoni që çdo rezultat i përket dërgesës dhe udhëtimit të synuar të kontejnerit. Përfshini pajisjet e ripërdorura dhe rezervimet me shumë kontejnerë kur është e nevojshme.
  3. Krahasoni me regjistrimet burimore. Kontrolloni etapat e kthyera kundrejt regjistrimeve të disponueshme të transportuesit ose terminalit, duke llogaritur ndryshimet në kohën e përditësimit.
  4. Testoni rishikimet dhe dështimet. Provoni njoftimet dublikatë, ngjarjet jashtë rendit, vulat kohore të korrigjuara, burimet e padisponueshme dhe ndërprerjet e endpoint-eve.
  5. Riluani një rrjedhë pune biznesi. Verifikoni nëse të dhënat mbështesin veprimin e synuar, si shqyrtimi i një lidhjeje të vonuar ose përditësimi i vlerësimit të inventarit në hyrje.
  6. Rishikoni boshllëqet e pazgjidhura. Shënoni nëse çdo boshllëk vjen nga burimi themelor, përpunimi i furnizuesit apo integrimi juaj. Dakordësoni masat korrigjuese përpara zgjerimit të përdorimit.

Për testimin e ETA-së, ruani çdo parashikim sapo të mbërrijë dhe krahasojeni me ngjarjen faktike përfundimtare për të njëjtën etapë. Mos e vlerësoni një parashikim të mbërritjes në port kundrejt marrjes në magazinë dhe mos kombinoni në një rezultat të pashpjeguar parashikime të bëra me kohë përgatitjeje shumë të ndryshme.

Rregulli i përzgjedhjes është i drejtpërdrejtë: zgjidhni integrimin që demonstrueshëm mbështet vendimet tuaja të kërkuara me ngjarje të gjurmueshme, vlerësime të kuptueshme dhe sjellje të rikuperueshme të dorëzimit. Nëse planifikimi i marrjes kërkon gjithashtu disponueshmërinë e terminalit, statusin e lirimit ose takimet, verifikoni veçmas këto të dhëna në vend që t'i nxirrni nga mbërritja e anijes.

Pyetje të shpeshta

A mund ta gjurmoj një dërgesë detare vetëm duke përdorur numrin e kontejnerit?

Kjo varet nga burimi i të dhënave dhe API-ja. Disa rrjedha pune mund të kërkojnë gjithashtu një identifikues transportuesi, referencë rezervimi ose referencë dokumenti transporti. Meqë pajisjet ripërdoren, konfirmoni që ngjarjet e kthyera i përkasin udhëtimit tuaj të synuar, në vend që të mbështeteni vetëm te numri i kontejnerit.

A do të thotë mbërritja faktike e anijes se kontejneri im është gati për t'u marrë?

Jo. Mbërritja e anijes, shkarkimi i kontejnerit, disponueshmëria e ngarkesës dhe leja për marrje janë fakte të ndara operacionale. Në varësi të dërgesës, marrja mund të kërkojë gjithashtu informacion lirimi dhe një takim në terminal. Verifikoni kushtet përkatëse me palët përgjegjëse.

A e zëvendëson gjurmimi i anijeve AIS gjurmimin e kontejnerëve?

Jo. AIS lidhet me identifikimin e anijes dhe informacionin e lëvizjes; ai vetë nuk përcakton statusin e ngarkimit, shkarkimit, lirimit ose daljes nga porta të një kontejneri individual. Lëvizja e anijes mund të ofrojë kontekst, por lidhja e kontejnerit me udhëtimin duhet ende të konfirmohet.

Sa shpesh duhet të përditësohet një API për gjurmimin detar?

Nuk ka një interval të vetëm të dobishëm për çdo rrjedhë pune. Përcaktoni kërkesat sipas shpejtësisë me të cilën ekipi juaj duhet të veprojë pasi informacioni përkatës burimor bëhet i disponueshëm. Matni veçmas vonesën e burimit nga vonesa e dorëzimit të API-së dhe konfirmoni çfarë ndodh kur burimi nuk publikon një ngjarje të re.

A mund të llogarisin ngjarjet e gjurmimit tarifat e demurrage ose detention?

Ngjarjet mund të mbështesin afatin kohor, por nuk përcaktojnë një llogaritje të plotë të tarifës. Ju nevojiten gjithashtu kushtet kontraktore, rregullat e kohës së lirë, trajtimi i kalendarit dhe kushtet autoritative të fillimit dhe përfundimit. Mos nxirrni shumat e pagueshme vetëm nga etapat e përgjithshme.

Burimet

Loading