Prieš kurį laiką užsibrėžiau tikslą išsiaiškinti, ar egzistuoja vieninga transporto API/EDI standartinė sistema, kurią naudoja kelios logistikos įmonės. Šiais laikais kažkas panašaus turėtų egzistuoti, tiesa? Universalus siuntimo API formatas?

Na, trumpai tariant, tokio nėra.

Artimiausias dalykas, kurį galite gauti, yra koks nors API teikėjas, kuris sukūrė daug vežėjų API jungčių ir tada siūlo savo API prieigą, kad galėtumėte pasiekti skirtingus transporto paslaugų teikėjus.

Šiame straipsnyje apžvelgsiu keletą skirtingų vežėjų API, trumpai aprašysiu jų galimybes ir aptarsiu jų įgyvendinimo būdus.

Pastaba! Jei tiesiog ieškote universalaus transporto API protokolo, štai nuoroda, kur galite užsisakyti trumpą pokalbį su manimi.

Bet kuriuo atveju, pradėkime nuo...

Pirmiausia apibrėžkime tikslą.

Įsivaizduokite vidutinį gamintoją, turintį tiek vietinius, tiek tarptautinius klientus ir tiekėjus. Prekes reikia paimti iš tiekėjų ir pristatyti į gamybos vietą, o galutinius produktus reikia išsiųsti klientams.

Norint sukurti patikimą tiekimo grandinę, tipiniam vidutinio dydžio gamintojui reikėtų 10-20 transporto partnerių:

Visų šių santykių valdymas yra pakankamai sudėtingas. Bet tikrasis smagumas prasideda, kai bandote integruoti jų IT sistemas! (kadangi nėra vieningo krovinių API protokolo)

Antra, turime susitarti dėl apimties.

Ne visos logistikos įmonės siūlo tokį patį paslaugų lygį. Kai kurios turi labai sudėtingus API, teikiančius momentinį krovinių kainų nustatymą, užsakymą, etiketes, sekimą, kurjerio užklausas ir t.t., o kitos gali turėti tik portalą, kur galite prisijungti ir pateikti užsakymą. Kai kurios visai neturi IT sistemų - tik el. paštą. Mūsų tiksliniam scenarijui laikykime dalykus paprastais ir tiesiog siekime:

Skamba pakankamai paprastai, tiesa? O, jei tik...

Rankinis būdas tvarkyti dalykus, kuris atrodo yra pramonės standartas daugumai įmonių, apima vežėjų portalų naudojimą, kur įmanoma, ir bendravimą el. paštu su likusiais transporto partneriais. Mūsų pavyzdyje darome prielaidą, kad transporto kainoraščiai, tvarkaraščiai, pristatymo laikas ir sąskaitų tvarkymas yra valdomi atskirai. Užsakymų pateikimui siekiame sukurti API jungtį iš mūsų ERP sistemos.

Tarkime, kad pasirinkome šį transporto įmonių sąrašą ir turime sukurti tiesioginę API jungtį su jų sistemomis iš mūsų ERP programinės įrangos. Šis pasirinkimas yra atsitiktinis ir apima tik dalį skirtingų vežėjų API, kurie yra rinkoje.

DHL Express – naudoja portalą, vadinamą MyDHL, kuris taip pat turi API galimybes. Tačiau jis naudoja skirtingus API Krovinių, Express ir Global Forwarding padaliniams, ir skirtingus API metodus įvairiuose regionuose. Prieigai prie žiniatinklio paslaugos reikalingas SOAP protokolas, RESTful paslaugos arba paprastas XML, o kūrėjai turėtų būti susipažinę su XML/JSON ir turėti pagrindinį supratimą apie žiniatinklio paslaugas. Vien API specifikacija yra 457 puslapių ilgio. Ji yra išsami, bet jūsų kūrėjas jums pateiks sąskaitą už valandas, praleistas vien ją skaitant. Įgyvendinus, reikėtų suaktyvinti vidutiniškai 5-12 užklausų vienai siuntai, pradedant nuo autentifikavimo iki adresų patvirtinimo, prieinamumo patikrinimo ir etikečių užklausų.

Schenker – naudoja skirtingus API/EDI sprendimus įvairiuose regionuose. Dažniausiai naudojamas SOAP protokolas su XML formatu. Pati žinutė yra paprasta, jei visos galimos klaidos yra tinkamai apdorojamos. Kūrėjams reikia asmeninės prieigos, norint įgyvendinti API. Priklausomai nuo jūsų vietos, jūsų gali būti paprašyta įgyvendinti EDIFACT sprendimą vietoj to, kurį aptarsiu vėliau.

DSV – neseniai perėjo prie savo API galinčio portalo, vadinamo MyDSV. Atsižvelgiant į tai, kad API yra gana naujas, jis naudojasi kai kuriais naujausiais ir moderniausiais metodais API pasaulyje. Nepaisant sudėtingumo autentifikuojant ir naršant jų produktų katalogą, metodas yra paprastas. Vėlgi, priklausomai nuo jūsų vietos, gali būti teikiama pirmenybė EDIFACT.

FedEx ir TNT – tai gali būti smagu. Pirmiausia turite nustatyti, ar naudojate TNT ar FedEx paslaugas. Nors jie turėjo būti ta pati įmonė jau keletą metų, migracija vis dar vyksta. Jei jūsų sutartis yra su TNT, greičiausiai jūsų bus paprašyta įgyvendinti TNT Express Connect API. Pats įgyvendinimas yra vidutinio sudėtingumo. Trūkumas yra tas, kad šis API laikomas pasenusiu ir galiausiai bus uždarytas. FedEx API, kita vertus, yra sudėtingesnis ir siūlo keletą variantų, priklausomai nuo regiono, kuriame esate. Cargoson įgyvendino FedEx Compatible API, kuris suteikia keletą labai naudingų papildomų funkcijų, bet yra prieinamas tik FedEx Compatible partneriams.

UPS – naudoja JSON pagrįstą API ir OAuth autentifikavimui, o tai reiškia, kad turėtumėte suaktyvinti nemažai užklausų, kol gausite savo užsakymą ir etiketes atgal.

Toliau turime EDIFACT, kurį naudoja daugelis transporto įmonių, tokių kaip DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics ir kt. Tai labai senas standartas, ir net jei gali atrodyti, kad galėtumėte išsisukti su viena API integracija kelioms logistikos įmonėms, pagalvokite dar kartą. Didžiausias trūkumas yra tas, kad tai yra failų mainais pagrįsta jungtis, o tai reiškia, kad turėtumėte sugeneruoti faktinį, fizinį failą, tada perduoti jį per FTP ir tiesiog tikėtis, kad viskas gerai, nes yra labai sudėtinga gauti atsiliepimus apie klaidas ir įspėjimus.

Panašus į EDIFACT yra FORTRAS, failais pagrįsta jungtis su tais pačiais trūkumais. Jis labiau naudojamas Vokietijoje ir kaimyninėse šalyse. Ne tik failų mainai yra sudėtingi, bet ir pats failo formatas yra sunkiai skaitomas, todėl labai daug laiko užima klaidų derinimas. Kai kurios gerai žinomos įmonės, kurios jį naudoja, yra Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss ir kt.

Net įgyvendinus visas pirmiau minėtas integracijas, lieka klausimas:

Ką daryti su vežėjų įmonėmis, kurios neturi jokios IT sistemos ar portalo, jau nekalbant apie API transporto užsakymams priimti?

Paprasčiausias sprendimas yra siųsti paprastą el. laišką. Nors tai gali skambėti paprastai, panagrinėkime giliau. Techninio ryšio su jūsų pašto serveriu nustatymas yra vienas dalykas, bet kaip dėl kontaktų? Paprastai skirtingas kryptis tvarko skirtingi kontaktiniai asmenys, o žmonės keičia pareigas. Taigi, jums reikėtų sukurti gana išsamią kontaktų matricą savo ERP sistemoje.

Taigi, kokios yra alternatyvos kovai su skirtingais vežėjų API ir EDI protokolais?

Vienas iš variantų, kurį verta apsvarstyti, yra kelių vežėjų API. Iš esmės tai yra paslaugų teikėjas, kuris sukūrė visas vežėjų jungtis, nesvarbu, ar tai būtų šiuolaikiniai API, seni EDIFACT ar FORTRAS pagrįsti EDI protokolai ar el. pašto integracijos, ir padarė jas prieinamas per savo standartizuotą siuntimo API. Vietoj to, kad įgyvendintumėte įvairius vežėjų API ir juos nuolat atnaujintumėte, galite įgyvendinti tik vieną kelių vežėjų API standartą ir suaktyvinti visus savo transporto užsakymus per jį.

Bet mes nuėjome dar toliau.

Skirtingos logistikos įmonės siūlo skirtingus paslaugų lygius. Kai kurios siūlo užsakymo API, o kitos - ne; kai kurios siūlo sekimo galimybes, o kitos šios funkcijos neturi. Cargoson įgyvendino visas funkcijas, kurios užpildo kiekvienos transporto įmonės spragas.

Pavyzdžiui, kai vežėjas nesiūlo internetinio užsakymo, mes suteikiame portalą tam. Jei jiems trūksta sekimo, mes jį pridedame. Mes turime sistemas pristatymo įrodymų (POD) ir kitų dokumentų įkėlimui, visiškai funkcionuojantį kelių vežėjų API, ETA įverčius, transporto kainų skaičiavimus, veiklos statistiką ir net transporto CO2 emisijos skaičius. Iš esmės, ko tik vežėjui trūksta, mes tai sukūrėme, kad jums nereikėtų rūpintis IT ar paslaugų lygio skirtumais tarp jūsų vežėjų.

Sužinokite, kaip Cargoson pagerina jūsų esamus vežėjus

Štai realaus pasaulio pavyzdys: Didieji žaidėjai, tokie kaip FedEx, TNT ir DHL Express, siūlo kainų nustatymo API. Tai reiškia, kad kai suaktyvinate kainos užklausą iš Cargoson, kainos yra tiesiogiai gaunamos iš vežėjo sistemos. Tačiau tais atvejais, kai įmonė, pavyzdžiui, DSV, neteikia kainų nustatymo API, DSV pateiktas Excel ar PDF kainoraštis yra įkeliamas į Cargoson, o kainos skaičiavimas atliekamas mūsų sistemoje. Mes turime galingą krovinių kainų įkėlimo ir skaičiavimo variklį tam. Tas pats metodas gali būti taikomas visoms kitoms transporto įmonėms ir taip pat taikomas kitoms funkcijoms.

Mūsų tikslas paprastas: suteikti jums nuoseklią, aukštos kokybės patirtį su visais vežėjais, net jei jie visi nepradeda su tomis pačiomis galimybėmis. De facto universalus vežėjų API standartas ir kelių vežėjų platforma viename.

Jei ieškote geresnio būdo valdyti savo vežėjų integracijas, Cargoson gali padėti. Mūsų platforma suteikia vieną standartizuotą transporto API, kuris sujungia jus su visais jūsų vežėjais, nepriklausomai nuo jų individualių galimybių. Tai reiškia, kad galite pasiekti visas savo siuntimo paslaugas per vieną vieningą sąsają, nesirūpindami dėl pagrindinių techninių skirtumų.

Norite pamatyti, kaip tai galėtų veikti jūsų verslui? Susitarkime trumpam pokalbiui aptarti jūsų dabartinę sąranką ir konkrečius integracijos iššūkius. Galime peržiūrėti keletą realaus pasaulio pavyzdžių, kaip Cargoson padėjo įmonėms panašiais atvejais kaip jūsų:

Suplanuokite nemokamą 30 minučių konsultaciją