Ako zjednotiť sledovanie zásielok v Austrálii a na Novom Zélande pomocou jedného API

Na zjednotenie sledovania zásielok v Austrálii a na Novom Zélande pomocou jedného API pripojte svoj systém objednávok alebo plnenia objednávok k sledovacej službe pre viacerých prepravcov, zaregistrujte každú zásielku so správnou identitou prepravcu a prekladajte prichádzajúce aktualizácie sledovania do konzistentného interného modelu udalostí. Integrácia by mala zachovať podrobnosti špecifické pre jednotlivých prepravcov a zároveň poskytnúť vášmu prevádzkovému tímu aj zákazníkom jednotný zážitok zo sledovania domácich aj trans-tasmánskych doručení.

Pre vývojárov, prevádzkovateľov e-commerce a logistické tímy nie je hlavnou výzvou vytvorenie prvej požiadavky API. Výzvou je udržať konzistentné identity zásielok, stavy doručenia, odovzdania medzi prepravcami a zákaznícke upozornenia v situácii, keď rôzni prepravcovia opisujú tú istú cestu odlišne. Táto príručka vysvetľuje, ako navrhnúť takúto integráciu, vyhodnotiť sledovacie API a otestovať ho pred použitím v produkcii.

Definujte, čo musí jednotné API zjednotiť

Zdieľané API poskytuje vašej aplikácii spoločný integračný bod. Nezabezpečí však, aby každý prepravca zverejňoval identické informácie alebo skenoval balíky s rovnakou frekvenciou. Vaša architektúra musí rozlišovať medzi konzistentným rozhraním a úplnou viditeľnosťou.

Začnite inventárom zásielok založeným na skutočnej aktivite plnenia objednávok, nie na všeobecnom zozname prepravcov pôsobiacich v ktorejkoľvek z týchto krajín. Zahrňte domáce zásielky v Austrálii, domáce zásielky na Novom Zélande a cezhraničné prepravy v oboch smeroch. Ak sú súčasťou vášho podnikania, pridajte aj ďalšie krajiny pôvodu.

• Prepravca a služba: Zaznamenajte prepravcu, použitú službu a všetkých známych doručovacích partnerov.
• Trasa: Rozlišujte pôvod a cieľ zásielky od miesta jej posledného skenu.
• Identifikátory: Zachyťte referenciu objednávky, referenciu plnenia objednávky, sledovacie číslo a prípadné náhradné alebo partnerské číslo.
• Prevádzkový účel: Určte, či aktualizácie slúžia na sledovanie zákazníkom, správu výnimiek, potvrdenie doručenia alebo na všetky tri účely.
• Požadované podrobnosti: Rozhodnite, či postačuje všeobecný stav doručenia alebo či agenti potrebujú aj popisy skenov, miesta a časové údaje.

Tento inventár sa stane vaším akceptačným kontrolným zoznamom. Všeobecné pokrytie prepravcov poskytovateľom je užitočné pri výbere kandidátov, no vaše rozhodnutie by malo vychádzať z toho, či skutočné kombinácie prepravcov a služieb poskytujú použiteľné informácie o sledovaní.

Vyhodnoťte sledovacie API podľa zloženia svojich zásielok

17TRACK ponúka Tracking API, čo z neho robí relevantnú možnosť na vyhodnotenie pri integrácii viacerých prepravcov. Pomocou jeho oficiálnej dokumentácie API si overte aktuálne požiadavky na integráciu. Podporu prepravcov, polia udalostí, správanie aktualizácií, limity účtu a obchodné podmienky považujte za položky, ktoré treba overiť pre vašu implementáciu, nie za predpoklady odvodené z kategórie produktu.

Každého zvažovaného poskytovateľa API sa pýtajte rovnaké praktické otázky:

• Dokáže identifikovať a sledovať prepravcov a služby vo vašom inventári zásielok?
• Ak je identifikácia prepravcu nejednoznačná, môžete zadať explicitný identifikátor prepravcu?
• Ako vaša aplikácia prijíma aktualizácie a aký mechanizmus obnovy je k dispozícii v prípade vynechanej aktualizácie?
• Ktoré pôvodné podrobnosti prepravcu zostávajú dostupné spolu s normalizovanými stavmi?
• Čo sa stane, keď je sledovacie číslo neplatné, ešte nerozpoznané alebo spojené s viac než jedným možným prepravcom?
• Ako sú pre váš účet definované používanie, fakturácia, trvanie sledovania a limity prístupu?

Odporúčané pravidlo rozhodovania: vyberajte na základe úspešných testov skutočných vzorcov vašej prepravy, nie podľa najvyššieho verejne uvádzaného počtu prepravcov. Integrácia je vhodná vtedy, keď poskytuje dostatok informácií na podporu vašich prevádzkových rozhodnutí a dostatočne jasne odhaľuje zlyhania, aby bolo možné ich riešiť.

Vytvorte interný model, ktorý odolá rozdielom medzi prepravcami

Oddeľte objednávky, zásielky a úseky sledovania

Nepoužívajte sledovacie číslo ako primárny kľúč objednávky. Jedna objednávka môže obsahovať niekoľko balíkov a cesta balíka môže zahŕňať viac než jeden sledovací identifikátor. Namiesto toho vytvorte interné ID zásielky a priraďte k nemu záznamy sledovania.

Praktický model má tri úrovne: zákaznícku objednávku, jej fyzické zásielky a úseky sledovania spojené s každou zásielkou. Domáci balík môže potrebovať iba jeden úsek sledovania. Cezhraničný balík môže vyžadovať prepojené záznamy, keď sa stane relevantným iný prepravca alebo identifikátor.

Rozsah záznamu sledovania určujte podľa prepravcu aj sledovacieho čísla a zachovajte jeho vzťah k ID zásielky. Ak sa objaví nové číslo doručovacieho partnera, pridajte ho ako súvisiaci identifikátor namiesto prepísania pôvodného čísla. Zachováte tak históriu, ktorú podporní agenti potrebujú pri preverovaní odovzdania.

Uchovávajte nespracovanú aj normalizovanú udalosť

Používajte malú internú slovnú zásobu stavov, podľa ktorej môže vaša firma konať. Môžete napríklad definovať stavy pred prepravou, v preprave, na doručenie, k dispozícii na vyzdvihnutie, doručené, výnimka a neznáme. Ide o navrhované interné kategórie, nie o tvrdenie týkajúce sa schémy stavov konkrétneho poskytovateľa.

Pôvodný popis prepravcu ukladajte spolu s namapovaným stavom. Udalosť na výdajnom mieste a problém s adresou môžu v oboch prípadoch vyžadovať zásah zákazníka, nemali by však vytvoriť rovnakú správu. Rovnako by vytvorenie štítku nemalo automaticky znamenať, že prepravca balík fyzicky prevzal.

Rozhodnutia o mapovaní dokumentujte vo verziovanej konfigurácii. Keď sa objaví nový popis udalosti, pri nejasnom význame ho umiestnite do frontu na kontrolu. Explicitný neznámy stav je bezpečnejší než sebavedomé priradenie nesprávneho výsledku doručenia.

Rozlišujte čas udalosti od času prijatia

Ukladajte oddelene čas, keď k udalosti došlo, a čas, keď ju prijal váš systém. Starší sken môže doraziť po novšom, najmä keď sú aktualizácie oneskorené alebo sa historické udalosti dodávajú spolu.

Pri Austrálii a Novom Zélande nepoužívajte jeden pevný časový posun pre každú zásielku. Ak sú poskytnuté, zachovajte zdrojové časové pečiatky a posuny. Na zobrazenie použite vhodné pomenované časové pásmo, ak máte spoľahlivý kontext miesta, a zohľadnite rozdiely v letnom čase. Ak časové pásmo zdroja chýba, zachovajte túto neistotu namiesto vytvorenia presného prepočtu na UTC.

Implementujte spoľahlivý pracovný postup prijímania údajov

1. Najprv vytvorte internú zásielku. Pred registráciou v sledovacej službe zaznamenajte jej vzťah k objednávke, trasu, výber prepravcu a sledovací identifikátor.
2. Odošlite registráciu sledovania. Použite zdokumentovaný formát požiadavky poskytovateľa. Uložte odpoveď a rozlišujte úspešnú registráciu od neskoršej dostupnosti udalostí prepravcu.
3. Klasifikujte zlyhania. Oddeľte neplatné vstupy a problémy s autentifikáciou od dočasných zlyhaní služby. Opakujte požiadavku iba vtedy, keď môže opakovanie rozumne pomôcť.
4. Prijímajte alebo získavajte aktualizácie. Implementujte mechanizmus doručovania podporovaný vybraným API. Ak používate webhooky, overujte prichádzajúce požiadavky zdokumentovanou metódou poskytovateľa a spracúvajte prijaté udalosti prostredníctvom trvalého frontu.
5. Pred aplikovaním zmien odstráňte duplicity. Ak je k dispozícii, použite identifikátor udalosti poskytovateľa alebo starostlivo navrhnutý zložený kľúč. Opakované doručenie nesmie spustiť opakované zákaznícke upozornenia.
6. Prepočítajte stav zásielky. Vyhodnocujte význam a chronológiu udalostí namiesto nahradenia aktuálneho stavu aktualizáciou, ktorá prišla ako posledná.
7. Zosúlaďte neúplné záznamy. Ak API podporuje získavanie údajov, použite ho na preverenie vynechaných aktualizácií alebo zastaraných záznamov v rámci príslušných limitov používania.

Autentifikáciu špecifickú pre poskytovateľa, názvy polí a spracovanie chýb uchovávajte v adaptéri. Váš systém správy objednávok by mal využívať váš interný model zásielok a nemal by priamo závisieť od každého detailu odpovede poskytovateľa. Toto oddelenie tiež uľahčuje testovanie neskorších zmien API.

Spracujte trans-tasmánske trasy bez predstierania istoty

Cezhraničné sledovanie potrebuje viac kontextu než iba sled stavových označení. Vaša aplikácia by mala rozlišovať exportnú udalosť, colnú udalosť, odovzdanie prepravcovi a udalosť konečného doručenia, ak zdrojové údaje tieto rozdiely podporujú.

Neodvodzujte colné odbavenie zo všeobecného skenu typu „v preprave“. Rovnako neprítomnosť nedávneho skenu nepotvrdzuje, že colnica zadržiava balík. Užitočná zákaznícka správa uvedie poslednú potvrdenú udalosť a jej čas a následne vysvetlí ďalší krok, ktorý váš tím skutočne dokáže podporiť.

Pôvod a cieľ uchovávajte oddelene od miesta skenu. Zásielka putujúca z Austrálie na Nový Zéland sa nestane domácou novozélandskou zásielkou len preto, že dostala sken po príchode. Toto rozlíšenie je dôležité pre vykazovanie trás a zodpovednosť za výnimky.

Ak sa zapojí doručovací partner, jeho záznam sledovania prepojte iba vtedy, keď je tento vzťah podporený údajmi o zásielke, sledovacou službou alebo prevádzkovo overeným záznamom. Balíky nespájajte len preto, že ich identifikátory vyzerajú podobne.

Premeňte udalosti sledovania na užitočné zákaznícke aktualizácie

Stránka pre zákazníkov by mala odpovedať na štyri otázky: aký je posledný potvrdený stav, kedy k nemu došlo, kde bol zaznamenaný, ak je to známe, a či musí zákazník konať.

Pravidlá upozornení uchovávajte oddelene od prijímania udalostí. Nie každý sken si zaslúži e-mail alebo textovú správu. Definujte významné prechody, napríklad prvý potvrdený pohyb, pokus o doručenie, požiadavku na vyzdvihnutie alebo udalosť doručenia, a potlačte opakované upozornenia pre rovnaký prechod.

• Zastarané sledovanie: Uveďte, kedy došlo k poslednej aktualizácii, bez toho, aby ste ticho považovali za dôkaz straty.
• Odhady doručenia: Rozlišujte odhad poskytnutý prepravcom od prísľubu obchodníka. Nevytvárajte dátum, ak neexistuje ani jeden z nich.
• Výnimky: Ak je známy, uveďte konkrétny ďalší krok namiesto zobrazenia nevysvetleného označenia chyby.
• Spory o doručenie: Zachovajte zdrojovú udalosť a prípad postúpte podpore; samotný stav doručenia nevyrieši každý zákaznícky spor.

Chráňte stránky sledovania rovnako ako prihlasovacie údaje API. Nevystavujte nepotrebné adresné ani kontaktné údaje, servisné prihlasovacie údaje uchovávajte na serveri a používajte kontrolu prístupu primeranú zobrazovaným informáciám.

Pred nasadením uskutočnite pilotný projekt podľa trás

Otestujte domáce austrálske, domáce novozélandské, austrálsko-novozélandské a novozélandsko-austrálske zásielky tam, kde sú tieto trasy relevantné pre vaše podnikanie. Zahrňte bežné doručenia aj prevádzkové okrajové prípady: rozdelené objednávky, nerozpoznané čísla, odovzdania, pokusy o doručenie, udalosti vyzdvihnutia, vrátenia a oneskorene prichádzajúce skeny.

Na overenie prepravcov používajte skutočné záznamy zásielok s príslušným oprávnením. Na testovanie odolnosti vlastnej aplikácie používajte syntetické udalosti, výsledky syntetických testov však nepovažujte za dôkaz živého pokrytia prepravcov.

• Kontrola identity: Každá aktualizácia sa dostane k správnej zásielke a objednávke.
• Kontrola chronológie: Udalosti mimo poradia nesmú nesprávne vrátiť priebeh doručenia späť.
• Kontrola obnovy: Dočasné zlyhania a duplicitné aktualizácie nesmú viesť k strate údajov ani k opakovaniu upozornení.
• Kontrola podpory: Agenti môžu skontrolovať pôvodnú udalosť a porozumieť stavu zobrazenému zákazníkovi.
• Obchodná kontrola: Očakávané používanie zodpovedá overenému fakturačnému modelu a limitom účtu.

Pred vyhodnotením pilotného projektu stanovte akceptačné prahy. Merajte výsledky registrácie, nenamapované udalosti, oneskorenia spracovania, duplicitné upozornenia a nevyriešené zastarané zásielky. Oddeľte oneskorenia v údajoch prepravcu od oneskorení vo vlastnej aplikácii, aby sa náprava dostala k správnemu zodpovednému pracovníkovi.

Implementácia je pripravená vtedy, keď váš tím dokáže vysvetliť a vyriešiť neúplné sledovanie, nielen zobrazovať úspešné doručenia. Jedno API zjednodušuje konektivitu; váš model zásielok, pravidlá udalostí a prevádzkové postupy robia túto konektivitu spoľahlivou.

Často kladené otázky

Nahrádza jedno sledovacie API integrácie prepravy jednotlivých prepravcov?

Nie nevyhnutne. Sledovanie, vytváranie štítkov, objednávanie vyzdvihnutia, výpočet sadzieb a colná dokumentácia sú samostatné funkcie. Overte rozsah vybraného produktu a zachovajte ďalšie integrácie tam, kde ich váš proces plnenia objednávok potrebuje.

Môžem zaregistrovať sledovacie číslo pred prvým skenom prepravcu?

Skontrolujte pravidlá registrácie API. Navrhnite aplikáciu tak, aby rozlišovala prijatú registráciu sledovania od potvrdeného fyzického pohybu. Záznam bez udalostí by sa nemal automaticky zobrazovať ako „v preprave“.

Poskytne jedno API aktualizácie v reálnom čase pre každého prepravcu?

Nepredpokladajte to. Aktuálnosť od začiatku do konca závisí od toho, kedy prepravca zverejní údaje, kedy ich sledovacia služba získa a kedy ich spracuje vaša aplikácia. Overte správanie aktualizácií pre kombinácie prepravcov a služieb, ktoré používate.

Čo sa má stať, keď sa sledovacie číslo zmení?

Pôvodný identifikátor zachovajte a overený náhradný alebo partnerský identifikátor priraďte k rovnakej internej zásielke. Zachovajte obe histórie a zabráňte tomu, aby duplicitné záznamy vytvárali konfliktné upozornenia.

Je 17TRACK relevantný pre túto integráciu?

Áno. Jeho Tracking API je relevantné pre integráciu viacerých prepravcov opísanú v tejto príručke. Vyhodnoťte ho pomocou vzoriek svojich austrálskych a novozélandských zásielok a pred nasadením potvrďte podporu prepravcov, technické správanie a podmienky účtu prostredníctvom oficiálnych zdrojov API.

Zdroje

• 17TRACK Tracking API — oficiálny produktový zdroj pre možnosť API diskutovanú v tejto príručke.
• Dokumentácia 17TRACK API — oficiálna technická referencia na kontrolu formátov požiadaviek, požiadaviek na integráciu a podporovaného správania.