Jonkin aikaa sitten päätin selvittää, onko olemassa yhtenäistä kuljetusalan API/EDI-standardia, jota useat logistiikkayritykset käyttävät. Varmasti tänä päivänä sellaisen täytyy olla olemassa, eikö niin? Universaali lähetys-API-formaatti?

No, lyhyesti sanottuna, sellaista ei ole olemassa.

Lähimmäksi pääsee jonkin API-palveluntarjoajan kanssa, joka on rakentanut useita kuljetusliikkeiden API-yhteyksiä ja tarjoaa sitten oman API-rajapintansa eri kuljetuspalveluntarjoajien käyttämiseksi.

Tässä artikkelissa käsittelen muutamia erilaisia kuljetusliikkeiden API-rajapintoja, kuvailen lyhyesti niiden ominaisuuksia ja keskustelen tavoista toteuttaa niitä.

Huom! Jos etsit vain universaalia kuljetusalan API-protokollaa, tässä on linkki, josta voit varata lyhyen puhelun kanssani.

Joka tapauksessa, aloitetaan...

Määritellään ensin tavoite.

Ajattele keskivertoa valmistajaa, jolla on sekä kotimaisia että kansainvälisiä asiakkaita ja toimittajia. Tavarat pitää noutaa toimittajilta ja toimittaa tuotantolaitokselle, kun taas valmiit tuotteet pitää lähettää asiakkaille.

Luotettavan toimitusketjun luomiseksi tyypillinen keskikokoinen valmistaja tarvitsisi 10-20 kuljetuskumppania:

Kaikkien näiden suhteiden hallinta on jo itsessään monimutkaista. Mutta todellinen hauskuus alkaa, kun yrität integroida niiden IT-järjestelmiä! (koska yhtenäistä rahti-API-protokollaa ei ole)

Toiseksi, meidän pitää sopia laajuudesta.

Kaikki logistiikkayritykset eivät tarjoa samaa palvelutasoa. Joillakin on erittäin kehittyneitä API-rajapintoja, jotka tarjoavat välittömän rahtihinnoittelun, varauksen, etiketit, seurannan, kuriirin tilauksen jne., kun taas toisilla saattaa olla vain portaali, johon voit kirjautua ja tehdä varauksen. Joillakin ei ole lainkaan IT-järjestelmiä - vain sähköposti. Kohdeskenaariomme kannalta pidetään asiat yksinkertaisina ja tähdätään vain:

Kuulostaa yksinkertaiselta, eikö vain? Voi, kunpa vain...

Manuaalinen tapa hoitaa asioita, joka näyttää olevan alan standardi useimmille yrityksille, sisältää kuljetusliikkeiden portaalien käytön aina kun mahdollista ja kommunikoinnin sähköpostitse muiden kuljetuskumppaneiden kanssa. Esimerkissämme oletamme, että kuljetushinnastot, aikataulut, toimitusajat ja laskujen käsittely hoidetaan erikseen. Varausten lähettämistä varten pyrimme rakentamaan API-yhteyden ERP-järjestelmästämme.

Oletetaan, että olemme valinneet seuraavan listan kuljetusyrityksiä ja meidän pitää rakentaa suora API-yhteys niiden järjestelmiin ERP-ohjelmistostamme. Tämä valinta on satunnainen ja kattaa vain murto-osan erilaisista kuljetusliikkeiden API-rajapinnoista.

DHL Express – käyttää MyDHL-nimistä portaalia, jolla on myös API-ominaisuuksia. Se käyttää kuitenkin eri API-rajapintoja Freight-, Express- ja Global Forwarding -haaroille sekä erilaisia API-lähestymistapoja eri alueilla. Verkkopalvelun käyttö vaatii SOAP-protokollan, RESTful-palvelut tai pelkän XML:n, ja kehittäjien tulisi olla perehtyneitä XML/JSON-kieleen ja ymmärtää verkkopalveluiden perusteet. Pelkästään API-spesifikaatio on 457 sivua pitkä. Se on perusteellinen, mutta kehittäjäsi veloittaa sinulta tunneista, jotka kuluvat pelkästään sen lukemiseen. Kun se on toteutettu, sinun pitäisi laukaista keskimäärin 5-12 pyyntöä lähetystä kohti, alkaen todennuksesta osoitteiden vahvistuksiin, saatavuustarkistuksiin ja etikettipyyntöihin.

Schenker – käyttää erilaisia API/EDI-ratkaisuja eri alueilla. Yleisimmin se käyttää SOAP-protokollaa XML-muodossa. Itse viesti on suoraviivainen, edellyttäen että kaikki mahdolliset virheet käsitellään asianmukaisesti. Kehittäjät tarvitsevat henkilökohtaisen pääsyn API:n toteuttamiseksi. Sijainnistasi riippuen sinua saatetaan pyytää toteuttamaan EDIFACT-ratkaisu sen sijaan, jota käsittelen myöhemmin.

DSV – on hiljattain siirtynyt API-kykyiseen portaaliinsa nimeltä MyDSV. Koska API on melko uusi, se hyödyntää joitakin uusimpia ja modernimpia lähestymistapoja API-maailmassa. Huolimatta monimutkaisuudesta todennuksessa ja heidän tuoteluettelonsa navigoinnissa, lähestymistapa on suoraviivainen. Jälleen kerran, sijainnistasi riippuen EDIFACT saattaa olla suositeltavampi.

FedEx ja TNT – tämä voi olla hauskaa. Ensin sinun pitää määrittää, käytätkö TNT:n vai FedExin palveluita. Vaikka niiden olisi pitänyt olla sama yritys jo useita vuosia, siirtymä on edelleen kesken. Jos sopimuksesi on TNT:n kanssa, sinua todennäköisesti pyydetään toteuttamaan TNT Express Connect API. Itse toteutus on keskimääräisen monimutkainen. Huono puoli on, että tätä API:a pidetään vanhentuneena ja se suljetaan lopulta. FedExin API on puolestaan monimutkaisempi ja tarjoaa useita vaihtoehtoja riippuen sijainnistasi. Cargosonilla olemme toteuttaneet FedEx Compatible API:n, joka tarjoaa joitakin erittäin siistejä lisätoimintoja, mutta on saatavilla vain FedEx Compatible -kumppaneille.

UPS – käyttää JSON-pohjaista API:a ja OAuth-todennusta, mikä tarkoittaa, että sinun pitäisi laukaista melko monta pyyntöä ennen kuin saat varauksesi läpi ja etiketit takaisin.

Seuraavaksi meillä on EDIFACT, jota monet kuljetusyritykset kuten DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics jne. käyttävät. Se on erittäin vanha standardi, ja vaikka saattaisi vaikuttaa siltä, että voisit selviytyä yhdellä API-integraatiolla useille logistiikkayrityksille, mieti uudelleen. Suurin haittapuoli on, että se on tiedostonvaihtoon perustuva yhteys, mikä tarkoittaa, että sinun pitäisi luoda todellinen, fyysinen tiedosto, sitten siirtää se FTP:n kautta ja kirjaimellisesti toivoa, että kaikki on kunnossa, koska virheistä ja varoituksista on erittäin hankala saada palautetta.

EDIFACTin kaltainen on FORTRAS, tiedostopohjainen yhteys samoilla puutteilla. Se on enemmän käytössä Saksassa ja naapurimaissa. Tiedostonvaihdon haastavuuden lisäksi itse tiedostomuoto on vaikea lukea ja siksi erittäin aikaa vievä virheiden korjaamisessa. Joitakin tunnettuja yrityksiä, jotka käyttävät sitä, ovat Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss jne.

Vaikka olisit toteuttanut kaikki edellä mainitut integraatiot, kysymys kuuluu edelleen:

Mitä teet kuljetusyritysten kanssa, joilla ei ole mitään IT-järjestelmää tai portaalia, saati sitten API:a kuljetustilausten vastaanottamiseen?

Yksinkertaisin ratkaisu on lähettää yksinkertainen sähköposti. Vaikka tämä saattaa kuulostaa suoraviivaiselta, mennään syvemmälle. Teknisen yhteyden muodostaminen sähköpostipalvelimeesi on yksi asia, mutta entä yhteystiedot? Normaalisti eri suuntia hoitavat eri yhteyshenkilöt, ja ihmiset vaihtavat asemia. Siksi sinun pitäisi rakentaa melko kattava yhteysmatriisi ERP-järjestelmääsi.

Joten mitkä ovat vaihtoehdot erilaisten kuljetusliikkeiden API- ja EDI-protokollien kanssa painimiselle?

Yksi harkittava vaihtoehto on usean kuljetusliikkeen API. Käytännössä tämä on palveluntarjoaja, joka on rakentanut kaikki kuljetusliikeyhteydet, olivatpa ne sitten moderneja API-rajapintoja, vanhoja EDIFACT- tai FORTRAS-pohjaisia EDI-protokollia tai sähköposti-integraatioita, ja tehnyt ne saataviksi oman standardoidun lähetys-API:nsa kautta. Sen sijaan, että toteuttaisit erilaisia kuljetusliikkeiden API-rajapintoja ja pitäisit ne ajan tasalla, voit toteuttaa vain yhden usean kuljetusliikkeen API-standardin ja laukaista kaikki kuljetustilauksesi sen kautta.

Mutta olemme vieneet sen vielä pidemmälle.

Eri logistiikkayritykset tarjoavat vaihtelevia palvelutasoja. Jotkut tarjoavat varaus-API:n, toiset eivät; joillakin on seurantaominaisuuksia, toisilta ne puuttuvat. Cargosonilla olemme toteuttaneet kaikki ominaisuudet, jotka täyttävät kunkin kuljetusyrityksen puutteet.

Esimerkiksi kun kuljetusliikkeellä ei ole online-varausta, tarjoamme portaalin sitä varten. Jos heiltä puuttuu seuranta, lisäämme sen. Meillä on järjestelmät toimitustodistuksen (POD) ja muiden asiakirjojen lataamiseen, täysin varusteltu usean kuljetusliikkeen API, ETA-arviot, kuljetushintalaskelmat, suorituskykytilastot ja jopa kuljetusten CO2-päästöluvut. Käytännössä, mitä tahansa kuljetusliikkeeltä puuttuu, olemme rakentaneet sen, jotta sinun ei tarvitse huolehtia IT- tai palvelutasoeroista kuljetusliikkeidesi välillä.

Katso, miten Cargoson parantaa nykyisiä kuljetusliikkeitäsi

Tässä on tosielämän esimerkki: Suuret toimijat kuten FedEx, TNT ja DHL Express tarjoavat hinnoittelu-API:n. Tämä tarkoittaa, että kun teet hintatiedustelun Cargosonista, hinnat haetaan suoraan kuljetusliikkeen järjestelmästä. Kuitenkin tapauksissa, joissa yritys kuten DSV ei tarjoa hinnoittelu-API:a, DSV:n toimittama Excel- tai PDF-hinnasto ladataan Cargosoniin, ja hintalaskenta suoritetaan meidän järjestelmässämme. Meillä on tehokas rahtihintojen lataus- ja laskentamoottori sitä varten. Samaa lähestymistapaa voidaan soveltaa kaikkiin muihinkin kuljetusyrityksiin ja se pätee myös muihin ominaisuuksiin.

Tavoitteemme on yksinkertainen: tarjota sinulle johdonmukainen, korkealaatuinen kokemus kaikista kuljetusliikkeistä, vaikka niillä kaikilla ei olisikaan samoja lähtökohtaisia ominaisuuksia. De facto universaali kuljetusliike-API-standardi ja usean kuljetusliikkeen alusta yhdessä paketissa.

Jos etsit parempaa tapaa hallita kuljetusliikkeiden integraatioitasi, Cargoson voi auttaa. Alustamme tarjoaa yhden, standardoidun kuljetus-API:n, joka yhdistää sinut kaikkiin kuljetusliikkeisiisi riippumatta niiden yksilöllisistä ominaisuuksista. Tämä tarkoittaa, että voit käyttää kaikkia lähetyspalveluitasi yhden yhtenäisen käyttöliittymän kautta, ilman että sinun tarvitsee huolehtia taustalla olevista teknisistä eroista.

Haluatko nähdä, miten se voisi toimia yrityksellesi? Sovitaan lyhyt puhelu keskustellaksemme nykyisestä asetelmastasi ja erityisistä integraatiohaasteistasi. Voimme käydä läpi joitakin tosielämän esimerkkejä siitä, miten Cargoson on auttanut yrityksiä samankaltaisissa tapauksissa kuin sinun:

Varaa ilmainen 30 minuutin konsultaatio