Si të unifikoni gjurmimin e dërgesave në Australi dhe Zelandën e Re me një API

Për të unifikuar gjurmimin e dërgesave në Australi dhe Zelandën e Re me një API të vetëm, lidhni sistemin e porosive ose të përmbushjes me një shërbim gjurmimi me shumë transportues, regjistroni çdo dërgesë me identitetin e saktë të transportuesit dhe përktheni përditësimet hyrëse të gjurmimit në një model të qëndrueshëm të ngjarjeve të brendshme. Integrimi duhet të ruajë detajet specifike të transportuesit, duke u ofruar ekipit tuaj të operacioneve dhe klientëve një përvojë të vetme gjurmimi për dërgesat vendase dhe ato trans-Tasman.

Për zhvilluesit, operatorët e tregtisë elektronike dhe ekipet e logjistikës, sfida kryesore nuk është të bëjnë kërkesën e parë API. Sfida është të mbajnë të qëndrueshme identitetet e dërgesave, statuset e dorëzimit, kalimet ndërmjet transportuesve dhe njoftimet për klientët, kur transportues të ndryshëm e përshkruajnë të njëjtin udhëtim në mënyra të ndryshme. Ky udhëzues shpjegon si ta projektoni këtë integrim, si të vlerësoni një API gjurmimi dhe si ta testoni para se të mbështeteni tek ai në prodhim.

Përcaktoni çfarë duhet të unifikojë API-ja e vetme

Një API e përbashkët i jep aplikacionit tuaj një pikë të përbashkët integrimi. Ajo nuk bën që çdo transportues të publikojë informacion identik ose të skanojë pakot me të njëjtën frekuencë. Arkitektura juaj duhet të dallojë ndërmjet një ndërfaqeje të qëndrueshme dhe dukshmërisë së plotë.

Filloni me një inventar dërgesash të bazuar në aktivitetin real të përmbushjes, jo në një listë të përgjithshme të transportuesve që operojnë në secilin vend. Përfshini dërgesat vendase australiane, dërgesat vendase të Zelandës së Re dhe lëvizjet ndërkufitare në të dyja drejtimet. Shtoni origjina të tjera ndërkombëtare nëse janë pjesë e biznesit tuaj.

• Transportuesi dhe shërbimi: Regjistroni transportuesin, shërbimin e përdorur dhe çdo partner të njohur të dorëzimit.
• Rruga: Dalloni origjinën dhe destinacionin e dërgesës nga vendndodhja e skanimit të fundit.
• Identifikuesit: Regjistroni referencën e porosisë, referencën e përmbushjes, numrin e gjurmimit dhe çdo numër zëvendësues ose partneri.
• Qëllimi operacional: Përcaktoni nëse përditësimet mbështesin gjurmimin nga klienti, menaxhimin e përjashtimeve, konfirmimin e dorëzimit apo të trija.
• Detaji i kërkuar: Vendosni nëse mjafton një status i përgjithshëm dorëzimi apo nëse agjentëve u duhen gjithashtu përshkrimet e skanimeve, vendndodhjet dhe vulat kohore.

Ky inventar bëhet lista juaj e kontrollit për pranimin. Mbulimi i përgjithshëm i transportuesve nga një ofrues është i dobishëm për përzgjedhjen fillestare, por vendimi juaj duhet të bazohet nëse kombinimet reale transportues-shërbim kthejnë informacion të përdorshëm gjurmimi.

Vlerësoni API-në e gjurmimit sipas përzierjes suaj të dërgesave

17TRACK ofron një Tracking API, duke e bërë atë një mundësi të përshtatshme për t’u vlerësuar për një integrim me shumë transportues. Përdorni dokumentacionin zyrtar të API-së për të kontrolluar kërkesat aktuale të integrimit. Trajtojeni mbështetjen e transportuesve, fushat e ngjarjeve, sjelljen e përditësimeve, kufijtë e llogarisë dhe kushtet tregtare si çështje që duhen verifikuar për zbatimin tuaj, jo si supozime të nxjerra nga kategoria e produktit.

Bëjini të njëjtat pyetje praktike çdo API-je që merrni në konsideratë:

• A mund të identifikojë dhe gjurmojë transportuesit dhe shërbimet në inventarin tuaj të dërgesave?
• Kur identifikimi i transportuesit është i paqartë, a mund të jepni një identifikues të qartë të transportuesit?
• Si i merr aplikacioni juaj përditësimet dhe çfarë mekanizmi rikuperimi është i disponueshëm nëse një përditësim humbet?
• Cilat detaje të transportuesit origjinal mbeten të disponueshme krahas statuseve të normalizuara?
• Çfarë ndodh kur një numër gjurmimi është i pavlefshëm, ende i panjohur ose i lidhur me më shumë se një transportues të mundshëm?
• Si përcaktohen përdorimi, faturimi, kohëzgjatja e gjurmimit dhe kufijtë e aksesit për llogarinë tuaj?

Rregull i rekomanduar vendimmarrjeje: zgjidhni në bazë të testeve të suksesshme të modeleve tuaja reale të transportit, jo të numrit më të madh të transportuesve të reklamuar. Një integrim është i përshtatshëm kur ofron informacion të mjaftueshëm për të mbështetur vendimet tuaja operative dhe i shfaq dështimet aq qartë sa të mund të rikuperoheni prej tyre.

Ndërtoni një model të brendshëm që përballon ndryshimet ndërmjet transportuesve

Ndani porositë, dërgesat dhe segmentet e gjurmimit

Mos përdorni numrin e gjurmimit si çelësin kryesor të një porosie. Një porosi mund të përmbajë disa pako dhe udhëtimi i një pakoje mund të përfshijë më shumë se një identifikues gjurmimi. Në vend të kësaj, krijoni një ID të brendshme të dërgesës dhe lidhni regjistrimet e gjurmimit me të.

Një model praktik ka tri nivele: porosinë e klientit, dërgesat fizike të saj dhe segmentet e gjurmimit të lidhura me çdo dërgesë. Një pako vendase mund të ketë nevojë vetëm për një segment gjurmimi. Një pako ndërkufitare mund të kërkojë regjistrime të lidhura kur bëhet i rëndësishëm një transportues ose identifikues tjetër.

Përcaktoni një regjistrim gjurmimi sipas transportuesit, si dhe sipas numrit të gjurmimit, dhe ruani lidhjen e tij me ID-në e dërgesës. Nëse shfaqet një numër i ri i partnerit të dorëzimit, shtojeni si identifikues të lidhur në vend që të mbishkruani origjinalin. Kjo ruan historikun që agjentëve të mbështetjes u nevojitet kur hetojnë një kalim ndërmjet transportuesve.

Ruani një ngjarje të papërpunuar dhe një ngjarje të normalizuar

Përdorni një fjalor të vogël statusesh të brendshme mbi të cilat biznesi juaj mund të veprojë. Për shembull, mund të përcaktoni: para tranzitit, në tranzit, në dorëzim, e disponueshme për tërheqje, e dorëzuar, përjashtim dhe e panjohur. Këto janë kategori të sugjeruara të brendshme, jo një pretendim për skemën e statusit të një ofruesi të caktuar.

Ruani përshkrimin origjinal të transportuesit krahas statusit të hartuar. Një ngjarje në pikën e tërheqjes dhe një problem me adresën mund të kërkojnë të dyja veprime nga klienti, por nuk duhet të prodhojnë të njëjtin mesazh. Po kështu, krijimi i një etikete nuk duhet të bëhet automatikisht provë se transportuesi e mban fizikisht pakon.

Dokumentoni vendimet e hartimit në një konfigurim me versione. Kur shfaqet një përshkrim i ri ngjarjeje, vendoseni në një radhë shqyrtimi nëse kuptimi i tij është i paqartë. Një gjendje e qartë “e panjohur” është më e sigurt sesa caktimi me siguri i rezultatit të gabuar të dorëzimit.

Dalloni kohën e ngjarjes nga koha e pranimit

Ruani veçmas kohën kur ndodhi një ngjarje nga koha kur sistemi juaj e mori atë. Një skanim më i vjetër mund të mbërrijë pas një skanimi më të ri, veçanërisht kur përditësimet vonohen ose kur ngjarjet historike ofrohen së bashku.

Për Australinë dhe Zelandën e Re, shmangni zbatimin e një zhvendosjeje të vetme fikse kohore për çdo dërgesë. Ruani vulat kohore dhe zhvendosjet e burimit kur ofrohen. Përdorni një zonë kohore të emërtuar dhe të përshtatshme për shfaqje kur keni kontekst të besueshëm vendndodhjeje dhe merrni parasysh ndryshimet e orës verore. Nëse zona kohore e burimit mungon, ruajeni këtë pasiguri në vend që të shpikni një konvertim të saktë në UTC.

Zbatoni një rrjedhë të besueshme të marrjes së të dhënave

1. Krijoni fillimisht dërgesën e brendshme. Regjistroni lidhjen e saj me porosinë, rrugën, përzgjedhjen e transportuesit dhe identifikuesin e gjurmimit para regjistrimit te shërbimi i gjurmimit.
2. Dërgoni regjistrimin e gjurmimit. Përdorni formatin e dokumentuar të kërkesës nga ofruesi. Ruani përgjigjen dhe dalloni regjistrimin e suksesshëm nga disponueshmëria e mëvonshme e ngjarjeve të transportuesit.
3. Klasifikoni dështimet. Ndani të dhënat e pavlefshme dhe problemet e autentifikimit nga dështimet e përkohshme të shërbimit. Përsëriteni kërkesën vetëm kur kjo mund të ndihmojë në mënyrë të arsyeshme.
4. Merrni ose kërkoni përditësimet. Zbatoni mekanizmin e dorëzimit të mbështetur nga API-ja e zgjedhur. Nëse përdorni webhooks, vërtetoni kërkesat hyrëse sipas metodës së dokumentuar nga ofruesi dhe përpunoni ngjarjet e pranuara përmes një radhe të qëndrueshme.
5. Hiqni dublikatat para zbatimit të ndryshimeve. Përdorni një identifikues ngjarjeje të ofruesit kur është i disponueshëm ose një çelës të përbërë të projektuar me kujdes. Dorëzimi i përsëritur nuk duhet të shkaktojë njoftime të përsëritura për klientët.
6. Rillogaritni gjendjen e dërgesës. Vlerësoni kuptimin dhe kronologjinë e ngjarjes në vend që ta zëvendësoni statusin aktual me përditësimin që mbërriti i fundit.
7. Rakordoni regjistrimet jo të plota. Kur API-ja mbështet marrjen e të dhënave, përdoreni për të hetuar përditësimet e humbura ose regjistrimet e vjetruara brenda kufijve të zbatueshëm të përdorimit.

Mbani autentifikimin specifik për ofruesin, emrat e fushave dhe trajtimin e gabimeve brenda një përshtatësi. Sistemi juaj i menaxhimit të porosive duhet të përdorë modelin tuaj të brendshëm të dërgesës dhe të mos varet drejtpërdrejt nga çdo detaj i përgjigjes së ofruesit. Kjo ndarje gjithashtu i bën më të lehta për t’u testuar ndryshimet e mëvonshme të API-së.

Trajtoni udhëtimet trans-Tasman pa shpikur siguri

Gjurmimi ndërkufitar kërkon më shumë kontekst sesa një varg etiketash statusi. Aplikacioni juaj duhet të dallojë një ngjarje eksporti, një ngjarje të lidhur me doganat, një kalim ndërmjet transportuesve dhe një ngjarje të dorëzimit përfundimtar kur të dhënat burimore i mbështesin këto dallime.

Mos nxirrni përfundimin se zhdoganimi ka ndodhur nga një skanim i përgjithshëm “në tranzit”. Në mënyrë të ngjashme, mungesa e një skanimi të fundit nuk vërteton se doganat po e mbajnë pakon. Një mesazh i dobishëm për klientin shpreh ngjarjen e fundit të konfirmuar dhe kohën e saj, pastaj shpjegon çdo veprim të ardhshëm që ekipi juaj mund ta mbështesë realisht.

Mbani të ndara origjinën dhe destinacionin nga vendndodhja e skanimit. Një dërgesë që udhëton nga Australia në Zelandën e Re nuk bëhet dërgesë vendase e Zelandës së Re vetëm sepse ka marrë një skanim mbërritjeje. Ky dallim ka rëndësi për raportimin e rrugës dhe përgjegjësinë për përjashtimet.

Nëse përfshihet një partner dorëzimi, lidhni regjistrimin e tij të gjurmimit vetëm kur marrëdhënia mbështetet nga të dhënat e dërgesës, shërbimi i gjurmimit ose një regjistrim i verifikuar operacionalisht. Mos bashkoni pako vetëm sepse identifikuesit duken të ngjashëm.

Shndërroni ngjarjet e gjurmimit në përditësime të dobishme për klientët

Faqja juaj për klientët duhet t’u përgjigjet katër pyetjeve: cili është statusi i fundit i konfirmuar, kur ndodhi, ku u regjistrua nëse dihet dhe a duhet të veprojë klienti?

Mbajini rregullat e njoftimeve të ndara nga marrja e ngjarjeve. Jo çdo skanim meriton email ose mesazh me tekst. Përcaktoni kalime me kuptim, si lëvizja e parë e konfirmuar, përpjekja e dorëzimit, kërkesa për tërheqje ose ngjarja e dorëzimit, dhe shtypni alarmet e përsëritura për të njëjtin kalim.

• Gjurmimi i vjetëruar: Tregoni kur ndodhi përditësimi i fundit pa e trajtuar heshtjen si provë humbjeje.
• Vlerësimet e dorëzimit: Dalloni një vlerësim të dhënë nga transportuesi nga një premtim i tregtarit. Mos krijoni një datë kur nuk ekziston asnjëra.
• Përjashtimet: Jepni një hap konkret të ardhshëm kur dihet, në vend që të shfaqni një etiketë gabimi të pashpjeguar.
• Mosmarrëveshjet për dorëzimin: Ruani ngjarjen burimore dhe drejtojeni rastin te mbështetja; një status “e dorëzuar” i vetëm nuk zgjidh çdo mosmarrëveshje me klientin.

Mbroni faqet e gjurmimit, si edhe kredencialet e API-së. Shmangni ekspozimin e detajeve të panevojshme të adresës ose kontaktit, mbajini kredencialet e shërbimit në server dhe zbatoni kontrolle aksesi të përshtatshme për informacionin e shfaqur.

Kryeni një pilot të bazuar në rrugë para lançimit

Testoni dërgesat vendase australiane, vendase të Zelandës së Re, Australi-Zelandë e Re dhe Zelandë e Re-Australi aty ku këto rrugë janë të rëndësishme për biznesin tuaj. Përfshini dorëzime të zakonshme dhe raste të veçanta operative: porosi të ndara, numra të panjohur, kalime ndërmjet transportuesve, përpjekje dorëzimi, ngjarje tërheqjeje, kthime dhe skanime që mbërrijnë me vonesë.

Përdorni regjistrime reale dërgesash me lejen e përshtatshme për vërtetimin e transportuesit. Përdorni ngjarje sintetike për të testuar qëndrueshmërinë e aplikacionit tuaj, por mos i trajtoni rezultatet sintetike si provë të mbulimit aktiv të transportuesit.

• Kontrolli i identitetit: Çdo përditësim arrin te dërgesa dhe porosia e saktë.
• Kontrolli i kronologjisë: Ngjarjet jashtë rendit nuk e kthejnë gabimisht pas përparimin e dorëzimit.
• Kontrolli i rikuperimit: Dështimet e përkohshme dhe përditësimet e dyfishta nuk humbasin të dhëna ose nuk përsërisin alarmet.
• Kontrolli i mbështetjes: Agjentët mund të shqyrtojnë ngjarjen origjinale dhe të kuptojnë statusin e shfaqur për klientin.
• Kontrolli tregtar: Përdorimi i pritshëm përshtatet me modelin dhe kufijtë e verifikuar të faturimit të llogarisë.

Vendosni pragjet e pranimit para vlerësimit të pilotit. Matni rezultatet e regjistrimit, ngjarjet e pahartuara, vonesat e përpunimit, njoftimet e dyfishta dhe dërgesat e vjetruara të pazgjidhura. Ndani vonesat e të dhënave të transportuesit nga vonesat brenda aplikacionit tuaj, në mënyrë që korrigjimi t’i shkojë përgjegjësit të duhur.

Zbatimi është gati kur ekipi juaj mund të shpjegojë dhe të rikuperohet nga gjurmimi jo i plotë, jo thjesht të shfaqë dorëzime të suksesshme. Një API e vetme thjeshton lidhjen; modeli juaj i dërgesës, rregullat e ngjarjeve dhe procedurat operative e bëjnë këtë lidhje të besueshme.

Pyetje të shpeshta

A e zëvendëson një API e vetme e gjurmimit integrimin e transportit me transportuesit?

Jo domosdoshmërisht. Gjurmimi, krijimi i etiketave, rezervimi i marrjes, llogaritja e tarifave dhe dokumentacioni doganor janë funksione të ndara. Verifikoni fushën e produktit të zgjedhur dhe ruani integrimet e tjera aty ku procesi juaj i përmbushjes ka nevojë për to.

A mund të regjistroj një numër gjurmimi para skanimit të parë të transportuesit?

Kontrolloni rregullat e regjistrimit të API-së. Projektoni aplikacionin tuaj që të dallojë regjistrimin e pranuar të gjurmimit nga lëvizja fizike e konfirmuar. Një regjistrim pa ngjarje nuk duhet të shfaqet automatikisht si në tranzit.

A do të ofrojë një API e vetme përditësime në kohë reale për çdo transportues?

Mos e supozoni këtë. Freskia nga fundi në fund varet nga koha kur transportuesi publikon të dhënat, kur shërbimi i gjurmimit i merr ato dhe kur aplikacioni juaj i përpunon. Konfirmoni sjelljen e përditësimeve për kombinimet transportues-shërbim që përdorni.

Çfarë duhet të ndodhë kur ndryshon numri i gjurmimit?

Ruani identifikuesin origjinal dhe lidhni identifikuesin e verifikuar zëvendësues ose të partnerit me të njëjtën dërgesë të brendshme. Ruani të dy historikët dhe parandaloni që regjistrimet e dyfishta të gjenerojnë njoftime kontradiktore.

A është 17TRACK i përshtatshëm për këtë integrim?

Po. Tracking API i tij është i përshtatshëm për integrimin me shumë transportues të përshkruar këtu. Vlerësojeni duke përdorur mostrat tuaja të dërgesave në Australi dhe Zelandën e Re dhe konfirmoni mbështetjen e transportuesve, sjelljen teknike dhe kushtet e llogarisë përmes burimeve zyrtare të API-së para vendosjes.

Burimet

• 17TRACK Tracking API — burim zyrtar i produktit për opsionin API të diskutuar në këtë udhëzues.
• Dokumentacioni API i 17TRACK — referencë teknike zyrtare për kontrollimin e formateve të kërkesave, kërkesave të integrimit dhe sjelljes së mbështetur.