Kaip pasirinkti tarpvalstybinių siuntų į Kanadą sekimo API

Pasirinkite siuntų į Kanadą tarpvalstybinio sekimo API išbandydami tikruosius siuntimo maršrutus, vežėjų perėmimus, su muitine susijusius įvykius ir pristatymo išimtis, o ne tik vertindami tiekėjo nurodomą vežėjų skaičių. Elektroninės prekybos operacijų komandoms ir kūrėjams tinkamiausia yra API, kuri išsaugo siuntos tapatybę kertant sieną, pateikia panaudojamus sekimo įvykius ir tiekia atnaujinimus, kuriuos jūsų sistemos gali patikimai apdoroti.

Sėkmingas pasirinkimas turėtų užtikrinti du rezultatus: klientai gauna tikslią informaciją apie siuntą, o operacijų komandos gali nustatyti siuntas, kurioms reikia įsikišimo. Nei vienas iš šių rezultatų automatiškai neatsiranda dėl ilgo palaikomų vežėjų sąrašo. Praktinis testas – ar API veikia su jūsų perkamomis paslaugomis, gaunamais siuntų identifikatoriais ir sprendimais, kuriuos turi priimti jūsų komanda.

Pradėkite nuo savo siuntimo maršrutų, o ne funkcijų sąrašo

Siuntimo maršrutas yra konkretesnis nei kilmės ir paskirties šalys. Vertinant API, jis turėtų apimti siuntimo paslaugą, tarptautinį gabenimą tvarkančią organizaciją ir už pristatymą Kanadoje atsakingą vežėją. Skirtingos paslaugos tame pačiame maršrute gali generuoti skirtingas sekimo istorijas.

Prieš kreipdamiesi į tiekėjus, sudarykite maršrutų sąrašą. Naudokite savo įmonės siuntų duomenis, užuot darę prielaidą, kad bendra tiekėjo tarptautinė aprėptis atitinka jūsų veiklą.

• Kilmė ir paskirtis: Užregistruokite kilmės šalį ir Kanados provincijas ar teritorijas, į kurias pristatote.
• Įsigyta paslauga: Nurodykite tikrąjį paslaugos pavadinimą, o ne tik vežėjo prekės ženklą.
• Siuntos identifikatoriai: Išvardykite pradinį sekimo numerį, paskirties vietos sekimo numerį, jei toks yra, ir vidinį užsakymo ar siuntos ID.
• Perėmimo modelis: Nustatykite, ar pristatymą perima kitas vežėjas ir kaip jūsų sistemos sužino apie šį perdavimą.
• Veiklos išimtys: Įtraukite su muitine susijusius vėlavimus, nesėkmingus pristatymo bandymus, atsiėmimo reikalavimus ir grąžinimus.
• Verslo prioritetas: Atskirai vertinkite didelės apimties maršrutus ir mažesnės apimties maršrutus, dėl kurių kyla neįprastai brangiai kainuojančių klientų aptarnavimo atvejų.

Šis sąrašas nulemia, ką reikia testuoti. Jei dauguma jūsų siuntų prieš patekdamos į Kanados pristatymo tinklą pereina per konsolidatorių, perdavimo tęstinumas turėtų būti svarbesnis už funkcijas, skirtas paprastai vieno vežėjo siuntai.

Vertinkite aprėptį paslaugos ir įvykio lygmeniu

Paprašykite tiekėjų patvirtinti kiekvieno jūsų sąraše esančio vežėjo ir paslaugos derinio palaikymą. Vežėjo pavadinimas integracijų sąraše yra tik pradžia, o ne įrodymas, kad per API pasiekiama kiekviena paslauga, įvykio rūšis ar paskirties vietos identifikatorius.

Paprašykite demonstracijos, kurioje būtų naudojamos jūsų įgaliotos pavyzdinės siuntos. Palyginkite API išvestį su atitinkamais vežėjo sekimo puslapiais. Vertinkite, ar jūsų darbo eigai reikalingi įvykiai yra pateikiami ir suprantami, o ne tikėkitės, kad visi šaltiniai naudos identišką formuluotę.

Vertinimo sritis	Ką tikrinti	Kodėl tai svarbu
Vežėjo identifikavimas	Kaip nustatomi dviprasmiški sekimo numeriai ir ar galima nurodyti vežėją	Tikėtinas, bet neteisingas vežėjo atitikmuo gali pateikti klaidinančius rezultatus
Tarpvalstybinis perdavimas	Ar pradiniai ir paskirties vietos identifikatoriai išlieka susieti	Jūsų užsakymo įrašas turi išlikti pasikeitus pristatymo vežėjui
Įvykio išsamumas	Originalūs pranešimai, normalizuotos būsenos, vietos ir laiko žymos, jei jos pateikiamos	Klientų pranešimams ir aptarnavimo tyrimams reikia skirtingo išsamumo lygio
Pristatymo išimtys	Atsiėmimas, bandytas pristatymas, adreso problemos ir grąžinimo įvykiai	Dėl šių įvykių gali reikėti veiksmų, o ne vien pasyvaus sekimo
Duomenų spragos	Elgsena, kai siunta neturi naujų nuskaitymų arba dar negali būti identifikuota	Trūkstami duomenys neturėtų tapti klaidingu pristatymo ar muitinės teiginiu

Daugelio vežėjų trumpajame sąraše tinkama vertinti 17TRACK sekimo API. Naudokite oficialią API dokumentaciją įgyvendinimo klausimams suformuluoti, tada patikrinkite konkrečius Kanados maršrutus atlikdami koncepcijos patikrą. Nepakeiskite konkrečių paslaugų, įvykių laukų, komercinių sąlygų ar atnaujinimų elgsenos patvirtinimo bendru produkto aprašymu.

Laikykite muitinės matomumą atskirai nuo muitinės institucijos

Sekimo API turėtų padėti jūsų komandai interpretuoti nurodomą siuntos eigą. Ji neturėtų būti laikoma autoritetinga muitinės sprendimų sistema. Vežėjo pateiktas muitinės pranešimas gali suteikti naudingą kontekstą, tačiau nepaaiškinti visos vėlavimo priežasties, nenurodyti, kas turi imtis veiksmų, ar nustatyti, kada įforminimas bus baigtas.

Pašto importui į Kanadą Kanados pasienio tarnybos agentūros pašto importo gairės pateikia oficialų kontekstą. Pašto gaires laikykite atskirai nuo kurjeriams taikomų procesų ir aiškindami importo reikalavimus naudokite tinkamas oficialias gaires. Vien pagal sekimo būseną nedarykite išvadų apie mokesčius, rinkliavas, lengvatas ar išleidimo sprendimus.

Vertindami patikrinkite, kaip API tvarko tokius pranešimus kaip muitinės procedūros, įforminimas baigtas ar reikalinga informacija, kai jie rodomi jūsų siuntų pavyzdžiuose. Paklauskite, ar originalus vežėjo tekstas išlieka pasiekiamas kartu su supaprastinta būsena.

Naudingas veiklos modelis atskiria tris dalykus:

• Stebėtas įvykis: Ką iš tikrųjų pranešė šaltinis.
• Paaiškinimas klientui: Paprastos kalbos interpretacija, nepridedanti nepagrįsto tikrumo.
• Kitas veiksmas: Patikrinta instrukcija arba vidinė tyrimo užduotis.

Pavyzdžiui, vien įvykis, nurodantis muitinės procedūras, savaime nepateisina pranešimo klientui, kad jis turi sumokėti mokestį. Mokėjimo instrukcija turi būti pagrįsta autoritetingu šaltiniu ir turėti patikrintą paskirties vietą. Taip pat nuskaitymų spraga nėra įrodymas, kad muitinė sulaikė siuntą.

Prieš kurdami pranešimus išnagrinėkite įvykių modelį

Būsenų normalizavimas palengvina skirtingų vežėjų pranešimų naudojimą, tačiau pernelyg didelis supaprastinimas gali pašalinti informaciją, kurios reikia jūsų komandai. Plati išimties būsena gali apimti adreso problemą, nesėkmingą pristatymo bandymą ar grąžinimą. Tokios situacijos neturėtų sukelti to paties pranešimo klientui.

Paprašykite pavyzdinių duomenų paketų, apimančių įprastą pristatymą ir išimtis. Patikrinkite, ar jūsų integracija gali išsaugoti šaltinio įvykį, normalizuotą būseną, įvykio laiką ir laiką, kada jūsų sistema gavo atnaujinimą. Jei vietos ar laiko juostos informacijos nėra, jūsų programa turėtų išsaugoti šį neapibrėžtumą, o ne sukurti tariamą tikslumą.

Išbandykite siuntos tapatybę ir chronologiją

Naudokite stabilų vidinį siuntos ID, kad susietumėte sekimo įrašus su užsakymais. Nepaverskite vežėjo sekimo numerio vieninteliu verslo identifikatoriumi: užsakyme gali būti kelios siuntos, o siunta kelionės metu gali gauti kitą identifikatorių.

Taip pat išbandykite vėluojančius įvykius. Senesnis nuskaitymas, gautas po naujesnio, neturėtų automatiškai grąžinti klientui rodomos siuntos būsenos atgal. Išsaugokite įvykių istoriją, tačiau nustatykite aiškias dabartinės būsenos taisykles. Grąžinimams skirkite ypatingą dėmesį, nes judėjimas po pristatymo gali reikšti naują veiklos etapą, o ne klaidą.

Pristatymo įverčius vertinkite kaip atskirą funkciją

Jei numatomos pristatymo datos svarbios jūsų verslui, paklauskite, iš kur jos gaunamos. Vežėjo pateiktas įvertis ir tiekėjo sugeneruota prognozė yra skirtingi duomenų produktai. Patvirtinkite, kaip atsakyme pateikiami trūkstami įverčiai, pakeistos datos ir laiko juostų ribos.

Nemanykite, kad API teikia prognozuojamas pristatymo datas vien todėl, kad palaiko sekimą. Jei konkrečiai paslaugai įvertis nepasiekiamas arba nepatikimas, naujausio patikrinto įvykio rodymas gali būti naudingesnis nei nepagrįsto pažado pateikimas.

Vertinkite atnaujinimų teikimą ir API stebėseną kartu

Žiniatinklio kabliukai gali sumažinti pasikartojančių būsenos užklausų poreikį, tačiau jiems vis tiek reikalinga veiklos kontrolė. Jei tiekėjas siūlo žiniatinklio kabliukus, patikrinkite autentifikavimo ar parašų parinktis, pakartotinių bandymų elgseną, patvirtinimo reikalavimus ir bet kokį praleistų atnaujinimų atkūrimo būdą. Jei jūsų darbo eiga naudoja apklausą, patvirtinkite užklausų limitus ir kaip planuosite užklausas jų neviršydami.

Sukurkite imtuvą, galintį toleruoti pasikartojančius pristatymus. Patikimai išsaugokite gaunamus atnaujinimus, užtikrinkite, kad apdorojimas būtų idempotentiškas, ir atskirkite gavimą nuo tolesnių veiksmų, pavyzdžiui, el. laiško siuntimo. Tai yra integracijos apsaugos priemonės, o ne prielaidos apie konkretaus tiekėjo elgseną.

Stebėkite ne tik sėkmingus HTTP atsakymus. Veikiantis galinis punktas vis tiek gali pateikti pasenusius arba neteisingai susietus duomenis.

• Registracijos būklė: Sekite priimtas, atmestas ir neišspręstas siuntų registracijas.
• Pristatymo būklė: Stebėkite žiniatinklio kabliukų klaidas, apdorojimo eiles ir atkūrimo bandymus.
• Duomenų naujumas: Atskirti paskutinio siuntos įvykio senumą nuo laiko, praėjusio nuo paskutinio jūsų sistemos gauto atnaujinimo.
• Susiejimo kokybė: Pažymėkite nežinomas būsenas ir netikėtus perėjimus peržiūrai.
• Poveikis verslui: Matuokite siuntas, kurioms reikia rankinio tyrimo, ir neteisingai išsiųstus klientų pranešimus.

Nustatykite įspėjimus pagal paslaugą ir veiklos kontekstą. Tylus laikotarpis, įprastas vienai tarptautinei paslaugai, kitai gali būti priežastis atlikti tyrimą. Ribas nustatykite pagal savo siuntų istoriją ir paslaugų lūkesčius, o ne taikydami universalią vėlavimo taisyklę.

Atlikite koncepcijos patikrą, galinčią atskleisti gedimus

Demonstracija, pagrįsta vien pristatytomis siuntomis, neatskleis pakankamai informacijos. Naudokite užbaigtas siuntas įvykių istorijai tikrinti, o aktyvias siuntas – atnaujinimams stebėti jiems gaunant. Įtraukite įprastas siuntas ir sudėtingus atvejus, turėdami tinkamus leidimus bet kokiems bendrinamiems siuntų duomenims.

1. Pirmiausia apibrėžkite priėmimo kriterijus. Nurodykite reikiamas paslaugas, svarbius įvykius, tapatybės tvarkymą ir veiklos atkūrimo procedūras.
2. Pasirinkite reprezentatyvius atvejus. Įtraukite vežėjų perėmimus, trūkstamus ankstyvuosius nuskaitymus, pristatymo bandymus, atsiėmimo įvykius ir grąžinimus, jei jie aktualūs jūsų verslui.
3. Palyginkite su šaltinio sekimu. Užregistruokite trūkstamus ar skirtingai interpretuojamus įvykius, atskirdami šaltinio duomenų ribotumus nuo integracijos problemų.
4. Išbandykite gedimų scenarijus. Išbandykite pasikartojančias registracijas, negaliojančius identifikatorius, nutrūkusį žiniatinklio kabliuko gavimą ir laikinus tolesnių sistemų gedimus.
5. Peržiūrėkite pranešimų išvestį. Leiskite aptarnavimo darbuotojams patikrinti, ar pranešimai tiksliai atspindi siuntos įrodymus ir siūlo tinkamus tolesnius veiksmus.
6. Dokumentuokite neišspręstus klausimus. Gaukite rašytinį paaiškinimą dėl reikalavimų, kurių testas negali nustatyti.

Atnaujinimų delsą matuokite atidžiai. Įvykio laikas, laikas, kada įvykis tampa matomas vežėjui, tiekėjo apdorojimo laikas ir jūsų gavimo laikas nėra tapatūs. Jei negalite stebėti tam tikro etapo, atitinkamai pažymėkite matavimą, o ne priskirkite visą delsą API.

Atmeskite kandidatą, kuris neatitinka kritinio maršruto reikalavimų arba generuoja nesaugius pranešimus klientams, net jei jo vidutiniai rezultatai atrodo geri. Kita vertus, trūkstamas šaltinio nuskaitymas neturėtų automatiškai būti laikomas API gedimu. Testas turėtų nustatyti, ką tiekėjas gali patikimai pateikti ir ką jūsų veikla turi tvarkyti atskirai.

Lyginkite veiklos sąnaudas, o ne tik prenumeratos kainą

Paprašykite kiekvieno į trumpąjį sąrašą įtraukto tiekėjo įvertinti tą patį darbo krūvį. Įtraukite numatomas siuntų registracijas, sezoninius pikus, atnaujinimų gavimą, saugomą istoriją ir atskiras aplinkas ar paskyras, kurių reikia jūsų komandai. Patvirtinkite, kuri veikla apmokestinama, užuot darę prielaidą, kad visi tiekėjai naudojimą skaičiuoja vienodai.

Išsiaiškinkite viršijimo tvarką, pasikartojančias registracijas, nesėkmingus sekimo bandymus, aptarnavimo sąlygas ir atšaukimo ar duomenų eksportavimo procedūras. Paprašykite rašytinių sąlygų dėl bet kokio paslaugų įsipareigojimo, nuo kurio priklauso jūsų verslas.

Saugumo peržiūra turėtų apimti kredencialų valdymą, prieigos kontrolę, žiniatinklio kabliukų apsaugą, duomenų saugojimą, trynimą ir faktiškai reikalingus siuntos laukus. Nesiųskite klientų informacijos vien todėl, kad yra pasirenkamas laukas. Tegul atitinkami teisės ir saugumo atsakingi asmenys peržiūri jūsų verslui aktualius įsipareigojimus.

Galutinis sprendimas turėtų apimti patikrintą tinkamumą maršrutams, įvykių kokybę, atkuriamumą, inžinerines pastangas ir komercines sąlygas. Tiesioginė integracija su vežėju gali būti tinkama, kai jūsų veikla naudoja siaurą, stabilią paslaugų aibę. Kelių vežėjų sekimo API tampa patrauklesnė, kai kelių integracijų priežiūra ir jų įvykių derinimas sukuria daug darbo. Bet kuriuo atveju rinkitės pagal įrodytą veiklos tinkamumą, o ne pagal didžiausią antraštėje nurodomą aprėpties skaičių.

DUK

Ar man reikia atskiros sekimo API kiekvienam Kanados pristatymo vežėjui?

Nebūtinai. Kelių vežėjų API gali suteikti vieną integraciją keliems aktualiems vežėjams. Vis dėlto patvirtinkite konkrečių paslaugų ir perėmimų palaikymą. Vieno vežėjo veikla gali rasti tiesioginę integraciją pakankamą, o mišrus tinklas turėtų patikrinti, ar bendras įvykių modelis iš tikrųjų sumažina priežiūros poreikį.

Ar sekimo API gali tiksliai paaiškinti, kodėl siunta vėluoja muitinėje?

Tik tiek, kiek šaltinio duomenys pateikia tokį paaiškinimą. Bendras muitinės procedūrų įvykis gali nenustatyti priežasties, reikalingo veiksmo ar išleidimo datos. Išsaugokite originalų pranešimą ir neišspręstus klausimus nukreipkite atitinkamam vežėjui, tarpininkui ar oficialiam kanalui.

Kas turėtų įvykti, kai siunta Kanadoje gauna naują sekimo numerį?

Jūsų sistema turėtų susieti abu identifikatorius su tuo pačiu vidiniu siuntos įrašu. Paprašykite tiekėjo parodyti, kaip paskirties vietos identifikatoriai pateikiami ir susiejami. Jei konkrečiai paslaugai automatinis susiejimas nepasiekiamas, prieš įjungdami automatinius pranešimus nustatykite kitą patikrintą susiejimo šaltinį.

Kaip pasirinkti tarp žiniatinklio kabliukų ir apklausos?

Rinkitės pagal tiekėjo palaikomus metodus ir atkūrimo reikalavimus. Žiniatinklio kabliukai gali palaikyti įvykiais grindžiamą apdorojimą, o apklausa gali būti naudojama suplanuotiems patikrinimams ar derinimui, jei tai leidžiama. Vertinkite patikimumą, limitus, autentifikavimą ir atkūrimą, o ne manykite, kad kuris nors metodas garantuoja naujesnius siuntų duomenis.

Koks yra svarbiausias priėmimo kriterijus?

Patikimas jūsų kritinių maršrutų ir išimčių tvarkymas. Prieš pasirašydami įsitikinkite, kad siuntos tapatybė išlieka perėmimų metu, klientų pranešimai išlieka ištikimi šaltinio įvykiams, o jūsų komanda gali aptikti ir atkurti trūkstamus atnaujinimus. Pasirenkamos funkcijos neturėtų kompensuoti šių reikalavimų nevykdymo.

Šaltiniai

• 17TRACK: sekimo API — oficiali produkto nuoroda API pagrįstai sekimo integracijai vertinti.
• 17TRACK: API dokumentacija — techninė nuoroda integracijos reikalavimams palyginti su siūlomu įgyvendinimu.
• Kanados pasienio tarnybos agentūra: importas paštu — oficialus kontekstas pašto importui į Kanadą; nepakeičia kurjeriams skirtų gairių ar su konkrečia siunta susijusių patarimų.