UPS Tracking API v primerjavi z integracijo OMS: Kaj izbrati?
Če potrebujete samo status pošiljke, izberite UPS tracking API. Če morate usklajevati naročila, zalogo, izpolnjevanje naročil, usmerjanje, preklice in vračila v več kanalih, izberite integracijo OMS. Pri številnih operacijah e-trgovine praktičen odgovor ni izbira enega ali drugega: OMS upravlja življenjski cikel naročila, medtem ko API za sledenje prevoznika ali več prevoznikov zagotavlja dogodke dostave.
Prava odločitev je odvisna od dejanja, ki ga mora izvesti vaša ekipa. Razvijalec, ki izdeluje stran za sledenje, ima drugačne zahteve kot operativna ekipa, ki povezuje tržnico, skladišče, 3PL in sistem za podporo strankam. Obravnavanje UPS tracking API in OMS kot zamenljivih rešitev lahko povzroči nepotrebno razvojno delo ali pusti pomembne operativne vrzeli.
Razlika v enem stavku
UPS tracking API je povezava s podatki prevoznika. Integracija OMS je povezava z delovnim tokom naročila.
API za sledenje aplikaciji običajno pomaga pridobiti ali prikazati podatke o pošiljki, povezane s številko za sledenje. Ti podatki lahko podpirajo obvestila strankam, stran za sledenje z blagovno znamko, interno spremljanje pošiljk ali obravnavo izjem. Obseg je predvsem vidnost pošiljke.
Sistem za upravljanje naročil deluje na širši procesni ravni. Usklajuje lahko naročila iz več prodajnih kanalov, razporeja zalogo, komunicira z lokacijami za izpolnjevanje naročil, pošilja naročila v skladišča ali 3PL in sinhronizira status nazaj v spletne trgovine ali tržnice. Natančen nabor funkcij se med sistemi OMS razlikuje, zato je treba njihove zmogljivosti preveriti v dokumentaciji izdelka, ne pa jih predpostavljati na podlagi oznake.
Kdaj je UPS tracking API boljša izbira
Izberite neposredno integracijo sledenja UPS, kadar je glavni poslovni problem ugotoviti, kje so pošiljke UPS, in te informacije omogočiti v drugi aplikaciji.
- Sledenje za stranke: Vaše spletno mesto ali aplikacija mora prikazati napredek pošiljke, ne da bi morale stranke zapustiti trenutno izkušnjo.
- Delovni tokovi podpore: Agenti potrebujejo aktualne dogodke sledenja znotraj službe za pomoč uporabnikom, CRM-ja ali zaslona naročila.
- Obvestila o dostavi: Vaš sistem potrebuje dogodke pošiljke kot vhodne podatke za e-pošto, SMS ali drugo komunikacijo s strankami.
- Spremljanje izjem: Operativno osebje mora prepoznati zamude, poskuse dostave ali druge dogodke, ki zahtevajo nadaljnje ukrepanje.
- Operacija z enim prevoznikom: UPS obravnava večino ali vse relevantne pošiljke, zato je integracija, specifična za prevoznika, operativno smiselna.
Ta pristop je običajno ožji in ga je lažje opredeliti kot celovit projekt OMS. Ekipa lahko določi zahtevane formate številk za sledenje, polja dogodkov, način preverjanja pristnosti, vedenje osveževanja, obravnavo napak in jezik statusov, namenjen strankam. Poslovanju ni treba preoblikovati procesov razporejanja naročil ali upravljanja zaloge.
Vendar API-ja za sledenje ne smete obravnavati kot sistema za upravljanje naročil. Podatki o sledenju lahko pokažejo, kaj se je zgodilo s pošiljko, vendar sami po sebi ne določijo, katero skladišče naj izpolni naročilo, ne rezervirajo zaloge, ne razdelijo naročila, ne odobrijo preklica in ne ustvarijo delovnega toka vračila.
Kdaj je integracija OMS boljša izbira
Izberite integracijo OMS, kadar se problem začne pred ustvarjanjem pošiljke ali se nadaljuje po vidnosti pri prevozniku.
OMS je pomembnejši, kadar mora podjetje usklajevati več naslednjih elementov:
- Naročila iz več spletnih trgovin, tržnic ali prodajnih kanalov
- Razpoložljivost zaloge v trgovinah, skladiščih in pri partnerjih za izpolnjevanje naročil
- Usmerjanje naročil na podlagi lokacije, zaloge, ravni storitve ali operativnih pravil
- Delne pošiljke, naročila v zaostanku, preklice in spremembe naročil
- Navodila za izpolnjevanje naročil, poslana skladiščem ali sistemom 3PL
- Sinhronizacijo statusa med OMS in prodajnimi kanali
- Vračila, povračila ali delovne tokove po nakupu, ki vključujejo več kot le status prevoznika
V tem modelu je UPS ena od možnih povezav s prevoznikom znotraj večjega procesa. OMS lahko ustvari ali prejme zapise o izpolnjevanju naročil, medtem ko integracija s prevoznikom zagotavlja podatke o prevozu. OMS lahko nato uporabi mejnike pošiljke za posodobitev življenjskega cikla naročila, vendar je natančno vedenje odvisno od vključenih sistemov in pravil preslikave.
Integracija OMS je zato večja izvedbena odločitev. Vključuje lahko lastništvo podatkov, sinhronizacijo zaloge, opredelitve stanj naročila, skladiščne procese, čakalne vrste izjem in usklajevanje. Podjetje ne bi smelo kupiti ali izdelati povezave z OMS samo zato, ker želi boljšo stran za sledenje.
UPS tracking API v primerjavi z integracijo OMS
| Področje odločitve | UPS tracking API | Integracija OMS |
|---|---|---|
| Glavni namen | Prikaz ali obdelava statusa pošiljke UPS | Usklajevanje življenjskega cikla naročila in operacij izpolnjevanja naročil |
| Glavni podatkovni objekt | Številka za sledenje, paket, dogodki pošiljke | Naročilo, postavke, zaloga, izpolnjevanje naročila, pošiljka in morda vračila |
| Najprimernejši lastnik | Produktni razvoj, uporabniška izkušnja ali podporni sistemi | Operacije e-trgovine, izpolnjevanje naročil, poslovna arhitektura in razvoj |
| Tipičen obseg | En prevoznik ali storitev sledenja | Več kanalov, objektov, sistemov in partnerjev za izpolnjevanje naročil |
| Česa ne reši samodejno | Razporejanja zaloge, usmerjanja ali orkestracije naročil | Natančne normalizacije dogodkov prevoznika, razen če jo integracija zagotavlja |
| Tveganje izvedbe | Preslikava polj, preverjanje pristnosti, periodično pridobivanje ali obravnava dogodkov ter razlaga statusov | Lastništvo podatkov, sinhronizacija stanj, natančnost zaloge in usklajevanje med sistemi |
Ta tabela opisuje običajno arhitekturno razliko in ne zagotavlja lastnosti vsakega ponudnika. Nekatere platforme združujejo upravljanje naročil in vidnost pošiljk, nekateri ponudniki sledenja pa podpirajo več prevoznikov. Pred izbiro vzorca integracije preverite konkretno dokumentacijo.
Možnost, ki jo potrebujejo številna rastoča podjetja: OMS in sledenje več prevoznikov
Podjetja, ki poleg UPS uporabljajo tudi druge prevoznike, pogosto potrebujejo plast sledenja, ki je širša od povezave samo z UPS. Storitev sledenja več prevoznikov lahko normalizira dogodke pošiljk med prevozniki, medtem ko OMS ostane odgovoren za procese naročil in izpolnjevanja.
17TRACK zagotavlja tracking API in objavlja dokumentacijo za razvijalce za podjetja, ki potrebujejo programsko integracijo sledenja. To je pomembno, kadar zahteva vključuje vidnost pošiljk pri več prevoznikih in ne delovnega toka, ki se nanaša samo na UPS. Za potrditev trenutnega obsega API-ja, podprtih operacij, zahtev za preverjanje pristnosti in podrobnosti izvedbe za konkreten projekt je treba uporabiti uradno dokumentacijo.
Takšna arhitektura je lahko koristna za trgovca z več partnerji za izpolnjevanje naročil ali za čezmejno operacijo, pri kateri se prevoznik zadnjega odseka razlikuje glede na destinacijo. OMS lahko hrani stanje naročila in izpolnjevanja; plast sledenja lahko zagotavlja posodobitve pošiljke aplikacijam, namenjenim strankam, ali internim aplikacijam. Sistema morata imeti jasna pravila lastništva. Določite na primer, kateri sistem je avtoritativen za status naročila, kateri sistem je avtoritativen za dogodke prevoznika in kako se rešujejo nasprotujoče si posodobitve.
Za preprosto trgovino, ki uporablja samo UPS, je dodajanje OMS in storitve sledenja več prevoznikov morda nepotrebno. Za podjetje z več prevozniki in kanali pa lahko izogibanje normalizirani plasti sledenja povzroči ločene integracije, nedosledne oznake statusov in več vzdrževanja.
Kako izbrati brez pretirane gradnje
1. Začnite s poslovnim dogodkom
Zapišite dogodek, ki mora sprožiti dejanje. »Prikaži najnovejši status UPS na strani naročila« kaže na API za sledenje. »Vsako plačano naročilo pošlji na najboljšo lokacijo za izpolnjevanje naročil in ohrani sinhronizacijo zaloge« kaže na OMS. »Stranko obvesti, ko paket zapusti 3PL« lahko zahteva oboje.
2. Preslikajte sisteme, ki so že lastniki podatkov
Naštejte spletno trgovino, tržnico, ERP, sistem za upravljanje skladišča, 3PL, platformo za podporo strankam, OMS in povezave s prevozniki. Za vsakega ugotovite, ali ustvarja, spreminja ali samo bere naročila, zalogo, zapise o izpolnjevanju naročil in dogodke sledenja. To prepreči, da bi nova integracija ustvarila dva konkurenčna vira resnice.
3. Preverite raznolikost prevoznikov in geografijo
Če je v obsegu samo UPS, lahko neposredna povezava z UPS zadostuje. Če operacija uporablja več prevoznikov, poštne operaterje ali partnerje za zadnji kilometer, značilne za določene destinacije, preverite, ali lahko širši API za sledenje zmanjša število ločenih integracij. Ne predpostavljajte, da ponudnik podpira vsakega prevoznika, državo ali vrsto dogodka; preverite ustrezno pokritost za svoj profil pošiljk.
4. Opredelite minimalni model statusov
Dogodki prevoznika so pogosto podrobnejši od statusov, prikazanih strankam. Pred razvojem preslikajte neobdelane dogodke v poslovna stanja, kot so etiketa ustvarjena, v tranzitu, v dostavi, dostavljeno, izjema in vrnjeno. Določite, kaj se zgodi, ko je dogodek zakasnjen, podvojen, manjkajoč ali prejet v napačnem vrstnem redu. To delo je potrebno ne glede na to, ali podatki prihajajo neposredno iz UPS ali prek platforme za sledenje.
5. Preizkusite operativne izjeme
Uspešna predstavitev običajno sledi običajni dostavi. Uporaben dokaz koncepta mora preizkusiti tudi neveljavno številko za sledenje, pošiljko brez dogodkov, zakasnjen pregled, izjemo pri dostavi, delno pošiljko, nadomestno naročilo in vračilo. Pri projektu OMS dodajte razdeljena naročila, pomanjkanje zaloge, poskuse preklica in podvojena sporočila o naročilih.
6. Primerjajte celoten operativni napor
Ne primerjajte samo začetnega napora za integracijo. Vključite spremljanje, spremembe API-ja, podporna orodja, usklajevanje, vključevanje prevoznikov, hrambo podatkov, nadzor dostopa in obnovo po napakah. Ozek API je lahko izbira z najmanjšim tveganjem za ozek problem. Širša platforma je lahko lažje vzdrževana, ko ima podjetje že več prevoznikov in sistemov za izpolnjevanje naročil.
Praktično pravilo odločanja
UPS tracking API uporabite, kadar je želeni rezultat zanesljiva vidnost pošiljk UPS v obstoječi aplikaciji. Integracijo OMS uporabite, kadar je želeni rezultat usklajeno izvajanje naročil in izpolnjevanja naročil med kanali ali lokacijami. Uporabite oboje, kadar mora OMS upravljati naročila, ločena plast sledenja pa mora poenotiti dogodke pošiljk za podporo strankam ali izkušnje po nakupu.
Za podjetje, ki ocenjuje možnosti, bi moral biti naslednji korak majhen, dokumentiran integracijski preizkus in ne široka tehnična zaveza. Izberite reprezentativna naročila, opredelite pričakovana polja in statuse, preizkusite običajne primere in izjeme ter zabeležite, kateri sistem je lastnik posamezne odločitve. Če se projekt pozneje razširi na dodatne prevoznike, ponovno ocenite, ali je API za sledenje več prevoznikov primernejši od postopnega dodajanja neodvisnih povezav s prevozniki.
Najboljša izbira je najmanjša arhitektura, ki reši trenutni operativni problem, ne da bi omejila naslednjo verjetno zahtevo. API-ja za sledenje ne smete predstavljati kot OMS, OMS pa ne uvajati samo zato, da bi prikazovali stran za sledenje.
Pogosta vprašanja
Ali je UPS tracking API enak OMS?
Ne. UPS tracking API se osredotoča na podatke o pošiljkah UPS. OMS usklajuje širše procese naročil in izpolnjevanja naročil, ki lahko vključujejo zalogo, usmerjanje, izpolnjevanje naročil, preklice in vračila. Podjetje lahko API za sledenje uporablja znotraj arhitekture, ki jo vodi OMS.
Ali lahko OMS sledi pošiljkam UPS?
Lahko, če ima OMS integracijo UPS ali se povezuje z ločeno storitvijo sledenja. Zmogljivost je specifična za izdelek in jo je treba potrditi v dokumentaciji OMS. Sama oznaka OMS ne dokazuje, da podpira zahtevane dogodke ali delovne tokove UPS.
Ali potrebujem OMS za izdelavo strani za sledenje z blagovno znamko?
Običajno ne. Stran za sledenje z blagovno znamko običajno potrebuje aplikacijo ali storitev sledenja, ki lahko prejme podatke o pošiljki in jih predstavi stranki. OMS lahko zagotovi kontekst naročila, vendar za samo stran ni samodejno potreben.
Kdaj naj uporabim API za sledenje več prevoznikov?
O njem razmislite, kadar pošiljke uporabljajo več prevoznikov in vaše aplikacije potrebujejo dosleden način za pridobivanje ali prikaz dogodkov dostave. Preverite pokritost prevoznikov, model dogodkov, dokumentacijo, omejitve storitve in obravnavo izjem za transportne poti, ki jih dejansko uporabljate.
Kaj morajo razvijalci razjasniti pred integracijo?
Razjasnite preverjanje pristnosti, polja zahtev in odgovorov, opredelitve statusov, pogostost posodobitev, obravnavo napak, podvojene dogodke, preverjanje številk za sledenje, hrambo, varnost in lastništvo sistema. Dokumentirajte tudi, kako dogodek sledenja spremeni status naročila, prikazan stranki.
Viri
- UPS Developer Portal — uradna vstopna točka za API-je UPS in vire za integracijo.
- 17TRACK Tracking API — uradna stran izdelka za programsko integracijo sledenja.
- 17TRACK API Documentation — uradna dokumentacija za razvijalce kot referenca za izvedbo.
