Pred časom sem si zadal nalogo, da ugotovim, ali obstaja enoten standard za transportni API/EDI, ki ga uporablja več logističnih podjetij. Zagotovo mora v današnjem času obstajati nekaj takega, kajne? Univerzalni format za API za pošiljanje?
No, če na kratko povzamem, ne obstaja.
Najbližje temu lahko pridete z nekaterimi ponudniki API-jev, ki so vzpostavili številne povezave s prevozniškimi API-ji in nato ponujajo svojo lastno končno točko API za dostop do različnih ponudnikov transportnih storitev.
V tem članku bom obravnaval nekaj različnih prevozniških API-jev, na kratko opisal njihove zmogljivosti in razpravljal o načinih njihove implementacije.
Opomba! Če iščete le univerzalni protokol za transportni API, je tukaj povezava, kjer lahko rezervirate hiter klic z mano.
Vsekakor pa začnimo s...
Primer iz resničnega življenja
Najprej opredelimo cilj.
Pomislite na povprečnega proizvajalca z domačimi in mednarodnimi strankami ter dobavitelji. Blago je treba prevzeti od dobaviteljev in dostaviti na proizvodno mesto, medtem ko je treba končne izdelke odpremiti strankam.
Za vzpostavitev zanesljive dobavne verige bi vaš tipični srednje velik proizvajalec potreboval 10-20 prevoznih partnerjev:
- En sklop za domače pakete
- Drug sklop za domače palete
- Prevozni partner, ki ponuja konkurenčne cene za severne sosednje države, morda ne ponuja enakega predloga za druge smeri ali daljše razdalje.
- Enako velja za zbirne pošiljke, LTL ali polne tovornjake (FTL)
- Za stranke v tujini bo morda potreben popolnoma drugačen nabor partnerjev
- ... in tako naprej.
Upravljanje vseh teh odnosov je že samo po sebi dovolj zapleteno. Toda prava zabava se začne, ko poskušate integrirati njihove IT sisteme! (saj ni enotnega protokola za tovorni API)
Drugič, moramo se dogovoriti o obsegu.
Vsa logistična podjetja ne ponujajo enake ravni storitev. Nekatera imajo zelo izpopolnjene API-je, ki omogočajo takojšnje določanje cen prevoza, rezervacije, nalepke, sledenje, zahteve za kurirje itd., medtem ko imajo druga morda le portal, kjer se lahko prijavite in oddate rezervacijo. Nekatera sploh nimajo IT sistemov - le e-pošto. Za naš ciljni scenarij ohranimo stvari preproste in si prizadevajmo le za:
- Oddajo naročila za prevoz
- Prejem transportnih nalepk
- Morda pridobitev ocenjene cene prevoza, če imamo srečo!
Sliši se dovolj preprosto, kajne? Oh, ko bi le bilo tako preprosto...
Povezave s prevozniki – dobrodošli v džungli
Ročni način obravnave stvari, ki se zdi industrijski standard za večino podjetij, vključuje uporabo prevozniških portalov, kjer je to mogoče, in komuniciranje prek e-pošte s preostalimi prevoznimi partnerji. V našem primeru predpostavljamo, da se ceniki prevozov, urniki, dobavni roki in obdelava računov upravljajo ločeno. Za oddajo rezervacij želimo vzpostaviti API povezavo iz našega ERP sistema.
Predpostavimo, da smo izbrali naslednji seznam prevoznih podjetij in moramo vzpostaviti neposredno API povezavo z njihovimi sistemi iz naše programske opreme ERP. Ta izbor je naključen in zajema le delček različnih prevozniških API-jev, ki obstajajo.
DHL Express – uporablja portal, imenovan MyDHL, ki ima tudi zmogljivosti API. Vendar uporablja različne API-je za veje Freight, Express in Global Forwarding ter različne pristope API v različnih regijah. Za dostop do spletne storitve je potreben protokol SOAP, storitve RESTful ali navadni XML, razvijalci pa morajo biti seznanjeni z XML/JSON in imeti osnovno razumevanje spletnih storitev. Sama specifikacija API je dolga 457 strani. Je temeljita, vendar vam bo razvijalec zaračunal ure, ki jih je porabil samo za branje. Ko je implementiran, bi morali sprožiti povprečno 5-12 zahtev na pošiljko, začenši z avtentikacijo do preverjanja naslovov, preverjanja razpoložljivosti in zahtev za nalepke.
Schenker – uporablja različne rešitve API/EDI v različnih regijah. Najpogosteje uporablja protokol SOAP z XML formatom. Samo sporočilo je preprosto, če so pravilno obravnavane vse možne napake. Razvijalci potrebujejo personaliziran dostop za implementacijo API-ja. Odvisno od vaše lokacije vas lahko prosijo, da namesto tega implementirate rešitev EDIFACT, ki jo bom obravnaval kasneje.
DSV – se je nedavno preselil na svoj portal z zmogljivostmi API, imenovan MyDSV. Glede na to, da je API precej nov, izkorišča nekatere najnovejše in najsodobnejše pristope v svetu API-jev. Kljub zapletenosti pri avtentikaciji in navigaciji po njihovem katalogu izdelkov je pristop preprost. Ponovno, odvisno od vaše lokacije, je lahko EDIFACT bolj zaželen.
FedEx in TNT – to je lahko zabavno. Najprej morate ugotoviti, ali uporabljate storitve TNT ali FedEx. Čeprav bi morali biti isto podjetje že kar nekaj let, migracija še vedno poteka. Če je vaša pogodba s TNT, vas bodo najverjetneje prosili, da implementirate API TNT Express Connect. Sama implementacija je povprečno zahtevna. Slabost je, da se ta API šteje za zastarel in bo sčasoma ukinjen. API FedEx je po drugi strani bolj zapleten in ponuja več možnosti, odvisno od regije, v kateri se nahajate. Pri Cargosonu smo implementirali FedEx Compatible API, ki ponuja nekaj zelo priročnih dodatnih funkcionalnosti, vendar je na voljo samo za partnerje, združljive s FedEx.
UPS – uporablja API, ki temelji na JSON, in OAuth za avtentikacijo, kar pomeni, da bi morali sprožiti kar nekaj zahtev, preden bi vašo rezervacijo spravili skozi in dobili nalepke nazaj.
Nato imamo EDIFACT, ki ga uporabljajo številna prevozna podjetja, kot so DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics itd. To je zelo star standard in tudi če se zdi, da bi se lahko izognili eni API integraciji za več logističnih podjetij, premislite še enkrat. Največja slabost je, da gre za povezavo, ki temelji na izmenjavi datotek, kar pomeni, da bi morali generirati dejansko, fizično datoteko, jo nato prenesti prek FTP in dobesedno upati, da je vse v redu, ker je povratna informacija o napakah in opozorilih zelo zapletena.
Podoben EDIFACT-u je FORTRAS, povezava, ki temelji na datotekah z enakimi pomanjkljivostmi. Bolj je v uporabi v Nemčiji in sosednjih državah. Ne samo, da je izmenjava datotek zahtevna, tudi sam format datoteke je težko berljiv in zato zelo zamuden za odpravljanje napak. Nekatera znana podjetja, ki ga uporabljajo, vključujejo Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss itd.
Tudi po implementaciji vseh zgoraj omenjenih integracij ostaja vprašanje:
Kaj narediti s prevoznimi podjetji, ki nimajo nobenega IT sistema ali portala, kaj šele API-ja za sprejemanje prevoznih naročil?
Najpreprostejša rešitev je poslati preprosto e-pošto. Čeprav se to morda sliši preprosto, poglejmo globlje. Vzpostavitev tehnične povezave z vašim poštnim strežnikom je ena stvar, kaj pa stiki? Običajno različne smeri obravnavajo različne kontaktne osebe, ljudje pa menjajo položaje. Tako bi morali v svoj ERP vgraditi precej obsežno kontaktno matriko.
Torej, kakšne so alternative spopadanju z različnimi prevozniškimi API-ji in EDI protokoli?
Ena možnost, ki jo je treba upoštevati, je API za več prevoznikov. V bistvu gre za ponudnika storitev, ki je vzpostavil vse povezave s prevozniki, naj gre za sodobne API-je, stare protokole EDI, ki temeljijo na EDIFACT ali FORTRAS, ali e-poštne integracije, in jih dal na voljo prek svojega lastnega, standardiziranega API-ja za pošiljanje. Namesto da implementirate različne prevozniške API-je in jih posodabljate, lahko implementirate samo en standard API za več prevoznikov in sprožite vsa svoja prevozna naročila prek njega.
Vendar smo šli še dlje.
Programska oprema za več prevoznikov – kako izboljšati vaše obstoječe prevoznike?
Različna logistična podjetja ponujajo različne ravni storitev. Nekatera ponujajo API za rezervacije, druga ne; nekatera ponujajo zmogljivosti sledenja, medtem ko drugim ta funkcija manjka. Pri Cargosonu smo implementirali vse funkcije, ki zapolnjujejo vrzeli za vsako prevozno podjetje.
Na primer, ko prevoznik ne ponuja spletne rezervacije, mi zagotovimo portal za to. Če jim manjka sledenje, ga dodamo. Imamo sisteme za nalaganje dokazila o dostavi (POD) in drugih dokumentov, polno funkcionalen API za več prevoznikov, ocene ETA, izračune cen prevoza, statistike uspešnosti in celo podatke o emisijah CO2 pri prevozu. V bistvu smo zgradili vse, kar prevozniku manjka, tako da vam ni treba skrbeti zaradi razlik v IT ali ravni storitev med vašimi prevozniki.
Tukaj je primer iz resničnega sveta: Veliki igralci, kot so FedEx, TNT in DHL Express, ponujajo API za določanje cen. To pomeni, da ko sprožite zahtevo za ceno iz Cargosona, se cene neposredno povlečejo iz sistema prevoznika. Vendar v primerih, ko podjetje, kot je DSV, ne ponuja API-ja za določanje cen, se cenik v Excelu ali PDF-ju, ki ga zagotovi DSV, naloži v Cargoson, izračun cene pa se izvede znotraj našega sistema. Za to imamo zmogljiv motor za nalaganje in izračun cen prevoza. Enak pristop lahko uporabimo za vsa druga prevozna podjetja in velja tudi za druge funkcije.
Naš cilj je preprost: zagotoviti vam dosledno, visokokakovostno izkušnjo z vsemi prevozniki, tudi če vsi ne začnejo z enakimi zmogljivostmi. De facto univerzalni standard API za prevoznike in platforma za več prevoznikov v enem.
Če iščete boljši način za upravljanje vaših integracij s prevozniki, vam lahko Cargoson pomaga. Naša platforma zagotavlja enoten, standardiziran transportni API, ki vas povezuje z vsemi vašimi prevozniki, ne glede na njihove posamezne zmogljivosti. To pomeni, da lahko dostopate do vseh svojih storitev pošiljanja prek enega poenotenega vmesnika, ne da bi vas skrbele osnovne tehnične razlike.
Želite videti, kako bi to lahko delovalo za vaše podjetje? Skočimo na hiter klic, da se pogovorimo o vaši trenutni postavitvi in specifičnih izzivih integracije. Lahko si ogledamo nekaj primerov iz resničnega sveta, kako je Cargoson pomagal podjetjem v podobnih primerih, kot je vaš: