Kaip suvienodinti tarpvalstybinį siuntų sekimą Vidurio ir Rytų Europoje

Siekiant suvienodinti tarpvalstybinių siuntų sekimą Vidurio ir Rytų Europoje, reikia susieti vežėjų atnaujinimus su vienu siuntos įrašu, išsaugoti sekimo identifikatorius perduodant siuntą kitam vežėjui ir išversti skirtingus įvykių formatus į bendrą būsenų modelį. Elektroninės prekybos operacijų komandoms tikslas nėra tiesiog vienas sekimo puslapis: tai patikimas kiekvienos siuntos vaizdas, aiškiai nurodant atsakomybę, kai pristatymas nebejuda į priekį.

Kurkite sistemą remdamiesi faktiniais siuntimo maršrutais, paslaugų tipais ir pristatymo partneriais, o ne regioniniu vežėjų sąrašu. Ryšys, tinkantis vienai vietinei paslaugai, neįrodo, kad tarptautinis perdavimas, pristatymas į siuntų saugyklą ar grąžinimo kelionė bus taip pat matomi.

Pradėkite nuo siuntimo maršrutų, o ne nuo šalių aprėpties

Vidurio ir Rytų Europa yra naudingas veiklos regionas, tačiau tai nėra viena muitų teritorija ar vienas pristatymo tinklas. Regionų apibrėžimai taip pat skiriasi. Aiškiai apibrėžkite apimtį: kilmės šalį, paskirties šalį, siuntimo paslaugą ir organizacijas, atsakingas už kiekvieną transportavimo etapą.

Atskirkite judėjimą ES muitų teritorijoje nuo judėjimo per jos išorinę sieną. Europos Komisija paaiškina ES muitų sistemą; vien geografinis artumas nenulemia siuntos muitinio režimo. Dėl specialių teritorijų, prekių statuso ir konkrečių procedūrų gali reikėti papildomų patikrų.

Sudarykite maršrutų sąrašą naudodami siuntų įrašus, vežėjų sutartis ir sandėlio išsiuntimo duomenis. Kiekvienam maršrutui užrašykite:

• Kilmę ir paskirties vietą, įskaitant susijusius pašto kodų intervalus.
• Sutartyje numatytą paslaugą ir šalį, kuri priima siuntą.
• Bet kurį žinomą tranzito ar paskirties pristatymo partnerį.
• Išsiuntimo metu suteiktą sekimo identifikatorių ir bet kurį vėlesnį identifikatorių.
• Pristatymą į namus, siuntų punktą arba saugyklą.
• Ar numatomas muitinis įforminimas.
• Komandą, atsakingą už pristatymo išimčių tyrimą.

Šis sąrašas tampa jūsų integracijos testavimo planu. Jei logistikos partneris negali paaiškinti, kaip tampa prieinamas paskirties vietos sekimas, išspręskite šį klausimą prieš žadėdami klientams viso proceso matomumą.

Pasirinkite integracijos būdą pagal veiklos reikalavimus

Kelių vežėjų sekimo API yra praktiškas atspirties taškas, kai keli pristatymo tinklai turi perduoti duomenis į vieną užsakymų valdymo ar pagalbos sistemą. Tiesioginės vežėjų integracijos taip pat gali būti tinkamos, kai konkrečiai paslaugai reikalingi duomenys ar veiksmai, kurių bendras ryšys nesuteikia. Hibridinis sprendimas gali sujungti abu būdus, klientams nerodant atskirų sekimo patirčių.

Šiam naudojimo atvejui tinkamas 17TRACK produktas yra jo Tracking API, o integracijos informacija pateikiama oficialioje API dokumentacijoje. Vertinkite jį pagal faktinius maršrutus ir reikalingus procesus, o ne manykite, kad nurodytas vežėjas užtikrina visišką kiekvienos paslaugos matomumą.

Vertinimą grįskite bandymo siuntų duomenimis. Patvirtinkite registracijos reikalavimus, vežėjo identifikavimą, prieinamus įvykių laukus, atnaujinimų perdavimą, klaidų valdymą ir paskyros apribojimus taikomoje dokumentacijoje bei sutartyje. Nekurkite gamybinio veikimo remdamiesi tariama webhook pakartotinio bandymo politika, istorinių duomenų laikotarpiu ar garantuotu atnaujinimo intervalu.

Tiesioginį ryšį verta svarstyti, kai bendrame sraute trūksta svarbaus įvykio arba operacijoms reikia konkrečiam vežėjui skirto veiksmo, nesusijusio vien su sekimu. Kita vertus, daugelio tiesioginių integracijų priežiūra didina autentifikavimo, schemų ir stebėsenos darbą. Rinkitės pagal įrodytus reikalavimus, o ne manykite, kad viena architektūra visada pranašesnė už kitą.

Sukurkite vieną siuntos įrašą, išliekantį perduodant siuntą tarp vežėjų

Užsakymo numeris nėra siuntos tapatybė. Vienas užsakymas gali būti išsiųstas keliomis siuntomis, o siunta, pasikeitus atsakomybei, gali gauti kitą sekimo identifikatorių. Jūsų vidinis siuntos įrašas turi išlikti stabilus abiem atvejais.

Naudokite vidinį siuntos ID kaip pagrindinę nuorodą. Vežėjų identifikatorius saugokite kaip susietus įrašus, o ne kaip šios tapatybės pakaitalus. Toliau pateikiamas rekomenduojamas vidinis modelis, o ne konkretaus teikėjo atsako schemos aprašymas.

Įrašas	Ką išsaugoti	Kodėl tai svarbu
Siuntos tapatybė	Vidinis siuntos ID, užsakymo nuoroda, siuntos nuoroda	Atskiriamos išskaidytos siuntos ir atskiri užsakymai.
Sekimo identifikatoriai	Sekimo numeris, vežėjo tapatybė, šaltinis, susijusi transportavimo atkarpa	Susiejamas kilmės ir paskirties sekimas neprarandant kilmės duomenų.
Neapdoroti įvykiai	Originalus aprašymas, šaltinio laiko žyma, vieta, gavimo laiko žyma	Padeda atlikti tyrimus ir vėlesnius pataisymus.
Normalizuoti įvykiai	Bendra būsena, išimties kategorija, susiejimo versija	Užtikrina nuoseklias ataskaitas ir klientų pranešimus.

Susiekite naują paskirties identifikatorių, kai vežėjas, logistikos partneris arba sekimo atsakas aiškiai susieja jį su siunta. Nejunkite įrašų vien todėl, kad jų numeriai atrodo panašūs arba sutampa paskirties vietos. Neaiškias sąsajas nukreipkite į peržiūros eilę, o ne tyliai sujunkite dviejų klientų siuntas.

Normalizuokite būsenų reikšmes neprarasdami detalių

Skirtingi vežėjai lygiaverčius etapus gali apibūdinti skirtingai. Ir atvirkščiai, panaši formuluotė gali apibūdinti skirtingas veiklos situacijas. Normalizuokite įvykio reikšmę, o ne tik išverstą jo tekstą.

Valdomas vidinis būsenų modelis galėtų apimti gautą siuntos informaciją, vežėjo priimtą siuntą, gabenamą siuntą, išsiųstą pristatyti, paruoštą atsiimti, pristatytą siuntą, pristatymo išimtį, grąžinamą ir grąžintą siuntą. Jei įmanoma, muitinės informaciją ir išimčių priežastis saugokite kaip papildomus matmenis. Muitinės procedūras atliekanti siunta automatiškai nėra vėluojanti ar laukianti kliento veiksmų.

• Gauta siuntos informacija: Egzistuoja elektroniniai siuntos duomenys, tačiau fizinis priėmimas nepatvirtintas.
• Paruošta atsiimti: Siunta paruošta atsiėmimo vietoje; tai nėra tas pats, kas kliento gautas pristatymas.
• Pristatymo išimtis: Kažkas gali sutrikdyti pristatymą. Išsaugokite konkrečią priežastį ir visus reikiamus veiksmus.
• Pristatyta: Pranešta apie atitinkamą pristatymo etapą. Išsaugokite detales, leidžiančias atskirti pristatymą gavėjui nuo kitos pristatymo tvarkos.

Originalų įvykį saugokite šalia normalizuoto atitikmens. Jei vietos kalba pateiktas pranešimas dviprasmiškas, palikite platesnę būseną, o ne sugalvokite tikslią paaiškinimo versiją. Pavyzdžiui, trūkstamas nuskaitymas neįrodo, kad siunta sulaikyta muitinėje, pristatyti nepavyko ar ji prarasta.

Versijuokite susiejimo taisykles. Pasikeitus interpretacijai, turite galėti nustatyti paveiktas siuntas ir perskaičiuoti jų rodymo būseną neprarasdami šaltinio istorijos.

Pritaikykite įvykių priėmimą netobuliems duomenims

Sekimo įvykiai gali ateiti vėliau, pasikartoti arba pasirodyti ne eilės tvarka. Priėmimą laikykite patvariu duomenų srautu, o ne tiesioginiu klientų el. laiškų paleidikliu.

1. Patikrinkite ir autentifikuokite gaunamus duomenis. Taikykite integracijai dokumentuotą tikrinimo metodą. Ribokite priimamų duomenų rinkinių dydį ir nefiksuokite prisijungimo duomenų žurnaluose.
2. Išsaugokite įvykį prieš tolesnį apdorojimą. Atskirai valdykite sėkmingą gavimą nuo vėlesnio normalizavimo ir pranešimų siuntimo.
3. Saugiai pašalinkite dublikatus. Jei įmanoma, naudokite stabilų įvykio identifikatorių. Priešingu atveju apibrėžkite dokumentuotą šaltinio laukų derinį ir atsižvelkite į teisėtus pasikartojančius nuskaitymus.
4. Įvykio laiką ir gavimo laiką saugokite atskirai. Išsaugokite laiko juostos informaciją. Nenustatykite laiko juostos, jei šaltinis jos nenurodo.
5. Apskaičiuokite dabartinę būseną. Vėliau gautas senesnis įvykis neturėtų automatiškai pakeisti pažangesnio etapo.
6. Suderinkite spragas. Kai tai palaikoma ir leidžiama, gaukite atnaujinimus, kad atkurtumėte praleistus pristatymus ar apdorojimo klaidas.

Nedarykite būsenos eigos visiškai negrįžtamos. Šaltinis gali pataisyti ankstesnį pranešimą apie pristatymą. Aiškius pataisymus tvarkykite su audito seka, o ne slopinkite juos vien todėl, kad siunta anksčiau atrodė užbaigta.

Paskirkite techninį atsakingą asmenį nepavykusioms registracijoms, autentifikavimo klaidoms, apdorojimo eilėms ir nesusietiems įvykiams. Tai yra integracijos problemos, o ne įrodymas, kad pati siunta nustojo judėti.

Paverskite sekimo išimtis priskirtomis užduotimis

Suvienodintas skydelis tampa naudingas, kai kas nors žino, ką daryti toliau. Apibrėžkite išimčių taisykles pagal maršrutą ir paslaugą, remdamiesi stebėtu siuntų elgesiu bei sutartiniais įsipareigojimais. Nėra pagrįsto universalaus laikotarpio, po kurio kiekviena tarpvalstybinė siunta turėtų būti priskiriama vėluojančioms ar prarastoms.

Atskirkite bent tris situacijas:

• Nėra fizinio priėmimo: Siuntos duomenys egzistuoja, tačiau nėra įrodymų, kad vežėjas ją gavo. Paprašykite sandėlio arba išsiuntimo partnerio patikrinti perdavimą.
• Nėra naujausio judėjimo: Anksčiau priimta siunta neturi vėlesnio atnaujinimo per maršrutui nustatytą tyrimo ribą. Prieš eskaluodami patikrinkite šaltinio prieinamumą ir suplanuotus tranzito etapus.
• Reikalingas aiškus veiksmas: Šaltinis praneša apie adreso problemą, prašomus dokumentus ar atsiėmimo reikalavimą. Nukreipkite atvejį komandai, galinčiai jį išspręsti.

Kiekviename įspėjime turi būti siuntos tapatybė, naujausi svarbūs įvykiai, sekimo nuorodos, atsakinga komanda, kitas veiksmas ir peržiūros terminas. Slopinkite pasikartojančius įspėjimus, bet išsaugokite reikšmingus pokyčius.

Siuntų punktų ir saugyklų pristatymams išsaugokite pateiktą atsiėmimo informaciją. Atsiėmimo terminą skelbkite tik tada, kai jis gaunamas iš patikimo šaltinio, susijusio su ta siunta ar paslauga. Neišveskite jo iš kitos šalies pristatymo taisyklių.

Suteikite klientams paprastesnį vaizdą nei operacijoms

Klientams skirtas puslapis turi atsakyti į tris klausimus: kur siunta yra savo kelyje, ar klientas turi imtis veiksmų ir kas bus toliau. Nebūtina rodyti kiekvieno vidinio nuskaitymo.

Naudokite tą patį normalizuotą siuntos įrašą sekimo puslapiui, pagalbos įrankiams ir pranešimams. Taip sumažinsite prieštaringas žinutes, pavyzdžiui, kai el. laiške nurodoma „gabenama“, o pagalbos ekrane rodoma, kad ją reikia atsiimti.

Pranešimus suaktyvinkite pagal reikšmingus perėjimus, o ne pagal kiekvieną gaunamą įvykį. Atskirkite „etiketė sukurta“ nuo „vežėjas gavo siuntą“, o „paruošta atsiimti“ nuo „pristatyta“. Numatomas pristatymo datas aiškiai atskirkite nuo patvirtintų etapų ir pažymėkite jas kaip prognozes.

Paaiškinimus lokalizuokite kliento kalba, bet originalų vežėjo tekstą išsaugokite pagalbai. Apsaugokite prieigą prie siuntos duomenų ir rodykite tik sekimui reikalingą informaciją. Adreso duomenys, telefono numeriai ir atsiėmimo prisijungimo duomenys neturėtų tapti vieši vien todėl, kad kas nors žino sekimo nuorodą.

Prieš plėsdami išbandykite visas keliones

Pasirinkite reprezentatyvius maršrutus, o ne tik lengviausią integraciją. Įtraukite judėjimą ES viduje, prireikus judėjimą per išorinę sieną, perdavimą paskirties vežėjui ir pristatymą į atsiėmimo vietą. Jei tai priklauso jūsų veiklos sričiai, pridėkite išskaidytus užsakymus ir grąžinimus.

Išbandykite įprastus pristatymus ir sudėtingus atvejus: neatpažintą sekimo numerį, pavėluotą pirmą nuskaitymą, pasikartojantį įvykį, ne eilės tvarka pateiktą atnaujinimą, trūkstamą laiko juostą, pasikeitusį paskirties identifikatorių ir pataisytą pristatymo būseną. Kai gyvų pavyzdžių nėra, naudokite istorinius įrašus arba kontroliuojamus bandymų duomenis.

Prieš bandomąjį etapą susitarkite dėl priėmimo rodiklių:

• Sėkmingai sekimui užregistruotų išsiųstų siuntų dalis.
• Teisingai su pradiniu siuntos įrašu susietų žinomų perdavimų dalis.
• Gautų įvykių, kuriuos reikia interpretuoti rankiniu būdu, dalis.
• Laikas nuo įvykio prieinamumo šaltinyje iki jo priėmimo ir parodymo klientui, jei išmatuojama.
• Neteisingi arba pasikartojantys klientų pranešimai.
• Išimtys, kurioms nepriskirtas atsakingas asmuo.

Apibrėžkite kiekvieną vardiklį. Vien įvykio laiko žyma negali įrodyti, kaip greitai jūsų integracija surinko atnaujinimą, nes šaltinis galėjo jį paskelbti vėliau. Taip pat nesekama siunta turėtų likti matoma ataskaitose, o ne išnykti iš sėkmės rodiklio skaičiavimo.

Plėskite tik tada, kai bandomasis etapas parodo patikimą tapatybių susiejimą, suprantamas būsenas, atkuriamas priėmimo klaidas ir veiksmingą išimčių atsakomybę. Mažesnis gerai suprastų maršrutų rinkinys yra tvirtesnis pagrindas nei platus ryšys su nepaaiškintomis spragomis.

DUK

Ar vienas sekimo numeris gali apimti visą tarpvalstybinę kelionę?

Kartais, tačiau nelaikykite to sistemos reikalavimu. Išsaugokite pradinį identifikatorių ir pridėkite papildomus vežėjų identifikatorius, kai patikimas šaltinis juos susieja. Klientai gali toliau naudoti vieną vidinį sekimo puslapį, net kai pagrindiniai identifikatoriai pasikeičia.

Ar sekimo API panaikina vežėjų santykių poreikį?

Ne. Ji gali konsoliduoti sekimo duomenis, tačiau transportavimo atsakomybės, pristatymo tyrimai, pretenzijos ir sutartiniai įsipareigojimai vis tiek turi aiškius atsakingus asmenis. Prieš atsirandant išimčiai patvirtinkite, kas gali tirti kiekvieną etapą.

Ar kiekviena siunta, kertanti nacionalinę sieną, turi rodyti muitinės etapą?

Ne. Nacionalinė siena nebūtinai yra išorinė muitinės siena, be to, ne kiekvienas sekimo srautas pateikia muitinės įvykius. Muitinės informaciją rodykite, kai ją patvirtina patikimas siuntos įvykis; neįterpkite muitinės etapo vien todėl, kad skiriasi paskirties šalis.

Ką klientai turėtų matyti, kai sekimas nebeatnaujinamas?

Rodykite paskutinį patvirtintą etapą ir jo laiko žymą. Jei viršyta jūsų veiklos riba, paaiškinkite, kad atliekamas tyrimas, ir pateikite tinkamą pagalbos kanalą. Nevadinkite siuntos prarasta be patvirtinančių įrodymų.

Kaip grąžintos siuntos turėtų būti įtrauktos į suvienodintą sekimą?

Išsaugokite pradinę išsiuntimo istoriją ir susiekite grąžinimo judėjimą kaip susijusią kelionę. Atskirkite vežėjo grąžinamą nepristatytą siuntą nuo kliento inicijuoto grąžinimo po gavimo. Jų veiklos atsakingi asmenys ir klientų pranešimai gali skirtis.

Šaltiniai

• 17TRACK Tracking API — oficiali produkto nuoroda vertinant API pagrįstą sekimo integraciją.
• 17TRACK API documentation — techninė nuoroda integracijos reikalavimams ir palaikomam veikimui tikrinti.
• European Commission: Customs — oficialus ES muitų sistemos ir susijusių procedūrų šaltinis.
• European Union: EU countries — oficialus šaltinis, padedantis atskirti ES narystę nuo platesnio geografinio veiklos regiono.