Cum să unificați urmărirea expedierilor în Australia și Noua Zeelandă cu un singur API

Pentru a unifica urmărirea expedierilor în Australia și Noua Zeelandă printr-un singur API, conectați sistemul de comenzi sau de procesare a comenzilor la un serviciu de urmărire multi-transportator, înregistrați fiecare expediere cu identitatea corectă a transportatorului și traduceți actualizările de urmărire primite într-un model intern coerent de evenimente. Integrarea ar trebui să păstreze detaliile specifice transportatorului, oferind în același timp echipei operaționale și clienților o singură experiență de urmărire pentru livrările interne și trans-Tasmaniene.

Pentru dezvoltatori, operatori de comerț electronic și echipe de logistică, principala provocare nu este efectuarea primei solicitări API. Provocarea este menținerea consecvenței identităților expedierilor, a stărilor de livrare, a transferurilor între transportatori și a notificărilor pentru clienți atunci când transportatori diferiți descriu aceeași călătorie în moduri diferite. Acest ghid explică modul de proiectare a acestei integrări, de evaluare a unui API de urmărire și de testare a acestuia înainte de utilizarea în producție.

Definiți ce trebuie să unifice API-ul unic

Un API comun oferă aplicației dumneavoastră un punct comun de integrare. Acesta nu îi determină pe toți transportatorii să publice informații identice sau să scaneze coletele cu aceeași frecvență. Arhitectura dumneavoastră trebuie să facă diferența între o interfață consecventă și o vizibilitate completă.

Începeți cu un inventar al expedierilor bazat pe activitatea reală de procesare a comenzilor, nu pe o listă generală a transportatorilor care operează în oricare dintre cele două țări. Includeți expedieri interne din Australia, expedieri interne din Noua Zeelandă și transporturi transfrontaliere în ambele direcții. Adăugați și alte origini internaționale dacă fac parte din activitatea dumneavoastră.

• Transportator și serviciu: Înregistrați transportatorul, serviciul utilizat și orice partener de livrare cunoscut.
• Rută: Faceți diferența între originea și destinația expedierii și locația celei mai recente scanări.
• Identificatori: Colectați referința comenzii, referința procesării comenzii, numărul de urmărire și orice număr de înlocuire sau al partenerului.
• Scop operațional: Specificați dacă actualizările sprijină urmărirea de către client, gestionarea excepțiilor, confirmarea livrării sau toate cele trei.
• Nivelul de detaliu necesar: Decideți dacă este suficientă o stare generală a livrării sau dacă agenții au nevoie și de descrieri ale scanărilor, locații și marcaje temporale.

Acest inventar devine lista dumneavoastră de verificare pentru acceptare. Acoperirea generală a transportatorilor de către un furnizor este utilă pentru preselecție, însă decizia ar trebui să se bazeze pe măsura în care combinațiile reale transportator-serviciu returnează informații de urmărire utilizabile.

Evaluați API-ul de urmărire în funcție de mixul dumneavoastră de expedieri

17TRACK oferă un API de urmărire, ceea ce îl face o opțiune relevantă pentru evaluarea unei integrări multi-transportator. Utilizați documentația oficială a API-ului pentru a verifica cerințele actuale de integrare. Tratați suportul pentru transportatori, câmpurile evenimentelor, comportamentul actualizărilor, limitele contului și condițiile comerciale ca elemente care trebuie verificate pentru implementarea dumneavoastră, nu ca presupuneri derivate din categoria produsului.

Adresați aceleași întrebări practice pentru orice API pe care îl luați în considerare:

• Poate identifica și urmări transportatorii și serviciile din inventarul dumneavoastră de expedieri?
• Atunci când identificarea transportatorului este ambiguă, puteți furniza un identificator explicit al transportatorului?
• Cum primește aplicația dumneavoastră actualizările și ce mecanism de recuperare este disponibil dacă o actualizare este omisă?
• Care dintre detaliile originale ale transportatorului rămân disponibile alături de stările normalizate?
• Ce se întâmplă când un număr de urmărire este invalid, nu este încă recunoscut sau este asociat cu mai mult de un transportator posibil?
• Cum sunt definite utilizarea, facturarea, durata urmăririi și limitele de acces pentru contul dumneavoastră?

Regula de decizie recomandată: alegeți pe baza testelor reușite ale tiparelor reale de expediere, nu pe baza celui mai mare număr prezentat de transportatori. O integrare este potrivită atunci când furnizează suficiente informații pentru a sprijini deciziile operaționale și expune eșecurile suficient de clar pentru a permite recuperarea.

Construiți un model intern care rezistă diferențelor dintre transportatori

Separați comenzile, expedierile și segmentele de urmărire

Nu utilizați numărul de urmărire ca identificator principal pentru o comandă. O comandă poate conține mai multe colete, iar parcursul unui colet poate implica mai mulți identificatori de urmărire. În schimb, creați un ID intern al expedierii și atașați înregistrările de urmărire acestuia.

Un model practic are trei niveluri: comanda clientului, expedierile sale fizice și segmentele de urmărire asociate fiecărei expedieri. Un colet intern poate avea nevoie de un singur segment de urmărire. Un colet transfrontalier poate necesita înregistrări corelate atunci când un alt transportator sau identificator devine relevant.

Delimitați o înregistrare de urmărire atât prin transportator, cât și prin numărul de urmărire și păstrați legătura acesteia cu ID-ul expedierii. Dacă apare un nou număr al partenerului de livrare, adăugați-l ca identificator asociat în loc să îl suprascrieți pe cel original. Astfel păstrați istoricul de care agenții de asistență au nevoie atunci când investighează un transfer.

Păstrați un eveniment brut și un eveniment normalizat

Utilizați un vocabular restrâns de stări interne pe baza căruia compania dumneavoastră poate acționa. De exemplu, puteți defini: înainte de expediere, în tranzit, în curs de livrare, disponibil pentru ridicare, livrat, excepție și necunoscut. Acestea sunt categorii interne sugerate, nu o afirmație despre schema de stări a unui anumit furnizor.

Stocați descrierea originală a transportatorului alături de starea mapată. Un eveniment la un punct de ridicare și o problemă legată de adresă pot necesita ambele acțiuni din partea clientului, dar nu ar trebui să genereze același mesaj. În mod similar, crearea unei etichete nu ar trebui să devină automat o dovadă că transportatorul deține fizic coletul.

Documentați deciziile de mapare într-o configurație versionată. Atunci când apare o nouă descriere a unui eveniment, plasați-o într-o coadă de verificare dacă semnificația sa nu este clară. O stare necunoscută explicită este mai sigură decât atribuirea cu certitudine a unui rezultat de livrare greșit.

Faceți diferența între momentul evenimentului și momentul primirii

Stocați separat momentul în care a avut loc un eveniment și momentul în care sistemul dumneavoastră l-a primit. O scanare mai veche poate sosi după una mai recentă, în special atunci când actualizările sunt întârziate sau evenimentele istorice sunt furnizate împreună.

Pentru Australia și Noua Zeelandă, evitați aplicarea unui singur decalaj fix de timp tuturor expedierilor. Păstrați marcajele temporale și decalajele sursă atunci când sunt furnizate. Utilizați pentru afișare un fus orar denumit corespunzător atunci când aveți un context fiabil privind locația și țineți cont de diferențele de ora de vară. Dacă fusul orar al sursei lipsește, păstrați această incertitudine în loc să inventați o conversie UTC precisă.

Implementați un flux fiabil de preluare a datelor

1. Creați mai întâi expedierea internă. Înregistrați relația cu comanda, ruta, selecția transportatorului și identificatorul de urmărire înainte de înregistrarea la serviciul de urmărire.
2. Trimiteți înregistrarea de urmărire. Utilizați formatul de solicitare documentat de furnizor. Stocați răspunsul și faceți diferența între înregistrarea reușită și disponibilitatea ulterioară a evenimentelor transportatorului.
3. Clasificați erorile. Separați datele de intrare invalide și problemele de autentificare de defecțiunile temporare ale serviciului. Reîncercați numai atunci când o nouă încercare poate ajuta în mod rezonabil.
4. Primiți sau preluați actualizările. Implementați mecanismul de livrare acceptat de API-ul ales. Dacă utilizați webhooks, validați solicitările primite folosind metoda documentată de furnizor și procesați evenimentele acceptate printr-o coadă persistentă.
5. Eliminați duplicatele înainte de aplicarea modificărilor. Utilizați, atunci când este disponibil, un identificator de eveniment al furnizorului sau o cheie compozită proiectată cu atenție. Livrarea repetată nu trebuie să declanșeze notificări repetate către clienți.
6. Recalculați starea expedierii. Evaluați semnificația și cronologia evenimentelor în loc să înlocuiți starea actuală cu actualizarea sosită ultima.
7. Reconciliați înregistrările incomplete. Atunci când API-ul acceptă preluarea datelor, utilizați această funcție pentru a investiga actualizările omise sau înregistrările învechite în limitele de utilizare aplicabile.

Păstrați autentificarea specifică furnizorului, numele câmpurilor și gestionarea erorilor într-un adaptor. Sistemul dumneavoastră de gestionare a comenzilor ar trebui să consume modelul intern al expedierii, nu să depindă direct de fiecare detaliu al răspunsului unui furnizor. Această separare facilitează și testarea modificărilor ulterioare ale API-ului.

Gestionați călătoriile trans-Tasmaniene fără a inventa certitudini

Urmărirea transfrontalieră necesită mai mult context decât o succesiune de etichete de stare. Aplicația dumneavoastră ar trebui să distingă un eveniment de export, un eveniment legat de vamă, un transfer între transportatori și un eveniment de livrare finală atunci când datele sursă permit aceste distincții.

Nu deduceți vămuirea dintr-o scanare generică „în tranzit”. În mod similar, absența unei scanări recente nu dovedește că vama reține coletul. Un mesaj util pentru client indică ultimul eveniment confirmat și momentul acestuia, apoi explică orice acțiune următoare pe care echipa dumneavoastră o poate sprijini efectiv.

Păstrați originea și destinația separate de locația scanării. O expediere care călătorește din Australia în Noua Zeelandă nu devine o expediere internă din Noua Zeelandă doar pentru că a primit o scanare de sosire. Această distincție este importantă pentru raportarea rutelor și atribuirea responsabilității pentru excepții.

Dacă este implicat un partener de livrare, legați înregistrarea sa de urmărire numai atunci când relația este susținută de datele expedierii, de serviciul de urmărire sau de o înregistrare verificată operațional. Nu îmbinați coletele doar pentru că identificatorii par similari.

Transformați evenimentele de urmărire în actualizări utile pentru clienți

Pagina destinată clienților ar trebui să răspundă la patru întrebări: care este ultima stare confirmată, când s-a produs, unde a fost înregistrată dacă se cunoaște și trebuie clientul să întreprindă o acțiune?

Păstrați regulile de notificare separate de preluarea evenimentelor. Nu orice scanare merită un e-mail sau un mesaj text. Definiți tranziții semnificative, precum prima mișcare confirmată, tentativa de livrare, necesitatea ridicării sau evenimentul de livrare și suprimați alertele repetate pentru aceeași tranziție.

• Urmărire învechită: Indicați momentul ultimei actualizări fără a trata tăcerea ca dovadă a pierderii coletului.
• Estimări de livrare: Faceți diferența între o estimare furnizată de transportator și o promisiune a comerciantului. Nu inventați o dată atunci când niciuna nu există.
• Excepții: Oferiți un pas următor concret atunci când este cunoscut, în loc să afișați o etichetă de eroare neexplicată.
• Contestații privind livrarea: Păstrați evenimentul sursă și direcționați cazul către asistență; o stare „livrat” nu soluționează singură orice contestație a clientului.

Protejați paginile de urmărire la fel ca datele de autentificare API. Evitați expunerea detaliilor inutile despre adresă sau contact, păstrați datele de autentificare ale serviciului pe server și aplicați controale de acces adecvate informațiilor afișate.

Derulați un proiect pilot bazat pe rute înainte de lansare

Testați expedieri interne din Australia, expedieri interne din Noua Zeelandă, expedieri din Australia către Noua Zeelandă și expedieri din Noua Zeelandă către Australia, atunci când aceste rute sunt relevante pentru activitatea dumneavoastră. Includeți livrări obișnuite și cazuri-limită operaționale: comenzi divizate, numere nerecunoscute, transferuri, tentative de livrare, evenimente de ridicare, retururi și scanări sosite cu întârziere.

Utilizați înregistrări reale ale expedierilor, cu permisiuni adecvate, pentru validarea transportatorului. Utilizați evenimente sintetice pentru a testa reziliența propriei aplicații, dar nu tratați rezultatele sintetice ca dovezi ale acoperirii transportatorilor activi.

• Verificarea identității: Fiecare actualizare ajunge la expedierea și comanda corecte.
• Verificarea cronologiei: Evenimentele sosite în ordine greșită nu inversează incorect progresul livrării.
• Verificarea recuperării: Defecțiunile temporare și actualizările duplicate nu duc la pierderea datelor sau la repetarea alertelor.
• Verificarea asistenței: Agenții pot inspecta evenimentul original și pot înțelege starea afișată clientului.
• Verificarea comercială: Utilizarea estimată se încadrează în modelul de facturare și limitele verificate ale contului.

Stabiliți pragurile de acceptare înainte de evaluarea proiectului pilot. Măsurați rezultatele înregistrărilor, evenimentele nemapate, întârzierile de procesare, notificările duplicate și expedierile învechite nerezolvate. Separați întârzierile datelor transportatorului de întârzierile din propria aplicație, astfel încât remedierea să ajungă la responsabilul potrivit.

Implementarea este pregătită atunci când echipa dumneavoastră poate explica și recupera expedierile urmărite incomplet, nu doar afișa livrări reușite. Un singur API simplifică conectivitatea; modelul expedierii, regulile evenimentelor și procedurile operaționale fac această conectivitate fiabilă.

Întrebări frecvente

Un singur API de urmărire înlocuiește integrările de expediere ale transportatorilor?

Nu neapărat. Urmărirea, crearea etichetelor, programarea ridicărilor, calcularea tarifelor și documentația vamală sunt funcții separate. Verificați domeniul de aplicare al produsului selectat și păstrați celelalte integrări acolo unde procesul dumneavoastră de procesare a comenzilor are nevoie de ele.

Pot înregistra un număr de urmărire înainte de prima scanare a transportatorului?

Verificați regulile de înregistrare ale API-ului. Proiectați aplicația astfel încât să distingă între o înregistrare de urmărire acceptată și o deplasare fizică confirmată. O înregistrare fără evenimente nu ar trebui afișată automat ca fiind în tranzit.

Va furniza un singur API actualizări în timp real pentru fiecare transportator?

Nu presupuneți acest lucru. Actualitatea de la un capăt la altul depinde de momentul în care transportatorul publică datele, de momentul în care serviciul de urmărire le obține și de momentul în care aplicația dumneavoastră le procesează. Confirmați comportamentul actualizărilor pentru combinațiile transportator-serviciu pe care le utilizați.

Ce ar trebui să se întâmple atunci când numărul de urmărire se schimbă?

Păstrați identificatorul original și atașați identificatorul de înlocuire sau al partenerului, verificat, aceleiași expedieri interne. Păstrați ambele istorice și împiedicați înregistrările duplicate să genereze notificări contradictorii.

Este 17TRACK relevant pentru această integrare?

Da. API-ul său de urmărire este relevant pentru integrarea multi-transportator descrisă aici. Evaluați-l utilizând eșantioane de expedieri din Australia și Noua Zeelandă și confirmați suportul pentru transportatori, comportamentul tehnic și condițiile contului prin resursele oficiale ale API-ului înainte de implementare.

Surse

• API-ul de urmărire 17TRACK — resursă oficială a produsului pentru opțiunea API discutată în acest ghid.
• Documentația API 17TRACK — referință tehnică oficială pentru verificarea formatelor solicitărilor, a cerințelor de integrare și a comportamentului acceptat.