For noget tid siden satte jeg mig for at finde ud af, om der fandtes en samlet transport-API/EDI-standard, som bruges af flere logistikvirksomheder. Sikkert må der i vore dage eksistere noget sådant, ikke? Et universelt forsendelse-API-format?

Nå, for at gøre en lang historie kort, så findes det ikke.

Det tætteste, du kan komme, er en API-udbyder, der har opbygget mange fragtmand-API-forbindelser og derefter tilbyder sit eget API-endpoint for at få adgang til forskellige transportserviceudbydere.

I denne artikel vil jeg gennemgå nogle forskellige fragtmand-API'er, kort beskrive deres funktioner og diskutere måder at implementere dem på.

NB! Hvis du bare leder efter en universel transport-API-protokol, er her et link, hvor du kan booke et hurtigt opkald med mig.

Lad os starte med et...

Lad os først definere målet.

Tænk på en gennemsnitlig producent med både indenlandske og internationale kunder og leverandører. Varer skal afhentes hos leverandører og leveres til produktionsstedet, mens de færdige produkter skal sendes til kunderne.

For at etablere en pålidelig forsyningskæde ville din typiske mellemstore producent have brug for 10-20 transportpartnere:

At håndtere alle disse relationer er komplekst nok. Men den rigtige sjov begynder, når du prøver at integrere deres IT-systemer! (da der ikke findes nogen samlet fragt-API-protokol)

For det andet skal vi blive enige om omfanget.

Ikke alle logistikvirksomheder tilbyder det samme serviceniveau. Nogle har meget sofistikerede API'er, der giver øjeblikkelig fragtprissætning, booking, labels, sporing, kurérforespørgsler osv., mens andre måske kun har en portal, hvor du kan logge ind og indsende en booking. Nogle har slet ingen IT-systemer - kun e-mail. For vores målscenarie, lad os holde tingene enkle og blot sigte mod at:

Lyder enkelt nok, ikke? Åh, hvis bare...

Den manuelle måde at håndtere tingene på, som ser ud til at være branchestandarden for de fleste virksomheder, involverer brug af fragtmandportaler hvor det er muligt og kommunikation via e-mail med resten af transportpartnerne. I vores eksempel antager vi, at transportprislister, tidsplaner, leveringstider og fakturabehandling håndteres separat. For bookingindleveringer sigter vi mod at opbygge en API-forbindelse fra vores ERP-system.

Lad os antage, at vi har valgt følgende liste over transportvirksomheder og har brug for at opbygge en direkte API-forbindelse til deres systemer fra vores ERP-software. Dette udvalg er tilfældigt og dækker kun en brøkdel af de forskellige fragtmand-API'er derude.

DHL Express - bruger en portal kaldet MyDHL, som også har API-funktioner. Den bruger dog forskellige API'er til Freight-, Express- og Global Forwarding-afdelinger og forskellige API-tilgange i forskellige regioner. Adgang til webtjenesten kræver en SOAP-protokol, RESTful Services eller almindelig XML, og udviklere bør være fortrolige med XML/JSON og have en grundlæggende forståelse af webtjenester. API-specifikationen alene er 457 sider lang. Den er grundig, men din udvikler vil opkræve dig for de timer, der bruges bare på at læse den. Når den er implementeret, skal du udløse i gennemsnit 5-12 anmodninger pr. forsendelse, startende fra godkendelse til adressevalideringer, tilgængelighedskontroller og labelanmodninger.

Schenker - bruger forskellige API/EDI-løsninger i forskellige regioner. Oftest bruger den en SOAP-protokol med et XML-format. Selve meddelelsen er ligetil, forudsat at alle mulige fejl håndteres korrekt. Udviklere har brug for personlig adgang for at implementere API'en. Afhængigt af din placering kan du blive bedt om at implementere en EDIFACT-løsning i stedet, som jeg vil dække senere.

DSV - er for nylig flyttet til deres API-kompatible portal kaldet MyDSV. Givet at API'en er ret ny, udnytter den nogle af de nyeste og mest moderne tilgange i API-verdenen. På trods af kompleksiteten ved godkendelse og navigation i deres produktkatalog er tilgangen ligetil. Igen kan EDIFACT foretrækkes afhængigt af din placering.

FedEx og TNT - dette kan være sjovt. Først skal du afgøre, om du bruger TNT- eller FedEx-tjenester. Selvom de burde have været det samme firma i flere år, er migrationen stadig i gang. Hvis din kontrakt er med TNT, vil du højst sandsynligt blive bedt om at implementere TNT Express Connect API'en. Selve implementeringen er af gennemsnitlig kompleksitet. Ulempen er, at denne API betragtes som forældet og vil blive lukket ned på et tidspunkt. FedEx API'en er på den anden side mere kompleks og tilbyder flere muligheder afhængigt af den region, du befinder dig i. Hos Cargoson har vi implementeret FedEx Compatible API'en, som giver nogle meget smarte ekstra funktioner, men kun er tilgængelig for FedEx Compatible-partnere.

UPS - bruger en JSON-baseret API og OAuth til godkendelse, hvilket betyder, at der er en del anmodninger, du skal udløse, før du får din booking igennem og labels tilbage.

Dernæst har vi EDIFACT, som bruges af mange transportvirksomheder som DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics osv. Det er en meget gammel standard, og selv hvis det måtte synes, at du kunne slippe af sted med én API-integration for flere logistikvirksomheder, så tænk igen. Den største ulempe er, at det er en filbaseret udvekslingsforbindelse, hvilket betyder, at du skulle generere en faktisk, fysisk fil, derefter overføre den via FTP og bogstaveligt talt håbe, at alt er okay, fordi der er meget besværlig feedback om fejl og advarsler.

Lignende EDIFACT er FORTRAS, en filbaseret forbindelse med de samme mangler. Den er mere i brug i Tyskland og nabolandene. Ikke kun er filoverførslen udfordrende, men selve filformatet er svært at læse og derfor meget tidskrævende at fejlfinde. Nogle velkendte virksomheder, der bruger det, inkluderer Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss osv.

Selv efter at have implementeret alle de ovennævnte integrationer, forbliver spørgsmålet:

Hvad gør du med fragtmandvirksomheder, der mangler ethvert IT-system eller portal, for ikke at tale om en API til at acceptere transportordrer?

Den enkleste løsning er at sende en simpel e-mail. Mens dette måske lyder ligetil, lad os dykke dybere ned. At opsætte den tekniske forbindelse til din mailserver er én ting, men hvad med kontakter? Normalt håndteres forskellige retninger af forskellige kontaktpersoner, og folk skifter stillinger. Derfor ville du være nødt til at opbygge en ret omfattende kontaktmatrix i dit ERP.

Så hvad er alternativerne til at kæmpe med forskellige fragtmand-API'er og EDI-protokoller?

En mulighed at overveje er en multi-fragtmand-API. Dette er i bund og grund en tjenesteudbyder, der har opbygget alle fragtmandforbindelser, hvad enten det er moderne API'er, gamle EDIFACT- eller FORTRAS-baserede EDI-protokoller eller e-mail-integrationer, og gjort dem tilgængelige via deres egen, standardiserede forsendelse-API. I stedet for at implementere forskellige fragtmand-API'er og holde dem opdaterede, kan du implementere blot én multi-fragtmand-API-standard og udløse alle dine transportordrer gennem den.

Men vi har taget det endnu videre.

Forskellige logistikvirksomheder tilbyder varierende serviceniveauer. Nogle tilbyder en booking-API, mens andre ikke gør; nogle tilbyder sporingsfunktioner, mens andre mangler denne funktion. Hos Cargoson har vi implementeret alle funktioner, der udfylder hullerne for hver transportvirksomhed.

For eksempel, når en fragtmand ikke tilbyder online booking, leverer vi en portal til det. Hvis de mangler sporing, tilføjer vi det. Vi har systemer til at uploade leveringsbevis (POD) og andre dokumenter, fuldt udstyret multi-fragtmand-API, ETA-estimater, transportprisberegninger, præstationsstatistikker og endda transport CO2-emissionstal. Grundlæggende, uanset hvad en fragtmand mangler, har vi bygget det, så du ikke behøver at bekymre dig om IT- eller serviceniveauforskelle mellem dine fragtmænd.

Se hvordan Cargoson gør dine eksisterende fragtmænd bedre

Her er et eksempel fra den virkelige verden: Store aktører som FedEx, TNT og DHL Express tilbyder en prissætnings-API. Det betyder, at når du udløser en prisforespørgsel fra Cargoson, hentes priserne direkte fra fragtmandens system. I tilfælde hvor en virksomhed som DSV ikke tilbyder en prissætnings-API, uploades Excel- eller PDF-prislisten fra DSV til Cargoson, og prisberegningen udføres inden for vores system. Vi har en kraftfuld fragtpris-upload- og beregningsmotor til det. Den samme tilgang kan anvendes på alle andre transportvirksomheder og gælder også for andre funktioner.

Vores mål er enkelt: give dig en konsistent oplevelse af høj kvalitet på tværs af alle fragtmænd, selv hvis de ikke alle starter med de samme funktioner. En de facto universel fragtmand-API-standard og multi-fragtmand-platform i ét.

Hvis du leder efter en bedre måde at håndtere dine fragtmandintegrationer på, kan Cargoson hjælpe. Vores platform giver en enkelt, standardiseret transport-API, der forbinder dig med alle dine fragtmænd, uanset deres individuelle funktioner. Det betyder, at du kan få adgang til alle dine forsendelsestjenester gennem én samlet grænseflade, uden at bekymre dig om de underliggende tekniske forskelle.

Vil du se, hvordan det kunne fungere for din virksomhed? Lad os tage et hurtigt opkald for at diskutere din nuværende opsætning og specifikke integrationsudfordringer. Vi kan gennemgå nogle eksempler fra den virkelige verden på, hvordan Cargoson har hjulpet virksomheder i lignende tilfælde som dit:

Book en gratis 30-minutters konsultation