Enige tijd geleden begon ik aan een zoektocht om uit te vinden of er een uniforme transport API/EDI-standaard bestond die door verschillende logistieke bedrijven wordt gebruikt. Zeker in deze tijd moet zoiets toch bestaan, nietwaar? Een universeel verzend-API-formaat?

Nou, om een lang verhaal kort te maken, het bestaat niet.

Het dichtste in de buurt komt een API-aanbieder die veel vervoerdersverbindingen heeft gebouwd en vervolgens zijn eigen API-eindpunt aanbiedt om toegang te krijgen tot verschillende transportdienstverleners.

In dit artikel zal ik een aantal verschillende vervoerders-API's behandelen, kort hun mogelijkheden beschrijven en manieren bespreken om ze te implementeren.

NB! Als u alleen op zoek bent naar een universeel transport-API-protocol, hier is een link waar u een kort gesprek met mij kunt boeken.

Laten we beginnen met een…

Laten we eerst het doel definiëren.

Neem een gemiddelde fabrikant met zowel binnenlandse als internationale klanten en leveranciers. Goederen moeten worden opgehaald bij leveranciers en afgeleverd op de productielocatie, terwijl de eindproducten naar klanten moeten worden verzonden.

Om een betrouwbare toeleveringsketen op te zetten, zou uw typische middelgrote fabrikant 10-20 transportpartners nodig hebben:

Het beheren van al die relaties is al complex genoeg. Maar het echte plezier begint als u probeert hun IT-systemen te integreren! (aangezien er geen uniform vracht-API-protocol bestaat)

Ten tweede moeten we het eens worden over de reikwijdte.

Niet alle logistieke bedrijven bieden hetzelfde serviceniveau. Sommige hebben zeer geavanceerde API's die directe vrachtprijzen, boekingen, labels, tracking, koeriersverzoeken, etc. bieden, terwijl andere misschien alleen een portaal hebben waar u kunt inloggen en een boeking kunt indienen. Sommige hebben helemaal geen IT-systemen - alleen e-mail. Voor ons doelscenario houden we het eenvoudig en richten we ons alleen op:

Klinkt eenvoudig genoeg, toch? Oh, was het maar zo simpel...

De handmatige manier van werken, die de industriestandaard lijkt te zijn voor de meeste bedrijven, omvat het gebruik van vervoerdersportalen waar mogelijk en communicatie via e-mail met de rest van de transportpartners. In ons voorbeeld gaan we ervan uit dat transportprijslijsten, schema's, levertijden en factuurafhandeling apart worden beheerd. Voor het indienen van boekingen streven we ernaar een API-verbinding van ons ERP-systeem te bouwen.

Laten we aannemen dat we de volgende lijst van transportbedrijven hebben geselecteerd en een directe API-verbinding met hun systemen vanuit onze ERP-software moeten bouwen. Deze selectie is willekeurig en dekt slechts een fractie van de verschillende vervoerders-API's die er zijn.

DHL Express – gebruikt een portaal genaamd MyDHL, dat ook API-mogelijkheden heeft. Het gebruikt echter verschillende API's voor Freight, Express en Global Forwarding-takken, en verschillende API-benaderingen in verschillende regio's. Toegang tot de webservice vereist een SOAP-protocol, RESTful Services of gewone XML, en ontwikkelaars moeten bekend zijn met XML/JSON en een basiskennis hebben van webservices. De API-specificatie alleen al is 457 pagina's lang. Het is grondig, maar uw ontwikkelaar zal u in rekening brengen voor de uren die besteed zijn aan alleen het lezen ervan. Eenmaal geïmplementeerd, zou u gemiddeld 5-12 verzoeken per zending moeten activeren, beginnend met authenticatie tot adresvalidaties, beschikbaarheidscontroles en labelverzoeken.

Schenker – gebruikt verschillende API/EDI-oplossingen in verschillende regio's. Meestal gebruikt het een SOAP-protocol met een XML-formaat. Het bericht zelf is eenvoudig, mits alle mogelijke fouten correct worden afgehandeld. Ontwikkelaars hebben gepersonaliseerde toegang nodig om de API te implementeren. Afhankelijk van uw locatie kan u worden gevraagd om in plaats daarvan een EDIFACT-oplossing te implementeren, die ik later zal behandelen.

DSV – is onlangs overgegaan op hun API-capabele portaal genaamd MyDSV. Gezien het feit dat de API vrij nieuw is, maakt het gebruik van enkele van de nieuwste en modernste benaderingen in de API-wereld. Ondanks de complexiteit bij het authenticeren en navigeren door hun productcatalogus, is de aanpak eenvoudig. Opnieuw, afhankelijk van uw locatie, kan EDIFACT de voorkeur hebben.

FedEx en TNT – dit kan leuk zijn. Eerst moet u bepalen of u TNT- of FedEx-diensten gebruikt. Hoewel ze al jaren hetzelfde bedrijf zouden moeten zijn, is de migratie nog steeds gaande. Als uw contract bij TNT ligt, zal u hoogstwaarschijnlijk worden gevraagd om de TNT Express Connect API te implementeren. De implementatie zelf is van gemiddelde complexiteit. Het nadeel is dat deze API als verouderd wordt beschouwd en uiteindelijk zal worden uitgeschakeld. De FedEx API daarentegen is complexer en biedt verschillende opties afhankelijk van de regio waar u gevestigd bent. Bij Cargoson hebben we de FedEx Compatible API geïmplementeerd, die enkele zeer nette extra functionaliteiten biedt maar alleen beschikbaar is voor FedEx Compatible partners.

UPS – gebruikt een op JSON gebaseerde API en OAuth voor authenticatie, wat betekent dat u vrij veel verzoeken moet activeren voordat u uw boeking doorheeft en labels terugkrijgt.

Vervolgens hebben we EDIFACT, gebruikt door veel transportbedrijven zoals DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics, etc. Het is een zeer oude standaard, en zelfs als het lijkt dat u met één API-integratie voor verschillende logistieke bedrijven zou kunnen volstaan, denk dan nog eens na. Het grootste nadeel is dat het een op bestandsuitwisseling gebaseerde verbinding is, wat betekent dat u een echt, fysiek bestand zou moeten genereren, het vervolgens via FTP zou moeten verzenden en letterlijk moet hopen dat alles in orde is omdat er zeer omslachtige feedback is over fouten en waarschuwingen.

Vergelijkbaar met EDIFACT is FORTRAS, een op bestanden gebaseerde verbinding met dezelfde tekortkomingen. Het wordt meer gebruikt in Duitsland en aangrenzende landen. Niet alleen is de bestandsuitwisseling uitdagend, maar het bestandsformaat zelf is moeilijk te lezen en daarom zeer tijdrovend om fouten op te sporen. Enkele bekende bedrijven die het gebruiken zijn Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss, etc.

Zelfs na het implementeren van alle bovengenoemde integraties blijft de vraag:

Wat doet u met transportbedrijven die geen IT-systeem of portaal hebben, laat staan een API om transportopdrachten te accepteren?

De eenvoudigste oplossing is het versturen van een eenvoudige e-mail. Hoewel dit eenvoudig klinkt, laten we er dieper op ingaan. Het opzetten van de technische verbinding met uw mailserver is één ding, maar hoe zit het met contacten? Normaal gesproken worden verschillende richtingen behandeld door verschillende contactpersonen, en mensen veranderen van functie. Dus zou u een vrij uitgebreide contactmatrix in uw ERP moeten bouwen.

Wat zijn dus de alternatieven voor het worstelen met uiteenlopende vervoerders-API's en EDI-protocollen?

Een optie om te overwegen is een multi-carrier API. In essentie is dit een dienstverlener die alle vervoerdersverbindingen heeft gebouwd, of het nu gaat om moderne API's, oude EDIFACT- of FORTRAS-gebaseerde EDI-protocollen of e-mailintegraties, en deze beschikbaar heeft gemaakt via hun eigen, gestandaardiseerde verzend-API. In plaats van verschillende vervoerders-API's te implementeren en up-to-date te houden, kunt u gewoon één multi-carrier API-standaard implementeren en al uw transportopdrachten daardoor activeren.

Maar we hebben het nog verder doorgetrokken.

Verschillende logistieke bedrijven bieden verschillende serviceniveaus. Sommige bieden een boekings-API, terwijl andere dat niet doen; sommige bieden trackingmogelijkheden, terwijl andere deze functie missen. Bij Cargoson hebben we alle functies geïmplementeerd die de hiaten voor elk transportbedrijf opvullen.

Bijvoorbeeld, wanneer een vervoerder geen online boeking aanbiedt, bieden wij daarvoor een portaal. Als ze tracking missen, voegen we het toe. We hebben systemen voor het uploaden van afleverbewijzen (POD) en andere documenten, een volledig uitgeruste multi-carrier API, ETA-schattingen, transportprijsberekeningen, prestatiestatistieken, en zelfs transport CO2-emissiecijfers. Kortom, wat een vervoerder ook mist, wij hebben het gebouwd zodat u zich geen zorgen hoeft te maken over IT- of serviceniveauverschillen tussen uw vervoerders.

Ontdek hoe Cargoson uw bestaande vervoerders verbetert

Hier is een voorbeeld uit de praktijk: Grote spelers zoals FedEx, TNT en DHL Express bieden een prijzen-API. Dit betekent dat wanneer u een prijsaanvraag doet via Cargoson, de prijzen rechtstreeks uit het systeem van de vervoerder worden gehaald. In gevallen waar een bedrijf als DSV geen prijzen-API aanbiedt, wordt de Excel- of PDF-prijslijst die door DSV wordt verstrekt, geüpload naar Cargoson, en de prijsberekening wordt binnen ons systeem uitgevoerd. We hebben daarvoor een krachtige vrachtprijs-upload en berekeningsengine. Dezelfde aanpak kan worden toegepast op alle andere transportbedrijven en is ook van toepassing op andere functies.

Ons doel is eenvoudig: u een consistente, hoogwaardige ervaring bieden met alle vervoerders, zelfs als ze niet allemaal met dezelfde mogelijkheden beginnen. Een de facto universele vervoerders-API-standaard en multi-carrier platform in één.

Als u op zoek bent naar een betere manier om uw vervoerdersintegraties te beheren, kan Cargoson helpen. Ons platform biedt een enkele, gestandaardiseerde transport-API die u verbindt met al uw vervoerders, ongeacht hun individuele mogelijkheden. Dit betekent dat u toegang heeft tot al uw verzendservices via één uniforme interface, zonder u zorgen te hoeven maken over de onderliggende technische verschillen.

Wilt u zien hoe het voor uw bedrijf zou kunnen werken? Laten we een kort gesprek plannen om uw huidige setup en specifieke integratieuitdagingen te bespreken. We kunnen enkele praktijkvoorbeelden doornemen van hoe Cargoson bedrijven in vergelijkbare situaties als de uwe heeft geholpen:

Plan een gratis, 30-minuten durende consultatie