Elektronisk datautveksling (Edi)

Hva er elektronisk datautveksling (EDI)?

Elektronisk datautveksling (EDI) er utveksling av strukturerte forretningsdokumenter mellom organisasjoner fra datamaskin til datamaskin ved bruk av avtalte standarder. Innen logistikk, netthandel og internasjonal handel gjør det det mulig for systemer som brukes av kjøpere, leverandører, lagre, transportører og andre handelspartnere å utveksle informasjon som innkjøpsordrer, forsendelsesvarsler, transportinstruksjoner og fakturaer uten at personer må skrive inn hvert dokument på nytt.

Det som kjennetegner EDI, er ikke bare at informasjon sendes elektronisk. Informasjonen organiseres i felt, segmenter og meldinger som mottakende programvare kan tolke i henhold til en avtalt spesifikasjon. En faktura som er lagt ved en e-post som PDF, er derfor ikke i seg selv en EDI-faktura: en person eller et dokumentbehandlingsverktøy kan fortsatt måtte hente ut innholdet før et forretningssystem kan bruke det.

EDI beskriver en metode for utveksling av forretningsinformasjon, ikke ett bestemt programvareprodukt, nettverk eller filformat. En fungerende løsning avhenger av kompatible dokumentdefinisjoner, kommunikasjonsmetoder, identifikatorer og forretningsregler.

EDI innen logistikk og netthandel

EDI kobler sammen aktiviteter som går på tvers av organisatoriske grenser. En forhandlers innkjøpssystem kan generere en ordre, leverandørens system kan bekrefte den, og et lager kan motta instruksjoner om å klargjøre varene. Forsendelsesinformasjon og fakturaer kan deretter flyttes mellom de relevante systemene som separate meldinger.

Innen netthandel kan EDI støtte forretningsprosessene mellom virksomheter som ligger bak en nettbutikk rettet mot forbrukere. En nettforhandler kan for eksempel bruke det til å bestille lagerbeholdning fra en leverandør eller utveksle informasjon om ordreoppfyllelse med et lager. Forbrukerens betalingstransaksjon og forhandlerens påfølgende EDI-meldinger er relaterte forretningshendelser, men de er ikke nødvendigvis den samme transaksjonen eller bruker det samme tekniske grensesnittet.

Ved grensekryssende handel kan EDI formidle informasjon som trengs for internasjonal transport og kommersiell dokumentasjon. Tollmyndigheter kan også bruke strukturerte elektroniske meldinger i henhold til egne spesifikasjoner. Utveksling av en EDI-melding med en leverandør eller transportør utgjør imidlertid ikke i seg selv en tolldeklarasjon, fastslår ikke at regelverket er fulgt og godkjenner ikke frigivelse av varer.

Vanlige forretningsdokumenter

Eksemplene nedenfor illustrerer dokumentfunksjoner og utgjør ikke en obligatorisk rekkefølge. Hvilke meldinger som brukes, avhenger av handelsforholdet og den aktuelle implementeringsveiledningen.

Et forhåndsvarsel om forsendelse, ofte forkortet ASN, beskriver en forventet forsendelse; det beviser ikke at varene har ankommet. På samme måte er en statusmelding for en forsendelse ikke automatisk et leveringsbevis. Betydningen avhenger av den rapporterte hendelsen og den underliggende informasjonen.

Standarder, formater og kommunikasjonsmetoder

EDI-standarder definerer hvordan forretningsmeldinger struktureres og hva dataelementene betyr. To etablerte standardfamilier er X12 og FNs regler for elektronisk datautveksling for administrasjon, handel og transport, kjent som UN/EDIFACT. GS1 vedlikeholder også EDI-standarder, blant annet EANCOM, som er basert på UN/EDIFACT, og GS1 XML.

Innen X12 omfatter eksempler 850 Purchase Order, 856 Ship Notice/Manifest og 810 Invoice. UN/EDIFACT tilbyr meldinger som ORDERS for innkjøpsordrer, DESADV for forsendelsesmeldinger og INVOIC for fakturaer. Disse eksemplene har tilsvarende forretningsformål på tvers av standardene, men strukturene og implementeringskravene deres kan ikke brukes om hverandre.

En standard alene definerer ikke alle detaljer i et handelsforhold. Partene må også bli enige om aktuell versjon og implementeringsveiledning, obligatoriske felt, tillatte koder, identifikatorer og valideringsregler. To organisasjoner kan støtte den samme standardfamilien og likevel trenge kartleggingsarbeid før systemene deres kan utveksle brukbare meldinger.

AS2 er en kommunikasjonsspesifikasjon for utveksling av forretningsdata over HTTP, med mekanismer for sikkerhet og kvitteringer. Det er ikke et format for innkjøpsordrer eller fakturaer. Et Value-Added Network, eller VAN, kan tilby mellomliggende tjenester for meldingsutveksling; det er på samme måte adskilt fra standarden for forretningsdokumenter.

Slik fungerer en EDI-utveksling

1. En forretningshendelse oppretter data. En kjøper godkjenner for eksempel en innkjøpsordre i et ERP- eller ordrehåndteringssystem.
2. Dataene kartlegges til en melding. Oversettelsesprogramvare konverterer interne felt til strukturen som kreves av den avtalte standarden og implementeringsveiledningen.
3. Den utgående meldingen kontrolleres. Validering kan kontrollere syntaks, obligatoriske felt, kodeverdier og partnerspesifikke krav.
4. Meldingen overføres. Den går gjennom den avtalte kommunikasjonskanalen til mottakeren eller en mellomliggende aktør.
5. Mottakeren validerer og oversetter den. Mottakssystemet kontrollerer meldingen og kartlegger godkjent informasjon til sitt interne applikasjonsformat.
6. Forretningsbehandlingen følger. Mottaksapplikasjonen kan opprette en ordre, registrere en forventet mottakelse eller sende et avvik til gjennomgang.
7. Svar avstemmes. Tekniske kvitteringer, bekreftelser og forretningssvar hjelper avsenderen med å fastslå hva som skjedde med utvekslingen.

Disse trinnene garanterer ikke at alle transaksjoner behandles automatisk. En ukjent produktidentifikator, ugyldig leveringsadresse, duplikat dokumentnummer eller ikke-støttet måleenhet kan kreve manuell inngripen selv når meldingen er strukturelt gyldig.

Kvittering, validering og forretningsmessig godkjenning

EDI-bekreftelser fungerer på ulike nivåer. En transportkvittering kan indikere at en melding nådde et kommunikasjonssluttpunkt. En funksjonell bekreftelse eller implementeringsbekreftelse kan rapportere resultatene av strukturelle kontroller. Et forretningssvar kan formidle om en ordre eller annen forespørsel ble godkjent, avvist eller endret.

Disse signalene bør ikke behandles som likeverdige. Vellykket overføring betyr ikke nødvendigvis at en ordre er godkjent eller at varer vil bli sendt. Den spesifikke betydningen av en bekreftelse må tolkes i henhold til den relevante spesifikasjonen og avtalen med handelspartneren.

Illustrerende eksempel fra ordre til forsendelse

En forhandler kan sende en innkjøpsordre til en utenlandsk leverandør gjennom EDI. Leverandørens system kontrollerer produktidentifikatorer, mengder og ønsket leveringsinformasjon. Hvis handelsavtalen omfatter et ordresvar, kan leverandøren formidle godkjenning eller foreslåtte endringer gjennom en separat melding.

Når varene er klargjort, kan leverandøren utstede et forhåndsvarsel om forsendelse som identifiserer forsendelsen og innholdet. Det mottakende lageret kan bruke denne informasjonen til å forberede mottaket og sammenligne forventede mengder med varene som faktisk mottas. Leverandøren kan også sende en faktura for behandling i forhandlerens økonomisystem.

Dette eksempelet viser hvordan EDI kobler sammen poster på tvers av organisasjoner. Det innebærer ikke at alle parter bruker samme programvare, at hver melding leveres i sanntid, eller at de kommersielle dokumentene erstatter transport- og tollkrav. Det kreves fortsatt konsekvente identifikatorer og avtalt forretningslogikk for å samsvare innkjøpsordrer, forsendelsesreferanser og fakturaer.

EDI og relaterte teknologier

EDI og API-er er ikke gjensidig utelukkende alternativer i alle arkitekturer. En organisasjon kan bruke EDI-meldinger for partnervtransaksjoner og API-er for å koble disse transaksjonene til interne applikasjoner. Den riktige løsningen avhenger av dokumentkrav, partnernes kapasitet, tidsbehov og driftskontroller, ikke bare av teknologibetegnelsen.

Implementeringshensyn og begrensninger

EDI kan redusere gjentatt manuell dataregistrering når systemer lykkes med å utveksle og behandle kompatible meldinger. Det korrigerer ikke unøyaktige kildedata, løser ikke kommersielle uenigheter og eliminerer ikke behovet for håndtering av avvik. Automatisering avhenger både av teknisk kompatibilitet og kvaliteten på forretningsinformasjonen som utveksles.

Før en EDI-forbindelse opprettes, bør handelspartnere avklare følgende driftsmessige punkter:

• Dokumentomfang: Hvilke meldinger kreves, og hvilke forretningshendelser utløser dem?
• Identifikatorer: Hvordan skal produkter, lokasjoner, parter, ordrer og forsendelser identifiseres og samsvares?
• Meldingskrav: Hvilke versjoner, obligatoriske felt, kodelister og kartleggingsregler gjelder?
• Kommunikasjon og sikkerhet: Hvilken tilkoblingsmetode, autentiseringsløsning og tilgangskontroll kreves?
• Bekreftelser: Hvilke svar indikerer levering, validering og forretningsmessig godkjenning?
• Håndtering av avvik: Hvem undersøker avviste meldinger, manglende svar og inkonsekvente data?
• Forebygging av duplikater: Hvordan skal videresendinger skilles fra nye forretningstransaksjoner?
• Testing og endringskontroll: Hvordan skal kartlegginger og partnerkrav testes før endringer settes i produksjon?

Driftsovervåkingen bør skille mellom kommunikasjonsfeil, datavalideringsfeil og forretningsmessige avvik. Å sende en melding på nytt kan løse en mislykket overføring, men vil ikke rette en ugyldig produktkode. Uten duplikatkontroller kan videresending av en ordre som allerede er behandlet, også opprette en utilsiktet annen transaksjon.

Vanlige spørsmål

Hva betyr EDI innen logistikk?

EDI betyr elektronisk datautveksling: strukturert utveksling av forretningsdokumenter mellom systemer. Innen logistikk kan disse dokumentene omfatte forsendelsesvarsler, transportinstruksjoner, fakturaer og statusmeldinger for forsendelser.

Er en PDF sendt på e-post et EDI-dokument?

Ikke i seg selv. En PDF kan presentere et forretningsdokument elektronisk, men EDI krever strukturert informasjon som mottakende systemer kan tolke i henhold til en avtalt spesifikasjon.

Er EDI det samme som et API?

Nei. EDI gjelder standardisert utveksling av forretningsdokumenter, mens et API definerer hvordan programvare samhandler med en annen tjeneste. En integrasjon kan bruke begge deler.

Betyr en EDI-bekreftelse at en ordre ble godkjent?

Ikke nødvendigvis. Bekreftelser kan bekrefte overføring eller strukturell validering i stedet for forretningsmessig godkjenning. Meldingstypen og avtalen med handelspartneren avgjør betydningen.

Kilder

• UNECE: UN/EDIFACT — Offisielt rammeverk for strukturert elektronisk utveksling av administrative, kommersielle og transportrelaterte data.
• X12: Transaction Sets — Offisielle beskrivelser av forretningstransaksjonssett, inkludert innkjøpsordrer, fakturaer, forsendelsesvarsler og bekreftelser.
• GS1: Electronic Data Interchange — Standarder for forretningsmeldinger og forholdet mellom GS1 EDI, EANCOM og GS1 XML.
• RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 — AS2-transport, sikkerhetsmekanismer og kvitteringsvarsler.