Vežėjo siuntų sekimo būsenų normalizavimas: kaip susieti vežėjo įvykius į vieną būsenų modelį

Vežėjo siuntų sekimo būsenos normalizavimas reiškia vežėjui būdingų nuskaitymo kodų ir pranešimų vertimą į nuoseklų siuntos modelį, išsaugant pirminius įrodymus. Norėdami tai patikimai įgyvendinti, susiekite kiekvieną įvykį su kanonine būsena ir priežastimi, tada apskaičiuokite dabartinę siuntos būseną naudodami įvykio laiką, siuntos kontekstą ir aiškias perėjimo taisykles. Automatiškai nelaikykite naujausio gauto pranešimo dabartine siuntos būsena.

Šis vadovas skirtas kūrėjams, logistikos operacijų komandoms ir produktų vadovams, kurie diegia siuntų sekimą užsakymų valdymo sistemoje, pagalbos skydelyje arba klientų pranešimų sraute. Toliau pateiktas modelis yra siūlomas įgyvendinimo būdas, o ne oficialus vežėjų standartas ar kurios nors sekimo paslaugos teikėjo būsenų taksonomijos atkūrimas.

Atskirkite vežėjo įvykį nuo siuntos būsenos

Sekimo įvykis apibūdina tai, kas pranešta apie siuntą: sukurta etiketė, siuntinys pasiekė objektą arba pristatymo bandymas nepavyko. Siuntos būsena yra jūsų programos interpretacija apie svarbius įrodymus konkrečiu laiko momentu. Šias sąvokas reikėtų saugoti atskirai.

Pavyzdžiui, po pristatymo bandymo įvykio gali sekti atvykimo į objektą įvykis. Atvykimas yra naudinga operacinė istorija, tačiau tai nebūtinai reiškia, kad nepavykusio bandymo sąlyga išspręsta. Ir atvirkščiai, po pristatymo patvirtinimo gautas vėluojantis nuskaitymas neturėtų automatiškai grąžinti siuntinio į gabenimo būseną.

Praktinę architektūrą sudaro trys sluoksniai:

1. Neapdoroti įrodymai: pradinis vežėjo arba paslaugos teikėjo naudingasis paketas, įskaitant kodus, tekstą, laiko žymas ir identifikatorius.
2. Normalizuoti įvykiai: jūsų kiekvieno atskiro įvykio interpretacija, naudojant versijuotą susiejimo taisyklę.
3. Dabartinė siuntos projekcija: iš įvykių istorijos parinkta būsena, taip pat visos aktyvios sąlygos ir klientų veiksmai.

Šis atskyrimas leidžia taisyti susiejimus ir iš naujo sukurti siuntų būsenas neištrinant pirminio įrašo.

Apibrėžkite kompaktišką būsenų modelį su atskiromis sąlygomis

Vieną būsenos lauką tampa sunku prižiūrėti, kai jis vienu metu turi atspindėti fizinį judėjimą, muitinės tvarkymą, pristatymo problemas ir grąžinimus. Naudokite nedidelį gyvavimo ciklo modelį, o tada pridėkite konkretesnes sąlygas ir priežastis.

Sąlygas, tokias kaip CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE ar DELAY_REPORTED, laikykite atskirai nuo pagrindinio gyvavimo ciklo lauko. Siunta gali likti IN_TRANSIT, o dėl adreso problemos vis tiek reikėti veiksmų. Įprasto muitinės tvarkymo nelaikykite išimtimi, nebent šaltinis praneša apie sulaikymą, problemą arba reikiamą veiksmą.

Kryptį nurodykite atskirai, naudodami tokį lauką kaip journey_type. Grąžinimas gali turėti atskiras gabenimo ir pristatymo būsenas. Taip išvengiama situacijos, kai pristatymas siuntėjui interpretuojamas kaip sėkmingas pristatymas pirkėjui.

Prieš rašydami susiejimo taisykles sukurkite įvykio įrašą

Normalizuotame įraše turi būti pakankamai konteksto, kad būtų galima paaiškinti susiejimą ir pakartoti rezultatą. Naudinga pradinė schema apima:

• Identifikavimas: vidinis siuntos ID, vežėjo identifikatorius, sekimo numeris, šaltinis ir siuntos dalis.
• Pirminiai įrodymai: neapdorotas įvykio kodas, neapdorotas aprašas, jei pateiktas – šaltinio įvykio ID, ir nuoroda į pradinį naudingąjį paketą.
• Laikas: įvykio laikas, informacija apie laiko juostą, gavimo laikas ir laiko žymos tikslumas.
• Interpretacija: kanoninė būsena, sąlyga, priežasties kodas, kelionės tipas ir veiksmo reikalavimas.
• Atsekamumas: susiejimo taisyklės ID, susiejimo versija ir pasitikėjimo kategorija.

Įvykio laiką laikykite atskirai nuo laiko, kada jūsų sistema gavo atnaujinimą. Popiet gautas saityno pranešimas gali apibūdinti ryte atliktą nuskaitymą. Apklausa taip pat gali pateikti kelis istorinius įvykius, o ne vieną naują įvykį.

Kai laikas ir poslinkis žinomi, naudokite dokumentuotą laiko žymos formatą, pvz., RFC 3339. Jei šaltinis pateikia vietinį laiką be patikimo poslinkio, išsaugokite šį apribojimą, o ne pridėkite klaidingą UTC žymėjimą. Įvykius, kuriuose pateikiama tik data, saugokite kaip datos įrodymus, neišgalvodami tikslaus nuskaitymo laiko.

Neapdorotus naudingus paketus saugokite taikydami tinkamas prieigos kontrolės ir saugojimo taisykles. Juose gali būti gavėjo duomenų ar kitos informacijos, kuri neturėtų patekti į plačiai prieinamą analizės lentelę.

Pirmiausia susiekite vežėjo kodus, tada atsargiai naudokite tekstą

Pradėkite nuo taisyklių, taikomų konkrečiam šaltiniui ir vežėjui. Toks kodas kaip 01 neturi patikimos reikšmės už dokumentuoto konteksto ribų. Jei šaltinis skiria paslaugas, regionus ar dalis, įtraukite šiuos matmenis, kai jie turi įtakos interpretacijai.

Kaip numatytąjį įgyvendinimo principą naudokite šią susiejimo tvarką:

1. Atitikinkite dokumentuotą struktūrinio įvykio kodą ir visus reikalingus kvalifikatorius.
2. Naudokite dokumentuotą šaltinio būseną arba antrinę būseną, kai ji aiškiai apibūdina tvarkomą įvykį.
3. Taikykite siaurai apibrėžtas teksto taisykles žinomiems pranešimams, kuriuose trūksta tinkamų struktūrinių laukų.
4. Neišspręstus įvykius palikite nesusietus, o pasikartojančius atvejus perduokite peržiūrai.

Pirmiausia nustatykite, ar teikėjo būsenos laukas apibūdina atskirą įvykį, ar dabartinę siuntos suvestinę. Nukopijavus siuntos lygio suvestinę į kiekvieną istorinį įvykį, ankstesni nuskaitymai gali atrodyti kaip pristatymo patvirtinimai.

Venkite visuotinių raktinių žodžių taisyklių, tokių kaip „contains delivered“. Atitikti galėtų ir frazė „not delivered“, taip pat pranešimas apie pristatymą logistikos partneriui. Teksto taisyklėms reikia neiginių apdorojimo, kalbinio konteksto ir išimčių. Mašininis vertimas gali padėti peržiūrėtojui suprasti pranešimą, tačiau išversta formuluotė neturėtų nepastebimai tapti autoritetingu įvykio apibrėžimu.

Aiškinamieji susiejimai ir jų ribos

Toliau pateiktuose pavyzdžiuose naudojami išgalvoti pranešimai, siekiant pademonstruoti taisyklių kūrimą. Tai nėra patikrinti konkretaus vežėjo kodai ar tikslūs jo pranešimai.

• „Shipment details submitted“: susiekite su PRE_TRANSIT, kai šaltinio apibrėžimas nurodo tik elektroninę informaciją.
• „Accepted at origin facility“: susiekite su IN_TRANSIT, kai įvykis patvirtina fizinį priėmimą.
• „Recipient unavailable; attempt unsuccessful“: užregistruokite DELIVERY_ATTEMPT_FAILED ir įvertinkite gyvavimo ciklą pagal aplinkinius įrodymus. Nedarykite išvados, kad siuntą galima atsiimti.
• „Available for collection“: susiekite su READY_FOR_PICKUP, kai šaltinis patvirtina, kad gavėjas gali atsiimti siuntą.
• „Transferred to delivery partner“: užregistruokite perdavimą ir išsaugokite tinkamą gabenimo būseną, o ne pažymėkite, kad pristatymas gavėjui baigtas.

Kiekviena taisyklė turėtų turėti trumpą pagrindimą ir savininką. Kai operacijų specialistas ginčija susiejimą, komanda turėtų galėti nustatyti tikslią taisyklę, o ne atkurti ją iš klientui rodomos etiketės.

Apskaičiuokite dabartinę būseną naudodami deterministinį reduktorių

Reduktorius yra funkcija, kuri įvertina normalizuotus įvykius ir sukuria dabartinę siuntos projekciją. Ji turi grąžinti tą patį rezultatą tiems patiems įrodymams ir taisyklės versijai, nesvarbu, kiek kartų įvestis pakartojama.

Pašalinkite dublikatus neištrindami prasmingų nuskaitymų

Jei yra stabilus šaltinio įvykio identifikatorius, pirmenybę teikite jam. Kitu atveju sukurkite dublikatų šalinimo raktą iš prieinamų atributų, pvz., siuntos tapatybės, vežėjo, kodo, įvykio laiko ir vietos. Atsižvelkite į laiko žymos tikslumą ir šaltinio elgseną. Du vienodų aprašų nuskaitymai nebūtinai yra dublikatai, ypač jei siuntinys vėl apsilanko tame pačiame objekte.

Rikiuokite įvykius nemanydami, kad laikrodžiai yra tobuli

Naudokite patikimus įvykio laikus ir, kai įmanoma, dokumentuotą sekos informaciją. Gavimo laikas gali padėti išspręsti lygiąsias, tačiau jis neturėtų įprastai pakeisti ankstesnio įvykio laiko. Jei laiko žymos prieštarauja viena kitai arba jų negalima patikimai palyginti, išsaugokite neapibrėžtumą, o ne sukurkite tariamą tikrumą.

Patvirtinkite perėjimus, o ne priskirkite visuotinį rangą

Paprasta skaitinė būsenų tvarka negali atspindėti kiekvienos siuntos kelionės. Po nesėkmingo bandymo siuntinys gali iš pristatymo būsenos grįžti į gabenimo būseną. Atsiėmimo galiojimas gali baigtis. Aiški pataisa gali panaikinti pristatymo patvirtinimą.

Apibrėžkite leidžiamus perėjimus ir kiekvienam reikalingus įrodymus. Laikykite pristatytą būseną apsaugota nuo įprastų senesnių nuskaitymų, tačiau leiskite dokumentuotą pataisą arba įgaliotą operacinį pakeitimą. Užregistruokite kiekvieno pakeitimo priežastį ir šaltinį.

Aktyvias sąlygas sekite atskirai

Vėlesnis judėjimo nuskaitymas gali rodyti pažangą, tačiau neįrodyti, kad mokėjimo ar adreso problema išspręsta. Apibrėžkite konkrečios sąlygos panaikinimo taisykles: aiškų išsprendimą, logiškai išsprendžiantį įvykį arba įgaliotą rankinį veiksmą. Nepanaikinkite kiekvienos sąlygos vien todėl, kad atsirado kitas įvykis.

Taip pat atskirkite vežėjo praneštą vėlavimą nuo jūsų neveiklumo įspėjimo. Naujų nuskaitymų nebuvimas yra duomenų šviežumo stebėjimas, o ne įrodymas, kad siuntinys prarastas.

Vežėjų perdavimus ir grąžinimus tvarkykite kaip susietas keliones

Tarptautinis sekimas gali apimti kelis vežėjus ir identifikatorius. Išsaugokite vidinę siuntos tapatybę ir prie atitinkamų dalių pridėkite vežėjui būdingas sekimo nuorodas. Susiekite nuorodas naudodami šaltinio pateiktus ryšius arba patikrintus operacinius duomenis, o ne vien panašias paskirties vietas ar artimas laiko žymas.

Dalies lygio pristatymo įvykis turi būti interpretuojamas kontekste. Pristatymas į konsolidavimo objektą arba partnerio tinklą gali užbaigti tą dalį, bet ne pristatymą pirkėjui. Jūsų siuntos projekcija turi žinoti, kokią paskirties vietą reiškia įvykis.

Taip pat atskirkite „return requested“, „return movement started“ ir „returned to sender“. Tai skirtingi etapai. Grąžinimo prašymas neįrodo, kad siuntinys fiziškai juda atgal, o atvirkštinės kelionės pristatymo patvirtinime turi būti nurodyta grąžinimo paskirties vieta.

Naudokite sekimo API neatsisakydami savo verslo taisyklių

Daugelio vežėjų integracija gali suteikti bendrą duomenų gavimo tašką, tačiau bendras atsakymo formatas nepanaikina aiškios vidinės sutarties poreikio. Vertindami 17TRACK Tracking API, naudokite jos official documentation, kad patikrintumėte jūsų įgyvendinimui svarbių laukų ir sąsajų reikšmę. Nemanykite, kad šiame vadove siūlomos būsenos sutampa su jos vietine taksonomija.

Prieš prijungdami bet kurią API prie klientų pranešimų ar operacinio automatizavimo, nustatykite:

• Kurie laukai apibūdina atskirus įvykius, o kurie – dabartinę siuntos suvestinę.
• Kuri pradinė vežėjo informacija pateikiama ir gali būti išsaugota.
• Kaip pateikiamos laiko žymos, trūkstamos reikšmės, pataisos ir pasikartojantys atnaujinimai.
• Kaip atskirti grąžinimo keliones ir pristatymą tarpiniams partneriams.
• Kaip integracija reaguos į nežinomus kodus arba būsimus schemos pakeitimus.

Tarp išorinio atsakymo ir kanoninio modelio laikykite ploną adapterį. Taip likusi jūsų programos dalis galės naudoti vieną sekimo būsenos sutartį, nepriklausydama nuo kiekvieno ankstesnio lauko pavadinimo. Pranešimų taisykles laikykite kitu sluoksniu: naujas normalizuotas įvykis neturėtų automatiškai sukelti klientui skirto pranešimo.

Tikrinkite įvykių istorijas, ne tik atskirus susiejimus

Susiejimas gali būti teisingas atskirai, tačiau vis tiek sukurti neteisingą siuntos būseną. Tikrinkite visas istorijas, įskaitant atnaujinimus, pateiktus kita tvarka nei jų įvykio laikai.

• Vėluojanti istorija: pristatymo patvirtinimas gaunamas anksčiau nei senesnis gabenimo nuskaitymas. Siunta lieka pristatyta.
• Pakartotinis gavimas: tas pats įvykis apdorojamas dar kartą. Klientui nesiunčiamas pasikartojantis pranešimas.
• Nesėkmingas bandymas: po išsiuntimo pristatyti įvyksta nesėkmingas bandymas. Projekcija nebežada aktyvaus pristatymo maršruto be jį pagrindžiančių įrodymų.
• Parengtis atsiimti: siuntinys pasiekia atsiėmimo objektą prieš patvirtinant jo parengtį. Neišduodamas ankstyvas nurodymas atsiimti.
• Nežinomas įvykis: atsiranda naujas kodas. Neapdorotas įrašas išsaugomas, o anksčiau nustatyta siuntos būsena automatiškai nepakeičiama į nežinomą.
• Grąžinimo judėjimas: atvirkštinė kelionė baigiasi pas siuntėją. Pirminis pristatymas pirkėjui nepažymimas kaip sėkmingas.
• Pataisa: aiški šaltinio pataisa pakeičia rezultatą per audituojamą perėjimą.

Pagal vežėją ir šaltinį stebėkite nesusietus įvykius, atsarginio teksto naudojimą, netinkamus perėjimus ir pasikartojančius bandymus siųsti pranešimus. Atskirti susiejimo išsamumą nuo susiejimo teisingumo: atpažinti kiekvieną kodą nėra naudinga, jei jo interpretacija klaidinga.

Prieš diegdami susiejimo pakeitimą, pakartokite tipines istorijas ir palyginkite senas bei naujas projekcijas. Peržiūrėkite skirtumus, turinčius įtakos pristatymo patvirtinimui, atsiėmimo nurodymams, grąžinimo užbaigimui ar kliento veiksmams. Versijuokite taisykles, kad pagalbos darbuotojas galėtų paaiškinti, kodėl sistema pateikė konkretų rezultatą.

DUK

Ar kiekvienas sekimo įvykis turi turėti lygiai vieną būseną?

Kiekvienas įvykis gali turėti vieną pagrindinę normalizuotą interpretaciją, tačiau jam taip pat gali reikėti sąlygos, priežasties ir kelionės konteksto. Bandant visą reikšmę sutalpinti į vieną plokščią būsenų sąrašą, modelį naudoti ir prižiūrėti tampa sunkiau.

Ar nežinomas įvykis turėtų pakeisti dabartinę siuntos būseną?

Paprastai ne. Palikite įvykio susiejimą neišspręstą, išsaugodami paskutinę palaikomą siuntos būseną. Duomenų šviežumą rodykite atskirai, kad naudotojai nepalaikytų senos patvirtintos būsenos naujausiu atnaujinimu.

Ar pristatyta siunta gali grįžti į gabenimo būseną?

Senesnis gabenimo nuskaitymas neturėtų sukelti tokio pakeitimo. Patikrinta pataisa gali jį pateisinti, o naujai pradėta grąžinimo kelionė paprastai turėtų būti vaizduojama atskirai. Perėjimui reikia aiškios priežasties, o ne vien vėlesnio gavimo laiko.

Kaip turėtų būti pateikiami trūkstami sekimo atnaujinimai?

Naudokite vidinį šviežumo rodiklį arba neveiklumo įspėjimą. Laikykite jį atskirai nuo vežėjo pranešto vėlavimo, praradimo ar išimties būsenų. Bet kokia eskalavimo riba turėtų atspindėti jūsų paslaugų įsipareigojimus ir veiklos politiką, o ne universalią prielaidą.

Kas turėtų tvirtinti susiejimo pakeitimus?

Inžinerijos komanda turėtų būti atsakinga už įgyvendinimą ir pakartotinio testavimo procesą; logistikos operacijos turėtų patvirtinti siuntimo reikšmę; o klientų patirties savininkas turėtų patvirtinti poveikį pranešimams. Paskirkite konkretų sprendimų priėmėją, kad neaiškūs įvykiai neliktų neišspręsti neribotą laiką.

Šaltiniai

• RFC 3339: Date and Time on the Internet: Timestamps — nuoroda į laiko žymų pateikimą ir skaitinius poslinkius.
• 17TRACK Tracking API — oficialus sekimo API integracijos, aptartos pirmiau, pradžios taškas.
• 17TRACK API documentation — įgyvendinimo nuoroda teikėjo sutarčiai patikrinti; šiame straipsnyje pateikiamas kanoninis modelis ir susiejimo pavyzdžiai yra siūlomi projektavimo būdai, o ne konkretaus teikėjo apibrėžimai.