For en stund siden satte jeg meg fore å finne ut om det fantes en enhetlig transport-API/EDI-standard som brukes av flere logistikkselskaper. Sikkert må noe slikt eksistere i vår tid, ikke sant? Et universelt API-format for forsendelser?

Vel, for å gjøre en lang historie kort, det eksisterer ikke.

Det nærmeste du kan komme er en API-leverandør som har bygget mange transportør-API-tilkoblinger og deretter tilbyr sitt eget API-endepunkt for å få tilgang til ulike transporttjenesteleverandører.

I denne artikkelen vil jeg dekke noen forskjellige transportør-APIer, kort beskrive deres muligheter, og diskutere måter å implementere dem på.

NB! Hvis du bare leter etter en universell transport-API-protokoll, her er en lenke hvor du kan bestille en rask samtale med meg.

Uansett, la oss begynne med et…

Først, la oss definere målet.

Tenk på en gjennomsnittlig produsent med både innenlandske og internasjonale kunder og leverandører. Varer må hentes fra leverandører og leveres til produksjonsstedet, mens de ferdige produktene må sendes til kunder.

For å etablere en pålitelig forsyningskjede, ville din typiske mellomstore produsent trenge 10-20 transportpartnere:

Å administrere alle disse forholdene er komplisert nok. Men den virkelige moroa begynner når du prøver å integrere IT-systemene deres! (siden det ikke finnes noen enhetlig frakt-API-protokoll)

For det andre må vi bli enige om omfanget.

Ikke alle logistikkselskaper tilbyr samme servicenivå. Noen har svært sofistikerte APIer som gir øyeblikkelig fraktprising, booking, etiketter, sporing, kurérforespørsler osv., mens andre kanskje bare har en portal hvor du kan logge inn og sende en booking. Noen har ikke IT-systemer i det hele tatt—bare e-post. For vårt målscenario, la oss holde ting enkelt og bare sikte på å:

Høres enkelt nok ut, ikke sant? Å, om bare...

Den manuelle måten å håndtere ting på, som ser ut til å være bransjestandarden for de fleste selskaper, innebærer å bruke transportørportaler der det er mulig og kommunisere via e-post med resten av transportpartnerne. I vårt eksempel antar vi at transportprislister, tidsplaner, leveringstider og fakturahåndtering administreres separat. For innsending av bookinger tar vi sikte på å bygge en API-tilkobling fra vårt ERP-system.

La oss anta at vi har valgt følgende liste over transportselskaper og trenger å bygge en direkte API-tilkobling til systemene deres fra vår ERP-programvare. Dette utvalget er tilfeldig og dekker bare en brøkdel av de forskjellige transportør-APIene som finnes der ute.

DHL Express – bruker en portal kalt MyDHL, som også har API-muligheter. Den bruker imidlertid forskjellige APIer for Freight, Express og Global Forwarding-avdelinger, og forskjellige API-tilnærminger i ulike regioner. Tilgang til webtjenesten krever en SOAP-protokoll, RESTful-tjenester eller ren XML, og utviklere bør være kjent med XML/JSON og ha en grunnleggende forståelse av webtjenester. API-spesifikasjonen alene er 457 sider lang. Den er grundig, men utvikleren din vil belaste deg for timene brukt bare på å lese den. Når den er implementert, ville du måtte utløse i gjennomsnitt 5-12 forespørsler per forsendelse, fra autentisering til adressevalideringer, tilgjengelighetskontroller og etiketteforespørsler.

Schenker – bruker forskjellige API/EDI-løsninger i ulike regioner. Oftest bruker den en SOAP-protokoll med et XML-format. Selve meldingen er enkel, forutsatt at alle mulige feil håndteres riktig. Utviklere trenger personlig tilgang for å implementere APIen. Avhengig av din plassering kan du bli bedt om å implementere en EDIFACT-løsning i stedet, som jeg vil dekke senere.

DSV – har nylig gått over til sin API-kapable portal kalt MyDSV. Gitt at APIen er ganske ny, drar den nytte av noen av de nyeste og mest moderne tilnærmingene i API-verdenen. Til tross for kompleksiteten ved autentisering og navigering i produktkatalogen deres, er tilnærmingen enkel. Igjen, avhengig av din plassering, kan EDIFACT foretrekkes.

FedEx og TNT – dette kan være gøy. Først må du bestemme om du bruker TNT- eller FedEx-tjenester. Selv om de skulle ha vært samme selskap i flere år, er migreringen fortsatt pågående. Hvis kontrakten din er med TNT, vil du mest sannsynlig bli bedt om å implementere TNT Express Connect API. Selve implementeringen er av gjennomsnittlig kompleksitet. Ulempen er at denne APIen anses som foreldet og vil bli stengt ned til slutt. FedEx-APIen, på den annen side, er mer kompleks og tilbyr flere alternativer avhengig av regionen du er basert i. Hos Cargoson har vi implementert FedEx Compatible API, som gir noen veldig fine tilleggsfunksjoner, men er bare tilgjengelig for FedEx Compatible-partnere.

UPS – bruker en JSON-basert API og OAuth for autentisering, noe som betyr at det er ganske mange forespørsler du må utløse før du får bookingen gjennom og etikettene tilbake.

Deretter har vi EDIFACT, som brukes av mange transportselskaper som DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics, osv. Det er en veldig gammel standard, og selv om det kan virke som om du kunne slippe unna med én API-integrasjon for flere logistikkselskaper, tenk igjen. Den største ulempen er at det er en filbasert utvekslingstilkobling, noe som betyr at du må generere en faktisk, fysisk fil, deretter overføre den via FTP og bokstavelig talt håpe at alt er ok fordi det er veldig tungvint tilbakemelding om feil og advarsler.

Lignende EDIFACT er FORTRAS, en filbasert tilkobling med de samme manglene. Den er mer i bruk i Tyskland og nabolandene. Ikke bare er filutvekling utfordrende, men selve filformatet er vanskelig å lese og derfor svært tidkrevende å feilsøke. Noen velkjente selskaper som bruker det inkluderer Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss, osv.

Selv etter å ha implementert alle integrasjonene nevnt ovenfor, gjenstår spørsmålet:

Hva gjør du med transportørselskaper som mangler ethvert IT-system eller portal, for ikke å snakke om en API for å akseptere transportordrer?

Den enkleste løsningen er å sende en enkel e-post. Selv om dette kan høres enkelt ut, la oss gå dypere. Å sette opp den tekniske tilkoblingen til e-postserveren din er én ting, men hva med kontakter? Normalt håndteres forskjellige retninger av forskjellige kontaktpersoner, og folk skifter stillinger. Derfor må du bygge en ganske omfattende kontaktmatrise inn i ERP-en din.

Så, hva er alternativene til å slite med ulike transportør-APIer og EDI-protokoller?

Et alternativ å vurdere er en multi-transportør API. I hovedsak er dette en tjenesteleverandør som har bygget alle transportørtilkoblinger, enten det er moderne APIer, gamle EDIFACT- eller FORTRAS-baserte EDI-protokoller eller e-postintegrasjoner, og gjort dem tilgjengelige via sin egen, standardiserte forsendelse-API. I stedet for å implementere ulike transportør-APIer og holde dem oppdatert, kan du implementere bare én multi-transportør API-standard og utløse alle dine transportordrer gjennom den.

Men vi har tatt det enda lenger.

Forskjellige logistikkselskaper tilbyr varierende servicenivåer. Noen tilbyr en booking-API, mens andre ikke gjør det; noen tilbyr sporingsfunksjoner, mens andre mangler denne funksjonen. Hos Cargoson har vi implementert alle funksjoner som fyller hullene for hvert transportselskap.

For eksempel, når en transportør ikke tilbyr online booking, tilbyr vi en portal for det. Hvis de mangler sporing, legger vi det til. Vi har systemer for opplasting av leveringsbevis (POD) og andre dokumenter, fullverdig multi-transportør API, ETA-estimater, transportprisberegninger, ytelsesstatistikk, og til og med transport CO2-utslippstall. Kort sagt, uansett hva en transportør mangler, har vi bygget det slik at du ikke trenger å bekymre deg for IT- eller servicenivåforskjeller mellom transportørene dine.

Se hvordan Cargoson gjør dine eksisterende transportører bedre

Her er et eksempel fra virkeligheten: Store aktører som FedEx, TNT og DHL Express tilbyr en prising-API. Dette betyr at når du utløser en prisforespørsel fra Cargoson, hentes prisene direkte fra transportørens system. I tilfeller der et selskap som DSV ikke tilbyr en prising-API, lastes Excel- eller PDF-prislisten som DSV har gitt opp til Cargoson, og prisberegningen utføres innenfor vårt system. Vi har en kraftig fraktprisopplastings- og beregningsmotor for det. Den samme tilnærmingen kan anvendes på alle andre transportselskaper og gjelder også for andre funksjoner.

Målet vårt er enkelt: gi deg en konsekvent opplevelse av høy kvalitet på tvers av alle transportører, selv om de ikke alle starter med de samme mulighetene. En de facto universell transportør-API-standard og multi-transportør plattform i ett.

Hvis du leter etter en bedre måte å administrere dine transportørintegrasjoner på, kan Cargoson hjelpe. Vår plattform gir en enkelt, standardisert transport-API som kobler deg til alle dine transportører, uavhengig av deres individuelle muligheter. Dette betyr at du kan få tilgang til alle dine frakttjenester gjennom ett enhetlig grensesnitt, uten å bekymre deg for de underliggende tekniske forskjellene.

Vil du se hvordan det kunne fungere for din virksomhet? La oss ta en rask samtale for å diskutere din nåværende oppsett og spesifikke integrasjonsutfordringer. Vi kan gå gjennom noen eksempler fra virkeligheten på hvordan Cargoson har hjulpet selskaper i lignende tilfeller som ditt:

Planlegg en gratis, 30-minutters konsultasjon