Kako slediti pošiljkam iz Kitajske v Evropo in ZDA z enim API-jem

Za sledenje pošiljkam iz Kitajske v Evropo in ZDA z enim API-jem povežite svoj sistem naročil s storitvijo za sledenje več prevoznikov, registrirajte vsak paket z njegovo sledilno številko in vsemi zahtevanimi podatki o prevozniku ter posodobitve sledenja vključite v skupni zapis pošiljke. Integracija mora upoštevati mednarodne predaje, zapoznele skene in ločene sledilne številke za dostavo na zadnji milji. En API lahko združi dostop do informacij o sledenju, vendar ne more ustvariti dogodkov, o katerih prevoznik ni poročal.

Za razvijalce in ekipe za e-trgovinske operacije cilj ni le prikazati statusa. Vsak fizični paket je treba povezati s pravim naročilom, stranke obveščati, ne da bi jim pošiljali zavajajoče posodobitve, ter prepoznati pošiljke, ki potrebujejo posredovanje. Ta vodnik pojasnjuje, kako zgraditi takšen potek dela in kako oceniti storitev, kot je 17TRACK Tracking API, glede na vaše dejanske pošiljateljske poti.

Začnite s pošiljateljsko potjo, ne le z državo destinacije

Paket, ki potuje iz Kitajske na evropski ali ameriški naslov, lahko potuje prek zbirne službe, mednarodnega transportnega omrežja, carinske obdelave in dostavnega prevoznika v ciljni državi. Nekatere pošiljateljske storitve ta gibanja prikažejo z eno sledilno številko. Druge pozneje med potjo zagotovijo ločeno referenco za dostavo.

Zato pokritost na ravni države ni dovolj za preverjanje integracije sledenja. Ponudnik lahko prepozna prevoznika, ne da bi vrnil vsak dogodek, ki ga potrebujete za določen pošiljateljski izdelek. Prav tako izvorni sken ne potrjuje, da bodo na voljo tudi skeni dostave na cilju.

Pred integracijo ustvarite popis poti na podlagi pošiljk, ki jih vaše podjetje dejansko pošilja. Zabeležite izvornega ponudnika logistike, pošiljateljsko storitev, ciljni trg, znanega dostavnega prevoznika in oblike sledilnih številk. Evropske trge med testiranjem obravnavajte posamično, namesto da bi domnevali, da uspešna dostava v eni državi dokazuje pokritost celotne regije.

• Za operacije: ugotovite, kje vrzeli v sledenju trenutno povzročajo ročno delo ali stike s strankami.
• Za inženiring: ugotovite, kateri sistemi ustvarjajo pošiljke in kateri sistemi potrebujejo posodobitve.
• Za nabavo: preverite podporo za konkretne prevoznike in storitve v tem popisu poti.

Kaj mora en API za sledenje omogočati — in česa ne more

API za sledenje več prevoznikov vaši aplikaciji zagotovi skupni integracijski sloj, namesto da bi morala ločeno obravnavati povezavo z vsakim prevoznikom. Glede na storitev in način integracije lahko vaša aplikacija pridobiva posodobitve, prejema povratne klice ali uporablja kombinacijo obojega. Pred načrtovanjem produkcijskega poteka dela v dokumentaciji ponudnika preverite podprte mehanizme.

Uporabna abstrakcija je dosleden model pošiljke. Vaš sistem za upravljanje naročil ne bi smel potrebovati drugačne poslovne logike za vsako besedilo prevoznika, vendar mora ohraniti izvirne informacije za podporo in preiskovanje.

Združeno sledenje ne zagotavlja neprekinjene fizične vidljivosti, ocene dostave ali popolne carinske zgodovine. Povezava API je lahko brezhibna, medtem ko prevoznik nima novega skena, o katerem bi poročal. Sledenje je ločeno tudi od nakupa nalepk za pošiljanje, priprave carinskih deklaracij in organizacije dostavnih storitev. Ne domnevajte, da so te funkcije vključene.

Integracijo zgradite okoli zapisa na ravni paketa

1. Ločite naročila, pošiljke in identifikatorje sledenja

Eno naročilo v e-trgovini lahko vsebuje več paketov, ti pa lahko prispejo ob različnih časih. Kot stabilni identifikator uporabite interni ID paketa ali pošiljke. Naročilo stranke povežite s tem zapisom, nato pa mu pripnite identifikatorje sledenja prevoznika.

Praktični interni model mora vključevati:

• Interni ID naročila in ID paketa.
• Izvirno sledilno številko in identifikator prevoznika, ki ga uporablja API.
• Vsako potrjeno sledilno številko prevoznika v ciljni državi.
• Pošiljateljsko storitev in ciljno državo.
• Trenutni normalizirani status in izvirni opis prevoznika.
• Čas dogodka, lokacijo dogodka, kadar je navedena, in čas, ko je vaš sistem prejel posodobitev.
• Stanje registracije, zadnjo uspešno sinhronizacijo in nerešene napake integracije.

To so priporočena polja aplikacije in ne trditev, da jih vrne vsak ponudnik. Notranjo shemo ločite od oblike odgovora ponudnika, da prihodnja sprememba API-ja ne bo zahtevala preoblikovanja podatkovne zbirke naročil.

2. Pakete registrirajte na podlagi zanesljivega poslovnega dogodka

Sledenje registrirajte, ko je paketu dodeljena veljavna številka, ne vsakič, ko nekdo odpre stran naročila. Dogodek ustvarjanja pošiljke iz vašega skladišča ali sistema naročil je običajno boljši sprožilec. Če je nalepka razveljavljena ali zamenjana, posodobite povezave med identifikatorji paketa, namesto da opuščeno številko pustite kot njegovo edino referenco za sledenje.

Preverite, ali je številka prisotna in ali je oblikovanje preglednice ni poškodovalo. Ohranite pomembne začetne ničle. Ko vaš pošiljateljski sistem pozna prevoznika, te informacije ohranite, namesto da bi se v celoti zanašali na samodejno prepoznavanje: oblike številk se lahko prekrivajo.

Odgovor registracije preberite na ravni posamezne pošiljke. Uspešna zahteva HTTP ne pomeni nujno, da je bil vsak element v paketu sprejet. Neuspehe shranite v čakalno vrsto za ponovne poskuse in operacijam omogočite razreševanje neveljavnih ali dvoumnih oddaj.

3. Dostavo posodobitev načrtujte, preden povežete obvestila strankam

Če izbrana storitev podpira spletne kavlje, za prejemanje posodobitev uporabite njen dokumentirani mehanizem povratnih klicev. Preverite razpoložljivi način preverjanja pristnosti ali podpisovanja, namesto da bi si izmislili glavo za preverjanje. Poverilnice hranite na strežniku, zahtevajte HTTPS in se izogibajte vključevanju skrivnosti API-ja v kodo brskalnika ali povezave, namenjene strankam.

Prejemnik mora posodobitev trajno sprejeti, preden jo potrdi, nato pa jo obdelati asinhrono. Načrtujte podvojene dostave in dogodke, ki prispejo v napačnem vrstnem redu. Kjer je na voljo, uporabite ID dogodka ponudnika; sicer določite dokumentirano pravilo za odstranjevanje dvojnikov na podlagi stabilnih atributov dogodka.

Če je potrebno periodično preverjanje, ga načrtujte v okviru dokumentiranih omejitev ponudnika in svojih operativnih potreb. Po odgovorih o omejitvi hitrosti upočasnite zahteve, izogibajte se usklajenim skokom ponovnih poskusov in prenehajte z nepotrebnimi preverjanji dokončanih pošiljk v skladu s svojo politiko hrambe in usklajevanja. Načrtovano opravilo za usklajevanje lahko pomaga odkriti tudi zgrešene posodobitve, kadar storitev omogoča njihovo pridobivanje.

4. Statuse normalizirajte, ne da bi izgubili pomen

Uporabite majhen nabor notranjih statusov, ki jih lahko vaš sistem naročil in podporna ekipa dosledno razlagata. Primeri vključujejo prejete informacije, v tranzitu, poslano v dostavo, dostavljeno, izjemo pri dostavi in vrnjeno. To so predlagane kategorije aplikacije, ne opis natančnih statusnih kod katerega koli ponudnika.

Podroben dogodek prevoznika ohranite poleg normaliziranega statusa. Neuspešen poskus dostave, težava z naslovom in zamuda, povezana s carino, lahko vsi zahtevajo pozornost, vendar ne zahtevajo enakega odziva. Preslikava vsega v splošno izjemo bi podatke olajšala za shranjevanje, vendar zmanjšala njihovo uporabnost pri ukrepanju.

Ustvarjanja nalepke ne prevedite v fizični prevzem. Prav tako paketa ne označite kot carinsko sproščenega zgolj zato, ker dogodek omenja carinski objekt. Uporabite jezik, ki ustreza dejanskemu pomenu dogodka.

Mednarodne predaje obravnavajte izrecno

Najpomembnejši integracijski preizkus je pogosto prehod med izvornim omrežjem in dostavo v ciljni državi. Ohranite izvirno referenco in vsako potrjeno referenco za zadnjo miljo. Nova sledilna številka mora postati še en identifikator istega paketa, ne samodejno druga pošiljka.

Identifikatorje povežite le, kadar povezava izhaja iz zanesljivega vira, kot so ponudnik logistike, odgovor sledenja ali vaš pošiljateljski sistem. Podobni časi dogodkov ali ujemajoče se ciljne države niso dovolj za dokaz, da dve številki pripadata istemu paketu.

Čas dogodka ločite od časa vnosa. Starejši dogodek lahko doseže vaš sistem po novejšem, zlasti kadar se informacije premikajo med omrežji. Ohranite navedene odmike časovnih pasov, časovne žige normalizirajte za obdelavo in nejasne izvorne vrednosti ohranite, namesto da bi jim dodelili časovni pas brez podpore.

Strankam prikažite najnovejši pomembni status z vidnim časom posodobitve. Če prevoznik v ciljni državi še ni poročal o skenu, pojasnite, da sledenje čaka na novo posodobitev. Ne sklepajte, da je paket izgubljen, da je še vedno fizično na lokaciji zadnjega skena ali da je že v ciljni državi.

Vloga 17TRACK v tem poteku dela

Storitev Tracking API podjetja 17TRACK je pomembna, kadar vaša aplikacija potrebuje integracijo sledenja več prevoznikov. Pri izvedbi avtentikacije, registracije, obdelave odgovorov in podprtih potekov posodobitev upoštevajte njeno uradno dokumentacijo API-ja. Uporabljajte dokumentirano pogodbo API-ja, ne pa potrošniške strani za sledenje kot integracijskega vmesnika.

Ocenite ga z enakimi operativnimi zahtevami, kot bi jih uporabili pri lastni izvedbi: pravilna identifikacija prevoznika, uporabni dogodki na vaših poteh, neprekinjenost predaj, obnovitev po napakah in obvladljiva dostava posodobitev. Pred zavezo produkcijski zasnovi potrdite komercialne pogoje, obračun uporabe, omejitve zahtev in zahtevano konfiguracijo računa.

Najmočnejši razlog za izbiro združenega API-ja je manjša kompleksnost integracije za poti, ki jih dejansko uporabljate. To prednost je še vedno treba potrditi z reprezentativnimi paketi. Ponudnika ne izberite samo zato, ker njegov splošni opis pokritosti zveni obsežno.

Pred uvedbo izvedite pilot na podlagi poti

Uporabite testni nabor, ki vključuje običajne dostave in zahtevne primere. Zgodovinske pošiljke pomagajo preizkusiti preslikavo statusov, medtem ko pošiljke v živo razkrijejo dostavo posodobitev in operativno časovno usklajevanje. Noben test sam ne odgovori na vsa vprašanja.

• Dostava iz Kitajske v ZDA: preverite izvorne dogodke, morebitno mednarodno predajo in končni dogodek dostave.
• Dostave iz Kitajske v Evropo: preizkusite ciljne države in pošiljateljske storitve, ki jih dejansko uporabljate.
• Nova nalepka: potrdite, da paket brez fizičnega skena ni prikazan kot paket v gibanju.
• Spremenjena referenca dostave: potrdite, da povezava ostane pripeta na pravilen paket.
• Izjema pri dostavi: preverite, ali podroben razlog doseže ustrezno operativno čakalno vrsto.
• Razdeljeno naročilo: potrdite, da dostava enega paketa ne zapre celotnega naročila.
• Podvojena ali zakasnjena posodobitev: potrdite, da ne ustvarja ponavljajočih se sporočil ali nepravilno prepiše novejšega statusa.
• Začasna napaka integracije: preverite ponovne poskuse, usklajevanje in vidnost za podporo.

Merila sprejemljivosti določite, preden pregledate rezultate. Izmerite uspešnost registracije, napačne dodelitve prevoznikov, manjkajoče mejnike, zamude pri obdelavi posodobitev in podvojena sporočila strankam. Določite sprejemljive pragove za svoje podjetje, namesto da bi si izposodili univerzalno merilo brez podpore. Manjkajoči dogodek preiščite v lastnem zapisu prevoznika, preden vrzel pripišete API-ju.

Svežino podatkov spremljajte ločeno od razpoložljivosti API-ja

Spremljanje API-ja mora odgovoriti na dve različni vprašanji: ali integracija deluje in ali so informacije o pošiljki uporabne? Uspešne zahteve odgovorijo le na prvo vprašanje. Vedeti morate tudi, ali se pri registracijah kopičijo napake, ali povratni klici ne uspevajo ali pa je pot prenehala ustvarjati pričakovane mejnike.

• Zdravje integracije: napake pri avtentikaciji, napake zahtev, odgovori o omejitvi hitrosti, napake povratnih klicev in zaostanki čakalnih vrst.
• Kakovost podatkov: neznani statusi, nepravilni časovni žigi, nerešene identitete prevoznikov in nepričakovane spremembe identifikatorjev.
• Svežina pošiljke: čas od zadnjega dogodka prevoznika, razčlenjen po poti in pošiljateljski storitvi.
• Vpliv na poslovanje: obseg izjem, neuspešna obvestila in naročila, ki so napačno označena kot dokončana.

Dolgo obdobje brez skena je lahko pri eni pošiljateljski storitvi običajno, pri drugi pa nenavadno. Za določanje prednosti preiskav uporabite pričakovanja, specifična za pot, in opaženo zgodovino pošiljk. Opozorilo o napaki integracije naj bo ločeno od opozorila o zamudi pošiljke, da ga prejme prava ekipa.

Obvestila strankam naj sledijo potrjenim mejnikom, ne vsakemu surovemu dogodku. Preprečite podvojitve, ločite poskus dostave od dokončane dostave in ne obljubljajte datumov prihoda, ki jih osnovni podatki ne podpirajo. Dostop do vsebin sledenja omejite, osebne podatke pa hranite le, kadar jih vaš potek dela zahteva.

Pogosta vprašanja

Ali lahko en API sledi tako kitajskemu izvornemu prevozniku kot dostavnemu prevozniku v ciljni državi?

Storitev za več prevoznikov lahko združi dogodke iz obeh delov poti, kadar so podprte ustrezne storitve in povezave med identifikatorji. Celotno pot preverite z dejanskimi paketi. Prepoznavanje izvorne sledilne številke samo po sebi ne dokazuje, da bodo na voljo informacije o dostavi v ciljni državi.

Zakaj se sledenje preneha posodabljati, ko paket zapusti Kitajsko?

Možni razlogi vključujejo vrzel med fizičnimi skeni, zapoznelo poročanje ali predajo drugi referenci za dostavo. Preverite surove dogodke in morebitno navedeno številko za zadnjo miljo, nato pa primerjajte podatke z zapisom ustreznega prevoznika. Sama vrzel v sledenju ne dokazuje, da je paket izgubljen ali zadržan na carini.

Ali naj aplikacija uporablja spletne kavlje ali periodično preverjanje?

Uporabite mehanizme, ki jih dokumentira vaš ponudnik. Kadar so podprti, lahko spletni kavlji zmanjšajo število ponavljajočih se preverjanj, dovoljene zahteve za pridobivanje pa lahko podpirajo usklajevanje. Pri obeh zasnovah pred zanašanjem na posodobitve za komunikacijo s strankami zgradite obravnavo dvojnikov, nadzor ponovnih poskusov in spremljanje.

Ali lahko API za sledenje zagotovi datum dostave ali carinsko sprostitev?

Podatki sledenja ne zagotavljajo ne enega ne drugega. Če je naveden ocenjeni datum dostave, ohranite njegov vir in ga predstavite kot oceno. Carinske skene opišite glede na njihovo dejansko besedilo in jih ne razlagajte kot sprostitev, razen če izrecno kažejo takšen rezultat.

Kaj je treba preveriti pred izbiro načrta API-ja?

Potrdite svoje prevoznike in pošiljateljske storitve, zahteve za registracijo, načine posodobitev, obračun uporabe, omejitve zahtev, razpoložljivost podatkov in podporne dogovore. Vprašajte, kako se komercialno obravnavajo nadomestne številke, ponovne registracije in zgodovinska iskanja. Za zahteve, ki vplivajo na vaš proračun ali arhitekturo, uporabite aktualno dokumentacijo in pisno potrditev.

Viri

• 17TRACK Tracking API — uradna predstavitev izdelka za API za sledenje.
• Dokumentacija 17TRACK API-ja — uradni tehnični vir za izvedbo integracije. Pred razvojem tukaj potrdite natančne oblike zahtev, podprte poteke in omejitve.