Kuinka yhdistää lähetysten seuranta Australiassa ja Uudessa-Seelannissa yhden API:n avulla

Yhdistääksesi lähetysten seurannan Australiassa ja Uudessa-Seelannissa yhden API:n avulla yhdistä tilaus- tai toimitusjärjestelmäsi usean kuljetusyhtiön seurantapalveluun, rekisteröi jokainen lähetys oikealla kuljetusyhtiötunnisteella ja muunna saapuvat seurantapäivitykset yhdenmukaiseksi sisäiseksi tapahtumamalliksi. Integraation tulee säilyttää kuljetusyhtiökohtaiset tiedot ja tarjota samalla operatiiviselle tiimillesi ja asiakkaillesi yksi seurantakokemus kotimaan ja Tasmanianmeren ylittävissä toimituksissa.

Kehittäjille, verkkokauppatoimijoille ja logistiikkatiimeille suurin haaste ei ole ensimmäisen API-pyynnön tekeminen. Haasteena on pitää lähetysidentiteetit, toimitustilat, kuljetusyhtiöiden väliset siirrot ja asiakasviestit yhdenmukaisina, kun eri kuljetusyhtiöt kuvaavat samaa matkaa eri tavoin. Tässä oppaassa kerrotaan, kuinka integraatio suunnitellaan, seurantaa tarjoava API arvioidaan ja testataan ennen sen käyttöönottoa tuotannossa.

Määritä, mitä yhden API:n tulee yhdistää

Jaettu API tarjoaa sovelluksellesi yhteisen integraatiopisteen. Se ei saa jokaista kuljetusyhtiötä julkaisemaan täysin samanlaisia tietoja tai skannaamaan paketteja samalla tiheydellä. Arkkitehtuurisi on erotettava toisistaan yhdenmukainen käyttöliittymä ja täydellinen näkyvyys.

Aloita todelliseen toimitustoimintaan perustuvasta lähetysinventaariosta yleisen kummassakin maassa toimivien kuljetusyhtiöiden luettelon sijaan. Sisällytä Australian kotimaan lähetykset, Uuden-Seelannin kotimaan lähetykset sekä rajat ylittävät kuljetukset molempiin suuntiin. Lisää muut kansainväliset lähtömaat, jos ne kuuluvat liiketoimintaasi.

• Kuljetusyhtiö ja palvelu: Kirjaa kuljetusyhtiö, käytetty palvelu ja mahdollinen tunnettu toimituskumppani.
• Reitti: Erottele lähetyksen lähtö- ja määränpää sen viimeisimmän skannauksen sijainnista.
• Tunnisteet: Tallenna tilausviite, toimitusviite, seurantanumero sekä mahdollinen korvaava tai kumppanin numero.
• Operatiivinen tarkoitus: Määritä, tukevatko päivitykset asiakasseurantaa, poikkeamien hallintaa, toimituksen vahvistamista vai kaikkia näitä.
• Tarvittavat tiedot: Päätä, riittääkö yleinen toimitustila vai tarvitsevatko asiakaspalvelijat myös skannausten kuvaukset, sijainnit ja aikaleimat.

Tästä inventaariosta tulee hyväksymistarkistuslistasi. Palveluntarjoajan yleinen kuljetusyhtiöiden kattavuus on hyödyllinen esikarsinnassa, mutta päätöksen tulee perustua siihen, palauttavatko todelliset kuljetusyhtiö-palveluyhdistelmäsi käyttökelpoisia seurantatietoja.

Arvioi seuranta-API lähetysvalikoimasi perusteella

17TRACK tarjoaa Tracking API -rajapinnan, joten se on relevantti vaihtoehto usean kuljetusyhtiön integraation arviointiin. Tarkista ajantasaiset integraatiovaatimukset sen virallisista API-dokumenteista. Käsittele kuljetusyhtiöiden tuki, tapahtumakentät, päivitystoiminta, tilirajoitukset ja kaupalliset ehdot toteutuksesi tarkistettavina asioina, älä tuoteryhmän perusteella tehtyinä oletuksina.

Esitä kaikille harkitsemillesi API-rajapinnoille samat käytännön kysymykset:

• Voiko se tunnistaa ja seurata lähetysinventaariosi kuljetusyhtiöitä ja palveluita?
• Kun kuljetusyhtiön tunnistus on epäselvä, voitko antaa tarkan kuljetusyhtiötunnisteen?
• Kuinka sovelluksesi vastaanottaa päivitykset, ja mikä palautumismekanismi on käytettävissä, jos päivitys jää väliin?
• Mitkä alkuperäiset kuljetusyhtiön tiedot säilyvät normalisoitujen tilojen rinnalla?
• Mitä tapahtuu, kun seurantanumero on virheellinen, sitä ei ole vielä tunnistettu tai se liittyy useampaan mahdolliseen kuljetusyhtiöön?
• Kuinka käyttö, laskutus, seurannan kesto ja käyttöoikeusrajat määritellään tilillesi?

Suositeltu päätössääntö: valitse ratkaisu todellisten toimitusmalliesi onnistuneiden testien perusteella, älä suurimman ilmoitetun kuljetusyhtiömäärän perusteella. Integraatio soveltuu käyttöön, kun se tarjoaa riittävästi tietoa operatiivisten päätösten tueksi ja tuo virheet esiin riittävän selkeästi, jotta niistä voidaan palautua.

Rakenna kuljetusyhtiöiden erot kestävä sisäinen malli

Erota tilaukset, lähetykset ja seurantavaiheet

Älä käytä seurantanumeroa tilauksen ensisijaisena avaimena. Yksi tilaus voi sisältää useita paketteja, ja paketin matkaan voi liittyä useampi kuin yksi seurannassa käytettävä tunniste. Luo sen sijaan sisäinen lähetys-ID ja liitä seurantatiedot siihen.

Käytännöllisessä mallissa on kolme tasoa: asiakkaan tilaus, sen fyysiset lähetykset ja kuhunkin lähetykseen liittyvät seurantavaiheet. Kotimaan paketti voi tarvita vain yhden seurantavaiheen. Rajat ylittävä paketti voi vaatia linkitettyjä tietueita, kun toinen kuljetusyhtiö tai tunniste tulee merkitykselliseksi.

Määritä seurantatietue sekä kuljetusyhtiön että seurantanumeron perusteella ja säilytä sen yhteys lähetys-ID:hen. Jos uusi toimituskumppanin numero ilmestyy, lisää se liittyväksi tunnisteeksi sen sijaan, että korvaisit alkuperäisen. Näin säilytetään historia, jota asiakaspalvelijat tarvitsevat siirtoa tutkiessaan.

Säilytä raakatapahtuma ja normalisoitu tapahtuma

Käytä pientä sisäistä tilasanastoa, jonka perusteella yrityksesi voi toimia. Voit esimerkiksi määrittää tilat: ei vielä kuljetuksessa, kuljetuksessa, jakelussa, noudettavissa, toimitettu, poikkeama ja tuntematon. Nämä ovat ehdotettuja sisäisiä luokkia eivätkä väite tietyn palveluntarjoajan tilakaaviosta.

Tallenna alkuperäinen kuljetusyhtiön kuvaus kartoitetun tilan rinnalle. Noutopisteeseen liittyvä tapahtuma ja osoiteongelma voivat molemmat edellyttää asiakkaan toimia, mutta niiden ei tule tuottaa samaa viestiä. Vastaavasti osoitekortin luomisen ei tule automaattisesti merkitä sitä, että kuljetusyhtiö pitää pakettia fyysisesti hallussaan.

Dokumentoi kartoituspäätökset versioidussa määrityksessä. Kun uusi tapahtumakuvaus ilmestyy, siirrä se tarkistusjonoon, jos sen merkitys on epäselvä. Selkeä tuntematon tila on turvallisempi kuin väärän toimitustuloksen varma määrittäminen.

Erota tapahtuma-aika vastaanottoajasta

Tallenna tapahtuman tapahtuma-aika erillään siitä, milloin järjestelmäsi vastaanotti sen. Vanhempi skannaus voi saapua uudemman jälkeen, erityisesti kun päivitykset viivästyvät tai historialliset tapahtumat toimitetaan yhdessä.

Australiassa ja Uudessa-Seelannissa vältä yhden kiinteän aikaeron soveltamista kaikkiin lähetyksiin. Säilytä lähteen aikaleimat ja aikaerot, jos ne toimitetaan. Käytä näyttämiseen asianmukaista nimettyä aikavyöhykettä, kun sinulla on luotettava sijaintikonteksti, ja huomioi kesäaikojen erot. Jos lähteen aikavyöhyke puuttuu, säilytä tämä epävarmuus sen sijaan, että keksisit tarkan UTC-muunnoksen.

Toteuta luotettava tietojen vastaanottotyönkulku

1. Luo sisäinen lähetys ensin. Kirjaa sen yhteys tilaukseen, reitti, kuljetusyhtiövalinta ja seurannan tunniste ennen rekisteröintiä seurantapalveluun.
2. Lähetä seurannan rekisteröinti. Käytä palveluntarjoajan dokumentoitua pyyntömuotoa. Tallenna vastaus ja erota onnistunut rekisteröinti siitä, milloin kuljetusyhtiön tapahtumat tulevat myöhemmin saataville.
3. Luokittele virheet. Erota virheelliset syötteet ja tunnistautumisongelmat tilapäisistä palveluhäiriöistä. Yritä uudelleen vain silloin, kun siitä voi kohtuudella olla hyötyä.
4. Vastaanota tai hae päivitykset. Toteuta valitsemasi API:n tukema toimitusmekanismi. Jos käytät webhookeja, vahvista saapuvat pyynnöt palveluntarjoajan dokumentoidulla menetelmällä ja käsittele hyväksytyt tapahtumat kestävän jonon kautta.
5. Poista kaksoiskappaleet ennen muutosten soveltamista. Käytä palveluntarjoajan tapahtumatunnistetta, jos se on saatavilla, tai huolellisesti suunniteltua yhdistelmäavainta. Toistuva toimitus ei saa käynnistää toistuvia asiakasviestejä.
6. Laske lähetyksen tila uudelleen. Arvioi tapahtuman merkitys ja aikajärjestys sen sijaan, että korvaisit nykyisen tilan viimeksi saapuneella päivityksellä.
7. Sovita puutteelliset tietueet yhteen. Jos API tukee hakua, käytä sitä väliin jääneiden päivitysten tai vanhentuneiden tietueiden tutkimiseen sovellettavien käyttörajojen puitteissa.

Pidä palveluntarjoajakohtainen tunnistautuminen, kenttänimet ja virheenkäsittely adapterissa. Tilaustenhallintajärjestelmäsi tulee käyttää sisäistä lähetysmalliasi eikä riippua suoraan jokaisesta palveluntarjoajan vastauksen yksityiskohdasta. Tämä erottelu helpottaa myös myöhempien API-muutosten testaamista.

Käsittele Tasmanianmeren ylittävät matkat ilman perusteettomia oletuksia

Rajat ylittävä seuranta tarvitsee enemmän kontekstia kuin tilamerkintöjen sarjan. Sovelluksesi tulee erottaa vientitapahtuma, tulliin liittyvä tapahtuma, kuljetusyhtiön vaihdos ja loppujakelutapahtuma silloin, kun lähdetiedot mahdollistavat nämä erot.

Älä päättele tulliselvitystä yleisestä kuljetuksessa-skanauksesta. Vastaavasti viimeaikaisen skannauksen puuttuminen ei osoita, että tulli pitää pakettia hallussaan. Hyödyllinen asiakasviesti kertoo viimeisimmän vahvistetun tapahtuman ja sen ajan ja selittää sen jälkeen mahdolliset seuraavat toimet, joita tiimisi voi tosiasiassa tukea.

Pidä lähtö- ja määränpää erillään skannauksen sijainnista. Australiasta Uuteen-Seelantiin matkalla olevasta lähetyksestä ei tule Uuden-Seelannin kotimaan lähetystä vain siksi, että sille on kirjattu saapumisskannaus. Tämä ero on tärkeä reittiraportoinnin ja poikkeamien omistajuuden kannalta.

Jos toimituskumppani tulee mukaan, linkitä sen seurantatietue vain, kun yhteys perustuu lähetysdataan, seurantapalveluun tai operatiivisesti vahvistettuun tietueeseen. Älä yhdistä paketteja vain siksi, että tunnisteet näyttävät samanlaisilta.

Muunna seurantatapahtumat hyödyllisiksi asiakaspäivityksiksi

Asiakkaille näkyvän sivun tulee vastata neljään kysymykseen: mikä on viimeisin vahvistettu tila, milloin se tapahtui, missä se kirjattiin, jos tieto on saatavilla, ja tarvitseeko asiakkaan toimia?

Pidä ilmoitussäännöt erillään tapahtumien vastaanotosta. Kaikki skannaukset eivät ansaitse sähköpostia tai tekstiviestiä. Määritä merkitykselliset siirtymät, kuten ensimmäinen vahvistettu liike, toimitusyritys, noutovaatimus tai toimitettu-tapahtuma, ja estä saman siirtymän toistuvat ilmoitukset.

• Vanhentunut seuranta: Kerro, milloin viimeisin päivitys tapahtui, mutta älä käsittele hiljaisuutta todisteena katoamisesta.
• Toimitusarviot: Erota kuljetusyhtiön antama arvio kauppiaan lupauksesta. Älä keksi päivämäärää, jos kumpaakaan ei ole.
• Poikkeamat: Anna tunnetussa tilanteessa konkreettinen seuraava vaihe sen sijaan, että näyttäisit selittämättömän virhenimikkeen.
• Toimituskiistat: Säilytä lähdetapahtuma ja ohjaa tapaus tukeen; toimitettu-tila yksin ei ratkaise jokaista asiakasriitaa.

Suojaa seurantatietosivut API-tunnistetietojen tavoin. Vältä tarpeettomien osoite- tai yhteystietojen näyttämistä, pidä palvelutunnistetiedot palvelimella ja käytä näytettäviin tietoihin sopivia käyttöoikeusrajoituksia.

Suorita reittipohjainen pilotti ennen käyttöönottoa

Testaa Australian kotimaan, Uuden-Seelannin kotimaan, Australia–Uusi-Seelanti- ja Uusi-Seelanti–Australia-lähetyksiä, jos nämä reitit ovat liiketoimintasi kannalta merkityksellisiä. Sisällytä tavalliset toimitukset ja operatiiviset poikkeustapaukset: jaetut tilaukset, tunnistamattomat numerot, siirrot, toimitusyritykset, noutotapahtumat, palautukset ja myöhässä saapuvat skannaukset.

Käytä kuljetusyhtiöiden vahvistamiseen todellisia lähetysrekistereitä ja asianmukaisia käyttöoikeuksia. Käytä synteettisiä tapahtumia oman sovelluksesi häiriönsietokyvyn testaamiseen, mutta älä pidä synteettisiä tuloksia todisteena reaaliaikaisesta kuljetusyhtiöiden kattavuudesta.

• Identiteetin tarkistus: Jokainen päivitys saavuttaa oikean lähetyksen ja tilauksen.
• Aikajärjestyksen tarkistus: Epäjärjestyksessä saapuvat tapahtumat eivät virheellisesti peruuta toimituksen etenemistä.
• Palautumisen tarkistus: Tilapäiset virheet ja päällekkäiset päivitykset eivät hukkaa tietoja tai toista ilmoituksia.
• Tuen tarkistus: Asiakaspalvelijat voivat tarkastella alkuperäistä tapahtumaa ja ymmärtää asiakkaalle näkyvän tilan.
• Kaupallinen tarkistus: Odotettu käyttö sopii tilin vahvistettuun laskutusmalliin ja rajoihin.

Aseta hyväksymiskynnykset ennen pilotin arviointia. Mittaa rekisteröintien tulokset, kartoittamattomat tapahtumat, käsittelyviiveet, ilmoitusten kaksoiskappaleet ja ratkaisemattomat vanhentuneet lähetykset. Erota kuljetusyhtiön tietoviiveet oman sovelluksesi viiveistä, jotta korjaavat toimet kohdistuvat oikealle omistajalle.

Toteutus on valmis, kun tiimisi osaa selittää puutteellisen seurannan ja palautua siitä, ei vain näyttää onnistuneita toimituksia. Yksi API yksinkertaistaa yhteyksiä; lähetysmallisi, tapahtumasääntösi ja toimintamenettelysi tekevät yhteyksistä luotettavia.

UKK

Korvaako yksi seuranta-API kuljetusyhtiöiden toimitusintegraatiot?

Ei välttämättä. Seuranta, osoitekorttien luominen, noutojen varaaminen, hintojen laskenta ja tulliasiakirjat ovat erillisiä toimintoja. Varmista valitun tuotteen laajuus ja säilytä muut integraatiot siellä, missä toimitusprosessisi niitä tarvitsee.

Voinko rekisteröidä seurantanumeron ennen kuljetusyhtiön ensimmäistä skannausta?

Tarkista API:n rekisteröintisäännöt. Suunnittele sovelluksesi erottamaan hyväksytty seurannan rekisteröinti vahvistetusta fyysisestä liikkeestä. Tietuetta, jossa ei ole tapahtumia, ei tule näyttää automaattisesti kuljetuksessa olevana.

Tarjoaako yksi API reaaliaikaiset päivitykset jokaiselta kuljetusyhtiöltä?

Älä oleta niin. Päästä päähän ulottuva ajantasaisuus riippuu siitä, milloin kuljetusyhtiö julkaisee tiedot, milloin seurantapalvelu saa ne ja milloin sovelluksesi käsittelee ne. Vahvista päivitystoiminta käyttämiesi kuljetusyhtiö-palveluyhdistelmien osalta.

Mitä pitäisi tapahtua, kun seurantanumero muuttuu?

Säilytä alkuperäinen tunniste ja liitä vahvistettu korvaava tai kumppanin tunniste samaan sisäiseen lähetykseen. Säilytä molemmat historiat ja estä kaksoiskappaleiden luomasta ristiriitaisia ilmoituksia.

Soveltuuko 17TRACK tähän integraatioon?

Kyllä. Sen Tracking API soveltuu tässä kuvattuun usean kuljetusyhtiön integraatioon. Arvioi sitä Australian ja Uuden-Seelannin lähetysesimerkkien avulla ja vahvista kuljetusyhtiöiden tuki, tekninen toiminta ja tiliehdot virallisista API-resursseista ennen käyttöönottoa.

Lähteet

• 17TRACK Tracking API — tässä oppaassa käsitellyn API-vaihtoehdon virallinen tuoteresurssi.
• 17TRACK API documentation — virallinen tekninen viite pyyntömuotojen, integraatiovaatimusten ja tuetun toiminnan tarkistamiseen.