UPS siuntų sekimo API ar OMS integracija: ką turėtumėte pasirinkti?
Jei jums reikia tik siuntos būsenos, pasirinkite UPS sekimo API. Jei reikia koordinuoti užsakymus, atsargas, užsakymų vykdymą, maršrutizavimą, atšaukimus ir grąžinimus keliuose kanaluose, pasirinkite OMS integraciją. Daugelyje el. prekybos operacijų praktinis atsakymas nėra „arba–arba“: OMS valdo užsakymo gyvavimo ciklą, o vežėjo arba kelių vežėjų sekimo API teikia pristatymo įvykius.
Tinkamas sprendimas priklauso nuo veiksmo, kurį turi atlikti jūsų komanda. Kūrėjo, kuriančio sekimo puslapį, poreikiai skiriasi nuo operacijų komandos, jungiančios prekyvietę, sandėlį, 3PL ir klientų aptarnavimo sistemą. Laikant UPS sekimo API ir OMS tarpusavyje pakeičiamais sprendimais, gali atsirasti nereikalingų kūrimo darbų arba likti svarbių veiklos spragų.
Skirtumas vienu sakiniu
UPS sekimo API yra ryšys su vežėjo duomenimis. OMS integracija yra ryšys su užsakymų darbo eiga.
Sekimo API paprastai padeda programai gauti arba rodyti siuntos informaciją, susietą su sekimo numeriu. Ši informacija gali būti naudojama klientų pranešimams, firminiam sekimo puslapiui, vidiniam siuntų stebėjimui arba išimčių tvarkymui. Pagrindinė apimtis yra siuntos matomumas.
Užsakymų valdymo sistema veikia platesniame proceso lygmenyje. Ji gali koordinuoti užsakymus iš kelių pardavimo kanalų, paskirstyti atsargas, palaikyti ryšį su užsakymų vykdymo vietomis, siųsti užsakymus sandėliams arba 3PL ir sinchronizuoti būseną su internetinėmis parduotuvėmis ar prekyvietėmis. Tikslus funkcijų rinkinys skiriasi priklausomai nuo OMS, todėl jos galimybes reikia patikrinti produkto dokumentacijoje, o ne numanyti iš pavadinimo.
Kada UPS sekimo API yra geresnis pasirinkimas
Rinkitės tiesioginę UPS sekimo integraciją, kai pagrindinė verslo problema yra žinoti, kur yra UPS siuntos, ir pateikti šią informaciją kitoje programoje.
- Sekimas klientams: jūsų svetainėje arba programėlėje reikia rodyti siuntos eigą, neverčiant klientų išeiti iš naudojamos aplinkos.
- Pagalbos procesai: agentams reikia matyti naujausius sekimo įvykius pagalbos tarnybos, CRM arba užsakymo lange.
- Pristatymo pranešimai: jūsų sistemai reikia siuntos įvykių kaip įvesties el. laiškams, SMS ar kitai komunikacijai su klientais.
- Išimčių stebėjimas: operacijų darbuotojai turi nustatyti vėlavimus, bandymus pristatyti ar kitus įvykius, kuriems reikia tolesnių veiksmų.
- Vieno vežėjo veikla: UPS aptarnauja didžiąją dalį arba visas svarbias siuntas, todėl konkretaus vežėjo integracija yra pagrįsta veiklos požiūriu.
Šis metodas paprastai yra siauresnis ir lengviau apibrėžiamas nei visas OMS projektas. Komanda gali nustatyti reikalingus sekimo numerių formatus, įvykių laukus, autentifikavimo metodą, atnaujinimo elgseną, klaidų tvarkymą ir klientams rodomų būsenų formuluotes. Tam nereikia pertvarkyti užsakymų paskirstymo ar atsargų procesų.
Tačiau sekimo API nereikėtų laikyti užsakymų valdymo sistema. Sekimo duomenys gali parodyti, kas nutiko siuntai, tačiau jie savaime nenusprendžia, kuris sandėlis turi įvykdyti užsakymą, rezervuoti atsargas, padalyti užsakymą, patvirtinti atšaukimą ar sukurti grąžinimo procesą.
Kada OMS integracija yra geresnis pasirinkimas
Rinkitės OMS integraciją, kai problema prasideda dar prieš sukuriant siuntą arba tęsiasi ilgiau nei vežėjo pateikiamas matomumas.
OMS yra aktualesnė, kai verslui reikia koordinuoti kelis iš toliau nurodytų aspektų:
- Užsakymus iš kelių internetinių parduotuvių, prekyviečių ar pardavimo kanalų
- Atsargų prieinamumą parduotuvėse, sandėliuose ir pas užsakymų vykdymo partnerius
- Užsakymų maršrutizavimą pagal vietą, atsargas, paslaugos lygį ar veiklos taisykles
- Dalinius pristatymus, atidėtus užsakymus, atšaukimus ir užsakymų pakeitimus
- Užsakymų vykdymo instrukcijų siuntimą sandėliams ar 3PL sistemoms
- Būsenos sinchronizavimą tarp OMS ir pardavimo kanalų
- Grąžinimus, pinigų grąžinimą ar po pirkimo vykstančius procesus, apimančius daugiau nei vežėjo būseną
Šiame modelyje UPS yra vienas iš galimų vežėjų ryšių didesniame procese. OMS gali kurti arba gauti užsakymų vykdymo įrašus, o vežėjo integracija teikia transportavimo informaciją. Tada OMS gali naudoti siuntos etapus užsakymo gyvavimo ciklui atnaujinti, tačiau tiksli elgsena priklauso nuo susijusių sistemų ir atvaizdavimo taisyklių.
Todėl OMS integracija yra didesnis įgyvendinimo sprendimas. Ji gali apimti duomenų nuosavybę, atsargų sinchronizavimą, užsakymo būsenų apibrėžimus, sandėlio procesus, išimčių eiles ir suderinimą. Verslas neturėtų pirkti ar kurti OMS ryšio vien todėl, kad nori geresnio sekimo puslapio.
UPS sekimo API ir OMS integracija
| Sprendimo sritis | UPS sekimo API | OMS integracija |
|---|---|---|
| Pagrindinis tikslas | UPS siuntos būsenos pateikimas arba apdorojimas | Užsakymo gyvavimo ciklo ir užsakymų vykdymo operacijų koordinavimas |
| Pagrindinis duomenų objektas | Sekimo numeris, paketas, siuntos įvykiai | Užsakymas, eilutės, atsargos, užsakymo vykdymas, siunta ir galbūt grąžinimai |
| Tinkamiausias savininkas | Produktų kūrimo, klientų patirties arba pagalbos sistemos | El. prekybos operacijos, užsakymų vykdymas, įmonės architektūra ir inžinerija |
| Įprasta apimtis | Vienas vežėjas arba sekimo paslauga | Keli kanalai, objektai, sistemos ir užsakymų vykdymo partneriai |
| Ko ji automatiškai neišsprendžia | Atsargų paskirstymo, maršrutizavimo ar užsakymų koordinavimo | Tikslaus vežėjo įvykių normalizavimo, nebent integracija jį užtikrina |
| Įgyvendinimo rizika | Laukų atvaizdavimas, autentifikavimas, apklausos arba įvykių tvarkymas ir būsenų interpretavimas | Duomenų nuosavybė, būsenų sinchronizavimas, atsargų tikslumas ir sistemų tarpusavio suderinimas |
Šioje lentelėje aprašomas įprastas architektūrinis skirtumas, o ne garantija dėl kiekvieno tiekėjo. Kai kurios platformos sujungia užsakymų valdymą ir siuntų matomumą, o kai kurie sekimo paslaugų teikėjai palaiko kelis vežėjus. Prieš pasirinkdami integracijos modelį patikrinkite konkrečią dokumentaciją.
Pasirinkimas, kurio reikia daugeliui augančių įmonių: OMS ir kelių vežėjų sekimas
Įmonėms, naudojančioms UPS kartu su kitais vežėjais, dažnai reikia platesnio sekimo sluoksnio nei vien UPS ryšys. Kelių vežėjų sekimo paslauga gali suvienodinti skirtingų vežėjų siuntų įvykius, o OMS išlieka atsakinga už užsakymų ir užsakymų vykdymo procesus.
17TRACK teikia sekimo API ir skelbia kūrėjams skirtą dokumentaciją įmonėms, kurioms reikalinga programinė sekimo integracija. Tai aktualu, kai reikia matyti siuntas pas skirtingus vežėjus, o ne įgyvendinti procesą, susijusį tik su UPS. Oficialioje dokumentacijoje reikia patikrinti dabartinę API apimtį, palaikomas operacijas, autentifikavimo reikalavimus ir konkretaus projekto įgyvendinimo informaciją.
Ši architektūra gali būti naudinga mažmenininkui, turinčiam kelis užsakymų vykdymo partnerius, arba tarptautinei veiklai, kur paskutinės mylios vežėjas priklauso nuo paskirties vietos. OMS gali saugoti užsakymo ir užsakymo vykdymo būseną, o sekimo sluoksnis gali teikti siuntų atnaujinimus klientams skirtoms ar vidinėms programoms. Vis dėlto abiem sistemoms reikia aiškių nuosavybės taisyklių. Pavyzdžiui, apibrėžkite, kuri sistema yra pagrindinis užsakymo būsenos šaltinis, kuri sistema yra pagrindinis vežėjo įvykių šaltinis ir kaip sprendžiami prieštaringi atnaujinimai.
Paprastai UPS naudojančiai parduotuvei gali būti nereikalinga ir OMS, ir kelių vežėjų sekimo paslauga. Įmonei, dirbančiai su keliais vežėjais ir kanalais, nesukūrus normalizuoto sekimo sluoksnio gali tekti prižiūrėti atskiras integracijas, susidurti su nenuosekliais būsenų pavadinimais ir skirti daugiau priežiūros išteklių.
Kaip pasirinkti neperkraunant sprendimo
1. Pradėkite nuo verslo įvykio
Užrašykite įvykį, kuris turi sukelti veiksmą. „Rodyti naujausią UPS būseną užsakymo puslapyje“ rodo sekimo API poreikį. „Siųsti kiekvieną apmokėtą užsakymą į tinkamiausią užsakymų vykdymo vietą ir sinchronizuoti atsargas“ rodo OMS poreikį. „Atnaujinti klientą, kai siunta išvyksta iš 3PL“ gali reikšti, kad reikia abiejų sprendimų.
2. Susiekite sistemas, kurioms jau priklauso duomenys
Išvardykite internetinę parduotuvę, prekyvietę, ERP, sandėlio valdymo sistemą, 3PL, klientų aptarnavimo platformą, OMS ir vežėjų ryšius. Kiekvienai sistemai nustatykite, ar ji kuria, keičia ar tik skaito užsakymus, atsargas, užsakymų vykdymo įrašus ir sekimo įvykius. Taip išvengsite situacijos, kai nauja integracija sukuria du konkuruojančius pagrindinius duomenų šaltinius.
3. Įvertinkite vežėjų įvairovę ir geografiją
Jei naudojamas tik UPS, tiesioginio UPS ryšio gali pakakti. Jei veikloje naudojami keli vežėjai, pašto operatoriai arba nuo paskirties priklausantys paskutinės mylios partneriai, įvertinkite, ar platesnė sekimo API gali sumažinti atskirų integracijų skaičių. Nemanykite, kad teikėjas palaiko kiekvieną vežėją, šalį ar įvykio tipą; patikrinkite jūsų siuntų profiliui aktualią aprėptį.
4. Apibrėžkite minimalų būsenų modelį
Vežėjų įvykiai dažnai yra išsamesni nei klientams rodomos būsenos. Prieš kūrimą susiekite neapdorotus įvykius su verslo būsenomis, tokiomis kaip etiketė sukurta, vežama, perduota pristatyti, pristatyta, išimtis ir grąžinta. Nustatykite, kas vyksta, kai įvykis vėluoja, pasikartoja, negaunamas arba gaunamas ne eilės tvarka. Šis darbas reikalingas nepriklausomai nuo to, ar duomenys gaunami tiesiogiai iš UPS, ar per sekimo platformą.
5. Išbandykite veiklos išimtis
Sėkmingas demonstracinis pavyzdys paprastai apima įprastą pristatymą. Naudingas koncepcijos patikrinimas taip pat turėtų apimti neteisingą sekimo numerį, siuntą be įvykių, pavėluotą nuskaitymą, pristatymo išimtį, dalinę siuntą, pakaitinį užsakymą ir grąžinimą. OMS projekto atveju papildomai išbandykite padalytus užsakymus, atsargų trūkumą, bandymus atšaukti ir pasikartojančius užsakymų pranešimus.
6. Palyginkite bendras veiklos pastangas
Nelyginkite tik pradinių integracijos pastangų. Įtraukite stebėjimą, API pakeitimus, pagalbos įrankius, suderinimą, vežėjų prijungimą, duomenų saugojimą, prieigos kontrolę ir atkūrimą po gedimų. Siaura API gali būti mažiausios rizikos pasirinkimas sprendžiant siaurą problemą. Platesnę platformą gali būti lengviau prižiūrėti, kai verslas jau dirba su keliais vežėjais ir užsakymų vykdymo sistemomis.
Praktinė sprendimo taisyklė
Naudokite UPS sekimo API, kai siekiamas rezultatas yra patikimas UPS siuntų matomumas esamoje programoje. Naudokite OMS integraciją, kai siekiamas rezultatas yra koordinuotas užsakymų ir užsakymų vykdymo procesas keliuose kanaluose ar vietose. Naudokite abu sprendimus, kai OMS turi valdyti užsakymus, o atskiras sekimo sluoksnis turi suvienodinti siuntų įvykius klientų aptarnavimui ar po pirkimo teikiamoms paslaugoms.
Vertinant pasirinkimus, kitas žingsnis turėtų būti nedidelis, dokumentuotas integracijos bandymas, o ne platus techninis įsipareigojimas. Pasirinkite tipinius užsakymus, apibrėžkite laukiamus laukus ir būsenas, išbandykite įprastus bei išimtinius atvejus ir užrašykite, kuri sistema priima kiekvieną sprendimą. Jei projektas vėliau išsiplės įtraukiant daugiau vežėjų, iš naujo įvertinkite, ar kelių vežėjų sekimo API nėra tinkamesnė nei nepriklausomų vežėjų ryšių pridėjimas po vieną.
Geriausias pasirinkimas yra mažiausia architektūra, išsprendžianti dabartinę veiklos problemą ir neužkertanti kelio kitam tikėtinam poreikiui. Sekimo API neturėtų būti pristatoma kaip OMS, o OMS neturėtų būti diegiama vien tam, kad būtų rodomas sekimo puslapis.
DUK
Ar UPS sekimo API yra tas pats, kas OMS?
Ne. UPS sekimo API daugiausia dėmesio skiria UPS teikiamai siuntos informacijai. OMS koordinuoja platesnius užsakymų ir užsakymų vykdymo procesus, kurie gali apimti atsargas, maršrutizavimą, užsakymų vykdymą, atšaukimus ir grąžinimus. Įmonė gali naudoti sekimo API OMS pagrįstoje architektūroje.
Ar OMS gali sekti UPS siuntas?
Gali, jei OMS turi UPS integraciją arba yra prijungta prie atskiros sekimo paslaugos. Galimybė priklauso nuo konkretaus produkto ir ją reikia patvirtinti OMS dokumentacijoje. Vien OMS pavadinimas neįrodo, kad sistema palaiko reikalingus UPS įvykius ar procesus.
Ar man reikia OMS firminiam sekimo puslapiui sukurti?
Paprastai ne. Firminiam sekimo puslapiui paprastai reikia programos arba sekimo paslaugos, galinčios gauti siuntos duomenis ir pateikti juos klientui. OMS gali pateikti užsakymo kontekstą, tačiau pačiam puslapiui ji nėra automatiškai būtina.
Kada turėčiau naudoti kelių vežėjų sekimo API?
Verta ją svarstyti, kai siuntos siunčiamos per kelis vežėjus, o jūsų programoms reikia nuoseklaus būdo gauti arba rodyti pristatymo įvykius. Patikrinkite teikėjo vežėjų aprėptį, įvykių modelį, dokumentaciją, paslaugų apribojimus ir išimčių tvarkymą maršrutams, kuriais faktiškai dirbate.
Ką kūrėjai turėtų išsiaiškinti prieš integraciją?
Išsiaiškinkite autentifikavimą, užklausų ir atsakymų laukus, būsenų apibrėžimus, atnaujinimų dažnį, klaidų tvarkymą, pasikartojančius įvykius, sekimo numerio tikrinimą, saugojimo laikotarpį, saugumą ir sistemų atsakomybę. Taip pat dokumentuokite, kaip sekimo įvykis pakeičia klientui rodomą užsakymo būseną.
Šaltiniai
- UPS kūrėjų portalas — oficialus UPS API ir integracijos išteklių pradinis puslapis.
- 17TRACK sekimo API — oficialus programinės sekimo integracijos produkto puslapis.
- 17TRACK API dokumentacija — oficiali kūrėjams skirta įgyvendinimo dokumentacija.
