Elektronisk dataudveksling (Edi)

Hvad er elektronisk dataudveksling (EDI)?

Elektronisk dataudveksling (EDI) er udveksling af strukturerede forretningsdokumenter mellem organisationer fra computer til computer ved hjælp af aftalte standarder. Inden for logistik, e-handel og international handel gør det det muligt for systemer, der drives af købere, leverandører, lagre, transportører og andre handelspartnere, at udveksle oplysninger såsom indkøbsordrer, forsendelsesmeddelelser, transportinstruktioner og fakturaer uden at kræve, at personer indtaster hvert dokument igen.

Det afgørende kendetegn ved EDI er ikke blot, at oplysninger sendes elektronisk. Oplysningerne organiseres i felter, segmenter og meddelelser, som den modtagende software kan fortolke i henhold til en aftalt specifikation. En faktura, der er vedhæftet en e-mail som PDF, er derfor ikke i sig selv en EDI-faktura: En person eller et dokumentbehandlingsværktøj kan stadig være nødt til at udtrække indholdet, før et forretningssystem kan bruge det.

EDI beskriver en metode til udveksling af forretningsoplysninger snarere end ét softwareprodukt, ét netværk eller ét filformat. En fungerende løsning afhænger af kompatible dokumentdefinitioner, kommunikationsmetoder, identifikatorer og forretningsregler.

EDI inden for logistik og e-handel

EDI forbinder aktiviteter, der går på tværs af organisatoriske grænser. En forhandlers indkøbssystem kan generere en ordre, en leverandørs system kan bekræfte den, og et lager kan modtage instruktioner om at klargøre varerne. Forsendelsesoplysninger og fakturaer kan derefter bevæge sig mellem de relevante systemer som separate meddelelser.

Inden for e-handel kan EDI understøtte de business-to-business-processer, der ligger bag en forbrugerrettet netbutik. En onlineforhandler kan for eksempel bruge det til at bestille lagerbeholdning fra en leverandør eller udveksle opfyldelsesoplysninger med et lager. Forbrugerens betalingshændelse og forhandlerens efterfølgende EDI-meddelelser er relaterede forretningshændelser, men de er ikke nødvendigvis den samme transaktion eller bruger den samme tekniske grænseflade.

Inden for grænseoverskridende handel kan EDI indeholde oplysninger, der er nødvendige for international transport og handelsdokumentation. Toldmyndigheder kan også bruge strukturerede elektroniske meddelelser i henhold til deres egne specifikationer. Udveksling af en EDI-meddelelse med en leverandør eller transportør udgør dog ikke i sig selv en toldangivelse, fastslår overholdelse af lovgivningen eller giver tilladelse til frigivelse af varer.

Almindelige forretningsdokumenter

Følgende eksempler illustrerer dokumentfunktioner snarere end en obligatorisk rækkefølge. De anvendte meddelelser afhænger af handelsforholdet og den gældende implementeringsvejledning.

En forhåndsmeddelelse om forsendelse, ofte forkortet ASN, beskriver en forventet forsendelse; den beviser ikke, at varerne er ankommet. På samme måde er en meddelelse om forsendelsesstatus ikke automatisk et leveringsbevis. Dens betydning afhænger af den rapporterede hændelse og de understøttende oplysninger.

Standarder, formater og kommunikationsmetoder

EDI-standarder definerer, hvordan forretningsmeddelelser struktureres, og hvad deres dataelementer betyder. To etablerede standardfamilier er X12 og De Forenede Nationers regler for Electronic Data Interchange for Administration, Commerce and Transport, kendt som UN/EDIFACT. GS1 vedligeholder også EDI-standarder, herunder EANCOM, som er baseret på UN/EDIFACT, samt GS1 XML.

Inden for X12 omfatter eksemplerne 850 Purchase Order, 856 Ship Notice/Manifest og 810 Invoice. UN/EDIFACT indeholder meddelelser som ORDERS for indkøbsordrer, DESADV for afsendelsesadvis og INVOIC for fakturaer. Disse eksempler har relaterede forretningsformål på tværs af standarder, men deres strukturer og implementeringskrav kan ikke udveksles direkte.

En standard alene definerer ikke alle detaljer i et handelsforhold. Partnerne skal også blive enige om den relevante version og implementeringsvejledning, obligatoriske felter, tilladte koder, identifikatorer og valideringsregler. To organisationer kan understøtte den samme standardfamilie og stadig have brug for mappingsarbejde, før deres systemer kan udveksle brugbare meddelelser.

AS2 er en kommunikationsspecifikation til udveksling af forretningsdata over HTTP med mekanismer til sikkerhed og kvitteringer. Det er ikke et format for indkøbsordrer eller fakturaer. Et Value-Added Network eller VAN kan levere formidlingstjenester til udveksling af meddelelser; det er ligeledes adskilt fra forretningsdokumentstandarden.

Sådan fungerer en EDI-udveksling

1. En forretningshændelse opretter data. En køber godkender for eksempel en indkøbsordre i et enterprise resource planning- eller ordrebehandlingssystem.
2. Dataene mappes til en meddelelse. Oversættelsessoftware konverterer interne felter til den struktur, der kræves af den aftalte standard og implementeringsvejledning.
3. Den udgående meddelelse kontrolleres. Valideringen kan kontrollere syntaks, obligatoriske felter, kodeværdier og partnerspecifikke krav.
4. Meddelelsen transmitteres. Den sendes gennem den aftalte kommunikationskanal til modtageren eller en mellemmand.
5. Modtageren validerer og oversætter den. Det modtagende system kontrollerer meddelelsen og mapper accepterede oplysninger til sit interne applikationsformat.
6. Forretningsbehandlingen følger. Den modtagende applikation kan oprette en ordre, registrere en forventet modtagelse eller sende en undtagelse til gennemgang.
7. Svar afstemmes. Tekniske kvitteringer, bekræftelser og forretningssvar hjælper afsenderen med at fastslå, hvad der skete med udvekslingen.

Disse trin garanterer ikke, at enhver transaktion behandles automatisk. En ukendt produktidentifikator, en ugyldig leveringsadresse, et duplikeret dokumentnummer eller en ikke-understøttet måleenhed kan kræve manuel indgriben, selv når meddelelsen er strukturelt gyldig.

Kvittering, validering og forretningsmæssig accept

EDI-bekræftelser fungerer på forskellige niveauer. En transportkvittering kan angive, at en meddelelse nåede et kommunikationsendepunkt. En funktionel eller implementeringsmæssig bekræftelse kan rapportere resultaterne af strukturelle kontroller. Et forretningssvar kan kommunikere, om en ordre eller en anden anmodning blev accepteret, afvist eller ændret.

Disse signaler bør ikke behandles som ækvivalente. En vellykket transmission betyder ikke nødvendigvis, at en ordre er accepteret, eller at varer vil blive afsendt. Den specifikke betydning af en bekræftelse skal fortolkes i henhold til den relevante specifikation og aftalen med handelspartneren.

Illustrativt eksempel fra ordre til forsendelse

En forhandler kan sende en indkøbsordre til en oversøisk leverandør via EDI. Leverandørens system kontrollerer produktidentifikatorer, mængder og ønskede leveringsoplysninger. Hvis handelsaftalen omfatter et ordresvar, kan leverandøren kommunikere sin accept eller foreslåede ændringer gennem en separat meddelelse.

Når varerne er klargjort, kan leverandøren udstede en forhåndsmeddelelse om forsendelse, der identificerer forsendelsen og dens indhold. Det modtagende lager kan bruge disse oplysninger til at forberede modtagelsen og sammenligne forventede mængder med de faktisk modtagne varer. Leverandøren kan også sende en faktura til behandling i forhandlerens økonomisystem.

Dette eksempel viser, hvordan EDI forbinder registreringer på tværs af organisationer. Det betyder ikke, at alle parter bruger den samme software, at hver meddelelse leveres i realtid, eller at handelsdokumenterne erstatter transport- og toldkrav. Afstemning af indkøbsordrer, forsendelsesreferencer og fakturaer kræver stadig ensartede identifikatorer og aftalt forretningslogik.

EDI og relaterede teknologier

EDI og API'er er ikke gensidigt udelukkende alternativer i enhver arkitektur. En organisation kan bruge EDI-meddelelser til partnertransaktioner og API'er til at forbinde disse transaktioner med interne applikationer. Den passende løsning afhænger af dokumentkrav, partnernes muligheder, tidsbehov og driftskontroller snarere end af teknologibetegnelsen alene.

Implementeringsovervejelser og begrænsninger

EDI kan reducere gentagen manuel dataindtastning, når systemer med succes udveksler og behandler kompatible meddelelser. Det korrigerer ikke unøjagtige kildedata, løser ikke kommercielle uenigheder og eliminerer ikke behovet for håndtering af undtagelser. Automatisering afhænger både af teknisk kompatibilitet og kvaliteten af de udvekslede forretningsoplysninger.

Før der etableres en EDI-forbindelse, bør handelspartnere afklare følgende driftsmæssige punkter:

• Dokumentomfang: Hvilke meddelelser kræves, og hvilke forretningshændelser udløser dem?
• Identifikatorer: Hvordan identificeres og matches produkter, lokationer, parter, ordrer og forsendelser?
• Meddelelseskrav: Hvilke versioner, obligatoriske felter, kodelister og mappingregler gælder?
• Kommunikation og sikkerhed: Hvilken forbindelsesmetode, autentificering og adgangskontrol kræves?
• Bekræftelser: Hvilke svar angiver levering, validering og forretningsmæssig accept?
• Håndtering af undtagelser: Hvem undersøger afviste meddelelser, manglende svar og uoverensstemmende data?
• Forebyggelse af dubletter: Hvordan skelnes retransmissioner fra nye forretningstransaktioner?
• Test og ændringsstyring: Hvordan testes mappings og partnerkrav, før ændringer sættes i produktion?

Driftsovervågning bør skelne mellem kommunikationsfejl, datavalideringsfejl og forretningsmæssige undtagelser. Gensendelse af en meddelelse kan afhjælpe en mislykket overførsel, men løser ikke en ugyldig produktkode. Uden kontroller mod dubletter kan gensendelse af en ordre, der allerede er behandlet korrekt, også oprette en utilsigtet anden transaktion.

Ofte stillede spørgsmål

Hvad betyder EDI inden for logistik?

EDI betyder elektronisk dataudveksling: struktureret udveksling af forretningsdokumenter mellem systemer. Inden for logistik kan disse dokumenter omfatte forsendelsesmeddelelser, transportinstruktioner, fakturaer og meddelelser om forsendelsesstatus.

Er en PDF sendt via e-mail et EDI-dokument?

Ikke i sig selv. En PDF kan præsentere et forretningsdokument elektronisk, men EDI kræver strukturerede oplysninger, som modtagende systemer kan fortolke i henhold til en aftalt specifikation.

Er EDI det samme som en API?

Nej. EDI vedrører standardiseret udveksling af forretningsdokumenter, mens en API definerer, hvordan software interagerer med en anden tjeneste. En integration kan bruge begge dele.

Betyder en EDI-bekræftelse, at en ordre blev accepteret?

Ikke nødvendigvis. Bekræftelser kan bekræfte transmission eller strukturel validering snarere end forretningsmæssig accept. Meddelelsestypen og aftalen med handelspartneren afgør betydningen.

Kilder

• UNECE: UN/EDIFACT — Officiel ramme for struktureret elektronisk udveksling af administrative, kommercielle og transportrelaterede data.
• X12: Transaction Sets — Officielle beskrivelser af forretningstransaktionssæt, herunder indkøbsordrer, fakturaer, forsendelsesmeddelelser og bekræftelser.
• GS1: Electronic Data Interchange — Standarder for forretningsmeddelelser og forholdet mellem GS1 EDI, EANCOM og GS1 XML.
• RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 — AS2-transport, sikkerhedsmekanismer og kvitteringsmeddelelser.