API za sledenje v primerjavi z API-jem za pošiljanje: katerega potrebuje vaš sistem e-trgovine (ali oba)?

Uporabite API za pošiljanje, kadar mora vaš e-trgovinski sklop ustvarjati pošiljke in generirati nalepke za pošiljanje. Uporabite API za sledenje, kadar mora po odpremi spremljati pošiljke in posodobitve prevoznikov pretvoriti v uporabne operativne informacije ali informacije za stranke. Obe zmogljivosti potrebujete, če mora vaša programska oprema upravljati ustvarjanje pošiljk in preglednost po nakupu, vendar nujno ne potrebujete dveh ponudnikov ali dveh ločenih integracij.

Odločitev pripada osebi, ki je odgovorna za vašo arhitekturo izpolnjevanja naročil: običajno vodji e-trgovinskih operacij, ki sodeluje z inženirsko ekipo. Najprej ugotovite, kaj vaša trgovina, skladišče ali partner za izpolnjevanje naročil že obravnava. Dodajanje drugega API-ja mora zapolniti določeno vrzel, ne pa podvajati delovnega toka, ki že deluje.

Kakšna je razlika med API-jem za sledenje in API-jem za pošiljanje?

Razlika se nanaša predvsem na nalogo, ki jo opravlja posamezni API, in ne na strogo mejo med kategorijami izdelkov. Platforma za pošiljanje lahko vključuje končne točke za sledenje, storitev za sledenje pa lahko zagotavlja orodja za obvestila in posodobitve dostave za stranke. Ocenite dokumentirane končne točke in vedenje dogodkov, namesto da se zanašate na ime izdelka.

Razsežnost odločitve	API za sledenje	API za pošiljanje
Glavna naloga	Pridobivanje ali prejemanje statusa pošiljke in dogodkov sledenja.	Ustvarjanje pošiljk ter pridobivanje nalepk in povezanih dokumentov za pošiljanje.
Običajni vnosi	Številka za sledenje, identifikator prevoznika in vse dodatne zahtevane podrobnosti pošiljke.	Podatki o pošiljatelju in prejemniku, informacije o paketu, izbira storitve in veljavni carinski podatki.
Običajni izhodi	Status pošiljke, zgodovina dogodkov in druge razpoložljive informacije o dostavi.	Identifikatorji pošiljke, nalepke in podprti dokumenti.
Glavni delovni tok	Preglednost dostave, obravnava izjem in posodobitve po nakupu.	Odprema iz skladišča in priprava odhodnih pošiljk.
Česa ne smete predpostaviti	Da dostop do sledenja vključuje ustvarjanje nalepk ali rezervacijo prevoznika.	Da ustvarjanje nalepk vključuje globino sledenja in nadzor obvestil, ki ju potrebujete.

Dokumentacija prevoznikov ponazarja to ločitev. FedEx dokumentira ustvarjanje pošiljk v svoji dokumentaciji API-ja Ship in zmogljivosti sledenja v svoji dokumentaciji API-ja za sledenje. To so primeri različnih tehničnih odgovornosti in ne priporočilo za izbiro določenega prevoznika.

Ustvarjanje pošiljke ni isto kot spremljanje njenega premikanja

Uspešen odgovor pri ustvarjanju pošiljke vaši programski opremi pove, da je bila zahteva za pošiljanje obdelana. Ne potrjuje pa, da je prevoznik paket fizično prejel. Prav tako lahko številka za sledenje obstaja, še preden se v zgodovini sledenja pojavi premik.

Vaš sistem za upravljanje naročil bi moral zato ločevati med ustvarjanjem nalepke, predajo v skladišču, sprejemom pri prevozniku in dostavo. Če vse to obravnavate kot en sam dogodek »odposlano«, lahko pošljete prezgodnja sporočila strankam in spregledate pakete, ki dejansko še niso zapustili skladišča.

Izberite zmogljivost, ki odpravi vaše trenutno ozko grlo

Izberite API za pošiljanje, kadar manjka odprema

API za pošiljanje je ustrezna začetna točka, kadar mora vaša aplikacija podatke o naročilu pretvoriti v pošiljko. Primeri vključujejo skladiščno ekipo, ki naslove ročno prepisuje v portale prevoznikov, ali prilagojen sistem za upravljanje naročil, ki ne more ustvarjati nalepk.

Pred izbiro integracije opredelite dejanski delovni tok odpreme. Potrebujete samo ustvarjanje pošiljk ali tudi pridobivanje cen, preklic, zahteve za prevzem, carinsko dokumentacijo ali postopke ob koncu dneva? Te funkcije so lahko ločeni API-ji, odvisne od prevoznika ali pa zahtevajo dodatna dovoljenja računa. Ne predpostavljajte, da izdelek z oznako »API za pošiljanje« vključuje vsako operacijo pošiljanja.

Ni idealen kot edina rešitev: integracija za ustvarjanje nalepk, zaradi katere mora vaša ekipa za podporo strankam preverjati posamezna spletna mesta prevoznikov. Reši lahko odpremo, medtem ko preglednost dostave ostane večinoma nespremenjena.

Izberite API za sledenje, kadar ustvarjanje pošiljk že deluje

API za sledenje je primernejša neposredna rešitev, kadar vaš sistem za upravljanje skladišča, partner za izpolnjevanje naročil, tržnica ali obstoječa integracija za pošiljanje že ustvarja nalepke, vendar so informacije o dostavi razpršene.

V takem primeru lahko zamenjava delovnega toka za nalepke povzroči dodatno migracijsko delo, ne da bi rešila osrednji problem. Namesto tega povežite številke za sledenje, ustvarjene v predhodnem sistemu, s plastjo preglednosti, ki jo lahko uporabljajo vaš sistem za upravljanje naročil, podporna orodja in komunikacija s strankami.

V tej kategoriji je 17TRACK Tracking API ustrezna možnost integracije. Njegova uradna dokumentacija API-ja opisuje registracijo številk za sledenje in delovne tokove podatkov sledenja, vključno s potisnimi obvestili. Te delovne tokove ocenite glede na zahtevane prevoznike, vrste pošiljk in arhitekturo aplikacije. To je premislek na ravni sledenja in ne dokaz, da storitev nadomešča integracijo za ustvarjanje nalepk.

Ni idealen kot edina rešitev: API za sledenje, kadar vaša programska oprema še vedno nima načina za ustvarjanje pošiljk, za odpremo katerih je odgovorna. Preglednost sledenja ne reši manjkajoče izvedbe pošiljanja.

Uporabite oboje, kadar je vaša aplikacija odgovorna za odpremo in preglednost dostave

Obe zmogljivosti sta ustrezni, kadar mora vaš sklop ustvarjati nalepke in nato vzdrževati zanesljiv pregled nad napredkom pošiljk. Izvirata lahko iz ene platforme, ločenih storitev ali kombinacije integracij prevoznikov in plasti sledenja.

Prednost dajte eni integraciji, kadar njene funkcije pošiljanja in sledenja izpolnjujejo vaše dokumentirane zahteve brez nepotrebnih kompromisov. Razmislite o ločenih integracijah, kadar je obstoječi delovni tok za pošiljanje vredno ohraniti ali kadar se zahteve glede sledenja bistveno razlikujejo od tega, kar ta delovni tok zagotavlja. Ločen ponudnik sledenja ni samodejno boljši; upravičiti mora dodatno integracijo, obračunavanje in operativno odgovornost.

Kako se oba API-ja vključujeta v e-trgovinski sklop

Praktična zasnova obravnava naročilo, pošiljko in dogodek sledenja kot ločene zapise. Eno naročilo lahko ustvari več paketov, vsak paket pa ima lahko svojo zgodovino sledenja. Status naročila, prikazan stranki, naj izhaja iz teh zapisov pošiljk, namesto da bi jih prepisal.

1. Naročilo je pripravljeno na izpolnitev. Trgovina ali sistem za upravljanje naročil pošlje zahtevane podatke o izpolnitvi odgovornemu skladišču.
2. Delovni tok pošiljanja ustvari pošiljko. Aplikacija shrani vrnjeni identifikator pošiljke, številko za sledenje, prevoznika, storitev in sklic na nalepko.
3. Skladišče dokonča predajo. Potrditev skladišča in sprejem pri prevozniku ostaneta ločena dogodka.
4. Začne se delovni tok sledenja. Aplikacija registrira ali pošlje številko za sledenje, kot zahteva izbrana integracija.
5. Posodobitve sledenja dosežejo vašo aplikacijo. Spletni kavlji, poizvedovanje ali podprta kombinacija napolnijo zapis pošiljke.
6. Poslovna pravila določijo naslednji korak. Sistem posodobi status, prikazan stranki, ustvari operativno nalogo ali pošlje sporočilo, ko so izpolnjeni ustrezni pogoji.

Trgovec, ki uporablja zunanje skladišče za izpolnjevanje naročil, lahko na primer v svoji programski opremi potrebuje le korake od štiri do šest. Skladišče je že odgovorno za ustvarjanje pošiljk. Trgovec, ki upravlja lastno skladišče, lahko potrebuje celoten potek.

Vsakemu nadaljnjemu dejanju določite enega odgovornega

Če obe integraciji zagotavljata posodobitve sledenja, določite, kateri sistem nadzoruje obvestila strankam in status pošiljke, prikazan v vaši trgovini. V nasprotnem primeru lahko stranke prejmejo podvojena sporočila ali vidijo nasprotujoča si stanja dostave.

Za preiskovanje lahko obdržite sekundarne podatke, ne da bi vsakemu viru dovolili sprožiti e-poštno sporočilo. Ohranite izvirni dogodek prevoznika skupaj z notranjim preslikavanjem statusa, da lahko podporno osebje razume, zakaj je sistem pošiljko razvrstil na določen način.

Primerjajte operativno ustreznost, ne oznak funkcij

Preverite prevoznike in storitve, ki jih dejansko uporabljate

Podpora prevoznikom ni enostavno vprašanje z odgovorom da ali ne. Storitev lahko podpira sledenje za prevoznika, ne da bi podpirala ustvarjanje nalepk zanj. Ustvarjanje nalepk je lahko odvisno tudi od države izvora, nastavitve računa prevoznika ali upravičenosti do storitve.

Ustvarite seznam testov na podlagi svojih dejanskih transportnih poti. Vključite domače pakete, mednarodne pošiljke in vse predaje med transportnimi partnerji. Za vsako potrdite zahtevano operacijo: ustvarjanje pošiljke, sledenje ali oboje. Široka izjava o pokritosti je manj uporabna kot uspešni testi storitev, od katerih je odvisno vaše poslovanje.

Preverite pomen dogodkov in popolnost podatkov

Pri sledenju preverite, kaj se zgodi pred prvim skenom, med izjemo pri dostavi, po neuspešnem poskusu dostave in ob dostavi. Preverite, ali časovni žigi vključujejo informacije o časovnem pasu in ali izvirni opisi prevoznika ostanejo na voljo.

Normaliziranega statusa ne razlagajte kot zagotovilo za enake podatke pri vsakem prevozniku. Predvideni datumi dostave, podrobnosti o lokaciji in informacije o dokazilu o dostavi so lahko odvisni od osnovnega prevoznika in pošiljke. Določite, kako se bo vaš vmesnik obnašal, kadar ta polja niso na voljo.

Preverite obnovitev po napakah na obeh straneh

Pri pošiljanju si posebno pozornost zasluži časovna omejitev med ustvarjanjem pošiljke: zahteva je bila morda uspešna, čeprav vaša aplikacija ni prejela odgovora. Pred slepim ponavljanjem preverite podprte mehanizme ponudnika za preprečevanje podvajanja in usklajevanje.

Pri sledenju preizkusite podvojena obvestila, zakasnele dogodke, neuspešno dostavo spletnega kavlja in začasne izpade končne točke. V ustrezni dokumentaciji potrdite preverjanje pristnosti, vedenje pri ponovnih poskusih in možnosti obnovitve. Obdelavo dogodkov zasnujte tako, da ponovno predvajanje posodobitve ne pošlje istega obvestila stranki še enkrat.

Primerjajte skupne operativne stroške, ne da bi predpostavljali model cen

Stroške API-ja ločite od poštnine in stroškov računa pri prevozniku. Storitve pošiljanja in sledenja lahko uporabljajo različne obračunske enote, združena platforma pa lahko zmogljivosti pakira drugače. Pridobite ponudbo ali preglejte veljavni paket za natančen delovni tok, ki ga nameravate izvajati.

Vprašajte, kako je opredeljena obračunljiva uporaba, ali se štejejo neuspešne zahteve, kako se obravnavajo ponavljajoče se predložitve sledenja in kaj se zgodi, ko uporaba preseže dovoljeno količino. Vključite vzdrževanje s strani inženiringa, trud podpore in stroške ohranjanja skladnosti dveh integracij. Brez opredeljene sestave pošiljk in trenutnih komercialnih pogojev bi bila izjava, da je ena kategorija cenejša, zavajajoča.

Preglejte varnost in hranjenje podatkov

Integracije za pošiljanje lahko obdelujejo naslove prejemnikov in carinske informacije. Integracije za sledenje lahko obdelujejo tudi identifikatorje pošiljk in povezane podatke o strankah. Potrdite, katera polja so zahtevana, omejite poverilnice na potreben dostop in skrivnosti hranite zunaj kode na strani brskalnika.

Hranjenje, brisanje in nadzor dostopa preglejte glede na svoje poslovne zahteve. Priročna integracija ne bi smela zahtevati pošiljanja podatkov o strankah, ki jih delovni tok ne potrebuje.

Praktični načrt preverjanja pred zavezo

Izvedite dokaz koncepta z reprezentativnimi pošiljkami in ne le z uspešnim primerom iz vodnika za hiter začetek. Z operacijami, inženiringom in podporo strankam se dogovorite o merilih sprejemljivosti.

• Odprema: ustvarite zahtevane formate nalepk in potrdite, da jih skladiščna oprema lahko uporablja.
• Povezovanje naročil: preizkusite razdeljene pošiljke, več paketov in nadomestne pošiljke, ne da bi izgubili izvirno zgodovino.
• Sledenje: preverite dejanska zaporedja dogodkov za prevoznike in poti, ki so pomembne za vaše poslovanje.
• Izjeme: preverite, ali težava pri dostavi, ki zahteva ukrepanje, doseže pravo ekipo, ne da bi vsak nenavaden sken samodejno obravnavali kot napako.
• Obnovitev: prekinite zahtevo ali končno točko spletnega kavlja in pokažite, kako aplikacija uskladi manjkajoče informacije.
• Komunikacija: potrdite, da vsako obvestilo stranki pošlje le določeni sistem.
• Komercialna ustreznost: ocenite stroške z uporabo pričakovane uporabe in potrjenih opredelitev obračunavanja ponudnika.

Pravilo odločanja: najprej kupite manjkajočo zmogljivost. Če odprema že deluje, ocenite integracijo za sledenje, ne da bi ponovno gradili izpolnjevanje naročil. Če manjka ustvarjanje nalepk, najprej rešite izvedbo pošiljanja. Če je vaša aplikacija odgovorna za celoten življenjski cikel pošiljke, preverite obe zmogljivosti in izberite, ali je združena ali ločena arhitektura za vašo ekipo lažja za upravljanje.

Pogosta vprašanja

Ali API za pošiljanje vedno vključuje sledenje?

Ne. Nekatere storitve vključujejo obe zmogljivosti, druge pa ju izpostavljajo prek ločenih končnih točk, izdelkov ali paketov. Tudi kadar je sledenje vključeno, pred njegovo uporabo kot rešitve za sledenje po nakupu preverite podrobnosti dogodkov, način dostave posodobitev, podporo prevoznikom in pogoje uporabe.

Ali lahko sledim paketom, katerih nalepke je ustvaril partner za izpolnjevanje naročil?

Potencialno da. Vaša aplikacija potrebuje identifikatorje, ki jih zahteva integracija za sledenje, običajno številko za sledenje in, kadar je zahtevano, identifikator prevoznika ali dodatne podatke za preverjanje. Potrdite podporo prevoznikom partnerja in zagotovite zanesljiv pretok številk za sledenje v vaš sistem.

Ali bo API za sledenje povzročil, da se skeni prevoznika izvedejo prej?

Ne more ustvariti fizičnih skenov prevoznika. Vaši aplikaciji lahko pomaga pridobiti, organizirati in posredovati informacije, ki so na voljo prek virov sledenja. Vedenje posodobitev ocenite z dejanskimi pošiljkami, namesto da predpostavljate, da API zagotavlja takojšnjo preglednost vsakega premika.

Ali potrebujem dva ponudnika API-jev za uporabo obeh zmogljivosti?

Ne. Potrebujete obe funkciji, ne nujno dveh ponudnikov. Uporabite enega ponudnika, kadar izpolnjuje vaše zahteve glede pošiljanja in sledenja. Ločite ju, kadar s tem ohranite delujoč delovni tok ali izpolnite posebno zahtevo, ki je združena možnost ne izpolnjuje.

Ali lahko API za sledenje nadomesti sistem za upravljanje naročil?

Ne. Podatki sledenja so vhodni podatki za upravljanje naročil in ne nadomestilo za razporejanje zalog, odločitve o izpolnjevanju, obravnavo plačil ali zapise naročil. Vaša aplikacija mora še vedno vsako pošiljko povezati s pravilnim naročilom in določiti, kako dogodki pošiljke vplivajo na poslovne delovne tokove.

Viri

• Dokumentacija API-ja FedEx Ship — referenca za ustvarjanje pošiljk, nalepke in zahteve delovnega toka pošiljanja.
• Dokumentacija API-ja FedEx za sledenje — referenca za zahteve sledenja in informacije o statusu pošiljke.
• 17TRACK Tracking API — uradna referenca izdelka za kategorijo integracij sledenja.
• Dokumentacija API-ja 17TRACK — referenca za registracijo sledenja, podatke sledenja in integracijo potisnih obvestil.