Normalizacija statusov sledenja pri prevoznikih: Kako preslikati dogodke prevoznikov v enoten statusni model

Normalizacija statusa sledenja prevoznikov pomeni prevajanje kod skeniranja in sporočil, značilnih za posameznega prevoznika, v enoten model pošiljke, pri tem pa se ohranijo izvirni dokazi. Za zanesljivo izvedbo vsak dogodek preslikajte v kanonični status in razlog, nato pa trenutno stanje pošiljke izračunajte na podlagi časa dogodka, konteksta pošiljke in izrecnih pravil prehodov. Najnovejšega prejetega sporočila ne obravnavajte samodejno kot trenutni status pošiljke.

Ta vodnik je namenjen razvijalcem, ekipam za logistične operacije in lastnikom izdelkov, ki v sistem za upravljanje naročil, nadzorno ploščo za podporo ali potek obveščanja strank vgrajujejo sledenje. Spodnji model je predlagani vzorec izvedbe, ne pa uradni standard prevoznikov ali reprodukcija taksonomije statusov katerega koli ponudnika sledenja.

Ločite dogodek prevoznika od stanja pošiljke

Dogodek sledenja opisuje nekaj, kar je bilo sporočeno o pošiljki: ustvarjena je bila nalepka, paket je prispel v objekt ali poskus dostave ni uspel. Stanje pošiljke je razlaga ustreznih dokazov v vaši aplikaciji ob določenem času. Ta koncepta je treba shranjevati ločeno.

Na primer, dogodku neuspešnega poskusa dostave lahko sledi dogodek prihoda v objekt. Prihod je uporabna operativna zgodovina, vendar ne pomeni nujno, da je bilo stanje neuspešnega poskusa odpravljeno. Nasprotno pa pozno prejeto skeniranje po potrditvi dostave ne bi smelo samodejno premakniti paketa nazaj v tranzit.

Praktična arhitektura ima tri plasti:

1. Surovi dokazi: izvirni koristni tovor prevoznika ali ponudnika, vključno s kodami, besedilom, časovnimi žigi in identifikatorji.
2. Normalizirani dogodki: vaša razlaga vsakega posameznega dogodka z uporabo različice preslikovalnega pravila.
3. Trenutna projekcija pošiljke: stanje, izbrano iz zgodovine dogodkov, skupaj z vsemi aktivnimi pogoji in dejanji stranke.

Ta ločitev vam omogoča popravljanje preslikav in ponovno izgradnjo stanj pošiljk, ne da bi zavrgli izvirni zapis.

Določite kompakten model statusov z ločenimi pogoji

Eno samo polje statusa je težko vzdrževati, kadar mora hkrati predstavljati fizično premikanje, carinsko obdelavo, težave pri dostavi in vračila. Uporabite majhen življenjski cikel, nato pa mu dodajte podrobnejše pogoje in razloge.

Pogoje, kot so CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE ali DELAY_REPORTED, hranite zunaj primarnega polja življenjskega cikla. Pošiljka lahko ostane v stanju IN_TRANSIT, medtem ko je zaradi težave z naslovom potrebno ukrepanje. Redne carinske obdelave ne označujte kot izjeme, razen če vir poroča o zadržanju, težavi ali potrebnem ukrepanju.

Smer predstavljajte ločeno s poljem, kot je journey_type. Vračilo ima lahko lastni stanji v tranzitu in dostavljeno. Tako se izognete razlagi dostave nazaj pošiljatelju kot uspešne dostave kupcu.

Pred pisanjem pravil preslikave sestavite zapis dogodka

Normalizirani zapis mora vsebovati dovolj konteksta, da pojasni preslikavo in omogoči ponovitev rezultata. Uporabna začetna shema vključuje:

• Identiteta: notranji ID pošiljke, identifikator prevoznika, številko za sledenje, vir in del pošiljke.
• Izvirni dokazi: surovo kodo dogodka, surovi opis, ID izvornega dogodka, kadar je posredovan, in sklic na izvirni koristni tovor.
• Čas: čas nastanka dogodka, informacije o časovnem pasu, čas prejema in natančnost časovnega žiga.
• Razlaga: kanonični status, pogoj, koda razloga, vrsta poti in zahteva po ukrepanju.
• Sledljivost: ID pravila preslikave, različico preslikave in kategorijo zaupanja.

Čas nastanka dogodka hranite ločeno od časa, ko je vaš sistem prejel posodobitev. Spletni klic, prejet popoldne, lahko opisuje skeniranje iz dopoldneva. Tudi odgovor na poizvedbo lahko vsebuje več zgodovinskih dogodkov in ne le enega novega dogodka.

Ko sta čas in odmik znana, uporabite dokumentiran format časovnega žiga, kot je RFC 3339. Če vir posreduje lokalni čas brez zanesljivega odmika, ohranite to omejitev, namesto da bi dodali lažno oznako UTC. Dogodke, ki vsebujejo samo datum, shranite kot dokaze samo z datumom in si ne izmišljajte natančnega časa skeniranja.

Surove koristne tovore shranjujte z ustreznimi pravili dostopa in hrambe. Lahko vsebujejo podatke o prejemniku ali druge informacije, ki ne sodijo v široko dostopno analitično tabelo.

Najprej preslikajte kode prevoznikov, nato previdno uporabite besedilo

Začnite s pravili, omejenimi na določen vir in prevoznika. Koda, kot je 01, nima zanesljivega pomena zunaj dokumentiranega konteksta. Kadar vir razlikuje med storitvami, regijami ali deli pošiljke, vključite te razsežnosti, če vplivajo na razlago.

To zaporedje preslikave uporabite kot privzeto izvedbeno pravilo:

1. Ujemite dokumentirano strukturirano kodo dogodka in vse zahtevane kvalifikatorje.
2. Uporabite dokumentiran status ali podstatus vira, kadar jasno opisuje obdelovani dogodek.
3. Uporabite ozko opredeljena besedilna pravila za znana sporočila, ki nimajo ustreznih strukturiranih polj.
4. Nerazrešene dogodke pustite brez preslikave in ponavljajoče se primere pošljite v pregled.

Najprej ugotovite, ali statusno polje ponudnika opisuje posamezen dogodek ali trenutni povzetek pošiljke. Kopiranje povzetka na ravni pošiljke v vsak zgodovinski dogodek lahko povzroči, da so prejšnja skeniranja videti kot potrditve dostave.

Izogibajte se globalnim pravilom ključnih besed, kot je »vsebuje delivered«. Ujemalo bi se tudi besedilo »not delivered« ali sporočilo, ki opisuje dostavo logističnemu partnerju. Besedilna pravila potrebujejo obravnavo zanikanja, jezikovni kontekst in izključitve. Strojno prevajanje lahko pregledovalcu pomaga razumeti sporočilo, vendar prevedeno besedilo ne sme tiho postati avtoritativna definicija dogodka.

Ilustrativne preslikave in njihove omejitve

Spodnji primeri uporabljajo izmišljena sporočila za prikaz zasnove pravil. Ne gre za preverjene kode prevoznikov ali natančna sporočila določenega prevoznika.

• »Shipment details submitted«: preslikajte v PRE_TRANSIT, kadar definicija vira kaže samo na elektronske informacije.
• »Accepted at origin facility«: preslikajte v IN_TRANSIT, kadar dogodek potrjuje fizični prevzem.
• »Recipient unavailable; attempt unsuccessful«: zabeležite DELIVERY_ATTEMPT_FAILED in življenjski cikel ocenite na podlagi okoliških dokazov. Ne sklepajte, da je prevzem na voljo.
• »Available for collection«: preslikajte v READY_FOR_PICKUP, kadar vir potrjuje pripravljenost za prevzem prejemnika.
• »Transferred to delivery partner«: zabeležite predajo in ohranite ustrezno stanje v tranzitu, namesto da bi označili dostavo prejemniku kot končano.

Vsako pravilo mora imeti kratko utemeljitev in lastnika. Ko strokovnjak za operacije izpodbija preslikavo, mora ekipa imeti možnost prepoznati natančno pravilo, namesto da za nazaj ugiba, kako je nastala oznaka, vidna stranki.

Trenutno stanje izračunajte z determinističnim reduktorjem

Reduktor je funkcija, ki ovrednoti normalizirane dogodke in ustvari trenutno projekcijo pošiljke. Za iste dokaze in različico pravil mora vedno vrniti enak rezultat, ne glede na to, kolikokrat se vhod ponovi.

Odstranite dvojnike, ne da bi izbrisali pomembna skeniranja

Kadar obstaja stabilen identifikator izvornega dogodka, mu dajte prednost. Sicer sestavite ključ za odstranjevanje dvojnikov iz razpoložljivih atributov, kot so identiteta pošiljke, prevoznik, koda, čas nastanka in lokacija. Upoštevajte natančnost časovnega žiga in vedenje vira. Dve skeniranji z enakima opisoma nista nujno dvojnika, zlasti če se paket ponovno vrne v objekt.

Razvrstite dogodke, ne da bi predpostavljali popolne ure

Kjer je mogoče, uporabite zanesljive čase nastanka in dokumentirane informacije o zaporedju. Čas prejema lahko pomaga razrešiti izenačenja, vendar ne sme rutinsko preglasiti prejšnjega časa nastanka. Če so časovni žigi v nasprotju ali jih ni mogoče zanesljivo primerjati, ohranite dvoumnost, namesto da bi ustvarili lažno gotovost.

Preverite prehode, namesto da bi določili univerzalno razvrstitev

Preprosto številčno razvrščanje statusov ne more predstavljati vsake poti pošiljke. Paket se lahko po neuspelem poskusu premakne iz stanja »v dostavi« nazaj v tranzit. Razpoložljivost za prevzem lahko poteče. Izrecni popravek lahko razveljavi potrditev dostave.

Določite dovoljene prehode in dokaze, ki jih vsak zahteva. Stanje dostavljeno zaščitite pred običajnimi starejšimi skeniranji, vendar dovolite dokumentiran popravek ali pooblaščen operativni preglas. Zabeležite razlog in vir vsakega preglasa.

Aktivne pogoje sledite neodvisno

Poznejše skeniranje premika lahko pokaže napredek, ne da bi dokazovalo, da je bila težava s plačilom ali naslovom rešena. Določite pravila razreševanja za posamezne pogoje: izrecna rešitev, logično razrešujoč dogodek ali pooblaščeno ročno dejanje. Ne odstranite vsakega pogoja samo zato, ker je prispel drug dogodek.

Prav tako ločite zamudo, o kateri poroča prevoznik, od lastnega opozorila o neaktivnosti. Odsotnost novih skeniranj je opažanje o svežini podatkov, ne dokaz, da je paket izgubljen.

Predaje med prevozniki in vračila obravnavajte kot povezane poti

Čezmejno sledenje lahko vključuje več prevoznikov in identifikatorjev. Ohranite notranjo identiteto pošiljke in sklice za sledenje, značilne za prevoznika, pripnite ustreznim delom pošiljke. Sklice povežite z odnosi, ki jih zagotovi vir, ali s preverjenimi operativnimi podatki, ne zgolj na podlagi podobnih ciljev ali bližnjih časovnih žigov.

Dogodek dostave na ravni dela pošiljke je treba razlagati v kontekstu. Dostava v konsolidacijski objekt ali partnersko omrežje lahko zaključi ta del, ne da bi zaključila dostavo kupcu. Projekcija vaše pošiljke mora vedeti, kateri cilj predstavlja dogodek.

Prav tako ločite »return requested«, »return movement started« in »returned to sender«. Ti izrazi opisujejo različne mejnike. Zahteva za vračilo ne dokazuje, da se paket fizično vrača, potrditev dostave povratne poti pa mora opredeliti cilj vračila.

Uporabite API za sledenje, ne da bi opustili poslovna pravila

Integracija z več prevozniki lahko zagotovi skupno vstopno točko za sprejem podatkov, vendar skupni format odgovora ne odpravi potrebe po jasnem notranjem dogovoru. Pri ocenjevanju 17TRACK Tracking API uporabite official documentation za preverjanje pomena polj in vmesnikov, pomembnih za vašo izvedbo. Ne predpostavljajte, da se predlagani statusi v tem vodniku ujemajo z njegovo izvorno taksonomijo.

Pred povezavo katerega koli API-ja z obvestili strank ali operativno avtomatizacijo določite:

• Katera polja opisujejo posamezne dogodke in katera trenutni povzetek pošiljke.
• Kateri izvirni podatki prevoznika so izpostavljeni in jih je mogoče ohraniti.
• Kako so predstavljeni časovni žigi, manjkajoče vrednosti, popravki in ponovljene posodobitve.
• Kako je mogoče razlikovati povratne poti in dostavo vmesnim partnerjem.
• Kako se bo vaša integracija odzvala na neznane kode ali prihodnje spremembe sheme.

Med zunanji odgovor in kanonični model vključite tanek adapter. Tako lahko preostanek aplikacije uporablja eno pogodbo za status sledenja, ne da bi bil odvisen od vsakega imena polja pri zunanjih virih. Pravila obveščanja obravnavajte kot še eno plast: nov normalizirani dogodek ne sme samodejno sprožiti sporočila stranki.

Preizkusite zgodovine dogodkov, ne le posameznih preslikav

Preslikava je lahko pravilna sama po sebi, vendar lahko še vedno ustvari napačno stanje pošiljke. Preizkusite celotne zgodovine, vključno s posodobitvami, dostavljenimi v drugačnem vrstnem redu od časov njihovega nastanka.

• Zapoznela zgodovina: potrditev dostave prispe pred starejšim skeniranjem v tranzitu. Pošiljka ostane dostavljena.
• Ponovljen vnos: isti dogodek se obdela znova. Nobeno podvojeno obvestilo stranki ni poslano.
• Neuspešen poskus: neuspešni poskus sledi stanju »v dostavi«. Projekcija brez podpornih dokazov ne obljublja več aktivne dostavne vožnje.
• Pripravljenost za prevzem: paket prispe v prevzemni objekt, preden je potrjena razpoložljivost. Navodilo za prevzem se ne izda prezgodaj.
• Neznani dogodek: pojavi se nova koda. Surovi zapis se ohrani, predhodno vzpostavljeno stanje pošiljke pa se ne nadomesti samodejno z neznanim.
• Povratno premikanje: povratna pot se konča pri pošiljatelju. Izvirna dostava kupcu ni označena kot uspešna.
• Popravek: izrecni popravek vira spremeni rezultat prek preverljivega prehoda.

Spremljajte dogodke brez preslikave, uporabo nadomestnega besedila, neveljavne prehode in poskuse podvojenih obvestil po prevozniku in viru. Ločite popolnost preslikave od pravilnosti preslikave: prepoznavanje vsake kode ni koristno, če je njena razlaga napačna.

Pred uvedbo spremembe preslikave ponovite reprezentativne zgodovine in primerjajte stare in nove projekcije. Preglejte razlike, ki vplivajo na potrditev dostave, navodila za prevzem, zaključek vračila ali dejanja stranke. Pravila verzionirajte, da lahko agent podpore pojasni, zakaj je sistem ustvaril določen rezultat.

Pogosta vprašanja

Ali mora imeti vsak dogodek sledenja natanko en status?

Vsak dogodek ima lahko eno primarno normalizirano razlago, vendar lahko potrebuje tudi pogoj, razlog in kontekst poti. Če vse pomene prisilite v en raven seznam statusov, postane model težje uporabljati in vzdrževati.

Ali mora neznani dogodek nadomestiti trenutni status pošiljke?

Običajno ne. Preslikava dogodka naj ostane nerazrešena, zadnje podprto stanje pošiljke pa se ohrani. Svežino podatkov prikažite ločeno, da uporabniki potrjenega starega stanja ne zamenjajo za nedavno posodobitev.

Ali se lahko dostavljena pošiljka vrne v tranzit?

Starejše skeniranje v tranzitu ne bi smelo povzročiti te spremembe. Preverjen popravek jo lahko upraviči, medtem ko je treba na novo začeto povratno pot običajno predstaviti ločeno. Prehod potrebuje izrecen razlog, ne le poznejšega časa prejema.

Kako naj bodo predstavljene manjkajoče posodobitve sledenja?

Uporabite notranji kazalnik svežine ali opozorilo o neaktivnosti. Hranite ga ločeno od zamude, izgube ali statusov izjem, o katerih poroča prevoznik. Prag za stopnjevanje mora odražati vaše zaveze glede storitev in operativno politiko, ne pa univerzalne predpostavke.

Kdo mora odobriti spremembe preslikav?

Inženiring mora biti odgovoren za izvedbo in preizkušanje ponovitev; logistične operacije morajo potrditi pomen pošiljanja; lastnik uporabniške izkušnje pa mora odobriti posledice za sporočanje. Določite imenovanega odločevalca, da dvoumni dogodki ne ostanejo nerazrešeni za nedoločen čas.

Viri

• RFC 3339: Date and Time on the Internet: Timestamps — referenca za predstavitev časovnih žigov in številčnih odmikov.
• 17TRACK Tracking API — uradna vstopna točka za zgoraj obravnavano integracijo API-ja za sledenje.
• 17TRACK API documentation — izvedbena referenca za preverjanje pogodbe ponudnika; kanonični model in primeri preslikav v tem članku so predlagani oblikovalski vzorci, ne definicije, značilne za ponudnika.