För ett tag sedan gav jag mig ut på ett uppdrag att ta reda på om det fanns en enhetlig transport-API/EDI-standard som används av flera logistikföretag. Säkert måste något sådant existera i dagens läge, eller hur? Ett universellt API-format för frakt?

Tja, för att göra en lång historia kort, det existerar inte.

Det närmaste du kan komma är någon API-leverantör som har byggt många transportörs-API-anslutningar och sedan erbjuder sin egen API-endpoint för att få tillgång till olika transporttjänstleverantörer.

I den här artikeln kommer jag att gå igenom några olika transportörs-API:er, kort beskriva deras möjligheter och diskutera sätt att implementera dem.

OBS! Om du bara letar efter ett universellt transportprotokoll för API, här är en länk där du kan boka ett snabbt samtal med mig.

Hur som helst, låt oss börja med ett...

Låt oss först definiera målet.

Tänk dig en genomsnittlig tillverkare med både inhemska och internationella kunder och leverantörer. Varor behöver hämtas från leverantörer och levereras till produktionsplatsen, medan de färdiga produkterna behöver skickas till kunderna.

För att etablera en pålitlig leveranskedja skulle din typiska medelstora tillverkare behöva 10-20 transportpartners:

Att hantera alla dessa relationer är komplext nog. Men det riktigt roliga börjar när du försöker integrera deras IT-system! (eftersom det inte finns något enhetligt frakt-API-protokoll)

För det andra måste vi komma överens om omfattningen.

Inte alla logistikföretag erbjuder samma servicenivå. Vissa har mycket sofistikerade API:er som erbjuder omedelbar fraktprissättning, bokning, etiketter, spårning, kurirförfrågningar etc., medan andra kanske bara har en portal där du kan logga in och skicka in en bokning. Vissa har inga IT-system alls - bara e-post. För vårt målscenario, låt oss hålla det enkelt och bara sikta på att:

Låter enkelt nog, eller hur? Åh, om det bara vore så enkelt...

Det manuella sättet att hantera saker, som verkar vara branschstandard för de flesta företag, innebär att använda transportörsportaler där det är möjligt och kommunicera via e-post med resten av transportpartnerna. I vårt exempel antar vi att transportprislistor, scheman, ledtider och fakturahantering hanteras separat. För bokningsinlämningar strävar vi efter att bygga en API-anslutning från vårt ERP-system.

Låt oss anta att vi har valt följande lista över transportföretag och behöver bygga en direkt API-anslutning till deras system från vår ERP-programvara. Detta urval är slumpmässigt och täcker bara en bråkdel av de olika transportörs-API:er som finns där ute.

DHL Express – använder en portal som kallas MyDHL, som också har API-möjligheter. Den använder dock olika API:er för Freight, Express och Global Forwarding-grenarna, och olika API-metoder i olika regioner. Åtkomst till webbtjänsten kräver ett SOAP-protokoll, RESTful-tjänster eller vanlig XML, och utvecklare bör vara bekanta med XML/JSON och ha en grundläggande förståelse för webbtjänster. API-specifikationen är ensam 457 sidor lång. Den är grundlig, men din utvecklare kommer att debitera dig för timmarna som spenderas bara på att läsa den. När den väl är implementerad skulle du behöva utlösa i genomsnitt 5-12 förfrågningar per försändelse, från autentisering till adressvalideringar, tillgänglighetskontroller och etikettsförfrågningar.

Schenker – använder olika API/EDI-lösningar i olika regioner. Oftast använder den ett SOAP-protokoll med ett XML-format. Själva meddelandet är okomplicerat, förutsatt att alla möjliga fel hanteras korrekt. Utvecklare behöver personlig åtkomst för att implementera API:et. Beroende på din plats kan du bli ombedd att implementera en EDIFACT-lösning istället, vilket jag kommer att täcka senare.

DSV – har nyligen flyttat till sin API-kapabla portal som kallas MyDSV. Med tanke på att API:et är ganska nytt, drar det nytta av några av de senaste och modernaste metoderna i API-världen. Trots komplexiteten vid autentisering och navigering i deras produktkatalog är metoden okomplicerad. Återigen, beroende på din plats kan EDIFACT föredras.

FedEx och TNT – detta kan vara roligt. Först måste du avgöra om du använder TNT- eller FedEx-tjänster. Även om de borde ha varit samma företag i ganska många år, är migreringen fortfarande pågående. Om ditt kontrakt är med TNT kommer du troligen att bli ombedd att implementera TNT Express Connect API. Själva implementeringen är av genomsnittlig komplexitet. Nackdelen är att detta API anses vara föråldrat och kommer så småningom att stängas ner. FedEx API, å andra sidan, är mer komplext och erbjuder flera alternativ beroende på vilken region du befinner dig i. På Cargoson har vi implementerat FedEx Compatible API, som erbjuder några mycket snygga ytterligare funktioner men är endast tillgängligt för FedEx Compatible-partners.

UPS – använder ett JSON-baserat API och OAuth för autentisering, vilket innebär att det finns ganska många förfrågningar du skulle behöva utlösa innan du får din bokning igenom och etiketterna tillbaka.

Näst har vi EDIFACT, som används av många transportföretag som DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics, etc. Det är en mycket gammal standard, och även om det kan verka som att du skulle kunna komma undan med en API-integration för flera logistikföretag, tänk igen. Den största nackdelen är att det är en filutbytesbaserad anslutning, vilket innebär att du skulle behöva generera en faktisk, fysisk fil, sedan överföra den via FTP och bokstavligen hoppas att allt är okej eftersom det finns mycket besvärlig feedback om fel och varningar.

Liknande EDIFACT är FORTRAS, en filbaserad anslutning med samma brister. Den används mer i Tyskland och grannländerna. Inte bara är filutbytet utmanande, utan själva filformatet är svårt att läsa och därför mycket tidskrävande att felsöka. Några välkända företag som använder det inkluderar Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss, etc.

Även efter att ha implementerat alla integrationer som nämnts ovan kvarstår frågan:

Vad gör du med transportföretag som saknar något IT-system eller portal, för att inte tala om ett API för att acceptera transportorder?

Den enklaste lösningen är att skicka ett enkelt e-postmeddelande. Även om detta kan låta okomplicerat, låt oss gå djupare. Att sätta upp den tekniska anslutningen till din e-postserver är en sak, men vad med kontakter? Normalt hanteras olika riktningar av olika kontaktpersoner, och människor byter positioner. Därför skulle du behöva bygga en ganska omfattande kontaktmatris i ditt ERP.

Så, vilka är alternativen till att brottas med disparata transportörs-API:er och EDI-protokoll?

Ett alternativ att överväga är ett multi-carrier API. I grund och botten är detta en tjänsteleverantör som har byggt alla transportörsanslutningar, vare sig det är moderna API:er, gamla EDIFACT- eller FORTRAS-baserade EDI-protokoll eller e-postintegrationer, och gjort dem tillgängliga via sitt eget, standardiserade frakt-API. Istället för att implementera olika transportörs-API:er och hålla dem uppdaterade kan du implementera bara ett multi-carrier API-standard och utlösa alla dina transportorder genom det.

Men vi har tagit det ännu längre.

Olika logistikföretag erbjuder varierande servicenivåer. Vissa tillhandahåller ett boknings-API, medan andra inte gör det; vissa erbjuder spårningsmöjligheter, medan andra saknar denna funktion. På Cargoson har vi implementerat alla funktioner som fyller i luckorna för varje transportföretag.

Till exempel, när en transportör inte erbjuder online-bokning, tillhandahåller vi en portal för det. Om de saknar spårning lägger vi till det. Vi har system för att ladda upp leveransbevis (POD) och andra dokument, fullfjädrat multi-carrier API, ETA-uppskattningar, transportprisberäkningar, prestandastatistik och till och med transportens CO2-utsläppssiffror. I princip, vad än en transportör saknar har vi byggt det så att du inte behöver oroa dig för IT- eller servicenivåskillnader mellan dina transportörer.

Se hur Cargoson gör dina befintliga transportörer bättre

Här är ett exempel från verkligheten: Stora aktörer som FedEx, TNT och DHL Express erbjuder ett pris-API. Detta innebär att när du utlöser en prisförfrågan från Cargoson hämtas priserna direkt från transportörens system. I fall där ett företag som DSV inte tillhandahåller ett pris-API, laddas Excel- eller PDF-prislistan som tillhandahålls av DSV upp till Cargoson, och prisberäkningen utförs inom vårt system. Vi har en kraftfull fraktprisuppladdnings- och beräkningsmotor för det. Samma metod kan tillämpas på alla andra transportföretag och är också tillämplig på andra funktioner.

Vårt mål är enkelt: ge dig en konsekvent upplevelse av hög kvalitet över alla transportörer, även om de inte alla börjar med samma förmågor. En de facto universell transportörs-API-standard och multi-carrier plattform i ett.

Om du letar efter ett bättre sätt att hantera dina transportörsintegrationer kan Cargoson hjälpa till. Vår plattform tillhandahåller ett enda, standardiserat transport-API som ansluter dig till alla dina transportörer, oavsett deras individuella förmågor. Detta innebär att du kan få tillgång till alla dina frakttjänster genom ett enhetligt gränssnitt, utan att behöva oroa dig för de underliggande tekniska skillnaderna.

Vill du se hur det skulle kunna fungera för ditt företag? Låt oss hoppa på ett snabbt samtal för att diskutera din nuvarande uppsättning och specifika integrationsutmaningar. Vi kan gå igenom några exempel från verkligheten på hur Cargoson har hjälpt företag i liknande fall som ditt:

Boka en gratis 30-minuters konsultation