Skip to main content
HemBloggOrdlistaElektroniskt datautbyte (EDI)

Elektroniskt datautbyte (EDI)

17TRACK

Vad är elektroniskt datautbyte (EDI)?

Elektroniskt datautbyte (EDI) är dator-till-dator-utbyte av strukturerade affärsdokument mellan organisationer med hjälp av överenskomna standarder. Inom logistik, e-handel och internationell handel gör det möjligt för system som används av köpare, leverantörer, lager, transportörer och andra handelspartner att utbyta information som inköpsorder, leveransaviseringar, transportinstruktioner och fakturor utan att människor behöver skriva in varje dokument på nytt.

Elektroniskt datautbyte EDI

Det utmärkande för EDI är inte bara att information skickas elektroniskt. Informationen organiseras i fält, segment och meddelanden som mottagande programvara kan tolka enligt en överenskommen specifikation. En faktura som bifogas ett e-postmeddelande som PDF är därför inte i sig en EDI-faktura: en person eller ett dokumentbehandlingsverktyg kan fortfarande behöva extrahera innehållet innan ett affärssystem kan använda det.

EDI beskriver en metod för att utbyta affärsinformation snarare än en viss programvaruprodukt, ett nätverk eller ett filformat. En fungerande lösning är beroende av kompatibla dokumentdefinitioner, kommunikationsmetoder, identifierare och affärsregler.

EDI inom logistik och e-handel

EDI kopplar samman aktiviteter som sträcker sig över organisationsgränser. En återförsäljares inköpssystem kan skapa en order, en leverantörs system kan bekräfta den och ett lager kan ta emot instruktioner om att förbereda varorna. Leveransinformation och fakturor kan sedan skickas mellan de berörda systemen som separata meddelanden.

Inom e-handel kan EDI stödja de processer mellan företag som ligger bakom en konsumentinriktad webbutik. En nätåterförsäljare kan till exempel använda det för att beställa lager från en leverantör eller utbyta information om orderhantering med ett lager. Konsumentens kassatransaktion och återförsäljarens efterföljande EDI-meddelanden är relaterade affärshändelser, men de är inte nödvändigtvis samma transaktion och använder inte alltid samma tekniska gränssnitt.

Vid gränsöverskridande handel kan EDI överföra information som behövs för internationell transport och kommersiell dokumentation. Tullmyndigheter kan också använda strukturerade elektroniska meddelanden enligt sina egna specifikationer. Att utbyta ett EDI-meddelande med en leverantör eller transportör utgör dock inte i sig en tulldeklaration, fastställer inte regelefterlevnad och ger inte heller tillstånd att frigöra varor.

Vanliga affärsdokument

Följande exempel illustrerar dokumentens funktioner snarare än en obligatorisk ordningsföljd. Vilka meddelanden som används beror på handelsrelationen och den tillämpliga implementeringsguiden.

Dokument eller meddelandeAffärssyfteExempel inom logistik eller e-handel
InköpsorderKommunicerar en köpares order av varor eller tjänster.En återförsäljare beställer påfyllnadslager från en leverantör.
Ordersvar eller orderbekräftelseKommunicerar leverantörens svar på en order.En leverantör bekräftar kvantiteter eller föreslår ändringar, när det överenskomna meddelandet stödjer detta.
Förhandsavisering av leverans eller leveransaviseringBeskriver en leverans innan den anländer.Ett lager får information om förväntade kartonger, artiklar och kvantiteter.
TransportinstruktionKommunicerar instruktioner för en transporttjänst.En avsändare skickar överenskomna transportuppgifter till en transportpartner.
LeveransstatusmeddelandeKommunicerar en transporthändelse eller status.En transportör rapporterar en händelse kopplad till en leverans.
FakturaKommunicerar faktureringsinformation.En leverantör fakturerar en återförsäljare för levererade varor.

En förhandsavisering av leverans, ofta förkortad ASN, beskriver en förväntad leverans; den bevisar inte att varorna har anlänt. På samma sätt är ett leveransstatusmeddelande inte automatiskt ett leveransbevis. Dess betydelse beror på den rapporterade händelsen och den kompletterande informationen.

Standarder, format och kommunikationsmetoder

EDI-standarder definierar hur affärsmeddelanden struktureras och vad deras dataelement betyder. Två etablerade standardfamiljer är X12 och FN:s regler för Electronic Data Interchange for Administration, Commerce and Transport, kända som UN/EDIFACT. GS1 upprätthåller också EDI-standarder, inklusive EANCOM, som bygger på UN/EDIFACT, samt GS1 XML.

Inom X12 finns exempelvis 850 Inköpsorder, 856 Leveransavisering/manifest och 810 Faktura. UN/EDIFACT tillhandahåller meddelanden som ORDERS för inköpsorder, DESADV för leveransavisering och INVOIC för fakturor. Dessa exempel har relaterade affärssyften mellan standarderna, men deras strukturer och implementeringskrav är inte utbytbara.

En standard definierar inte ensam varje detalj i en handelsrelation. Partner måste också komma överens om tillämplig version och implementeringsguide, obligatoriska fält, tillåtna koder, identifierare och valideringsregler. Två organisationer kan stödja samma standardfamilj och ändå behöva mappningsarbete innan deras system kan utbyta användbara meddelanden.

KomponentVad den avgörExempel
MeddelandestandardStrukturen och betydelsen hos ett affärsmeddelande.En X12-faktura eller en UN/EDIFACT-leveransavisering.
ImplementeringsguideHur ett visst meddelande används i en handelsrelation.Obligatoriska leveransidentifierare och tillåtna kvantitetsenheter.
KommunikationsmetodHur ett meddelande överförs mellan system.AS2 eller en överenskommen säker filöverföringslösning.
Översättning och mappningHur externa meddelandefält motsvarar interna applikationsdata.Att mappa en inkommande orderrad till en post i orderhanteringen.

AS2 är en kommunikationsspecifikation för utbyte av affärsdata över HTTP, med mekanismer för säkerhet och kvittenser. Det är inte ett format för inköpsorder eller fakturor. Ett värdeadderande nätverk, eller VAN, kan tillhandahålla tjänster för förmedling av meddelanden; det är på samma sätt skilt från standarden för affärsdokument.

Så fungerar ett EDI-utbyte

  1. En affärshändelse skapar data. En köpare godkänner till exempel en inköpsorder i ett affärssystem för resursplanering eller ett orderhanteringssystem.
  2. Data mappas till ett meddelande. Översättningsprogramvara omvandlar interna fält till den struktur som krävs av den överenskomna standarden och implementeringsguiden.
  3. Det utgående meddelandet kontrolleras. Valideringen kan kontrollera syntax, obligatoriska fält, kodvärden och partnerspecifika krav.
  4. Meddelandet överförs. Det skickas via den överenskomna kommunikationskanalen till mottagaren eller en mellanhand.
  5. Mottagaren validerar och översätter det. Det mottagande systemet kontrollerar meddelandet och mappar godkänd information till sitt interna applikationsformat.
  6. Affärsbehandling följer. Den mottagande applikationen kan skapa en order, registrera ett förväntat mottagande eller skicka ett undantag för granskning.
  7. Svar stäms av. Tekniska kvittenser, bekräftelser och affärssvar hjälper avsändaren att fastställa vad som hände med utbytet.

Dessa steg garanterar inte att varje transaktion behandlas automatiskt. En okänd produktidentifierare, ogiltig leveransplats, dubblett av dokumentnummer eller en kvantitetsenhet som inte stöds kan kräva ingripande även när meddelandet är strukturellt giltigt.

Kvittens, validering och affärsmässigt godkännande

EDI-bekräftelser fungerar på olika nivåer. En transportkvittens kan visa att ett meddelande nådde en kommunikationsslutpunkt. En funktionell eller implementeringsrelaterad bekräftelse kan rapportera resultatet av strukturella kontroller. Ett affärssvar kan meddela om en order eller annan begäran accepterades, avvisades eller ändrades.

Dessa signaler bör inte behandlas som likvärdiga. En lyckad överföring innebär inte nödvändigtvis att en order har accepterats eller att varor kommer att skickas. Den specifika betydelsen av en bekräftelse måste tolkas enligt relevant specifikation och avtal med handelspartnern.

Illustrativt exempel från order till leverans

En återförsäljare kan skicka en inköpsorder till en utländsk leverantör via EDI. Leverantörens system kontrollerar produktidentifierare, kvantiteter och begärd leveransinformation. Om handelsupplägget omfattar ett ordersvar kan leverantören kommunicera sitt godkännande eller föreslagna ändringar genom ett separat meddelande.

När varorna har förberetts kan leverantören utfärda en förhandsavisering av leverans som identifierar leveransen och dess innehåll. Det mottagande lagret kan använda informationen för att förbereda mottagandet och jämföra förväntade kvantiteter med de varor som faktiskt mottagits. Leverantören kan också skicka en faktura för behandling i återförsäljarens ekonomisystem.

Detta exempel visar hur EDI kopplar samman register över organisationsgränser. Det innebär inte att alla parter använder samma programvara, att varje meddelande levereras i realtid eller att de kommersiella dokumenten ersätter transport- och tullkrav. Att matcha inköpsorder, leveransreferenser och fakturor kräver fortfarande konsekventa identifierare och överenskommen affärslogik.

EDI och relaterad teknik

Relaterat konceptFörhållande till EDIViktig skillnad
Programmeringsgränssnitt för applikationer (API)Ett gränssnitt genom vilket programvara utbyter begäranden och data.EDI betonar standardiserade affärsmeddelanden; ett API definierar interaktion med en programvarutjänst. De två kan samexistera.
XMLEtt märkspråk som används för att strukturera data.Enbart XML-syntax fastställer inte en överenskommen standard för affärsmeddelanden.
Elektronisk faktureringElektroniskt utfärdande och utbyte av fakturor.EDI kan stödja elektronisk fakturering, men juridiska och tekniska krav varierar beroende på jurisdiktion.
ERP- eller lagerhanteringssystemEn applikation som skapar eller använder affärsinformation.Dessa system hanterar verksamheten; EDI tillhandahåller ett sätt att utbyta information med andra organisationer.
LeveransspårningRapportering och tolkning av leveranshändelser.EDI kan överföra statusinformation, men är inte i sig en spårningswebbplats eller en komplett spårningstjänst.

EDI och API:er är inte ömsesidigt uteslutande alternativ i alla arkitekturer. En organisation kan använda EDI-meddelanden för partnertransaktioner och API:er för att ansluta dessa transaktioner till interna applikationer. Den lämpliga lösningen beror på dokumentkrav, partnernas kapacitet, tidsbehov och operativa kontroller snarare än enbart på teknikens benämning.

Implementeringsöverväganden och begränsningar

EDI kan minska upprepad manuell datainmatning när systemen framgångsrikt utbyter och behandlar kompatibla meddelanden. Det korrigerar inte felaktiga källdata, löser inte kommersiella meningsskiljaktigheter och eliminerar inte behovet av undantagshantering. Automatisering beror både på teknisk kompatibilitet och kvaliteten på den utbytta affärsinformationen.

Innan en EDI-anslutning etableras bör handelspartner klargöra följande operativa punkter:

  • Dokumentomfattning: Vilka meddelanden krävs och vilka affärshändelser utlöser dem?
  • Identifierare: Hur ska produkter, platser, parter, order och leveranser identifieras och matchas?
  • Meddelandekrav: Vilka versioner, obligatoriska fält, kodlistor och mappningsregler gäller?
  • Kommunikation och säkerhet: Vilken anslutningsmetod, autentiseringslösning och åtkomstkontroll krävs?
  • Bekräftelser: Vilka svar visar leverans, validering och affärsmässigt godkännande?
  • Undantagshantering: Vem utreder avvisade meddelanden, uteblivna svar och inkonsekventa data?
  • Förebyggande av dubbletter: Hur ska omsändningar skiljas från nya affärstransaktioner?
  • Testning och förändringskontroll: Hur ska mappningar och partnerkrav testas innan ändringar tas i produktion?

Operativ övervakning bör skilja kommunikationsfel från datavalideringsfel och affärsundantag. Att skicka om ett meddelande kan åtgärda en misslyckad överföring, men det korrigerar inte en ogiltig produktkod. Utan dubblettkontroller kan en omsändning av en framgångsrikt behandlad order dessutom skapa en oavsiktlig andra transaktion.

Vanliga frågor

Vad betyder EDI inom logistik?

EDI betyder elektroniskt datautbyte: ett strukturerat utbyte av affärsdokument mellan system. Inom logistik kan dessa dokument omfatta leveransaviseringar, transportinstruktioner, fakturor och leveransstatusmeddelanden.

Är en PDF som skickats via e-post ett EDI-dokument?

Inte i sig. En PDF kan presentera ett affärsdokument elektroniskt, men EDI kräver strukturerad information som mottagande system kan tolka enligt en överenskommen specifikation.

Är EDI samma sak som ett API?

Nej. EDI handlar om standardiserat utbyte av affärsdokument, medan ett API definierar hur programvara interagerar med en annan tjänst. En integration kan använda båda.

Innebär en EDI-bekräftelse att en order har accepterats?

Inte nödvändigtvis. Bekräftelser kan bekräfta överföring eller strukturell validering snarare än affärsmässigt godkännande. Meddelandetypen och avtalet med handelspartnern avgör dess betydelse.

Källor