Kuljetusyhtiöiden seurantatilojen normalisointi: Kuinka kuljetusyhtiöiden tapahtumat yhdistetään yhdeksi tilamalliksi

Rahdinkuljettajan seurantatilan normalisointi tarkoittaa kuljettajakohtaisten skannauskoodien ja viestien kääntämistä yhdenmukaiseksi lähetysmalliksi samalla, kun alkuperäinen näyttöaineisto säilytetään. Luotettavan toteutuksen varmistamiseksi yhdistä jokainen tapahtuma kanoniseen tilaan ja syyhyn, ja laske sitten lähetyksen nykyinen tila tapahtuman ajankohdan, lähetyksen kontekstin ja yksiselitteisten siirtymäsääntöjen avulla. Älä käsittele uusinta vastaanotettua viestiä automaattisesti lähetyksen nykyisenä tilana.

Tämä opas on tarkoitettu kehittäjille, logistiikan operatiivisille tiimeille ja tuoteomistajille, jotka rakentavat seurantaa tilaustenhallintajärjestelmään, tukipaneeliin tai asiakasviestintäprosessiin. Alla oleva malli on ehdotettu toteutustapa, ei virallinen kuljetusyhtiöiden standardi eikä minkään seurantapalveluntarjoajan tilaluokituksen toisinto.

Erota kuljetusyhtiön tapahtuma lähetyksen tilasta

Seurantatapahtuma kuvaa jotakin lähetyksestä raportoitua: lähetysluonti on tehty, paketti on saapunut käsittelypaikkaan tai toimitusyritys on epäonnistunut. Lähetyksen tila on sovelluksesi tulkinta merkityksellisestä näyttöaineistosta tiettynä ajankohtana. Nämä käsitteet tulee tallentaa erikseen.

Pakettiin voi esimerkiksi liittyä toimitusyritystapahtuma, jota seuraa saapuminen käsittelypaikkaan. Saapuminen on hyödyllistä operatiivista historiaa, mutta se ei välttämättä tarkoita, että epäonnistunut toimitusyritys olisi ratkaistu. Vastaavasti toimitusvahvistuksen jälkeen saapuva viivästynyt skannaus ei saa automaattisesti siirtää pakettia takaisin kuljetukseen.

Käytännöllisessä arkkitehtuurissa on kolme kerrosta:

1. Raakatodisteet: alkuperäinen kuljetusyhtiön tai palveluntarjoajan hyötykuorma, mukaan lukien koodit, tekstit, aikaleimat ja tunnisteet.
2. Normalisoidut tapahtumat: tulkintasi kustakin yksittäisestä tapahtumasta versioidun yhdistämissäännön avulla.
3. Nykyinen lähetysprojektio: tapahtumahistoriasta valittu tila sekä aktiiviset ehdot ja asiakastoimet.

Tämän erottelun ansiosta voit korjata yhdistämisiä ja rakentaa lähetyksen tilat uudelleen hävittämättä alkuperäistä tietuetta.

Määritä tiivis tilamalli erillisillä ehdoilla

Yhden tilakentän ylläpito vaikeutuu, kun sen on kuvattava samanaikaisesti fyysistä liikkumista, tullikäsittelyä, toimitusongelmia ja palautuksia. Käytä pientä elinkaarimallia ja liitä siihen tarkemmat ehdot ja syyt.

Pidä ehdot, kuten CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE ja DELAY_REPORTED, ensisijaisen elinkaarikentän ulkopuolella. Lähetys voi pysyä tilassa IN_TRANSIT, vaikka osoiteongelma vaatisi huomiota. Älä merkitse tavanomaista tullikäsittelyä poikkeukseksi, ellei lähde ilmoita pidätyksestä, ongelmasta tai vaaditusta toimesta.

Esitä suunta erikseen esimerkiksi kentällä journey_type. Palautuksella voi olla omat kuljetuksessa- ja toimitettu-tilansa. Näin lähetyksen toimittamista takaisin lähettäjälle ei tulkita onnistuneeksi toimitukseksi ostajalle.

Muodosta tapahtumatietue ennen yhdistämissääntöjen kirjoittamista

Normalisoidun tietueen tulee sisältää riittävästi kontekstia yhdistämisen selittämiseen ja tuloksen toistamiseen. Hyödyllinen lähtökohtainen skeema sisältää:

• Tunnistetiedot: sisäinen lähetys-ID, kuljetusyhtiön tunniste, seurantanumero, lähde ja lähetysosuus.
• Alkuperäiset todisteet: raakatapahtumakoodi, raakakuvaus, lähteen tapahtuma-ID, jos se toimitetaan, sekä viittaus alkuperäiseen hyötykuormaan.
• Ajoitus: tapahtuman tapahtuma-aika, aikavyöhyketiedot, vastaanottoaika ja aikaleiman tarkkuus.
• Tulkinta: kanoninen tila, ehto, syykoodi, matkan tyyppi ja toiminnan vaatimus.
• Jäljitettävyys: yhdistämissäännön ID, yhdistämisen versio ja luottamusluokka.

Pidä tapahtuman tapahtuma-aika erillään ajasta, jolloin järjestelmäsi vastaanotti päivityksen. Iltapäivällä vastaanotettu webhook voi kuvata aamulla tehtyä skannausta. Kyselyvastaus voi myös sisältää useita historiallisia tapahtumia yhden uuden tapahtuman sijaan.

Käytä dokumentoitua aikaleimamuotoa, kuten RFC 3339, kun aika ja poikkeama tunnetaan. Jos lähde toimittaa paikallisen ajan ilman luotettavaa poikkeamaa, säilytä tämä rajoitus sen sijaan, että lisäisit virheellisen UTC-merkinnän. Tallenna vain päivämäärän sisältävät tapahtumat päivämäärämuotoisina todisteina sen sijaan, että keksisit tarkan skannausajan.

Tallenna raakahyötykuormat asianmukaisten käyttöoikeus- ja säilytyssääntöjen mukaisesti. Ne voivat sisältää vastaanottajan tietoja tai muita tietoja, jotka eivät kuulu laajasti saatavilla olevaan analytiikkataulukkoon.

Yhdistä kuljetusyhtiön koodit ensin ja käytä tekstiä varoen

Aloita tiettyyn lähteeseen ja kuljetusyhtiöön rajatuilla säännöillä. Koodilla 01 ei ole luotettavaa merkitystä dokumentoidun kontekstinsa ulkopuolella. Jos lähde erottaa palvelut, alueet tai lähetysosuudet, sisällytä nämä ulottuvuudet, kun ne vaikuttavat tulkintaan.

Käytä tätä yhdistämisjärjestystä toteutuksen oletuksena:

1. Yhdistä dokumentoitu rakenteinen tapahtumakoodi ja kaikki vaaditut tarkenteet.
2. Käytä dokumentoitua lähteen tilaa tai alitilaa, kun se kuvaa selkeästi käsiteltävää tapahtumaa.
3. Sovella tarkasti rajattuja tekstisääntöjä tunnettuihin viesteihin, joista puuttuvat riittävät rakenteiset kentät.
4. Jätä ratkaisemattomat tapahtumat yhdistämättä ja lähetä toistuvat tapaukset tarkistettaviksi.

Selvitä ensin, kuvaako palveluntarjoajan tilakenttä yksittäistä tapahtumaa vai lähetyksen nykyistä yhteenvetoa. Lähetyskohtaisen yhteenvedon kopioiminen jokaiseen historialliseen tapahtumaan voi saada aiemmat skannaukset näyttämään toimitusvahvistuksilta.

Vältä yleisiä avainsanasääntöjä, kuten ”sisältää sanan delivered”. Ilmaus ”not delivered” täsmäisi myös, samoin viesti, joka kuvaa toimitusta logistiikkakumppanille. Tekstisäännöt tarvitsevat kieltolauseiden käsittelyä, kielikontekstin ja poissulkemiset. Konekäännös voi auttaa tarkistajaa ymmärtämään viestin, mutta käännetystä sanamuodosta ei saa huomaamatta tulla arvovaltaista tapahtuman määritelmää.

Esimerkkitapaukset ja niiden rajoitukset

Alla olevissa esimerkeissä käytetään keksittyjä viestejä sääntöjen suunnittelun havainnollistamiseksi. Ne eivät ole varmennettuja kuljetusyhtiöiden koodeja tai tietyn kuljetusyhtiön täsmällisiä viestejä.

• ”Shipment details submitted”: yhdistä tilaan PRE_TRANSIT, kun lähteen määritelmä osoittaa kyseessä olevan vain sähköiset tiedot.
• ”Accepted at origin facility”: yhdistä tilaan IN_TRANSIT, kun tapahtuma vahvistaa fyysisen vastaanoton.
• ”Recipient unavailable; attempt unsuccessful”: tallenna DELIVERY_ATTEMPT_FAILED ja arvioi elinkaari ympäröivän näyttöaineiston perusteella. Älä päättele, että nouto olisi mahdollista.
• ”Available for collection”: yhdistä tilaan READY_FOR_PICKUP, kun lähde vahvistaa vastaanottajan noudettavuuden.
• ”Transferred to delivery partner”: tallenna luovutus ja säilytä asianmukainen kuljetustila sen sijaan, että merkitset toimituksen vastaanottajalle valmiiksi.

Jokaisella säännöllä tulee olla lyhyt perustelu ja omistaja. Kun operatiivinen asiantuntija kiistää yhdistämisen, tiimin tulee pystyä tunnistamaan täsmällinen sääntö sen sijaan, että asiakasnäytössä näkyvä nimike joudutaan selvittämään jälkikäteen.

Laske nykyinen tila deterministisellä vähentäjällä

Vähentäjä on funktio, joka arvioi normalisoidut tapahtumat ja tuottaa nykyisen lähetysprojektion. Sen tulee palauttaa sama tulos samalle näyttöaineistolle ja sääntöversiolle riippumatta siitä, kuinka monta kertaa syöte toistetaan.

Poista kaksoiskappaleet merkityksellisiä skannauksia poistamatta

Suosi vakaata lähteen tapahtumatunnistetta, jos sellainen on olemassa. Muussa tapauksessa muodosta kaksoiskappaleiden poistamiseen avain käytettävissä olevista ominaisuuksista, kuten lähetyksen tunnistetiedoista, kuljetusyhtiöstä, koodista, tapahtuma-ajasta ja sijainnista. Ota huomioon aikaleiman tarkkuus ja lähteen toimintatapa. Kahdella kuvaukseltaan identtisellä skannauksella ei välttämättä ole kyse kaksoiskappaleista, etenkin jos paketti käy samassa käsittelypaikassa uudelleen.

Järjestä tapahtumat olettamatta täydellisiä kelloja

Käytä luotettavia tapahtuma-aikoja ja saatavilla olevia dokumentoituja järjestystietoja. Vastaanottoaika voi auttaa tasatilanteiden ratkaisemisessa, mutta sen ei pitäisi rutiininomaisesti ohittaa aiempaa tapahtuma-aikaa. Jos aikaleimat ovat ristiriidassa tai niitä ei voida luotettavasti verrata, säilytä epäselvyys sen sijaan, että loisit varmuuden keinotekoisesti.

Vahvista siirtymät yleisen järjestysluvun määrittämisen sijaan

Yksinkertainen tilojen numeerinen järjestys ei voi kuvata kaikkia lähetyksen kulkuja. Paketti voi siirtyä toimitukseen lähteneestä takaisin kuljetukseen epäonnistuneen yrityksen jälkeen. Noudettavuus voi vanhentua. Nimenomainen korjaus voi mitätöidä toimitusvahvistuksen.

Määritä sallitut siirtymät ja niiden edellyttämä näyttöaineisto. Suojaa delivered tavallisilta vanhemmilta skannauksilta, mutta salli dokumentoitu korjaus tai valtuutettu operatiivinen ohitus. Kirjaa jokaisen ohituksen syy ja lähde.

Seuraa aktiivisia ehtoja itsenäisesti

Myöhempi liikkumisskannaus voi osoittaa edistymistä todistamatta, että maksu- tai osoiteongelma on ratkaistu. Määritä ehtokohtaiset poistamissäännöt: nimenomainen ratkaisu, loogisesti ratkaiseva tapahtuma tai valtuutettu manuaalinen toimi. Älä poista jokaista ehtoa vain siksi, että uusi tapahtuma saapui.

Erota myös kuljetusyhtiön ilmoittama viivästys omasta toimettomuushälytyksestäsi. Uusien skannausten puuttuminen on havainto tietojen tuoreudesta, ei todiste paketin katoamisesta.

Käsittele kuljetusyhtiöiden väliset luovutukset ja palautukset linkitettyinä matkoina

Kansainväliseen seurantaan voi liittyä useita kuljetusyhtiöitä ja tunnisteita. Säilytä sisäinen lähetysidentiteetti ja liitä kuljetusyhtiökohtaiset seuranta-viitteet asiaankuuluviin lähetysosuuksiin. Linkitä viitteet lähteen toimittamien suhteiden tai varmennettujen operatiivisten tietojen perusteella, älä pelkästään samankaltaisten määränpäiden tai läheisten aikaleimojen perusteella.

Lähetysosuuden toimitustapahtuma tulee tulkita asiayhteydessään. Toimitus yhdistelykeskukseen tai kumppaniverkostoon voi päättää kyseisen lähetysosuuden saattamatta ostajan toimitusta päätökseen. Lähetysprojektion tulee tietää, mitä määränpäätä tapahtuma koskee.

Erottele samalla ”return requested”, ”return movement started” ja ”returned to sender”. Ne kuvaavat eri virstanpylväitä. Palautuspyyntö ei todista, että paketti liikkuu fyysisesti takaisin, ja käänteisen matkan toimitusvahvistuksen tulee yksilöidä palautuksen määränpää.

Käytä seuranta-APIa luopumatta liiketoimintasäännöistäsi

Monen kuljetusyhtiön integraatio voi tarjota yhteisen sisäänotopisteen, mutta jaettu vastausmuoto ei poista selkeän sisäisen sopimuksen tarvetta. Kun arvioit 17TRACK Tracking API -rajapintaa, tarkista toteutuksesi kannalta merkityksellisten kenttien ja rajapintojen merkitys sen virallisesta dokumentaatiosta. Älä oleta, että tämän oppaan ehdotetut tilat vastaavat sen omaa luokitusta.

Ennen kuin yhdistät minkään API:n asiakasilmoituksiin tai operatiiviseen automaatioon, määritä:

• Mitkä kentät kuvaavat yksittäisiä tapahtumia ja mitkä lähetyksen nykyistä yhteenvetoa.
• Mitkä alkuperäiset kuljetusyhtiön tiedot ovat saatavilla ja voidaan säilyttää.
• Miten aikaleimat, puuttuvat arvot, korjaukset ja toistuvat päivitykset esitetään.
• Miten palautusmatkat ja toimitukset välikumppaneille voidaan erottaa.
• Miten integraatiosi reagoi tuntemattomiin koodeihin tai tuleviin skeemamuutoksiin.

Pidä ulkoisen vastauksen ja kanonisen mallisi välissä ohut sovitin. Näin muu sovelluksesi voi käyttää yhtä seurantatilasopimusta ilman riippuvuutta jokaisesta ylävirran kentänimestä. Käsittele ilmoitussääntöjä toisena kerroksena: uusi normalisoitu tapahtuma ei saa automaattisesti käynnistää asiakasviestiä.

Testaa tapahtumahistorioita, älä vain yksittäisiä yhdistämisiä

Yhdistäminen voi olla erikseen tarkasteltuna oikein ja silti tuottaa väärän lähetyksen tilan. Testaa kokonaisia historioita, mukaan lukien päivitykset, jotka toimitetaan eri järjestyksessä kuin niiden tapahtuma-ajat.

• Viivästynyt historia: toimitusvahvistus saapuu ennen vanhempaa kuljetusskannausta. Lähetys pysyy toimitettuna.
• Toistuva sisäänotto: sama tapahtuma käsitellään uudelleen. Päällekkäistä asiakasilmoitusta ei lähetetä.
• Epäonnistunut yritys: epäonnistunut yritys seuraa toimitukseen lähtöä. Projektio ei enää lupaa aktiivista toimituskierrosta ilman sitä tukevaa näyttöaineistoa.
• Noudettavuus: paketti saapuu noutopaikkaan ennen kuin sen saatavuus on vahvistettu. Ennenaikaista nouto-ohjetta ei anneta.
• Tuntematon tapahtuma: uusi koodi ilmestyy. Raakatietue säilytetään, eikä aiemmin vahvistettua lähetyksen tilaa korvata automaattisesti tuntemattomalla.
• Palautusmatka: käänteinen matka päättyy lähettäjälle. Alkuperäistä toimitusta ostajalle ei merkitä onnistuneeksi.
• Korjaus: nimenomainen lähteen korjaus muuttaa lopputulosta auditoitavan siirtymän kautta.

Seuraa yhdistämättä jääneitä tapahtumia, tekstipalautuksen käyttöä, virheellisiä siirtymiä ja päällekkäisiä ilmoitusyrityksiä kuljetusyhtiön ja lähteen mukaan. Erota yhdistämisen kattavuus yhdistämisen oikeellisuudesta: jokaisen koodin tunnistaminen ei ole hyödyllistä, jos sen tulkinta on väärä.

Toista edustavat historiat ennen yhdistämismuutoksen käyttöönottoa ja vertaa vanhoja ja uusia projektioita. Tarkista erot, jotka vaikuttavat toimitusvahvistukseen, nouto-ohjeisiin, palautuksen valmistumiseen tai asiakkaan toimintaan. Versioi säännöt, jotta tukihenkilö voi selittää, miksi järjestelmä tuotti tietyn tuloksen.

UKK

Pitäisikö jokaisella seurantatapahtumalla olla täsmälleen yksi tila?

Jokaisella tapahtumalla voi olla yksi ensisijainen normalisoitu tulkinta, mutta se voi tarvita myös ehdon, syyn ja matkan kontekstin. Kaiken merkityksen pakottaminen yhteen litteään tilaluetteloon tekee mallista vaikeamman käyttää ja ylläpitää.

Pitäisikö tuntemattoman tapahtuman korvata nykyinen lähetyksen tila?

Yleensä ei. Pidä tapahtuman yhdistäminen ratkaisemattomana ja säilytä samalla viimeisin tuettu lähetyksen tila. Näytä tietojen tuoreus erikseen, jotta käyttäjät eivät sekoita vanhaa vahvistettua tilaa uuteen päivitykseen.

Voiko toimitettu lähetys siirtyä takaisin kuljetukseen?

Vanhemman kuljetusskannauksen ei pitäisi aiheuttaa tätä muutosta. Varmennettu korjaus voi oikeuttaa siihen, kun taas juuri alkanut palautusmatka tulisi yleensä esittää erikseen. Siirtymä tarvitsee yksiselitteisen syyn, ei vain myöhempää vastaanottoaikaa.

Miten puuttuvat seurantapäivitykset tulisi esittää?

Käytä sisäistä tuoreusilmaisinta tai toimettomuushälytystä. Pidä se erillään kuljetusyhtiön ilmoittamasta viivästyksestä, katoamisesta tai poikkeustiloista. Mahdollisen eskalointikynnyksen tulee perustua palvelulupauksiisi ja toimintaperiaatteisiisi, ei yleiseen oletukseen.

Kenen tulisi hyväksyä yhdistämismuutokset?

Tekniikan tulisi vastata toteutuksesta ja toistotestauksesta; logistiikan operatiivisen tiimin tulisi vahvistaa toimituksiin liittyvä merkitys; ja asiakaskokemuksesta vastaavan omistajan tulisi hyväksyä viestinnälliset seuraukset. Nimeä päätöksestä vastaava henkilö, jotta epäselvät tapahtumat eivät jää ratkaisematta määräämättömäksi ajaksi.

Lähteet

• RFC 3339: Date and Time on the Internet: Timestamps — viite aikaleimojen ja numeeristen poikkeamien esittämiseen.
• 17TRACK Tracking API — edellä käsitellyn seuranta-API-integraation virallinen aloituspiste.
• 17TRACK API documentation — toteutusviite palveluntarjoajan sopimuksen tarkistamiseen; tämän artikkelin kanoninen malli ja yhdistämisesimerkit ovat ehdotettuja suunnittelumalleja, eivät palveluntarjoajakohtaisia määritelmiä.