Tracking API ar Shipping API: kurio reikia jūsų el. prekybos technologijų rinkiniui (o gal abiejų)?

Naudokite siuntimo API, kai jūsų el. prekybos sistemai reikia kurti siuntas ir generuoti siuntimo etiketes. Naudokite siuntų sekimo API, kai jai reikia sekti siuntas po išsiuntimo ir paversti vežėjų atnaujinimus naudinga operacine arba klientams skirta informacija. Jei jūsų programinė įranga turi valdyti siuntų kūrimą ir matomumą po pirkimo, jums reikia abiejų funkcijų, tačiau nebūtinai dviejų tiekėjų ar dviejų atskirų integracijų.

Sprendimą priima asmuo, atsakingas už jūsų užsakymų vykdymo architektūrą: paprastai el. prekybos operacijų vadovas, dirbantis su inžinerijos komanda. Pradėkite nuo to, ką jūsų parduotuvė, sandėlis ar užsakymų vykdymo partneris jau tvarko. Papildoma API turėtų užpildyti konkrečią spragą, o ne dubliuoti jau veikiantį procesą.

Kuo skiriasi siuntų sekimo API ir siuntimo API?

Skirtumas pirmiausia susijęs su kiekvienos API atliekama užduotimi, o ne su griežta riba tarp produktų kategorijų. Siuntimo platforma gali turėti sekimo galinius taškus, o sekimo paslauga gali teikti pranešimų ir klientams skirtų pristatymo atnaujinimų įrankius. Vertinkite dokumentuotus galinius taškus ir įvykių veikimą, o ne pasikliaukite produkto pavadinimu.

Vežėjų dokumentacija iliustruoja šį atskyrimą. FedEx dokumentuoja siuntų kūrimą savo Ship API dokumentacijoje, o sekimo funkcijas – savo sekimo API dokumentacijoje. Tai yra skirtingų techninių atsakomybių pavyzdžiai, o ne rekomendacija pasirinkti konkretų vežėją.

Siuntos sukūrimas nėra tas pats, kas jos judėjimo stebėjimas

Sėkmingas atsakymas sukūrus siuntą jūsų programinei įrangai nurodo, kad siuntimo užklausa buvo apdorota. Tai nepatvirtina, kad vežėjas fiziškai gavo siuntinį. Taip pat sekimo numeris gali egzistuoti dar prieš pasirodant informacijai apie judėjimą sekimo istorijoje.

Todėl jūsų užsakymų valdymo sistema turėtų atskirti etiketės sukūrimą, perdavimą sandėlyje, vežėjo priėmimą ir pristatymą. Laikant visus šiuos veiksmus vienu „išsiųsta“ įvykiu, klientams gali būti išsiųsti per ankstyvi pranešimai, o iš tikrųjų iš sandėlio neišsiųstos siuntos gali likti nepastebėtos.

Pasirinkite funkciją, kuri pašalina dabartinę kliūtį

Rinkitės siuntimo API, kai trūksta išsiuntimo funkcijos

Siuntimo API yra tinkamas pradinis pasirinkimas, kai jūsų programa turi paversti užsakymo duomenis siunta. Pavyzdžiui, kai sandėlio darbuotojai rankiniu būdu kopijuoja adresus į vežėjų portalus arba pasirinktinė užsakymų valdymo sistema negali generuoti etikečių.

Prieš pasirinkdami integraciją apibrėžkite tikrąjį išsiuntimo procesą. Ar jums reikia tik sukurti siuntą, ar taip pat gauti tarifus, atšaukti siuntą, pateikti paėmimo užklausas, parengti muitinės dokumentus arba vykdyti dienos pabaigos procesus? Šios funkcijos gali būti atskiros API, priklausyti nuo vežėjo arba reikalauti papildomų paskyros teisių. Nemanykite, kad produktas, pavadintas „siuntimo API“, apima visas siuntimo operacijas.

Ne idealus kaip vienintelis sprendimas: etikečių kūrimo integracija, dėl kurios klientų aptarnavimo komanda vis tiek turi tikrinti atskiras vežėjų svetaines. Ji gali išspręsti išsiuntimo problemą, tačiau pristatymo matomumas iš esmės nepasikeis.

Rinkitės sekimo API, kai siuntų kūrimas jau veikia

Sekimo API yra tinkamesnis pasirinkimas, kai etiketes jau kuria jūsų sandėlio valdymo sistema, užsakymų vykdymo partneris, prekyvietė arba esama siuntimo integracija, tačiau pristatymo informacija yra išskaidyta.

Tokiu atveju pakeitus etikečių procesą gali atsirasti papildomų migracijos darbų, neišsprendžiant pagrindinės problemos. Vietoj to prijunkite ankstesniame procese sugeneruotus sekimo numerius prie matomumo sluoksnio, kurį galėtų naudoti jūsų užsakymų valdymo sistema, pagalbos įrankiai ir komunikacija su klientais.

Šioje kategorijoje 17TRACK Tracking API yra tinkama integracijos galimybė. Jos oficialioje API dokumentacijoje aprašomi sekimo numerių registravimo ir sekimo duomenų procesai, įskaitant tiesioginius pranešimus. Įvertinkite šiuos procesus pagal jums reikalingus vežėjus, siuntų tipus ir programos architektūrą. Tai yra sekimo sluoksnio aspektas, o ne įrodymas, kad paslauga pakeičia etikečių generavimo integraciją.

Ne idealus kaip vienintelis sprendimas: sekimo API, kai jūsų programinė įranga vis dar neturi galimybės sukurti siuntų, už kurių išsiuntimą yra atsakinga. Pristatymo matomumas neišsprendžia trūkstamo siuntimo vykdymo.

Naudokite abi funkcijas, kai jūsų programa valdo išsiuntimą ir pristatymo matomumą

Abi funkcijos yra tinkamos, kai jūsų sistema turi generuoti etiketes ir palaikyti patikimą siuntos eigos vaizdą. Jos gali būti teikiamos vienos platformos, atskirų paslaugų arba vežėjų integracijų ir sekimo sluoksnio derinio.

Rinkitės vieną integraciją, kai jos siuntimo ir sekimo funkcijos atitinka dokumentuotus jūsų reikalavimus ir nereikalauja nereikalingų kompromisų. Apsvarstykite atskiras integracijas, kai verta išsaugoti esamą siuntimo procesą arba kai sekimo reikalavimai iš esmės skiriasi nuo to, ką suteikia šis procesas. Atskiras sekimo tiekėjas ne visada yra geresnis; jis turi pateisinti papildomą integravimą, atsiskaitymą ir operacinę atsakomybę.

Kaip abi API įsilieja į el. prekybos sistemą

Praktiškas sprendimas užsakymą, siuntą ir sekimo įvykį laiko atskirais įrašais. Vienas užsakymas gali sukurti kelis siuntinius, o kiekvienas siuntinys gali turėti atskirą sekimo istoriją. Klientams rodoma užsakymo būsena turėtų būti nustatoma pagal šiuos siuntų įrašus, o ne juos perrašyti.

1. Užsakymas paruošiamas vykdyti. Parduotuvė arba užsakymų valdymo sistema siunčia reikiamus vykdymo duomenis atsakingam sandėliui.
2. Siuntimo procesas sukuria siuntą. Programa išsaugo grąžintą siuntos identifikatorių, sekimo numerį, vežėją, paslaugą ir etiketės nuorodą.
3. Sandėlis užbaigia perdavimą. Sandėlio patvirtinimas ir vežėjo priėmimas lieka atskirais įvykiais.
4. Prasideda sekimo procesas. Programa užregistruoja arba pateikia sekimo numerį taip, kaip reikalauja pasirinkta integracija.
5. Sekimo atnaujinimai pasiekia jūsų programą. Žiniatinklio iškvietimai, apklausa arba palaikomas jų derinys atnaujina siuntos įrašą.
6. Verslo taisyklės nustato tolesnius veiksmus. Sistema atnaujina klientams rodomą būseną, sukuria operacinę užduotį arba išsiunčia pranešimą, kai įvykdomos atitinkamos sąlygos.

Pavyzdžiui, prekybininkui, naudojančiam trečiosios šalies užsakymų vykdymo sandėlį, jo programinėje įrangoje gali reikėti tik ketvirto–šešto žingsnių. Sandėlis jau valdo siuntų kūrimą. Prekybininkui, valdančiam savo sandėlį, gali reikėti viso proceso.

Priskirkite vieną atsakingą savininką kiekvienam tolesniam veiksmui

Jei abi integracijos teikia sekimo atnaujinimus, nustatykite, kuri sistema valdo pranešimus klientams ir jūsų parduotuvėje rodomą siuntos būseną. Priešingu atveju klientai gali gauti pasikartojančius pranešimus arba matyti prieštaringas pristatymo būsenas.

Galite išsaugoti antrinius duomenis tyrimui, neleisdami kiekvienam šaltiniui suaktyvinti el. laiško. Išsaugokite pirminį vežėjo įvykį kartu su vidiniu būsenos susiejimu, kad pagalbos darbuotojai galėtų suprasti, kodėl sistema siuntą priskyrė konkrečiai būsenai.

Vertinkite operacinį tinkamumą, o ne funkcijų etiketes

Patikrinkite faktiškai naudojamus vežėjus ir paslaugas

Vežėjų palaikymas nėra vienas klausimas, į kurį galima atsakyti taip arba ne. Paslauga gali palaikyti vežėjo siuntų sekimą, bet nepalaikyti etikečių kūrimo tam pačiam vežėjui. Etikečių kūrimas taip pat gali priklausyti nuo išsiuntimo šalies, vežėjo paskyros nustatymų arba paslaugos tinkamumo.

Sudarykite bandymų sąrašą pagal faktinius siuntimo maršrutus. Įtraukite vietines siuntas, tarptautines siuntas ir bet kokį perdavimą tarp transporto partnerių. Patvirtinkite reikiamą operaciją kiekvienam atvejui: siuntos sukūrimą, sekimą arba abu veiksmus. Platus aprėpties teiginys yra mažiau naudingas nei sėkmingi jūsų verslui svarbių paslaugų bandymai.

Išnagrinėkite įvykių reikšmę ir duomenų išsamumą

Sekimo atveju patikrinkite, kas vyksta prieš pirmąjį nuskaitymą, pristatymo išimties metu, po nesėkmingo bandymo pristatyti ir pristatymo metu. Patikrinkite, ar laiko žymose pateikiama informacija apie laiko juostą ir ar išlieka pirminiai vežėjo aprašymai.

Neinterpretuokite normalizuotos būsenos kaip pažado, kad visų vežėjų duomenys bus vienodi. Numatoma pristatymo data, vietos informacija ir pristatymo įrodymo duomenys gali priklausyti nuo konkretaus vežėjo ir siuntos. Nuspręskite, kaip jūsų sąsaja veiks, kai šių laukų nėra.

Patikrinkite abiejų pusių veikimą sutrikimų atveju

Siuntimo atveju ypatingą dėmesį skirkite skirtajam laikui kuriant siuntą: užklausa galėjo būti sėkminga, net jei jūsų programa negavo atsakymo. Prieš aklai kartodami užklausą patikrinkite, kokius dubliavimo prevencijos ir suderinimo mechanizmus palaiko tiekėjas.

Sekimo atveju išbandykite pasikartojančius pranešimus, vėluojančius įvykius, nesėkmingą žiniatinklio iškvietimų pristatymą ir laikinus galinių taškų sutrikimus. Atitinkamoje dokumentacijoje patvirtinkite autentifikavimą, pakartotinių bandymų veikimą ir atkūrimo galimybes. Sukurkite įvykių apdorojimą taip, kad pakartotinai paleidus atnaujinimą tas pats pranešimas klientui nebūtų išsiųstas dar kartą.

Palyginkite bendras veiklos sąnaudas, nedarydami prielaidų apie kainodaros modelį

Atskirkite API mokesčius nuo pašto ir vežėjo paskyros mokesčių. Siuntimo ir sekimo paslaugos gali naudoti skirtingus atsiskaitymo vienetus, o bendra platforma funkcijas gali pakuoti skirtingai. Gaukite pasiūlymą arba peržiūrėkite taikomą planą pagal konkretų procesą, kurį ketinate vykdyti.

Pasiteiraukite, kaip apibrėžiamas apmokestinamas naudojimas, ar skaičiuojamos nesėkmingos užklausos, kaip tvarkomi pakartotiniai sekimo pateikimai ir kas nutinka viršijus suteiktą limitą. Įtraukite inžinerinę priežiūrą, pagalbos pastangas ir dviejų integracijų suderinimo išlaidas. Neturint apibrėžto siuntų derinio ir galiojančių komercinių sąlygų, teiginys, kad viena kategorija yra pigesnė, būtų klaidinantis.

Peržiūrėkite saugumą ir duomenų saugojimą

Siuntimo integracijos gali apdoroti gavėjų adresus ir muitinės informaciją. Sekimo integracijos taip pat gali apdoroti siuntų identifikatorius ir susijusius klientų duomenis. Patvirtinkite, kurie laukai būtini, apribokite prisijungimo duomenis iki reikalingos prieigos ir nelaikykite slaptų duomenų naršyklės pusės kode.

Peržiūrėkite saugojimo, trynimo ir prieigos kontrolės taisykles pagal savo verslo reikalavimus. Patogi integracija neturėtų reikalauti siųsti klientų informacijos, kurios procesui nereikia.

Praktinis patvirtinimo planas prieš įsipareigojant

Atlikite koncepcijos patikrinimą naudodami reprezentatyvias siuntas, o ne tik sėkmingą pavyzdį iš greitojo paleidimo vadovo. Suderinkite priėmimo kriterijus su operacijų, inžinerijos ir klientų aptarnavimo komandomis.

• Išsiuntimas: sugeneruokite reikiamus etikečių formatus ir patvirtinkite, kad sandėlio įranga gali juos naudoti.
• Užsakymų susiejimas: išbandykite padalytas siuntas, kelis siuntinius ir pakaitines siuntas neprarasdami pirminės istorijos.
• Sekimas: patikrinkite tikras svarbių jūsų verslui vežėjų ir maršrutų įvykių sekas.
• Išimtys: įsitikinkite, kad spręstina pristatymo problema pasiekia tinkamą komandą, automatiškai nelaikant kiekvieno neįprasto nuskaitymo klaida.
• Atkūrimas: nutraukite užklausą arba žiniatinklio iškvietimo galinį tašką ir pademonstruokite, kaip programa suderina trūkstamą informaciją.
• Komunikacija: patvirtinkite, kad kiekvieną pranešimą klientui siunčia tik paskirta sistema.
• Komercinis tinkamumas: įvertinkite mokesčius pagal numatomą naudojimą ir patvirtintus tiekėjo atsiskaitymo apibrėžimus.

Sprendimo taisyklė: pirmiausia įsigykite trūkstamą funkciją. Jei išsiuntimas jau veikia, įvertinkite sekimo integraciją neatkurdami užsakymų vykdymo proceso. Jei trūksta etikečių kūrimo, pirmiausia išspręskite siuntimo vykdymo problemą. Jei jūsų programa valdo visą siuntos gyvavimo ciklą, patvirtinkite abi funkcijas ir nuspręskite, ar jūsų komandai lengviau valdyti bendrą, ar atskirtą architektūrą.

DUK

Ar siuntimo API visada apima sekimą?

Ne. Kai kurios paslaugos apima abi funkcijas, o kitos jas pateikia per atskirus galinius taškus, produktus ar planus. Net jei sekimas įtrauktas, prieš laikydami jį savo sprendimu sekimui po pirkimo patikrinkite įvykių išsamumą, atnaujinimų pristatymo būdą, vežėjų palaikymą ir naudojimo sąlygas.

Ar galiu sekti siuntinius, kurių etiketes sukūrė užsakymų vykdymo partneris?

Galimai taip. Jūsų programai reikės sekimo integracijos reikalaujamų identifikatorių, paprastai sekimo numerio, o kai kuriais atvejais ir vežėjo identifikatoriaus arba papildomos patvirtinimo informacijos. Patvirtinkite partnerio vežėjų palaikymą ir įsitikinkite, kad sekimo numeriai patikimai patenka į jūsų sistemą.

Ar sekimo API privers vežėją greičiau atlikti nuskaitymus?

Ji negali sukurti fizinių vežėjo nuskaitymų. Ji gali padėti jūsų programai gauti, tvarkyti ir platinti informaciją, kurią pateikia sekimo šaltiniai. Vertinkite atnaujinimų veikimą pagal tikras siuntas, o ne manykite, kad API garantuoja tiesioginį matomumą apie kiekvieną judėjimą.

Ar man reikia dviejų API tiekėjų, kad galėčiau naudoti abi funkcijas?

Ne. Jums reikia abiejų funkcijų, bet nebūtinai dviejų tiekėjų. Naudokite vieną tiekėją, kai jis atitinka jūsų siuntimo ir sekimo reikalavimus. Atskirkite jas, kai tai leidžia išsaugoti veikiantį procesą arba patenkinti konkretų reikalavimą, kurio bendras sprendimas neatitinka.

Ar sekimo API gali pakeisti užsakymų valdymo sistemą?

Ne. Sekimo duomenys yra užsakymų valdymo įvestis, o ne atsargų paskirstymo, užsakymų vykdymo sprendimų, mokėjimų tvarkymo ar užsakymų įrašų pakaitalas. Jūsų programai vis tiek reikia susieti kiekvieną siuntą su tinkamu užsakymu ir nuspręsti, kaip siuntų įvykiai veikia verslo procesus.

Šaltiniai

• FedEx Ship API dokumentacija — siuntų kūrimo, etikečių ir siuntimo proceso reikalavimų šaltinis.
• FedEx sekimo API dokumentacija — sekimo užklausų ir siuntų būsenos informacijos šaltinis.
• 17TRACK Tracking API — oficialus sekimo integracijos kategorijos produkto šaltinis.
• 17TRACK API dokumentacija — sekimo registravimo, sekimo duomenų ir tiesioginių pranešimų integracijos šaltinis.