Kuinka seurata lähetyksiä Kiinasta Eurooppaan ja Yhdysvaltoihin yhdellä API:lla

Voit seurata lähetyksiä Kiinasta Eurooppaan ja Yhdysvaltoihin yhdellä API-rajapinnalla yhdistämällä tilausjärjestelmäsi usean kuljetusliikkeen seurantapalveluun, rekisteröimällä jokaisen paketin seurantatunnuksella ja tarvittavilla kuljetusliikkeen tiedoilla sekä tuomalla seurantapäivitykset yhteiseen lähetystietueeseen. Integraatiossa on otettava huomioon kansainväliset luovutukset, viivästyneet skannaukset ja erilliset viimeisen toimitusvaiheen seurantatunnukset. Yksi API voi keskittää pääsyn seurantatietoihin, mutta se ei voi luoda tapahtumia, joista kuljetusliike ei ole ilmoittanut.

Kehittäjille ja verkkokauppojen operatiivisille tiimeille tavoitteena ei ole vain näyttää tilaa. Tavoitteena on yhdistää jokainen fyysinen paketti oikeaan tilaukseen, pitää asiakkaat ajan tasalla lähettämättä harhaanjohtavia päivityksiä ja tunnistaa lähetykset, jotka vaativat toimenpiteitä. Tässä oppaassa selitetään, kuinka tämä työnkulku rakennetaan ja kuinka palvelua, kuten 17TRACK Tracking API -rajapintaa, arvioidaan todellisten toimitusreittiesi perusteella.

Aloita toimitusreitistä, älä pelkästään kohdemaasta

Kiinasta eurooppalaiseen tai yhdysvaltalaiseen osoitteeseen kulkeva paketti voi kulkea keräilypalvelun, kansainvälisen kuljetusverkoston, tullikäsittelyn ja kohdetoimituksen kuljetusliikkeen kautta. Jotkin toimituspalvelut näyttävät nämä vaiheet yhdellä seurantatunnuksella. Toiset antavat myöhemmin matkan aikana erillisen toimitusviitteen.

Siksi maakohtainen kattavuus ei riitä seuranta-integraation vahvistamiseen. Palveluntarjoaja voi tunnistaa kuljetusliikkeen mutta olla palauttamatta kaikkia tietyn toimitustuotteen tarvitsemia tapahtumia. Vastaavasti lähtömaan skannaus ei takaa, että kohdemaan toimitusskannaukset ovat saatavilla.

Ennen integrointia laadi reittiluettelo käyttämällä lähetyksiä, joita yrityksesi todella lähettää. Kirjaa alkuperäinen logistiikkapalveluntarjoaja, toimituspalvelu, kohdemarkkina, tunnettu toimituksen kuljetusliike ja seurantatunnusten muodot. Käsittele Euroopan markkinoita testauksen aikana erikseen sen sijaan, että olettaisit yhdessä maassa onnistuneen toimituksen todistavan kattavuuden koko alueella.

• Operatiivisille tiimeille: tunnista, missä seurantapuutteet aiheuttavat tällä hetkellä manuaalista työtä tai asiakasyhteydenottoja.
• Tekniikalle: tunnista, mitkä järjestelmät luovat lähetyksiä ja mitkä järjestelmät tarvitsevat päivityksiä.
• Hankinnalle: varmista, että reittiluetteloon kuuluvat tietyt kuljetusliikkeet ja palvelut ovat tuettuja.

Mitä yhden seuranta-API:n pitäisi tehdä – ja mitä se ei voi tehdä

Usean kuljetusliikkeen Tracking API tarjoaa sovelluksellesi yhteisen integraatiokerroksen sen sijaan, että sen pitäisi käsitellä jokainen kuljetusliikeyhteys erikseen. Palvelusta ja integrointitavasta riippuen sovelluksesi voi hakea päivityksiä, vastaanottaa takaisinsoittoja tai käyttää näiden yhdistelmää. Vahvista tuetut mekanismit palveluntarjoajan dokumentaatiosta ennen tuotantotyönkulun suunnittelua.

Hyödyllinen abstraktio on yhdenmukainen lähetysmalli. Tilaustenhallintajärjestelmäsi ei tarvitse erilaista liiketoimintalogiikkaa jokaisen kuljetusliikkeen sanamuotoja varten, vaikka sen tulisi säilyttää alkuperäiset tiedot tukea ja selvityksiä varten.

Keskitetty seuranta ei takaa jatkuvaa fyysistä näkyvyyttä, toimitusarviota tai täydellistä tullihistoriaa. API-yhteys voi toimia moitteettomasti, vaikka kuljetusliikkeellä ei olisi ilmoitettavana uutta skannausta. Seuranta on myös erillinen asia kuin toimitustarrojen ostaminen, tulliselvitysten valmistelu ja toimituspalvelujen järjestäminen. Älä oleta, että nämä toiminnot sisältyvät palveluun.

Rakenna integraatio pakettitason tietueen ympärille

1. Erota tilaukset, lähetykset ja seurantatunnisteet

Yksi verkkokauppatilaus voi sisältää useita paketteja, ja paketit voivat saapua eri aikoina. Käytä sisäistä paketti- tai lähetys-ID:tä pysyvänä tunnisteena. Liitä asiakkaan tilaus tähän tietueeseen ja yhdistä sitten kuljetusliikkeen seurantatunnisteet siihen.

Käytännöllisen sisäisen mallin tulisi sisältää:

• Sisäinen tilaus-ID ja paketti-ID.
• Alkuperäinen seurantatunnus ja API:n käyttämä kuljetusliikkeen tunniste.
• Vahvistettu kohdetoimituksen kuljetusliikkeen seurantatunnus.
• Toimituspalvelu ja kohdemaa.
• Nykyinen normalisoitu tila ja kuljetusliikkeen alkuperäinen kuvaus.
• Tapahtuma-aika, tapahtumapaikka silloin kun se toimitetaan, sekä aika, jolloin järjestelmäsi vastaanotti päivityksen.
• Rekisteröinnin tila, viimeisin onnistunut synkronointi ja ratkaisemattomat integraatiovirheet.

Nämä ovat suositeltuja sovelluskenttiä, eivät väite siitä, että jokainen palveluntarjoaja palauttaisi ne. Pidä sisäinen skeemasi erillään palveluntarjoajan vastausmuodosta, jotta tuleva API-muutos ei edellytä tilaustietokannan uudelleensuunnittelua.

2. Rekisteröi paketit luotettavan liiketoimintatapahtuman perusteella

Rekisteröi seuranta, kun paketille on määritetty kelvollinen numero, älä aina kun joku avaa tilaussivun. Varastolta tai tilausjärjestelmästä tuleva lähetyksen luontitapahtuma on yleensä parempi käynnistin. Jos tarra mitätöidään tai vaihdetaan, päivitä paketin tunnisteiden väliset suhteet sen sijaan, että jättäisit hylätyn numeron ainoaksi seurantaviitteeksi.

Varmista, että numero on olemassa eikä taulukkolaskentaohjelman muotoilu ole vahingoittanut sitä. Säilytä merkitykselliset etunollat. Kun toimitusjärjestelmäsi tuntee kuljetusliikkeen, säilytä tämä tieto sen sijaan, että luottaisit täysin automaattiseen tunnistukseen: numeromuodot voivat olla päällekkäisiä.

Lue rekisteröintivastaus yksittäisen lähetyksen tasolla. Onnistunut HTTP-pyyntö ei välttämättä tarkoita, että jokainen erän kohde hyväksyttiin. Tallenna epäonnistumiset uudelleenyritysjonoon ja tarjoa operatiiviselle tiimille tapa ratkaista virheelliset tai epäselvät lähetykset.

3. Suunnittele päivitysten toimitus ennen asiakasilmoitusten yhdistämistä

Jos valittu palvelu tukee webhookeja, käytä sen dokumentoitua takaisinsoittomekanismia päivitysten vastaanottamiseen. Vahvista käytettävissä oleva todennus- tai allekirjoitusmenetelmä sen sijaan, että keksisit vahvistusotsakkeen itse. Säilytä tunnistetiedot palvelimella, edellytä HTTPS-yhteyttä ja vältä API-avainten sisällyttämistä selainkoodiin tai asiakkaille näkyviin linkkeihin.

Vastaanottajan tulee hyväksyä päivitys pysyvästi ennen sen kuittaamista ja käsitellä se sitten asynkronisesti. Varaudu päällekkäisiin toimituksiin ja väärässä järjestyksessä saapuviin tapahtumiin. Käytä palveluntarjoajan tapahtuma-ID:tä, jos se on saatavilla; muussa tapauksessa määritä dokumentoitu deduplikointisääntö pysyvien tapahtuma-attribuuttien avulla.

Jos kysely on tarpeen, ajoita se palveluntarjoajan dokumentoitujen rajojen ja operatiivisten tarpeidesi mukaisesti. Hidasta pyyntötahtia nopeusrajoitusvastausten jälkeen, vältä samanaikaisia uudelleenyrityspiikkejä ja lopeta tarpeettomat tarkistukset valmiiksi toimitettujen lähetysten osalta säilytys- ja täsmäytyskäytäntösi mukaisesti. Ajastettu täsmäytystyö voi myös auttaa havaitsemaan puuttuvia päivityksiä silloin, kun palvelu sallii tietojen haun.

4. Normalisoi tilat merkitystä menettämättä

Käytä pientä joukkoa sisäisiä tiloja, jotka tilausjärjestelmäsi ja tukitiimisi voivat tulkita yhdenmukaisesti. Esimerkkejä ovat tiedot vastaanotettu, kuljetuksessa, toimitettavana, toimitettu, toimituspoikkeus ja palautettu. Nämä ovat ehdotettuja sovellusluokkia, eivät kuvaus minkään palveluntarjoajan tarkoista tilakoodeista.

Säilytä kuljetusliikkeen yksityiskohtainen tapahtuma normalisoidun tilan rinnalla. Epäonnistunut toimitusyritys, osoiteongelma ja tulliin liittyvä viivästys voivat kaikki vaatia huomiota, mutta ne eivät edellytä samaa vastausta. Kaiken yhdistäminen yleiseksi poikkeukseksi helpottaisi tietojen tallentamista mutta vähentäisi niiden käyttökelpoisuutta toimenpiteissä.

Älä tulkitse tarran luomista fyysiseksi noudoksi. Älä myöskään merkitse pakettia tulliselvitettynä vain siksi, että tapahtumassa mainitaan tullilaitos. Käytä ilmaisua, joka vastaa tapahtuman todellista merkitystä.

Käsittele kansainväliset luovutukset nimenomaisesti

Tärkein integraatiotesti on usein siirtymä lähtöverkon ja kohdetoimituksen välillä. Säilytä sekä alkuperäinen viite että kaikki vahvistetut viimeisen toimitusvaiheen viitteet. Uudesta seurantatunnuksesta tulee samaan pakettiin kuuluva toinen tunniste, ei automaattisesti toinen lähetys.

Yhdistä tunnisteet toisiinsa vain, kun luotettava lähde, kuten logistiikkapalveluntarjoaja, seurantavastaus tai toimitusjärjestelmäsi, vahvistaa suhteen. Samankaltaiset tapahtuma-ajat tai vastaavat kohdemaat eivät riitä osoittamaan, että kaksi numeroa kuuluvat samaan pakettiin.

Pidä tapahtuma-aika erillään tietojen vastaanottoajasta. Vanhempi tapahtuma voi saapua järjestelmääsi uudemman jälkeen, erityisesti kun tiedot siirtyvät verkkojen välillä. Säilytä toimitetut aikavyöhykkeiden poikkeamat, normalisoi aikaleimat käsittelyä varten ja säilytä epäselvät lähdearvot sen sijaan, että määrittäisit tukemattoman aikavyöhykkeen.

Näytä asiakkaille viimeisin merkityksellinen tila ja näkyvä päivitysaika. Jos kohdetoimituksen kuljetusliike ei ole vielä ilmoittanut skannausta, kerro, että seuranta odottaa uutta päivitystä. Älä päättele, että paketti on kadonnut, edelleen fyysisesti viimeisimmässä skannauspaikassa tai jo kohdemaassa.

17TRACKin rooli tässä työnkulussa

17TRACKin Tracking API -tarjonta on merkityksellinen, kun sovelluksesi tarvitsee usean kuljetusliikkeen seurantaintegraation. Sen virallisen API-dokumentaation tulee ohjata todennuksen, rekisteröinnin, vastausten käsittelyn ja tuettujen päivitystyönkulkujen toteutusta. Käytä dokumentoitua API-sopimusta sen sijaan, että käsittelisit kuluttajille tarkoitettua seurantaa integroitavana käyttöliittymänä.

Arvioi sitä samojen operatiivisten vaatimusten perusteella, joita soveltaisit omaan toteutukseesi: kuljetusliikkeen oikea tunnistaminen, hyödylliset tapahtumat reiteilläsi, luovutusten jatkuvuus, virheistä palautuminen ja hallittava päivitysten toimitus. Vahvista kaupalliset ehdot, käytön laskenta, pyyntörajoitukset ja mahdolliset tilin määritykset ennen tuotantosuunnitelmaan sitoutumista.

Vahvin syy valita keskitetty API on todellisuudessa käyttämiesi reittien integroinnin pienempi monimutkaisuus. Tämä hyöty on silti vahvistettava edustavilla paketeilla. Palveluntarjoajaa ei pidä valita yksinomaan siksi, että sen yleinen kattavuuskuvaus kuulostaa laajalta.

Suorita reittipohjainen pilotti ennen käyttöönottoa

Käytä testijoukkoa, joka sisältää sekä normaalit toimitukset että haastavat tapaukset. Historialliset lähetykset auttavat testaamaan tilojen yhdistämistä, kun taas reaaliaikaiset lähetykset paljastavat päivitysten toimituksen ja operatiivisen ajoituksen. Kumpikaan testi ei yksin vastaa kaikkiin kysymyksiin.

• Toimitus Kiinasta Yhdysvaltoihin: varmista lähtömaan tapahtumat, mahdollinen kansainvälinen luovutus ja lopullinen toimitustapahtuma.
• Toimitukset Kiinasta Eurooppaan: testaa kohdemaat ja toimituspalvelut, joita todella käytät.
• Uusi tarra: varmista, ettei pakettia, jota ei ole fyysisesti skannattu, esitetä kuljetuksessa olevana.
• Muuttunut toimitusviite: varmista, että suhde pysyy liitettynä oikeaan pakettiin.
• Toimituspoikkeus: tarkista, että yksityiskohtainen syy saavuttaa asianmukaisen operatiivisen jonon.
• Jaettu tilaus: varmista, ettei yhden paketin toimitus sulje koko tilausta.
• Päällekkäinen tai viivästynyt päivitys: varmista, ettei se luo toistuvia viestejä tai korvaa uudempaa tilaa virheellisesti.
• Väliaikainen integraatiohäiriö: varmista uudelleenyritykset, täsmäytys ja tuen näkyvyys.

Määritä hyväksymiskriteerit ennen tulosten tarkastelua. Mittaa rekisteröinnin onnistumista, virheellisiä kuljetusliikemäärityksiä, puuttuvia virstanpylväitä, päivitysten käsittelyviiveitä ja päällekkäisiä asiakasviestejä. Määritä yrityksellesi hyväksyttävät raja-arvot sen sijaan, että lainaisit tukematonta yleistä vertailuarvoa. Selvitä puuttunut tapahtuma kuljetusliikkeen omasta tietueesta ennen kuin yhdistät puutteen API:in.

Valvo tietojen tuoreutta erillään API:n saatavuudesta

API-valvonnan tulee vastata kahteen eri kysymykseen: toimiiko integraatio ja ovatko lähetyksen tiedot hyödyllisiä? Onnistuneet pyynnöt vastaavat vain ensimmäiseen kysymykseen. Sinun on myös tiedettävä, kasaantuuko rekisteröinneissä virheitä, epäonnistuvatko takaisinsoitot tai onko jokin reitti lakannut tuottamasta odotettuja virstanpylväitä.

• Integraation tila: todennusvirheet, pyyntövirheet, nopeusrajoitusvastaukset, takaisinsoittojen epäonnistumiset ja jonojen ruuhkautuminen.
• Tietojen laatu: tuntemattomat tilat, virheelliset aikaleimat, ratkaisemattomat kuljetusliikkeiden tunnisteet ja odottamattomat tunnisteiden muutokset.
• Lähetyksen tuoreus: aika viimeisimmästä kuljetusliikkeen tapahtumasta reitin ja toimituspalvelun mukaan jaoteltuna.
• Liiketoimintavaikutus: poikkeusten käsittelymäärä, epäonnistuneet ilmoitukset ja virheellisesti valmiiksi merkityt tilaukset.

Pitkä skannaustauko voi olla normaali yhdellä toimituspalvelulla ja poikkeuksellinen toisella. Käytä reittikohtaisia odotuksia ja havaittua lähetysten historiaa selvitysten priorisointiin. Pidä integraatiovirhehälytys erillään lähetysviivehälytyksestä, jotta oikea tiimi saa sen.

Asiakasilmoitusten tulee perustua vahvistettuihin virstanpylväisiin, ei jokaiseen raakatapahtumaan. Estä päällekkäisyydet, erota toimitusyritys onnistuneesta toimituksesta ja vältä lupaamasta saapumispäiviä, joita taustalla olevat tiedot eivät tue. Rajoita seurantatietojen käyttöoikeuksia ja säilytä henkilötietoja vain silloin, kun työnkulkusi niitä edellyttää.

UKK

Voiko yksi API seurata sekä kiinalaista lähtömaan kuljetusliikettä että kohdetoimituksen kuljetusliikettä?

Usean kuljetusliikkeen palvelu voi yhdistää matkan molempien osien tapahtumat, kun asiaankuuluvat palvelut ja tunnisteiden väliset suhteet ovat tuettuja. Vahvista koko reitti todellisilla paketeilla. Lähtömaan seurantatunnuksen tunnistaminen yksin ei osoita, että kohdetoimituksen tiedot ovat saatavilla.

Miksi seuranta lakkaa päivittymästä, kun paketti lähtee Kiinasta?

Mahdollisia syitä ovat fyysisten skannausten välinen aukko, viivästynyt raportointi tai luovutus toiselle toimitusviitteelle. Tarkista raakatapahtumat ja mahdollinen toimitettu viimeisen toimitusvaiheen numero ja vertaa niitä asiaankuuluvan kuljetusliikkeen tietueeseen. Seuranta-aukko ei yksin osoita, että paketti on kadonnut tai tullin hallussa.

Pitäisikö sovelluksen käyttää webhookeja vai kyselyä?

Käytä palveluntarjoajasi dokumentoimia mekanismeja. Tuettuina webhookit voivat vähentää toistuvia tarkistuksia, kun taas sallitut hakupyynnöt voivat tukea täsmäytystä. Kummassakin mallissa toteuta päällekkäisten tapahtumien käsittely, uudelleenyritysten hallinta ja valvonta ennen kuin luotat päivityksiin asiakasviestinnässä.

Voiko seuranta-API taata toimituspäivän tai tulliselvityksen?

Seurantatiedot eivät takaa kumpaakaan. Jos arvioitu toimituspäivä ilmoitetaan, säilytä sen lähde ja esitä se arviona. Tulliin liittyvät skannaukset tulee kuvata niiden todellisen sanamuodon mukaisesti, eikä niitä pidä tulkita tulliselvitykseksi, ellei tapahtuma nimenomaisesti ilmaise tätä lopputulosta.

Mitä tulisi vahvistaa ennen API-paketin valitsemista?

Vahvista kuljetusliikkeesi ja toimituspalvelusi, rekisteröintivaatimukset, päivitysmenetelmät, käytön laskenta, pyyntörajoitukset, tietojen saatavuus ja tukijärjestelyt. Selvitä, miten korvaavat numerot, toistuvat rekisteröinnit ja historialliset haut käsitellään kaupallisesti. Käytä ajantasaista dokumentaatiota ja kirjallista vahvistusta vaatimuksille, jotka vaikuttavat budjettiisi tai arkkitehtuuriisi.

Lähteet

• 17TRACK Tracking API — virallinen tuotereferenssi Tracking API -tarjonnalle.
• 17TRACK API -dokumentaatio — virallinen tekninen viite integraation toteuttamiseen. Vahvista tarkat pyyntömuodot, tuetut työnkulut ja rajoitukset täältä ennen kehitystyötä.