Mõni aeg tagasi seadsin endale eesmärgiks uurida, kas on olemas ühtne transpordi API/EDI standard, mida kasutavad mitmed logistikaettevõtted. Kindlasti peab tänapäeval midagi sellist olemas olema, eks? Universaalne veonduse API formaat?

Noh, lühidalt öeldes, seda ei ole olemas.

Lähim, mida saab, on mõni API pakkuja, kes on loonud palju vedaja API ühendusi ja pakub seejärel oma API-lõpp-punkti erinevate transporditeenuse pakkujate kasutamiseks.

Selles artiklis käsitlen mõnda erinevat vedaja API-t, kirjeldan lühidalt nende võimalusi ja arutlen nende rakendamise viiside üle.

NB! Kui otsite lihtsalt universaalset transpordi API protokolli, siis siin on link, kust saate minuga kiire kõne broneerida.

Igal juhul, alustame...

Näide päriselust


Kõigepealt seame eesmärgi.

Kujutage ette keskmist tootmisettevõtet, kellel on nii kodumaised kui ka rahvusvahelised kliendid ja tarnijad. Kaubad tuleb tarnijatelt ära tuua ja toimetada tootmiskohta, samas kui valmistooted tuleb saata klientidele.

Töökindla tarneahela loomiseks vajaks tüüpiline keskmise suurusega tootja 10-20 veopartnerit:

  • Üks komplekt kodumaistele pakkidele
  • Teine komplekt kodumaistele alustele
  • Veopartner, kes pakub konkurentsivõimelisi hindu põhjapoolsetesse naaberriikidesse, ei pruugi pakkuda sama head lahendust teistesse suundadesse või pikematele vahemaadele.
  • Sama kehtib koondvedude, LTL või täiskoormaveose (FTL) puhul
  • Ülemereklientide jaoks võib olla vaja täiesti teistsugust partnerite komplekti
  • ... ja nii edasi.

Kõigi nende suhete haldamine on juba piisavalt keeruline. Kuid tõeline lõbu algab siis, kui püüate integreerida nende IT-süsteeme! (kuna ühtset veonduse API protokolli ei ole)

Teiseks peame kokku leppima ulatuses.

Kõik logistikaettevõtted ei paku sama teenindustaset. Mõnel on väga keerukad API-d, mis pakuvad kohest veohinna arvutust, broneerimist, etikette, jälgimist, kulleriteenuse tellimist jne, samas kui teistel võib olla ainult portaal, kuhu saate sisse logida ja broneeringu esitada. Mõnel pole üldse IT-süsteeme - ainult e-post. Meie sihtolukorra jaoks hoiame asjad lihtsad ja püüame lihtsalt:

  1. Esitada veotellimuse
  2. Saada vastu veoetikette
  3. Võib-olla saada hinnanguline veohind, kui meil veab!

Kõlab piisavalt lihtsalt, eks? Oh, kui vaid...

Vedajate ühendused – tere tulemast džunglisse


Asjade käsitsi haldamise viis, mis näib olevat enamiku ettevõtete jaoks tööstusharu standard, hõlmab vedajate portaalide kasutamist võimaluse korral ja suhtlemist e-posti teel ülejäänud veopartneritega. Meie näites eeldame, et veohinnakiri, ajakavad, tarneajad ja arvete käsitlemine hallatakse eraldi. Broneeringute esitamiseks püüame luua API-ühenduse oma ERP-süsteemist.

Oletame, et oleme valinud järgmise transpordiettevõtete nimekirja ja peame looma otsese API-ühenduse nende süsteemidega oma ERP-tarkvarast. See valik on juhuslik ja hõlmab vaid murdosa erinevatest vedajate API-dest.

DHL Express – kasutab portaali nimega MyDHL, millel on ka API võimalused. Siiski kasutab see erinevaid API-sid Freight, Express ja Global Forwarding harude jaoks ning erinevaid API lähenemisviise erinevates piirkondades. Veebiteenuse kasutamiseks on vaja SOAP protokolli, RESTful teenuseid või lihtsat XML-i ning arendajad peaksid olema tuttavad XML/JSON-iga ja omama põhiteadmisi veebiteenustest. Ainuüksi API spetsifikatsioon on 457 lehekülge pikk. See on põhjalik, kuid teie arendaja nõuab teilt tunde selle lugemise eest. Pärast rakendamist peaksite käivitama keskmiselt 5-12 päringut saadetise kohta, alustades autentimisest kuni aadresside valideerimise, saadavuse kontrollimise ja etikettide taotlemiseni.

Schenker – kasutab erinevates piirkondades erinevaid API/EDI lahendusi. Kõige sagedamini kasutatakse SOAP protokolli XML-formaadis. Sõnum ise on lihtne, eeldusel, et kõik võimalikud vead on korralikult käsitletud. API rakendamiseks vajavad arendajad isiklikku juurdepääsu. Sõltuvalt teie asukohast võidakse teilt paluda hoopis EDIFACT-lahenduse rakendamist, mida käsitlen hiljem.

DSV – on hiljuti üle läinud oma API-võimalustega portaalile nimega MyDSV. Arvestades, et API on üsna uus, kasutab see ära mõningaid uusimaid ja kõige kaasaegsemaid lähenemisviise API-maailmas. Vaatamata keerukusele autentimisel ja nende tootekataloogis navigeerimisel on lähenemine lihtne. Taas, sõltuvalt teie asukohast võidakse eelistada EDIFACT-i.

FedEx ja TNT – see võib olla lõbus. Kõigepealt peate kindlaks tegema, kas kasutate TNT või FedEx-i teenuseid. Kuigi nad oleksid pidanud olema sama ettevõte juba mitu aastat, on üleminek endiselt pooleli. Kui teie leping on TNT-ga, palutakse teil tõenäoliselt rakendada TNT Express Connect API-t. Rakendamine ise on keskmise keerukusega. Miinuseks on see, et seda API-t peetakse aegunuks ja see suletakse lõpuks. FedEx-i API on seevastu keerulisem ja pakub mitmeid võimalusi sõltuvalt teie asukohast. Cargosonis oleme rakendanud FedEx Compatible API, mis pakub mõningaid väga korralikke lisafunktsioone, kuid on saadaval ainult FedEx Compatible partneritele.

UPS – kasutab JSON-põhist API-t ja OAuth-i autentimiseks, mis tähendab, et peate käivitama päris mitu päringut, enne kui saate oma broneeringu läbi ja etiketid tagasi.

Järgmisena on meil EDIFACT, mida kasutavad paljud transpordiettevõtted nagu DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics jne. See on väga vana standard ja isegi kui võib tunduda, et saaksite hakkama ühe API integratsiooniga mitme logistikaettevõtte jaoks, mõelge uuesti. Suurim miinus on see, et see on failide vahetusel põhinev ühendus, mis tähendab, et peaksite genereerima tegeliku füüsilise faili, seejärel edastama selle FTP kaudu ja sõna otseses mõttes lootma, et kõik on korras, sest vigade ja hoiatuste kohta on väga tülikas tagasisidet saada.

Sarnane EDIFACT-iga on FORTRAS, failipõhine ühendus samade puudustega. Seda kasutatakse rohkem Saksamaal ja naaberriikides. Mitte ainult ei ole failivahetuse väljakutsuv, vaid failivorming ise on raskesti loetav ja seetõttu väga aeganõudev vigade silumiseks. Mõned tuntud ettevõtted, kes seda kasutavad, on Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss jne.

Isegi pärast kõigi eelmainitud integratsioonide rakendamist jääb küsimus:

Mida teha vedajatega, kellel puudub igasugune IT-süsteem või portaal, rääkimata API-st veotellimuste vastuvõtmiseks?

Lihtsaim lahendus on saata lihtne e-kiri. Kuigi see võib kõlada lihtsalt, süveneme sügavamale. Tehnilise ühenduse loomine teie meiliserveriga on üks asi, aga mis saab kontaktidest? Tavaliselt tegelevad erinevate suundadega erinevad kontaktisikud ja inimesed vahetavad ametikohti. Seega peaksite oma ERP-sse ehitama üsna põhjaliku kontaktimaatriksi.

Niisiis, millised on alternatiivid erinevate vedajate API-de ja EDI protokollidega võitlemisele?

Üks võimalus, mida kaaluda, on mitme vedaja API. Sisuliselt on see teenusepakkuja, kes on loonud kõik vedajate ühendused, olgu need siis kaasaegsed API-d, vanad EDIFACT- või FORTRAS-põhised EDI protokollid või e-posti integratsioonid, ja teinud need kättesaadavaks oma standardiseeritud veonduse API kaudu. Selle asemel, et rakendada erinevaid vedajate API-sid ja hoida neid ajakohasena, saate rakendada ainult ühe mitme vedaja API standardi ja käivitada kõik oma veotellimused selle kaudu.

Aga me oleme läinud veelgi kaugemale.

Mitme vedaja tarkvara – muudab Sinu olemasolevad vedajad paremaks?


Erinevad logistikaettevõtted pakuvad erinevaid teenustasemeid. Mõned pakuvad broneerimise API-t, teised mitte; mõned pakuvad jälgimisvõimalusi, teistel see funktsioon puudub. Cargosonis oleme rakendanud kõik funktsioonid, mis täidavad iga transpordiettevõtte lüngad.

Näiteks kui vedajal pole võimalik veebis broneerida, pakume selleks portaali. Kui neil puudub jälgimine, lisame selle. Meil on süsteemid kättetoimetamise tõendite (POD) ja muude dokumentide üleslaadimiseks, täisfunktsionaalne mitme vedaja API, ETA hinnangud, veohinna arvutused, jõudluse statistika ja isegi transpordi CO2 heite näitajad. Põhimõtteliselt, mida iganes vedajal puudu on, oleme selle ehitanud, et te ei peaks muretsema IT- või teenustaseme erinevuste pärast oma vedajate vahel.


Erinevate vedajate teenustasemete ühtlustamine - universaalne veonduse API standard
Erinevate vedajate teenustasemete ühtlustamine - universaalne veonduse API standard




Vaata, kuidas Cargoson muudab teie olemasolevad vedajad paremaks

Siin on reaalne näide: Suured tegijad nagu FedEx, TNT ja DHL Express pakuvad hinna API-t. See tähendab, et kui käivitate Cargosonist hinnapäringu, tõmmatakse hinnad otse vedaja süsteemist. Samas juhul, kui ettevõte nagu DSV ei paku hinna API-t, laaditakse DSV poolt antud Exceli või PDF-i hinnakiri Cargosoni üles ja hinna arvutamine toimub meie süsteemis. Meil on selleks võimas veohinna üleslaadimise ja arvutamise mootor. Sama lähenemist saab rakendada kõigile teistele transpordiettevõtetele ja see kehtib ka muude funktsioonide puhul.

Meie eesmärk on lihtne: pakkuda teile ühtlast, kvaliteetset kogemust kõigi vedajate lõikes, isegi kui nad kõik ei alusta samade võimalustega. De facto universaalne vedaja API standard ja mitme vedaja platvorm ühes.

Kui otsite paremat viisi oma vedajate integratsioonide haldamiseks, saab Cargoson aidata. Meie platvorm pakub ühtset, standardiseeritud transpordi API-t, mis ühendab teid kõigi teie vedajatega, olenemata nende individuaalsetest võimalustest. See tähendab, et saate kasutada kõiki oma veoteenuseid ühe ühtse liidese kaudu, muretsemata aluseks olevate tehniliste erinevuste pärast.

Soovite näha, kuidas see võiks teie ettevõtte jaoks toimida? Hüppame kiirele kõnele, et arutada teie praegust seadistust ja konkreetseid integreerimisega seotud väljakutseid. Võime läbi vaadata mõned reaalsed näited sellest, kuidas Cargoson on aidanud ettevõtteid teie omaga sarnastes olukordades:

Broneeri tasuta 30-minutiline konsultatsioon