Egy ideje elhatároztam, hogy utánajárok, létezik-e egységes szállítási API/EDI szabvány, amelyet több logisztikai vállalat használ. Bizonyára napjainkban már létezik ilyesmi, nem igaz? Egy univerzális szállítási API formátum?

Nos, röviden összefoglalva, nem létezik.

A legközelebbi megoldás egy olyan API-szolgáltató lehet, aki sok fuvarozói API-kapcsolatot épített ki, és aztán saját API-végpontot kínál a különböző szállítási szolgáltatók eléréséhez.

Ebben a cikkben néhány különböző fuvarozói API-t fogok bemutatni, röviden ismertetem a képességeiket, és megvitatom a megvalósításuk módjait.

Megjegyzés! Ha csak egy univerzális szállítási API protokollt keres, itt egy link, ahol gyors beszélgetést foglalhat velem.

Nos, kezdjük egy...

Először határozzuk meg a célt.

Vegyünk egy átlagos gyártót, akinek belföldi és nemzetközi ügyfelei és beszállítói is vannak. Az árut fel kell venni a beszállítóktól és el kell szállítani a gyártási helyszínre, míg a késztermékeket el kell juttatni az ügyfelekhez.

Egy megbízható ellátási lánc kialakításához egy tipikus közepes méretű gyártónak 10-20 szállítási partnerre lenne szüksége:

Már önmagában ezeknek a kapcsolatoknak a kezelése is elég összetett. De az igazi móka akkor kezdődik, amikor megpróbálja integrálni az IT-rendszereiket! (mivel nincs egységes fuvarozási API protokoll)

Másodszor, meg kell állapodnunk a hatókörben.

Nem minden logisztikai vállalat kínál azonos szolgáltatási szintet. Néhánynak nagyon kifinomult API-ja van, amely azonnali fuvardíjszámítást, foglalást, címkéket, nyomkövetést, futárszolgálat-kérést stb. biztosít, míg másoknak csak egy portáljuk van, ahová bejelentkezhet és leadhat egy foglalást. Néhánynak egyáltalán nincs IT-rendszere - csak e-mail. A célforgatókönyvünkhöz tartsuk egyszerűen a dolgokat, és csak arra törekedjünk, hogy:

Elég egyszerűnek hangzik, igaz? Ó, bárcsak így lenne...

A dolgok kézi kezelésének módja, amely úgy tűnik, hogy a legtöbb vállalat iparági szabványa, magában foglalja a fuvarozói portálok használatát, ahol csak lehetséges, és e-mailen keresztüli kommunikációt a többi szállítási partnerrel. Példánkban feltételezzük, hogy a szállítási árlistákat, menetrendeket, szállítási időket és a számlakezelést külön kezelik. A foglalások leadásához az ERP-rendszerünkből API-kapcsolatot szeretnénk kiépíteni.

Tegyük fel, hogy a következő szállítmányozó vállalatokat választottuk ki, és közvetlen API-kapcsolatot kell kiépítenünk a rendszereikhez az ERP-szoftverünkből. Ez a választás véletlenszerű, és csak töredékét fedi le a különböző fuvarozói API-knak.

DHL Express – egy MyDHL nevű portált használ, amely API-képességekkel is rendelkezik. Azonban különböző API-kat használ a Freight, Express és Global Forwarding ágazatokhoz, és különböző API-megközelítéseket alkalmaz a különböző régiókban. A webszolgáltatáshoz való hozzáféréshez SOAP protokoll, RESTful szolgáltatások vagy egyszerű XML szükséges, és a fejlesztőknek ismerniük kell az XML/JSON-t, és alapvető ismeretekkel kell rendelkezniük a webszolgáltatásokról. Csak az API specifikáció 457 oldal hosszú. Alapos, de a fejlesztő fel fogja számolni az órákat, amit csak az elolvasásával töltött. A megvalósítás után átlagosan 5-12 kérést kellene indítania szállítmányonként, kezdve a hitelesítéstől a címellenőrzéseken, rendelkezésre állási ellenőrzéseken és címkekéréseken át.

Schenker – különböző API/EDI megoldásokat használ a különböző régiókban. Leggyakrabban SOAP protokollt használ XML formátummal. Maga az üzenet egyszerű, feltéve, hogy minden lehetséges hibát megfelelően kezelnek. A fejlesztőknek személyre szabott hozzáférésre van szükségük az API megvalósításához. A tartózkodási helyétől függően előfordulhat, hogy ehelyett EDIFACT megoldás megvalósítását kérik, amelyet később tárgyalok.

DSV – nemrég áttért a MyDSV nevű API-képes portáljukra. Tekintettel arra, hogy az API meglehetősen új, kihasználja az API-világ legújabb és legmodernebb megközelítéseinek némelyikét. A hitelesítés és a termékkatalógusukban való navigálás összetettsége ellenére a megközelítés egyszerű. Ismét, a tartózkodási helyétől függően előnyben részesíthetik az EDIFACT-ot.

FedEx és TNT – ez lehet szórakoztató. Először meg kell határoznia, hogy TNT vagy FedEx szolgáltatásokat használ-e. Bár már évek óta ugyanannak a vállalatnak kellene lenniük, a migráció még mindig folyamatban van. Ha a szerződése a TNT-vel van, valószínűleg a TNT Express Connect API megvalósítását fogják kérni. Maga a megvalósítás átlagos összetettségű. A hátránya az, hogy ezt az API-t elavultnak tekintik, és végül le fogják állítani. A FedEx API ezzel szemben összetettebb, és több lehetőséget kínál attól függően, hogy melyik régióban tartózkodik. A Cargosonnál megvalósítottuk a FedEx Compatible API-t, amely néhány nagyon jó további funkcionalitást biztosít, de csak a FedEx Compatible partnerek számára érhető el.

UPS – JSON-alapú API-t és OAuth hitelesítést használ, ami azt jelenti, hogy elég sok kérést kell indítania, mielőtt a foglalását és a címkéket visszakapná.

Ezután következik az EDIFACT, amelyet sok szállítmányozó vállalat használ, például a DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics stb. Ez egy nagyon régi szabvány, és még ha úgy is tűnhet, hogy egy API-integrációval megúszhatja több logisztikai vállalat esetében, gondolja át újra. A legnagyobb hátránya, hogy fájlcserén alapuló kapcsolat, ami azt jelenti, hogy egy tényleges, fizikai fájlt kellene generálnia, majd FTP-n keresztül továbbítania, és szó szerint reménykednie, hogy minden rendben van, mert nagyon nehézkes visszajelzést kapni a hibákról és figyelmeztetésekről.

Az EDIFACT-hoz hasonló a FORTRAS, egy fájlalapú kapcsolat ugyanazokkal a hiányosságokkal. Inkább Németországban és a szomszédos országokban használják. Nemcsak a fájlcsere jelent kihívást, de maga a fájlformátum is nehezen olvasható, ezért nagyon időigényes a hibák elhárítása. Néhány jól ismert vállalat, amely használja, többek között a Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss stb.

Még a fent említett összes integráció megvalósítása után is felmerül a kérdés:

Mit tesz azokkal a fuvarozó vállalatokkal, amelyeknek nincs IT-rendszerük vagy portáljuk, nemhogy API-juk a szállítási megrendelések elfogadására?

A legegyszerűbb megoldás egy egyszerű e-mail küldése. Bár ez egyszerűnek tűnhet, nézzük meg közelebbről. A levelezőszerverhez való technikai kapcsolat beállítása egy dolog, de mi a helyzet a kapcsolattartókkal? Normális esetben a különböző irányokat különböző kapcsolattartó személyek kezelik, és az emberek változtatják a pozícióikat. Így egy meglehetősen átfogó kapcsolati mátrixot kellene beépítenie az ERP-jébe.

Tehát mik az alternatívák a különböző fuvarozói API-k és EDI protokollok kezelésével való küzdelemre?

Egy lehetőség, amit érdemes megfontolni, a több fuvarozós API. Lényegében ez egy olyan szolgáltató, aki kiépítette az összes fuvarozói kapcsolatot, legyen szó modern API-król, régi EDIFACT- vagy FORTRAS-alapú EDI protokollokról vagy e-mail integrációkról, és elérhetővé tette őket saját, szabványosított szállítási API-ján keresztül. Ahelyett, hogy különböző fuvarozói API-kat kellene megvalósítania és naprakészen tartania, csak egy több fuvarozós API szabványt kell megvalósítania, és az összes szállítási megrendelését ezen keresztül indíthatja.

De mi még tovább mentünk.

A különböző logisztikai vállalatok eltérő szolgáltatási szintet kínálnak. Néhányan foglalási API-t biztosítanak, mások nem; néhányan nyomkövetési képességeket kínálnak, míg mások nem rendelkeznek ezzel a funkcióval. A Cargosonnál minden olyan funkciót megvalósítottunk, amely kitölti a hiányosságokat minden egyes szállítmányozó vállalatnál.

Például, amikor egy fuvarozó nem kínál online foglalást, mi biztosítunk egy portált erre a célra. Ha hiányzik náluk a nyomkövetés, mi hozzáadjuk. Vannak rendszereink a kézbesítési igazolás (POD) és egyéb dokumentumok feltöltésére, teljes funkcionalitású több fuvarozós API, ETA becslések, szállítási árkalkulációk, teljesítménystatisztikák, és még szállítási CO2-kibocsátási adatok is. Alapvetően bármit, ami egy fuvarozónál hiányzik, mi megépítettük, hogy Önnek ne kelljen aggódnia az IT- vagy szolgáltatási szintbeli különbségek miatt a fuvarozói között.

Nézze meg, hogyan teszi a Cargoson jobbá a meglévő fuvarozóit

Íme egy valós példa: A nagy szereplők, mint a FedEx, TNT és DHL Express árazási API-t kínálnak. Ez azt jelenti, hogy amikor Ön árajánlatot kér a Cargosontól, az árak közvetlenül a fuvarozó rendszeréből érkeznek. Azonban olyan esetekben, amikor egy cég, mint a DSV nem biztosít árazási API-t, a DSV által biztosított Excel vagy PDF árlistát feltöltjük a Cargasonba, és az árkalkulációt a rendszerünkön belül végezzük el. Ehhez egy erőteljes fuvardíj-feltöltő és kalkulációs motorral rendelkezünk. Ugyanez a megközelítés alkalmazható az összes többi szállítmányozó vállalatra, és más funkciókra is érvényes.

A célunk egyszerű: következetes, magas minőségű élményt nyújtani Önnek az összes fuvarozóval kapcsolatban, még akkor is, ha nem mindegyikük indul ugyanazokkal a képességekkel. Egy de facto univerzális fuvarozói API szabvány és több fuvarozós platform egyben.

Ha jobb módot keres a fuvarozói integrációk kezelésére, a Cargoson segíthet. Platformunk egyetlen, szabványosított szállítási API-t biztosít, amely összeköti Önt az összes fuvarozójával, függetlenül azok egyéni képességeitől. Ez azt jelenti, hogy az összes szállítási szolgáltatásához hozzáférhet egy egységes felületen keresztül, anélkül, hogy aggódnia kellene az alapul szolgáló technikai különbségek miatt.

Szeretné látni, hogyan működhetne ez az Ön vállalkozása esetében? Ugorjunk egy gyors hívásra, hogy megbeszéljük a jelenlegi beállításait és specifikus integrációs kihívásait. Átnézhetünk néhány valós példát arról, hogyan segített a Cargoson az Önéhez hasonló esetekben lévő vállalatoknak:

Foglaljon egy ingyenes, 30 perces konzultációt