Kako poenotiti sledenje pošiljkam v Avstraliji in na Novi Zelandiji z enim API-jem

Za poenotenje sledenja pošiljkam po Avstraliji in Novi Zelandiji z enim API-jem povežite svoj sistem za naročila ali izpolnjevanje naročil s storitvijo za sledenje več prevoznikom, vsako pošiljko registrirajte z ustrezno identiteto prevoznika ter prejete posodobitve sledenja prevedite v enoten notranji model dogodkov. Integracija mora ohraniti podrobnosti, specifične za posameznega prevoznika, hkrati pa vaši operativni ekipi in strankam zagotoviti enotno izkušnjo sledenja pri domačih in čez-Tasmanskih dostavah.

Za razvijalce, upravljavce spletnih trgovin in logistične ekipe glavni izziv ni izvedba prve zahteve API-ja. Izziv je ohranjati skladnost identitet pošiljk, statusov dostave, predaj med prevozniki in obvestil strankam, ko različni prevozniki isto pot opisujejo na različne načine. Ta vodnik pojasnjuje, kako zasnovati takšno integracijo, oceniti API za sledenje in ga preizkusiti, preden se nanj zanesete v produkciji.

Določite, kaj mora enotni API poenotiti

Skupni API vaši aplikaciji zagotavlja enotno integracijsko točko. Ne zagotavlja pa, da bodo vsi prevozniki objavljali enake informacije ali pakete skenirali enako pogosto. Vaša arhitektura mora razlikovati med doslednim vmesnikom in popolno vidljivostjo.

Začnite s popisom pošiljk, ki temelji na dejanskih dejavnostih izpolnjevanja naročil, ne pa na splošnem seznamu prevoznikov, ki delujejo v eni ali drugi državi. Vključite domače pošiljke v Avstraliji, domače pošiljke na Novi Zelandiji ter čezmejna gibanja v obe smeri. Dodajte tudi druge mednarodne izhode, če so del vašega poslovanja.

• Prevoznik in storitev: Zabeležite prevoznika, uporabljeno storitev in morebitnega znanega dostavnega partnerja.
• Pot: Ločite izvor in cilj pošiljke od lokacije njenega zadnjega skeniranja.
• Identifikatorji: Zabeležite referenco naročila, referenco izpolnitve naročila, številko za sledenje ter morebitno nadomestno ali partnersko številko.
• Operativni namen: Določite, ali posodobitve podpirajo sledenje strank, upravljanje izjem, potrditev dostave ali vse troje.
• Zahtevane podrobnosti: Odločite se, ali zadostuje splošen status dostave ali pa agenti potrebujejo tudi opise skenov, lokacije in časovne žige.

Ta popis postane vaš kontrolni seznam za sprejem. Splošna pokritost prevoznikov ponudnika je koristna za ožji izbor, vendar mora vaša odločitev temeljiti na tem, ali vaše dejanske kombinacije prevoznikov in storitev vračajo uporabne informacije o sledenju.

Ocenite API za sledenje glede na svojo mešanico pošiljk

17TRACK ponuja Tracking API, zato je primerna možnost za ocenjevanje pri integraciji z več prevozniki. V official API documentation preverite trenutne zahteve za integracijo. Podporo prevoznikov, polja dogodkov, vedenje posodobitev, omejitve računa in komercialne pogoje obravnavajte kot elemente, ki jih morate preveriti za svojo izvedbo, ne pa kot predpostavke, izpeljane iz kategorije izdelka.

Vsak API, o katerem razmišljate, preverite z enakimi praktičnimi vprašanji:

• Ali lahko prepozna in sledi prevoznikom ter storitvam iz vašega popisa pošiljk?
• Ali lahko ob nejasnem zaznavanju prevoznika posredujete izrecni identifikator prevoznika?
• Kako vaša aplikacija prejema posodobitve in kateri mehanizem za obnovitev je na voljo, če posodobitev ni prejeta?
• Katere izvirne podrobnosti prevoznika ostanejo na voljo poleg normaliziranih statusov?
• Kaj se zgodi, ko je številka za sledenje neveljavna, še ni prepoznana ali povezana z več možnimi prevozniki?
• Kako so za vaš račun opredeljeni uporaba, obračunavanje, trajanje sledenja in omejitve dostopa?

Priporočeno pravilo odločanja: izberite na podlagi uspešnih preizkusov svojih dejanskih vzorcev pošiljanja, ne na podlagi največjega oglaševanega števila prevoznikov. Integracija je primerna, ko zagotavlja dovolj informacij za podporo vašim operativnim odločitvam in dovolj jasno izpostavlja napake, da jih lahko odpravite.

Zgradite notranji model, ki bo odporen na razlike med prevozniki

Ločite naročila, pošiljke in odseke sledenja

Številke za sledenje ne uporabljajte kot primarnega ključa naročila. Eno naročilo lahko vsebuje več paketov, pot paketa pa lahko vključuje več kot en identifikator za sledenje. Namesto tega ustvarite notranji ID pošiljke in mu pripnite zapise sledenja.

Praktični model ima tri ravni: naročilo stranke, njegove fizične pošiljke in odseke sledenja, povezane z vsako pošiljko. Domači paket morda potrebuje le en odsek sledenja. Čezmejni paket lahko zahteva povezane zapise, ko postane pomemben drug prevoznik ali identifikator.

Zapis sledenja določite tako glede na prevoznika kot glede na številko za sledenje ter ohranite njegovo povezavo z ID-jem pošiljke. Če se pojavi nova številka dostavnega partnerja, jo dodajte kot povezan identifikator, namesto da prepišete izvirnega. Tako ohranite zgodovino, ki jo podporni agenti potrebujejo pri preiskovanju predaje.

Ohranite surovi in normalizirani dogodek

Uporabite majhen notranji besednjak statusov, na podlagi katerega lahko vaše podjetje ukrepa. Določite lahko na primer: pred tranzitom, v tranzitu, v dostavi, na voljo za prevzem, dostavljeno, izjema in neznano. To so predlagane notranje kategorije, ne trditev o shemi statusov določenega ponudnika.

Izvirni opis prevoznika shranite poleg preslikanega statusa. Dogodek na prevzemni točki in težava z naslovom lahko oba zahtevata ukrepanje stranke, vendar ne smeta ustvariti istega sporočila. Prav tako ustvarjanje etikete ne sme samodejno postati dokaz, da ima prevoznik paket fizično pri sebi.

Odločitve o preslikavi dokumentirajte v različici konfiguracije. Ko se pojavi nov opis dogodka, ga uvrstite v čakalno vrsto za pregled, če njegov pomen ni jasen. Izrecno stanje »neznano« je varnejše od samozavestne dodelitve napačnega izida dostave.

Ločite čas dogodka od časa prejema

Čas nastanka dogodka shranite ločeno od časa, ko ga je prejela vaša sistema. Starejši sken lahko prispe za novejšim, zlasti ko so posodobitve zakasnjene ali so zgodovinski dogodki posredovani skupaj.

Pri Avstraliji in Novi Zelandiji se izogibajte uporabi enega fiksnega časovnega zamika za vse pošiljke. Ohranite izvorne časovne žige in odmike, kadar so posredovani. Za prikaz uporabite ustrezni imenovani časovni pas, ko imate zanesljiv kontekst lokacije, ter upoštevajte razlike zaradi poletnega časa. Če izvorni časovni pas manjka, ohranite to negotovost, namesto da si izmislite natančen pretvorbeni čas UTC.

Izvedite zanesljiv potek zaužitja podatkov

1. Najprej ustvarite notranjo pošiljko. Pred registracijo pri storitvi za sledenje zabeležite njeno povezavo z naročilom, pot, izbranega prevoznika in identifikator za sledenje.
2. Pošljite registracijo sledenja. Uporabite dokumentirano obliko zahteve ponudnika. Shranite odgovor in ločite uspešno registracijo od poznejše razpoložljivosti dogodkov prevoznika.
3. Razvrstite napake. Neveljavne vnose in težave z overjanjem ločite od začasnih napak storitve. Ponovno poskusite le tam, kjer lahko ponovni poskus razumno pomaga.
4. Prejmite ali pridobite posodobitve. Izvedite mehanizem dostave, ki ga podpira izbrani API. Če uporabljate webhooke, preverite prejete zahteve z dokumentirano metodo ponudnika in sprejete dogodke obdelajte prek trajne čakalne vrste.
5. Pred uporabo sprememb odstranite podvojitve. Kjer je na voljo, uporabite identifikator dogodka ponudnika ali skrbno zasnovan sestavljeni ključ. Ponavljajoča se dostava ne sme sprožiti ponavljajočih se obvestil strankam.
6. Ponovno izračunajte stanje pošiljke. Ocenite pomen in kronologijo dogodkov, namesto da trenutni status zamenjate s posodobitvijo, ki je prispela zadnja.
7. Uskladite nepopolne zapise. Kjer API podpira pridobivanje podatkov, ga uporabite za preiskovanje zgrešenih posodobitev ali zastarelih zapisov v okviru veljavnih omejitev uporabe.

Preverjanje pristnosti, imena polj in obravnavo napak, specifične za ponudnika, ohranite znotraj adapterja. Vaš sistem za upravljanje naročil naj uporablja vaš notranji model pošiljke, namesto da bi bil neposredno odvisen od vsake podrobnosti odgovora ponudnika. Ta ločitev olajša tudi poznejše preizkušanje sprememb API-ja.

Obravnavajte čez-Tasmanske poti brez ustvarjanja lažne gotovosti

Čezmejno sledenje potrebuje več konteksta kot zaporedje oznak statusa. Vaša aplikacija mora razlikovati izvozni dogodek, carinski dogodek, predajo prevozniku in dogodek končne dostave, kadar izvorni podatki te razlike podpirajo.

Carinskega postopka ne sklepajte iz splošnega skena »v tranzitu«. Prav tako odsotnost nedavnega skena ne dokazuje, da carina zadržuje paket. Koristno sporočilo stranki navede zadnji potrjeni dogodek in njegov čas, nato pa pojasni morebitno naslednje dejanje, ki ga vaša ekipa dejansko lahko podpre.

Izvor in cilj ohranite ločena od lokacije skena. Pošiljka, ki potuje iz Avstralije na Novo Zelandijo, ne postane domača novozelandska pošiljka samo zato, ker je prejela sken prihoda. Ta razlika je pomembna za poročanje o poteh in lastništvo izjem.

Če se vključi dostavni partner, njegov zapis sledenja povežite le, kadar odnos podpirajo podatki o pošiljki, storitev za sledenje ali operativno preverjen zapis. Paketov ne združujte zgolj zato, ker so identifikatorji podobni.

Pretvorite dogodke sledenja v uporabne posodobitve za stranke

Stran, namenjena strankam, mora odgovoriti na štiri vprašanja: kateri je zadnji potrjeni status, kdaj se je zgodil, kje je bil zabeležen, če je lokacija znana, in ali mora stranka ukrepati?

Pravila obveščanja naj bodo ločena od zaužitja dogodkov. Vsak sken si ne zasluži e-pošte ali besedilnega sporočila. Določite pomembne prehode, kot so prvi potrjeni premik, poskus dostave, zahteva za prevzem ali dogodek dostave, ter preprečite ponavljajoča se opozorila za isti prehod.

• Zastarelo sledenje: Navedite, kdaj je bila izvedena zadnja posodobitev, ne da bi molk obravnavali kot dokaz izgube.
• Ocene dostave: Ločite oceno, ki jo zagotovi prevoznik, od obljube trgovca. Datuma ne izmišljajte, če ne obstaja nobeden od njiju.
• Izjeme: Kjer je znan, navedite konkreten naslednji korak, namesto da prikažete nepojasnjeno oznako napake.
• Spori glede dostave: Ohranite izvorni dogodek in primer posredujte podpori; sam status »dostavljeno« ne razreši vsakega spora s stranko.

Zaščitite strani za sledenje in poverilnice API-ja. Ne razkrivajte nepotrebnih naslovnih ali kontaktnih podatkov, poverilnice storitve hranite na strežniku in uporabite nadzor dostopa, primeren prikazanim informacijam.

Pred uvedbo izvedite pilotni projekt na podlagi poti

Preizkusite domače avstralske, domače novozelandske, avstralsko-novozelandske in novozelandsko-avstralske pošiljke, kadar so te poti pomembne za vaše poslovanje. Vključite običajne dostave in operativne robne primere: razdeljena naročila, neprepoznane številke, predaje, poskuse dostave, dogodke prevzema, vračila in pozno prispele skene.

Za preverjanje prevoznikov uporabite dejanske zapise pošiljk z ustreznim dovoljenjem. Za preizkušanje odpornosti lastne aplikacije uporabite sintetične dogodke, vendar sintetičnih rezultatov ne obravnavajte kot dokaz dejanske pokritosti prevoznikov.

• Preverjanje identitete: Vsaka posodobitev doseže pravilno pošiljko in naročilo.
• Preverjanje kronologije: Dogodki izven vrstnega reda napačno ne obrnejo napredka dostave.
• Preverjanje obnovitve: Začasne napake in podvojene posodobitve ne povzročijo izgube podatkov ali ponavljanja opozoril.
• Preverjanje podpore: Agenti lahko pregledajo izvirni dogodek in razumejo status, prikazan stranki.
• Komercialno preverjanje: Pričakovana uporaba ustreza preverjenemu modelu obračunavanja in omejitvam računa.

Pred ocenjevanjem pilota določite pragove sprejemljivosti. Merite rezultate registracije, nepreslikane dogodke, zamude pri obdelavi, podvojena obvestila in nerešene zastarele pošiljke. Zamude v podatkih prevoznika ločite od zamud znotraj lastne aplikacije, da bo odprava težave dodeljena pravi odgovorni osebi.

Izvedba je pripravljena, ko lahko vaša ekipa razloži in odpravi nepopolno sledenje, ne pa le prikaže uspešne dostave. En API poenostavi povezljivost; vaš model pošiljk, pravila dogodkov in operativni postopki pa zagotavljajo zanesljivost te povezljivosti.

Pogosta vprašanja

Ali en API za sledenje nadomesti integracije za pošiljanje posameznih prevoznikov?

Ni nujno. Sledenje, ustvarjanje etiket, naročanje prevzema, izračun cen in carinska dokumentacija so ločene funkcije. Preverite obseg izbranega izdelka in ohranite druge integracije, kjer jih vaš postopek izpolnjevanja naročil potrebuje.

Ali lahko registriram številko za sledenje pred prvim skenom prevoznika?

Preverite pravila registracije API-ja. Aplikacijo zasnujte tako, da bo razlikovala med sprejeto registracijo sledenja in potrjenim fizičnim premikom. Zapisa brez dogodkov ne smete samodejno prikazati kot »v tranzitu«.

Ali bo enotni API zagotavljal posodobitve v realnem času za vsakega prevoznika?

Tega ne predpostavljajte. Svežina od začetka do konca je odvisna od tega, kdaj prevoznik objavi podatke, kdaj jih pridobi storitev za sledenje in kdaj jih obdela vaša aplikacija. Potrdite vedenje posodobitev za kombinacije prevoznikov in storitev, ki jih uporabljate.

Kaj se mora zgoditi, ko se številka za sledenje spremeni?

Ohranite izvirni identifikator ter preverjeni nadomestni ali partnerski identifikator pripnite isti notranji pošiljki. Ohranite obe zgodovini in preprečite, da bi podvojeni zapisi ustvarjali nasprotujoča si obvestila.

Ali je 17TRACK pomemben za to integracijo?

Da. Njegov Tracking API je pomemben za tukaj opisano integracijo z več prevozniki. Ocenite ga z vzorci svojih avstralskih in novozelandskih pošiljk ter pred uvedbo prek uradnih virov API-ja potrdite podporo prevoznikom, tehnično vedenje in pogoje računa.

Viri

• 17TRACK Tracking API — uradni vir izdelka za možnost API-ja, obravnavano v tem vodniku.
• 17TRACK API documentation — uradna tehnična referenca za preverjanje oblik zahtev, zahtev za integracijo in podprtega vedenja.