EDI för små åkerier: vad det är, när det lönar sig och när det inte gör det

Du vinner en kund. Någonstans i onboardingpaketet, mellan försäkringsbeviset och prislistan, står en rad som lyder EDI krävs. Ingen hos kunden kan riktigt förklara vad det innebär, och den första offerten du får tillbaka kommer med en projektplan häftad vid sig.

Så här ser det faktiskt ut bakom den raden — och så här räknar du på om det är värt att göra.

EDI är ett format, en kanal och en överenskommelse

Electronic Data Interchange betyder att två företags system utbyter affärsdokument i ett överenskommet, strukturerat format, så att ingen behöver skriva av något. Inom europeisk vägtransport är det formatet oftast UN/EDIFACT, en FN-standard som publiceras via UNECE i versionerade kataloger. Varje meddelandetyp har ett namn på sex bokstäver, och varje katalog har en utgåva: den publicerade definitionen av transportinstruktionen ligger till exempel i katalog D.23A, revision 17, daterad 21 juli 2023. Din kund kommer att ange en version, och den spelar roll.

Standarden reglerar meddelandets innehåll och syntax — själva syntaxreglerna är ISO 9735. Den säger ingenting om hur filen tar sig från deras server till din. Formatet och kanalen är två separata överenskommelser, och att blanda ihop dem är den vanligaste anledningen till att ett första EDI-samtal går i cirklar.

Tre meddelanden bär nästan hela arbetet

För ett åkeri är den användbara formen: order in, statusar ut, fakturor ut.

Order in — IFTMIN

Officiellt Instruction message, instruktionsmeddelandet. UNECE definierar det som ett meddelande från parten som utfärdar en instruktion om speditions- eller transporttjänster för en sändning på avtalade villkor, till parten som ordnar tjänsterna. På ren svenska: kundens transportorder, som kommer in som en fil i stället för ett mejl.

Två detaljer är värda att känna till. Det är ett meddelande per sändning, i linje med de separata bokningsmeddelandena (IFTMBP, IFTMBF, IFTMBC) — så om din kund pratar om bokning via EDI, kontrollera vilket av dem de menar. Och UNECE skriver själva att instruktionen resulterar i ett transportavtal och i första hand är avsedd för administrativa ändamål. Det är ordern, inte trafikplanen.

Status ut — IFTSTA

International multimodal status report message: ett meddelande som rapporterar transportstatus, eller en förändring av den, mellan avtalade parter. Det täcker sändningars, godsets eller utrustningens fysiska förflyttning vid vilken punkt som helst i transportkedjan.

UNECE listar fyra sätt att skicka det på — på begäran, enligt schema vid förutbestämda tidpunkter, när utvalda händelser inträffar, eller vid en undantagshändelse som parterna kommit överens om. Den listan är förhandlingen. Att lova lastad, framme, levererad och avvikelse är ett helt annat driftsåtagande än att lova varje statusförändring i samma stund den sker — och skillnaden landar rakt i knät på förarna.

Faktura ut — INVOIC

Invoice message: ett meddelande som kräver betalning för varor eller tjänster som levererats på villkor avtalade mellan säljare och köpare. Praktiskt nog fungerar samma meddelande, med rätt datakvalificering, också som kreditfaktura och debetnota — rättelser kräver alltså ingen egen meddelandetyp. Är faktureringen den del av veckan som gör ont är det här den du ska börja med, och den hänger ihop med att få ut fakturan på leveransdagen.

Två meddelanden ingen nämner förrän något går sönder

CONTRL, syntax- och tjänsterapporten, kvitterar eller avvisar syntaktiskt en mottagen försändelse, grupp eller meddelande. Det säger att kuvertet kom fram och var korrekt uppbyggt.

APERAK, meddelandet för applikationsfel och kvittens, gör två saker: det talar om för avsändaren att meddelandet nått mottagarens applikation och avvisats på grund av fel som upptäckts under bearbetningen — eller kvitterar att applikationen tagit emot det.

Skillnaden märks klockan fyra på en fredag. Tystnad där det borde ligga en CONTRL betyder att filen aldrig kom fram. En avvisning via APERAK betyder att den kom fram och att deras system nekade den — ett annat problem med en annan lösning. Kom överens om båda från början, annars blir vi har aldrig fått er faktura ett gräl som ingen part kan avgöra.

Vad uppsättningen faktiskt innebär

1. Kundens implementationsguide. Ingen skickar ren EDIFACT. Kunder ger ut ett delmängdsdokument som anger vilka segment de använder, vilka kvalificerare och vilka av standardens valfria fält som är obligatoriska hos dem. Det handlar om tiotals sidor. Två kunder som båda kör IFTMIN är inte likadana, och just det faktumet styr kalkylen mer än något annat här.
2. Kodmappning. Deras platskoder, godskoder och statuskoder mot dina. Sällan svårt, pålitligt långsamt, och det blottlägger varje inkonsekvens i din egen grunddata.
3. Anslutningen. Kanalen, inloggningsuppgifterna och — den del som brukar hoppas över — vem som märker när den slutar fungera.
4. Testning. Exempelfiler, rättelser och sedan en parallellperiod där både EDI och mejl går. Räkna ordentligt med parallellperioden; det är där missmatchningarna faktiskt visar sig.
5. Ägarskapet efteråt. Katalogversioner byts, guider revideras, någon lägger till en kod. EDI är inget projekt som tar slut.

Den ärliga brytpunkten

Kostnaderna är i huvudsak fasta och ligger i början: läsa guiden, mappa koderna, testa. Nyttan kommer per meddelande: en order som inte skrivs av, ett statussamtal som inte besvaras, en faktura som inte ifrågasätts. Alltså handlar kalkylen om återkommande volym och avtalslängd, inte om prestige:

• Hur många order i månaden, och är arbetet kontrakterat eller spot?
• Går flödet bara åt ett håll? Order in, med statusar som fortfarande går ut per telefon, fångar bara en bråkdel av nyttan.
• Kommer en mappning att tjäna flera kunder? En guide som täcker tre kunder ändrar summorna. Tre guider för tre kunder gör det inte.

En kund som skickar flera lass om dagen på ett flerårigt avtal betalar tillbaka uppsättningen. En enda kund som skickar en handfull lass i månaden för att EDI var en ruta i deras upphandling gör det inte — och att säga det är ett rimligt affärssamtal, inte ett misslyckande att modernisera. Fråga vad de annars accepterar: en kundportal, en filöverföring eller ett API. Mycket ofta betyder EDI krävs i praktiken vi tänker inte skriva av era mejl, och det svarar en kundportal också på, utan någon implementationsguide.

Vad du bör fråga innan du säger ja

• Vilka meddelanden, i vilken riktning? (Order in, statusar ut, fakturor ut är den vanliga formen.)
• Vilken katalogversion, och vems implementationsguide?
• Vilka statushändelser, hur ofta, och mätt mot vad?
• Vilka kvittenser — CONTRL, APERAK eller båda?
• Vem betalar uppsättningen, och vem betalar när deras guide revideras?
• Vad händer när förbindelsen ligger nere: stannar arbetet, eller finns en reservväg?

De sex frågorna gör ett skrämmande krav till ett avgränsat. De avslöjar också, ganska ofta, att det kunden behöver är mindre än ordet antydde. Samma instinkt gäller när du väljer systemet under det hela.

Var navichain kommer in

Skillnaden mellan EDI som projekt och EDI som inställning ligger mest i om ditt system redan talar det. navichain listar EDIFACT bland sina fraktpartnersintegrationer vid sidan av Opter, LogTrade och Fraktjakt, med ett REST-API för ERP- och TMS-integration och en kundportal för de kunder som inte behöver EDI alls — och eftersom varje funktion ingår i varje plan flyttar en vunnen EDI-kund dig inte upp en prisnivå. Plattformssidan visar vad som ingår, och priserna börjar på 995 kr i månaden.