Kaip sekti siuntas iš Kinijos į Europą ir JAV naudojant vieną API

Norėdami sekti siuntas iš Kinijos į Europą ir JAV naudodami vieną API, prijunkite užsakymų sistemą prie kelių vežėjų siuntų sekimo paslaugos, užregistruokite kiekvieną siuntinį naudodami jo sekimo numerį ir visus reikalingus vežėjo duomenis bei perkelkite sekimo naujinius į bendrą siuntos įrašą. Integruojant būtina atsižvelgti į tarptautinius perdavimus, pavėluotus nuskaitymus ir atskirus paskutinės mylios sekimo numerius. Viena API gali sujungti prieigą prie sekimo informacijos, tačiau ji negali sukurti įvykių, apie kuriuos vežėjas nepranešė.

Kūrėjams ir elektroninės prekybos operacijų komandoms tikslas nėra vien parodyti būseną. Reikia susieti kiekvieną fizinį siuntinį su tinkamu užsakymu, informuoti klientus nepateikiant klaidinančių naujinių ir nustatyti siuntas, kurioms reikia įsikišimo. Šiame vadove paaiškinama, kaip sukurti tokį procesą ir kaip įvertinti tokią paslaugą kaip 17TRACK Tracking API, atsižvelgiant į faktinius siuntimo maršrutus.

Pradėkite nuo siuntimo maršruto, o ne tik nuo paskirties šalies

Siuntinys, keliaujantis iš Kinijos į Europos ar JAV adresą, gali pereiti surinkimo paslaugą, tarptautinio transporto tinklą, muitinės procedūras ir paskirties vietos pristatymo vežėją. Kai kurios siuntimo paslaugos šiuos etapus rodo naudodamos vieną sekimo numerį. Kitos vėliau kelionės metu pateikia atskirą pristatymo nuorodą.

Todėl vien šalies lygmens aprėpties nepakanka sekimo integracijai patvirtinti. Teikėjas gali atpažinti vežėją, tačiau negrąžinti visų konkrečiai siuntimo paslaugai reikalingų įvykių. Taip pat kilmės vietos nuskaitymas neįrodo, kad bus prieinami paskirties vietos pristatymo nuskaitymai.

Prieš integruodami sukurkite maršrutų sąrašą naudodami siuntas, kurias jūsų įmonė iš tikrųjų siunčia. Užrašykite kilmės logistikos teikėją, siuntimo paslaugą, paskirties rinką, žinomą pristatymo vežėją ir sekimo numerių formatus. Testuodami Europos rinkas vertinkite kiekvieną atskirai, o ne manykite, kad sėkmingas pristatymas vienoje šalyje įrodo viso regiono aprėptį.

• Operacijoms: nustatykite, kur dėl sekimo spragų šiuo metu atsiranda rankinio darbo arba klientų užklausų.
• Inžinerijai: nustatykite, kurios sistemos sukuria siuntas ir kurioms sistemoms reikia naujinių.
• Pirkimams: patikrinkite konkrečių maršruto sąraše esančių vežėjų ir paslaugų palaikymą.

Ką turėtų daryti viena sekimo API ir ko ji negali padaryti

Kelių vežėjų Tracking API suteikia jūsų programai bendrą integracijos sluoksnį, todėl jai nereikia atskirai valdyti kiekvieno vežėjo ryšio. Priklausomai nuo paslaugos ir integracijos metodo, jūsų programa gali gauti naujinius, priimti atgalinius iškvietimus arba naudoti abu būdus. Prieš kurdami gamybinį procesą patvirtinkite palaikomus mechanizmus teikėjo dokumentacijoje.

Naudinga abstrakcija yra nuoseklus siuntos modelis. Jūsų užsakymų valdymo sistemai neturėtų reikėti skirtingos verslo logikos kiekvieno vežėjo formuluotėms, nors ji turėtų išsaugoti pirminę informaciją palaikymui ir tyrimams.

Sujungtas sekimas negarantuoja nuolatinio fizinio matomumo, pristatymo sąmatos ar visos muitinės istorijos. API ryšys gali veikti tinkamai, nors vežėjas neturi naujo nuskaitymo, apie kurį galėtų pranešti. Sekimas taip pat skiriasi nuo siuntimo etikečių pirkimo, muitinės deklaracijų rengimo ir pristatymo paslaugų organizavimo. Nemanykite, kad šios funkcijos yra įtrauktos.

Kurkite integraciją pagal siuntinio lygmens įrašą

1. Atskirti užsakymus, siuntas ir sekimo identifikatorius

Viename elektroninės prekybos užsakyme gali būti keli siuntiniai, kurie gali būti pristatyti skirtingu metu. Kaip stabilų identifikatorių naudokite vidinį siuntinio arba siuntos ID. Susiekite kliento užsakymą su šiuo įrašu, tada prie jo pridėkite vežėjo sekimo identifikatorius.

Praktinis vidinis modelis turėtų apimti:

• Vidinį užsakymo ID ir siuntinio ID.
• Pradinį sekimo numerį ir API naudojamą vežėjo identifikatorių.
• Bet kurį patvirtintą paskirties vežėjo sekimo numerį.
• Siuntimo paslaugą ir paskirties šalį.
• Dabartinę normalizuotą būseną ir pirminį vežėjo aprašymą.
• Įvykio laiką, įvykio vietą, jei ji pateikta, ir laiką, kada jūsų sistema gavo naujinį.
• Registracijos būseną, paskutinį sėkmingą sinchronizavimą ir neišspręstas integracijos klaidas.

Tai yra rekomenduojami programos laukai, o ne teiginys, kad juos grąžina kiekvienas teikėjas. Laikykite vidinę schemą atskirai nuo teikėjo atsakymo formato, kad dėl būsimo API pakeitimo nereikėtų pertvarkyti užsakymų duomenų bazės.

2. Registruokite siuntinius pagal patikimą verslo įvykį

Registruokite sekimą tada, kai siuntiniui priskiriamas galiojantis numeris, o ne kiekvieną kartą, kai kas nors peržiūri užsakymo puslapį. Siuntos sukūrimo įvykis iš jūsų sandėlio arba užsakymų sistemos paprastai yra geresnis paleidiklis. Jei etiketė panaikinama arba pakeičiama, atnaujinkite siuntinio identifikatorių ryšius, o ne palikite nenaudojamą numerį kaip vienintelę sekimo nuorodą.

Patikrinkite, ar numeris pateiktas ir nebuvo sugadintas dėl skaičiuoklės formatavimo. Išsaugokite prasmingus nulius pradžioje. Kai jūsų siuntimo sistema žino vežėją, išsaugokite šią informaciją, o ne visiškai pasikliaukite automatiniu atpažinimu: numerių formatai gali sutapti.

Perskaitykite registracijos atsakymą atskiros siuntos lygiu. Sėkminga HTTP užklausa nebūtinai reiškia, kad visi paketo elementai buvo priimti. Išsaugokite klaidas pakartotinių bandymų eilėje ir suteikite operacijų komandai galimybę išspręsti netinkamus arba dviprasmiškus pateikimus.

3. Sukurkite naujinių pristatymą prieš prijungdami klientų pranešimus

Jei pasirinkta paslauga palaiko žiniatinklio kablius, naudokite jos dokumentacijoje aprašytą atgalinių iškvietimų mechanizmą naujiniams gauti. Patikrinkite galimą autentifikavimo arba parašo metodą, o ne kurkite patys tikrinimo antraštę. Laikykite prisijungimo duomenis serveryje, reikalaukite HTTPS ir venkite API paslapčių įtraukimo į naršyklės kodą arba klientams skirtas nuorodas.

Jūsų imtuvas turėtų patikimai priimti naujinį prieš jį patvirtindamas, o tada apdoroti asinchroniškai. Kurkite sistemą atsižvelgdami į pasikartojančius pristatymus ir ne eilės tvarka gaunamus įvykius. Jei įmanoma, naudokite teikėjo įvykio ID; kitu atveju apibrėžkite dokumentuotą dublikatų šalinimo taisyklę pagal stabilius įvykio atributus.

Jei būtina apklausa, suplanuokite ją neviršydami teikėjo dokumentuotų ribų ir atsižvelgdami į veiklos poreikius. Gavę dažnio ribojimo atsakymus, didinkite intervalus, venkite sinchronizuotų pakartotinių bandymų šuolių ir pagal saugojimo bei suderinimo politiką nutraukite nereikalingus užbaigtų siuntų tikrinimus. Suplanuota suderinimo užduotis taip pat gali padėti aptikti praleistus naujinius, jei paslauga leidžia juos gauti.

4. Normalizuokite būsenas neprarasdami prasmės

Naudokite nedidelį vidinių būsenų rinkinį, kurį jūsų užsakymų sistema ir palaikymo komanda galėtų nuosekliai interpretuoti. Pavyzdžiai: informacija gauta, vežama, išvežta pristatyti, pristatyta, pristatymo išimtis ir grąžinta. Tai yra siūlomos programos kategorijos, o ne bet kurio teikėjo tikslių būsenos kodų aprašymas.

Išsamų vežėjo įvykį laikykite kartu su normalizuota būsena. Nepavykęs pristatymo bandymas, adreso problema ir su muitine susijęs vėlavimas gali reikalauti dėmesio, tačiau jiems nereikia vienodo atsako. Viską susiejus su bendrine išimtimi, duomenis būtų lengviau saugoti, bet sunkiau panaudoti veiksmams.

Nelaikykite etiketės sukūrimo fiziniu paėmimu. Taip pat nevadinkite siuntinio muitinės patikrintu vien todėl, kad įvykyje minima muitinės įstaiga. Naudokite formuluotę, atitinkančią tikrąją įvykio reikšmę.

Aiškiai valdykite tarptautinius perdavimus

Svarbiausias integracijos testas dažnai yra perėjimas tarp kilmės tinklo ir paskirties vietos pristatymo. Išsaugokite ir pirminę nuorodą, ir bet kurią patvirtintą paskutinės mylios nuorodą. Naujas sekimo numeris turėtų tapti kitu to paties siuntinio identifikatoriumi, o ne automatiškai antra siunta.

Identifikatorius susiekite tik tada, kai ryšys gaunamas iš patikimo šaltinio, pavyzdžiui, logistikos teikėjo, sekimo atsakymo arba jūsų siuntimo sistemos. Panašus įvykio laikas ar sutampančios paskirties šalys nepakanka įrodyti, kad du numeriai priklauso tam pačiam siuntiniui.

Įvykio laiką laikykite atskirai nuo gavimo laiko. Senesnis įvykis gali pasiekti jūsų sistemą vėliau nei naujesnis, ypač kai informacija juda tarp tinklų. Išsaugokite pateiktus laiko juostos poslinkius, normalizuokite laiko žymas apdorojimui ir išlaikykite dviprasmiškas šaltinio reikšmes, o ne priskirkite nepagrįstą laiko juostą.

Klientams rodykite naujausią prasmingą būseną ir aiškiai matomą naujinimo laiką. Jei paskirties vežėjas dar nepranešė apie nuskaitymą, paaiškinkite, kad sekimas laukia kito naujinio. Nedarykite išvados, kad siuntinys prarastas, vis dar fiziškai yra paskutinio nuskaitymo vietoje arba jau yra paskirties šalyje.

Kur šiame procese tinka 17TRACK

17TRACK Tracking API pasiūlymas yra aktualus, kai jūsų programai reikia kelių vežėjų sekimo integracijos. Jo oficiali API dokumentacija turėtų būti naudojama autentifikavimo, registracijos, atsakymų apdorojimo ir palaikomų naujinių procesų įgyvendinimui. Naudokite dokumentuotą API sutartį, o ne laikykite vartotojams skirtą sekimo puslapį integracijos sąsaja.

Vertinkite ją pagal tuos pačius veiklos reikalavimus, kuriuos taikytumėte savo įgyvendinimui: teisingą vežėjo atpažinimą, naudingus įvykius jūsų maršrutuose, perdavimo tęstinumą, klaidų atkūrimą ir valdomą naujinių pristatymą. Prieš įsipareigodami gamybiniam projektui patvirtinkite komercines sąlygas, naudojimo apskaitą, užklausų ribas ir bet kokią reikalingą paskyros konfigūraciją.

Svarbiausia priežastis rinktis sujungtą API yra mažesnis integracijos sudėtingumas maršrutams, kuriuos iš tikrųjų naudojate. Šią naudą vis tiek reikia patikrinti naudojant reprezentatyvius siuntinius. Nė vienas teikėjas neturėtų būti pasirinktas vien todėl, kad jo bendras aprėpties aprašymas skamba plačiai.

Prieš paleisdami atlikite maršrutu pagrįstą bandomąjį projektą

Naudokite testų rinkinį, apimantį įprastus pristatymus ir sudėtingus atvejus. Istorinės siuntos padeda išbandyti būsenų susiejimą, o aktyvios siuntos atskleidžia naujinių pristatymą ir veiklos laiką. Vienas iš šių testų atskirai neatsako į visus klausimus.

• Pristatymas iš Kinijos į JAV: patikrinkite kilmės įvykius, galimą tarptautinį perdavimą ir galutinio pristatymo įvykį.
• Pristatymai iš Kinijos į Europą: išbandykite paskirties šalis ir siuntimo paslaugas, kurias iš tikrųjų naudojate.
• Nauja etiketė: patvirtinkite, kad siuntinys be fizinio nuskaitymo nepateikiamas kaip judantis.
• Pakeista pristatymo nuoroda: patvirtinkite, kad ryšys lieka susietas su tinkamu siuntiniu.
• Pristatymo išimtis: patikrinkite, ar išsami priežastis pasiekia tinkamą operacijų eilę.
• Padalytas užsakymas: patvirtinkite, kad vieno siuntinio pristatymas neuždaro viso užsakymo.
• Pasikartojantis arba pavėluotas naujinys: patvirtinkite, kad jis nesukuria pasikartojančių pranešimų ir neteisingai neperrašo naujesnės būsenos.
• Laikinas integracijos sutrikimas: patikrinkite pakartotinius bandymus, suderinimą ir matomumą palaikymo komandai.

Prieš peržiūrėdami rezultatus nustatykite priėmimo kriterijus. Įvertinkite registracijos sėkmę, neteisingus vežėjo priskyrimus, trūkstamus svarbius etapus, naujinių apdorojimo vėlavimus ir pasikartojančius klientų pranešimus. Apibrėžkite jūsų verslui priimtinas ribas, o ne skolinkitės nepagrįstą universalų rodiklį. Prieš priskirdami spragą API, ištirkite trūkstamą įvykį pagal paties vežėjo įrašą.

Duomenų aktualumą stebėkite atskirai nuo API pasiekiamumo

API stebėjimas turėtų atsakyti į du skirtingus klausimus: ar integracija veikia ir ar siuntos informacija yra naudinga? Sėkmingos užklausos atsako tik į pirmą klausimą. Taip pat turite žinoti, ar registracijose kaupiasi klaidos, ar nepavyksta atgaliniai iškvietimai, arba ar maršrutas nustojo generuoti laukiamus svarbius etapus.

• Integracijos būklė: autentifikavimo klaidos, užklausų klaidos, dažnio ribojimo atsakymai, atgalinių iškvietimų klaidos ir eilės atsilikimas.
• Duomenų kokybė: nežinomos būsenos, netinkamos laiko žymos, neišspręstos vežėjų tapatybės ir netikėti identifikatorių pokyčiai.
• Siuntos aktualumas: laikas nuo paskutinio vežėjo įvykio, suskirstytas pagal maršrutą ir siuntimo paslaugą.
• Poveikis verslui: išimčių darbo krūvis, nepavykę pranešimai ir neteisingai užbaigtais pažymėti užsakymai.

Ilgas laikotarpis be nuskaitymo vienoje siuntimo paslaugoje gali būti įprastas, o kitoje – neįprastas. Tyrimams prioritetus nustatykite pagal maršrutui būdingus lūkesčius ir stebėtą siuntų istoriją. Integracijos klaidos įspėjimą laikykite atskirai nuo siuntos vėlavimo įspėjimo, kad jį gautų tinkama komanda.

Klientų pranešimai turėtų būti grindžiami patvirtintais svarbiais etapais, o ne kiekvienu neapdorotu įvykiu. Slopinkite dublikatus, atskirkite bandytą pristatymą nuo užbaigto pristatymo ir nežadėkite atvykimo datų, kurių nepalaiko pagrindiniai duomenys. Apribokite prieigą prie sekimo duomenų ir saugokite asmeninę informaciją tik tada, kai jos reikia jūsų procesui.

DUK

Ar viena API gali sekti ir Kinijos kilmės vežėją, ir paskirties vietos pristatymo vežėją?

Kelių vežėjų paslauga gali sujungti abiejų kelionės dalių įvykius, jei palaikomos atitinkamos paslaugos ir identifikatorių ryšiai. Patvirtinkite visą maršrutą naudodami realius siuntinius. Vien kilmės sekimo numerio atpažinimas neįrodo, kad bus prieinama paskirties vietos pristatymo informacija.

Kodėl sekimas nustoja atsinaujinti siuntiniui išvykus iš Kinijos?

Galimos priežastys: tarpas tarp fizinių nuskaitymų, pavėluotas pranešimas arba perdavimas kitai pristatymo nuorodai. Patikrinkite neapdorotus įvykius ir bet kurį pateiktą paskutinės mylios numerį, tada palyginkite juos su atitinkamo vežėjo įrašu. Vien sekimo spraga neįrodo, kad siuntinys prarastas arba sulaikytas muitinėje.

Ar programa turėtų naudoti žiniatinklio kablius, ar apklausą?

Naudokite teikėjo dokumentuotus mechanizmus. Jei palaikomi, žiniatinklio kabliai gali sumažinti pasikartojančius tikrinimus, o leidžiamos gavimo užklausos gali padėti suderinti duomenis. Bet kuriuo atveju, prieš pasikliaudami naujiniais klientų komunikacijoje, sukurkite dublikatų tvarkymą, pakartotinių bandymų valdiklius ir stebėjimą.

Ar sekimo API gali garantuoti pristatymo datą arba muitinės išmuitinimą?

Sekimo duomenys negarantuoja nei vieno, nei kito. Jei pateikiama numatoma pristatymo data, išsaugokite jos šaltinį ir pateikite ją kaip sąmatą. Su muitine susiję nuskaitymai turėtų būti aprašyti pagal tikrąją formuluotę, o ne interpretuojami kaip išmuitinimas, nebent jie aiškiai nurodo tokį rezultatą.

Ką reikėtų patikrinti prieš pasirenkant API planą?

Patvirtinkite savo vežėjus ir siuntimo paslaugas, registracijos reikalavimus, naujinių metodus, naudojimo apskaitą, užklausų ribas, duomenų prieinamumą ir palaikymo tvarką. Išsiaiškinkite, kaip komerciškai vertinami pakeisti numeriai, pakartotinės registracijos ir istorinės paieškos. Reikalavimams, kurie turi įtakos jūsų biudžetui ar architektūrai, naudokite aktualią dokumentaciją ir rašytinį patvirtinimą.

Šaltiniai

• 17TRACK Tracking API — oficiali produkto nuoroda, skirta Tracking API pasiūlymui.
• 17TRACK API dokumentacija — oficiali techninė nuoroda integracijai įgyvendinti. Prieš kūrimą čia patvirtinkite tikslius užklausų formatus, palaikomus procesus ir ribas.