I dette kapitlet beskriver jeg hva EDI er, og gir eksempler på hvordan EDI brukes. Til slutt i kapitlet kommer jeg inn på følgende problemområder knyttet til EDI:
Identifisering av sentrale problemer med dagens EDI er første delmål.
Utveksling av informasjon med handelspartnere er i de fleste typer virksomhet en viktig del av primærvirksomheten. Informasjonen kan være handelsdokumenter som bestilling, faktura, ordrebekreftelse, betalingsoppdrag, fortollingsdokumenter m.m. Et eksempel er Toll og Avgiftsdirektoratets fortollingstjeneste som benytter elektroniske fortollingsdokumenter. Vi omgir oss med en mengde blanketter og skjemaer som i mange sammenhenger kan utveksles mellom de involverte partene uten at informasjonen må være på papir. Blanketter og skjemaer har vanligvis den egenskapen at de systematiserer informasjonen i forhold til formålet med skjemaet. Det at informasjonen allerede er systematisert gjør det enkelt å lage elektroniske handelsdokumenter som dekker samme funksjon. Elektroniske handelsdokumenter blir ofte kalt EDI-meldinger.
For å illustrere bruken av EDI bruker jeg et enkelt eksempel på bestilling av en vare. Først som papirbasert bestilling, og etterpå som EDI-bestilling.
Papirbasert bestilling
Bestillingen kan ses på som en avtale mellom to parter. Bestillingen er ofte et skjema, eventuelt en utskrift fra et datasystem som gir et skjema. Dette fylles ut og signeres. Skjemaet utveksles så mellom partene, gjerne ved tradisjonell postgang. Når mottaker får bestillingen tastes bestillingsinformasjonen vanligvis inn i et datasystem for lagerstyring eller et faktureringssystem. Når bestillingen er registrert skal den effektueres.
EDI-bestilling
En EDI-bestilling kan ses på som en avtale, tilsvarende en papirbasert bestilling. Bestillingssystemet kan for eksempel være et PC-program som benytter EDI. En bruker av PC-programmet legger inn en bestilling av varer, og brukeren gir deretter PC-programmet beskjed om å sende bestillingen til mottakeren. Dette skjer uten at bestillingen skrives ut på et papirskjema. Det som vanligvis så skjer er at denne formidlingen realiseres ved at data trekkes ut av PC-programmet. De data som er trukket ut kodes maskinelt til et meldingsformat som avsender og mottaker er enig om å benytte. Deretter sender PC-programmet de kodede data over en datalinje til mottaker. Mottagers datasystem mottar og dekoder bestillingen, og legger for eksempel bestillingen i «innkurven» for brukerne av mottagers datasystemet slik at de kan effektuere bestillingen.
Figur 1
Figur 1 viser et eksempel på hvordan en EDI-melding blir utvekslet mellom to virksomheter.
EDB som nyvinning har skapt endringer i måten en arbeider og samhandler på. De mest optimistiske røster for EDI mener at EDI vil oppnå en dominerende rolle allerede inneværende 10-år. Bruk av EDI forutsetter bruk av EDB, og etterhvert som datakommunikasjon blir enklere og billigere, vil utveksling av informasjon på et elektronisk format på tvers av organisasjoner bli stadig enklere.
Gevinster en virksomhet kan oppnå ved å ta i bruk EDI er ifølge [TEDIS-info]:
I dag finnes det EDI-meldingstyper for bruksområdene handel, produksjon, transport, fortolling, forsikring, administrasjon, betalingsformidling, reiseliv, fiskeri, helse, trygd, undervisning, statistikk o.s.v. På sikt vil EDI kunne omfatte så godt som alle typer informasjonsflyt. EDI er vanligvis i første rekke et verktøy for å effektivisere informasjonsflyt mellom parter der det allerede er etablert et forretningsforhold.
Eksempel på et EDI-system som har vært i bruk siden slutten av 1980-tallet er Toll og Avgiftsdirektoratets TVINN-system (Tollvesenets informasjonssystem for næringslivet i Norge). Systemet håndterer per 1996 ca. 9,4 millioner fortollingsdokumenter. Tallstørrelsen 9,4 millioner dokumenter fremkommer som summen av innkommende fortollingsdokumenter pluss svarmeldinger. Fortollingsdokumentene kontrolleres i hovedsak automatisk. En liten prosentandel av dokumentene skal behandles manuelt. Realiseringen av TVINN-systemet har gitt både Toll og Avgiftsdirektoratet og aktører som benytter seg av systemet en bedre hverdag. Toll og Avgiftsdirektoratet har kunnet frigjøre et stort antall personer fra kontrolloppgaver, og aktører som benytter seg av fortolling ved hjelp av TVINN-systemet er lovet svar innen 1 time. Dette er et mye bedre tjenestetilbud enn tidligere.
En av grunnideene til EDIFACT standardiseringsarbeidet er at alles behov for og krav til datautveksling skal dekkes i en global standard. ISO 9735 er ISO sin betegnelse på EDIFACT, og er opprinnelig en standard som United Nations har utviklet. Europa har vært representert i utviklingen av EDIFACT ved Western European EDIFACT Board. Arbeidet med EDIFACT er nå flyttet til CEN (Comité Européen de Normalisation) [EDIPROSA]. Pr. våren 1996 er ISO 9735 versjon-2 i bruk. Utviklingen av versjon-3 er ikke fullført, men det ser ut som om versjon 4 kommer til å bli en ny revidert standard.
EDIFACT er en standard for hvordan meldingene som utveksles mellom virksomheter skal modelleres, hvilke kodifisering som er mulig og hvilken syntaks meldingen skal ha. Standarden er mye brukt i Europa, mens X.12 er mest utbredt i USA. X.12 er utviklet av American National Standardisation Institute. X.12 er i all hovedsak ment å dekke det samme funksjonsområdet som EDIFACT.
EDIFACT inngår i en katalog som heter United Nations Trade Data Interchange Directory. Denne katalogen inneholder nødvendig informasjon for å kunne utnytte EDIFACT i henhold til vedtatte standarder. United Nations Trade Data Interchange Directory katalogen består blant annet av kataloger for de under nevnte deler.
| Dataelementer | Informasjonsbærere som består av en verdi |
| Sammensatt dataelementer | To eller flere dataelementer som hører sammen |
| Koder | Lovlige verdier til et dataelement med tilhørende forklaring |
| Segmenter | Et segment er en samling dataelementer / sammensatt dataelement som danner en helhet. For eksempel dato og tid, eller varepris og myntenhet m.m. |
| Meldinger | En EDIFACT-meldingstype er en samling segmenter, som sammen skal dekke en funksjon. Typer funksjoner kan være, faktura, ordre, laboratoriesvar, varekatalog, betalingsoppdrag med flere. En melding skal ofte dekke en funksjon som tilsvarer et eksisterende papirskjema. |
Tabell 1 forklarer de forskjellige katalogene United Nations Trade Data Interchange Directory består av.
Figur 2
Figur 2 viser relasjonen mellom de forskjellige katalogene nevnt i Tabell 1. Figuren er en forenklet versjon av en figur i [NO-TED91 kap 5 s.4].
Forkortelsene UNB / UNZ angir begynnelse på utveksling / slutt på utveksling. UNH/ UNT angir begynnelse av melding / slutt på melding. Med oppdeling på disse to innkapslingsnivåene kan en sende flere meldinger i en utveksling. Analogi til tradisjonell postgang er at du kan legge flere meldinger (f.eks. fakturaer) til samme mottaker i en og samme konvolutt.
Det segmentet som er identifisert med «UNA» angir hvilke tegn som benyttes til å skille de forskjellige segmenter, dataelementer fra hverandre, se Figur 3. Dette segmentet kommer helt først i en EDIFACT melding. Et eksempel på en veldig enkel «INVOIC 91.1» basert på ISO 9735 versjon 2 ser ut som følger:
-------------------------------------------------------------------------------
UNA:+,?’
UNB+UNOA:2+STATENS DATASENTRAL A.S+MOTTAGER+960815:0900+ID_0001'
UNH+1+INVOIC:2:911:UN'
BGM+380+1996123456'
DTM+3:199505230830:102'
FTX+TEX+++g=Ole;s=Hansen'
FTX+TEX+++Tekst som gjelder hele fakturaen'
RFF+K1'
RFF+K2'
LIN+1++1:::91'
QTY+47:11'
MOA+203:100'
LIN+2++6:::91'
QTY+47:12'
MOA+203:200'
LIN+3++8:::91'
QTY+47:3'
MOA+203:300'
LIN+4++12:::91'
QTY+47:22'
MOA+203:400'
UNS+S'
MOA+125:1000'
UNT+22+1'
UNZ+1+ID_0001'
-------------------------------------------------------------------------------
Figur 3
Jeg har gjort denne EDIFACT-meldingen mer leselig ved å legge inn linjebrudd og tabulatorer. Vanligvis vil meldingen bli utvekslet som en lang streng, uten vognretur (CR/LF) og uten unødvendige blanke (space) som gir innrykk.
Det finnes to typer segmenter. Den ene er tjenestesegmenter som inneholder typisk hode- og hale-informasjon som avsender, mottaker, identifikator for meldingen og kontrollsummer for antall segmenter o.a. Segmentene «UNB», «UNZ», «UNH», «UNT» og «UNS» er eksempler på slike. Den andre typen inneholder nyttedata som
Fakturaen i Figur 3 har fire varelinjer og summen på fakturaen står idet siste «MOA» segmentet. Koden «125» i det siste «MOA» segmentet betyr: faktura sum som det skal beregnes avgifter på. Tallet «1000» i samme segment er kronebeløpet for hele fakturaen.
Siden EDIFACT har som hensikt å være fleksibel på tvers av bransje, sektor og landegrenser [NO-TED91 3-1], har man lagt vekt på valgfrihet i mye av innholdet i meldinger. I en gitt melding vil det enkelte segment og det enkelte dataelement innen segmentet ha attributter som angir om de er obligatoriske eller valgfrie informasjonsbærere. Tilsvarende gjelder for antall repetisjoner av segmenter og grupper av segmenter. Siden EDIFACT er en romslig standard har den enkelte melding stor funksjonalitet. For eksempel skal en fakturamelding kunne dekke de aller fleste varianter av fakturaer som finnes på papir. Et eksempel fra Jens Hørlück [Hørlück95] gir et perspektiv på variasjonsmulighetene:
The latest version of the EDIFACT invoice requires as a minimum a few mandatory data elements with less than 100 characters. If on the other hand, an invoice with 10 detail lines was filled with the maximum allowed, there would be approximately 522,000 data elements with a total of 8,66 MB.
I den tiden EDI har eksistert i standardisert form er det tatt i bruk i et stort antall virksomheter. Den teknologiske utviklingen har gått fort, og en del av de forutsetningene EDIFACT bygger på har endret seg. Informasjonssystemer har blitt mer komplekse, og dagens informasjonsteknologi kan håndtere mer komplekse løsninger enn det som var mulig for eksempel for 15 år siden. Det utvikles stadig nye EDIFACT-meldingstyper. Disse baserer seg på:
Som eksempler på IT-evolusjon vil jeg spesielt nevne at ER modellering ble introdusert av Chen i 1976, og at i 1983 kom de første kommersielle relasjonsdatabasene som Oracle, Sybase, Informix og DB2 [Elmasri]. Mange av dagens datasystemer som bruker EDI baserer seg på relasjonsdatabaser. Mens det har vært en evolusjon i IT-løsningene har EDIFACT så godt som stått stille utviklingsmessig.
Meldinger basert på EDIFACT presenteres grafisk som eksempelet i Figur 4 viser. Som datamodell har EDIFACT sitt oversiktsdiagram (branching diagram) store likhetstrekk med en datamodell for hierarkisk databaser. Begge modellene håndterer 1 til n relasjoner data bra, mens andre typer relasjoner håndteres mindre bra.
Figur 4
Figur 4 viser deler av et oversiktsdiagram for faktura release 95B.
Forklaring til figuren:
NIAM eller ER er datamodelleringsmetoder for relasjonsdatabaser [Elmasri]. Disse gir mulighet for å uttrykke flere typer relasjoner som «mange til mange», «en til mange» og «mange til en», og kan også uttrykke andre typer beskrankninger. EDIFACT oversiktsdiagram er kun velegnet til å uttrykke «en til mange» relasjoner siden den har en hierarkisk struktur. I Norsk veiledning i bruk av EDIFACT [NO-TED91 Kap 6 s. 4-25] er det et eget avsnitt om «Bruk av datamodellering ved fortolkning og konstruksjon av meldingstype». Avsnittet gir en fremgangsmåte for å omforme en ER-modell til en EDIFACT oversiktsdiagram. Algoritmen går bl.a. gjennom følgende punkter [NO-TED91 Kap 6 s. 4-25&26]:
«Første skritt i oversettelsesprosessen bringer datamodellen over på en form som stemmer med den grunnleggende strukturen i en EDIFACT-meldingstype. En meldingstype er alltid hierarkisk oppbygget, mens en datamodell som oftest har struktur som et nettverk av likestilte noder.» [NO-TED91 Kap 6 s. 4-26]
Algoritmen brukt på en ER-modell gir en hierarkisk datastruktur som resultatet. Den hierarkiske datastrukturen brukes som utgangspunkt for en ny algoritme hvor entiteter byttes ut med et eller flere segmenter. Relasjoner i ER-modellen kan bli til grupper av segmenter, repeterte grupper eller repeterte enkeltsegmenter eller bare et enkelt segment [NO-TED91 Kap 6 s. 4-27&28]. Kortfattet kan en si at ER-modellen blir omformet til en hierarkisk datastruktur, og derfra videre til et EDIFACT oversiktsdiagram. Dette er en enveis prosess; det går ikke an å ta et EDIFACT oversiktsdiagram og komme tilbake til den opprinnelige ER-modellen. Algoritmen som benyttes vil føre til at informasjon og strukturer kan gå tapt. Det er verd å merke seg at en vanlig datastrøm ved bruk av EDI vil være at data lastes ut av en relasjonsdatabase hos avsender, data konverteres til en EDI-melding og deretter blir EDI-meldingen konvertert tilbake til en relasjonsdatabasestruktur hos mottaker. Mye hadde vært forenklet hvis ER-modellen hadde vært ekvivalent med EDIFACT oversiktsdiagrammet. Da ville en ha beholdt informasjon og strukturer i data selv om en konverterte mellom forskjellige formater.
Ved utvikling av et interorganisatorisk system som skal benytte EDIFACT-meldingstyper, er det vanlig å ta i bruk en meldingshåndbok som beskriver det aktuelle forretningsområde og implementasjonsguider for de meldinger som skal benyttes. Implementasjonsguidene beskriver hva som er intensjonen med den aktuelle EDIFACT-meldingstype, hvordan den skal brukes og fortolkes og hvordan syntaks på meldingen er. Norsk EDIPRO har sammen med andre aktører laget implementasjonsguider tilpasset norske forhold.
Hensikten med å utveksle data er at en skal utføre noe på basis av de data en sender eller mottar. «EDI is more than just the exchange of DATA. Each exchange has a purpose: to let the receiving organization act upon the message received» [Hørlück93]. For å sikre at alle involverte parter tillegger en EDIFACT-melding samme intensjon må de kodes og dekodes på en symetrisk måte. For å oppnå dette brukes det vanligvis meldingshåndbøker og implementasjonsguider.
«Meldingstypene i EDIFACT er utviklet for bruk i både nasjonale og internasjonale transaksjoner, og for bruk innenfor et stort spekter av ulike bransjer. Meldingstypene er derfor meget fleksible. For å integrere de forskjellige meldingstypene mot en virksomhets interne applikasjoner på en effektiv måte, er det nødvendig med en fortolkning av de foreliggende EDIFACT-meldingstypene for å oppnå den nødvendige grad av presisjon både når det gjelder datainnhold og behandlingsregler.» [NO-TED91 Kap 6 s. 1-2]
Avgrensning av funksjonalitetsmengde skjer ved at implementasjonsguiden gir retningslinjer for hvilke segmenter i meldingen som skal benyttes, hvordan de skal benyttes og hvilke koder fra kodekatalogen som kan eller skal benyttes.
En EDI-melding har en funksjon eller hensikt, og innholdet i meldingen skal tolkes i henhold til den funksjonen. Selve meldingen har en funksjon, for eksempel funksjonen faktura, og dataelementene meldingen består av har en delfunksjon. For eksempel vil dataelementene for rabatter i en EDI-faktura ha den funksjon at de angir hva slags rabatt som er gitt, og hvor stor denne rabatten er. Dataelementene vil være knyttet til gitte segmenter i en melding. For å kunne sammenlikne to virksomheters implementasjoner av en EDIFACT-meldingstype (for eksempel faktura) trenger jeg en måleenhet som angir hvor stor del av en komplett EDIFACT-meldingstype som er implementert. Jeg vil bruke funksjonalitetsmengde som begrep for å angi hvilke segmenter og dataelementer i en melding som blir brukt, og hvordan de blir brukt. En meldings funksjonalitetsmengde kan si om den er kompatibel eller ikke med andre meldinger.
Når flere virksomheter sammenlikner sine implementasjoner av EDIFACT-meldingstyper for å finne ut om de er kompatible, vil det være nyttig å ha en form for klassifisering av implementasjonene. Et sett av slike klassifiseringer kan være som følger:
Når virksomhetenes implementasjoner er klassifisert i henhold til overstående kategorier vil en kunne si om to virksomheter har implementert kompatible funksjonalitetsmengder av en EDIFACT-meldingstype.
Figur 5
Figur 5 viser funksjonalitetsmengder skissert som ven diagram.
Figur 5 illustrerer en situasjon hvor to EDI-aktører har implementert deler av samme implementasjonsguide. EDI-aktørene har valgt ut de delene av implementasjonsguiden som er hensiktsmessig ut fra egen forretningstradisjon og interne rutiner. Som skissen viser vil Firma A og Firma B ikke uten videre kunne utveksle EDI-meldinger. Dette fordi et lovlig meldingsinnhold ut fra funksjonalitetsmengde hos Firma A ikke nødvendigvis er lovlig ut fra funksjonalitetsmengde hos Firma B. Hensikten med bruk av implementasjonsguider til EDIFACT-meldingstyper er at de enkelte aktørene lettere skal kunne implementere EDI-meldinger med kompatible funksjonalitetsmengder, altså ikke slik som i Figur 5. Funksjonalitetsmengdene vil alltid ha noe felles siden det er påkrevd å bruke deler av EDIFACT-meldingstypene.
To virksomheter som benytter forskjellige implementasjonsguider til samme EDIFACT-meldingstype vil ikke være funksjonalitetsmengde kompatible. Dette er et problemet som gjør at EDIFACT likevel ikke er global. En får grupperinger av virksomheter som implementerer en implementasjonsguide, men de er ikke kompatible med andre virksomheter som benytter andre implementasjonsguider til samme EDIFACT-meldingstype.
Bruk av EDI reiser en rekke juridiske problemstillinger. Skal en kunne utveksle EDI-meldinger må en forholde seg til gjeldende lover og regler. Disse kan variere, avhengig av forretningsdokument. I tillegg kan det være forskjellige krav til privat og offentlig virksomhet knyttet til samme type forretningsdokument. Utveksling av EDI-meldinger på kryss av landegrenser gjør det mer komplisert, da det vil involvere flere nasjoners lovverk. I følge [TEDIS-info] krever lovverket i noen EU nasjoner skriftlige avtaler med håndskrevet signatur for at en kontrakt skal være gyldig. Dette er ikke tilfelle i Norge, her er for eksempel en muntlig avtale bindende. Regler for bevisføring, dokumentasjon og kontrakter vil også variere.
Hensikten med avtaler relatert til bruk av EDI er å sikre rammene og vilkårene for anvendelsen. Norsk veiledning i bruk av EDIFACT [EDIPRO94] gir forslag til avtalestruktur ved bruk av EDIFACT i interorganisatoriske systemer.
Partene må bli enige om et EDI-samarbeid nedfelt i en samarbeidsavtale. De må også være enige om retningslinjene for hvordan en skal drive elektronisk handel i forhold til tradisjonell handelsvirksomhet. Dette kalles en utvekslingsavtale. Utvekslingsavtalen har definert fire delmål: Sikre måloppnåelse, retningslinjer for bruk, forebyggelse av konflikter og bidra til å løse konflikter. Det er også behov for avtaler relatert til de enkelte handelsdokumenter og måten de skal benyttes på. Dette kalles dokumentavtale. Med den forstås en avtale som regulerer rettigheter og plikter relatert til utveksling av en eller flere spesifikke dokumenttyper. Dokumentavtalene refererer til implementasjonsguider, som gir selve fortolkningen av meldingene som skal utveksles.
Figur 6
Figur 6 er hentet fra [EDIPRO94] og viser sammenheng mellom avtaler og implementasjonguider.
En dokumentavtale kan for eksempel påpeke forskjeller i formelle krav angående håndtering av faktura, ordre og ordrebekreftelse. For ordre og ordrebekreftelse vil det ifølge [NO-TED91 kap 2 s.5] være nok å henvise til kjøpsloven for å få støtte for at elektronisk overføring av forretningsdokumenter er juridisk bindende.
[Kjøpsloven, §91]: «Muntlig eller skriftlig avtale
(1) Et kjøp behøver ikke å sluttes eller bekreftes skriftlig og er ikke undergitt noe annet formkrav. Det kan bevises ved hjelp av ethvert bevismiddel, vitner medreknet...... »
[Kjøpsloven, §92]: «Fremmed lovgivning som krever skriftlig avtale
Bestemmelser i §91 gjelder ikke internasjonalt kjøp hvor en part har sitt forretningssted i en konvensjonsstat.....»
I følge [EDIPRO94] vil bruk av EDI-faktura også måtte forholde seg til regnskapsloven: «Kjøpslovens §91 kan imidlertid ikke benyttes som grunnlag for å hevde at en faktura ikke behøver å være skriftlig. Krav til faktura må i første rekke utledes av regnskapslovgivningen.» [EDIPRO94]
På bakgrunn av de ovennevnte lover ser en at det også i Norge stilles forskjellige krav til forskjellige typer dokumenter. Formkravet i [Kjøpsloven, §91] er sentralt for å kunne bruke EDI som avtaleform i Norge.
Ved utvikling av et interorganisatorisk system må det tas en del sentrale overordnede valg knyttet til systemutviklingsfasene. [UN-Rapport] trekker frem noen motsetninger som er relevante ved utvikling av interorganisatoriske systemer. Grunnideene til EDIFACT er at alles behov for og krav til datautveksling skal dekkes i en felles global standard. Dette er en grunnidé som [UN-Rapport] er kritisk til. Ifølge [UN-Rapport] må en blant annet forholde seg til følgende motsetninger:
| Motsetning | EDIFACTs valg |
| Brukere som ønsker stabile meldinger, kontra brukere som ønsker rask videreutvikling av eksisterende meldinger for å møte konkurransemessige krav. | Jeg mener at EDIFACT er å betrakte som en stabil standard som bruker lang tid for å utvikle en melding. Standarden kommer ut med årlige oppdateringer som en kan ta i bruk om en ønsker det. Disse årlige oppdateringene er vanligvis minimale for stabile meldinger. |
| Brukere som ønsker meldinger til bruk for en lukket gruppe, kontra brukere som ønsker universelle og globale meldinger. | EDIFACT støtter primært globale og universelle meldinger. Men EDIFACT tillater bruk av implementasjonsguider som i praksis kan brukes til å gi en brukergruppe en lukket løsning, basert på en fravalgstankegang fra en global standard. |
| Brukere som ønsker meldinger raskt tilgjengelig for å bytte papirflyt med tilsvarende EDI meldingsflyt, kontra brukere som ønsker meldinger som støtter virksomhetsomlaftning basert på EDI som verktøy. | I senere tid har EDIFACT som verktøy for virksomhetsomlaftning fått mer fokus i forbindelse med meldingsdesign. Men tyngden av meldinger erstatter eksisterende papirflyt, også kalt EDIfisering. |
Jeg mener [UN-Rapport] kommer med sunn kritikk fordi (i) definering av hvem som er potensielle brukere er viktig for utformingen av EDIFACT og (ii) valg av hvordan utvikling og versjonshåndtering av EDIFACT skal skje er viktig for hvordan en kan designe og videreutvikle interorganisatoriske systemer.
Jeg mener at EDIFACT ikke tilfredsstiller alles behov for og krav til datautveksling. Det er kun den gruppen av virksomheter som ønsker en standard bygget på samme motsetningsvalg som EDIFACT som får dekket sine behov.
I dette avsnittet ble EDI beskrevet. Eksempler på forskjellen mellom utveksling av forretningsdokumenter ved tradisjonell postgang og EDI ble gitt. En faktura ble gitt som eksempel på en konkret EDIFACT-meldingstype, og strukturen på EDIFACT-meldingstyper generelt ble beskrevet. Gevinster det er mulig å få i en virksomhet ved å ta i bruk EDI ble listet opp.
ER-datamodeller kan konverteres til EDI-meldinger, algoritme for dette ble skissert. ER-modellen kan bli konvertert til et EDIFACT oversiktsdiagram, men meningsinnholdet i ER-modellen og EDIFACT oversiktsdiagram er ikke ekvivalent. Algoritmen som benyttes fører til at informasjon og strukturer fra opprinnelig ER-modell kan gå tapt. Hvis meningsinnholdet i ER-modeller hadde vært ekvivalent med EDIFACT oversiktsdiagrammer, hadde det vært en vesentlig forenkling.
Problemet med at virksomheter implementerer EDI-meldinger forskjellig gjør at en EDIFACT-meldingstype i praksis ikke er en fullgod global standard. Samme EDIFACT-meldingstype vil kun være en standard for de som benytter samme implementasjonsguide. Til bruk ved sammenlikning av implementasjoner av EDI-meldinger ble det beskrevet fire kategorier av funksjonalitetsmengder. Disse kategoriene kan benyttes når flere virksomheter skal sammenlikne sine implementasjoner av EDI-meldinger for å se om de enkelt kan utveksle EDI-meldinger.
Forhold mellom jus og bruk av EDI ble beskrevet, og spesielt ved internasjonal handel er det mange problemer som å ivaretas. Overordnede motsetninger som er relevante ved utvikling av interorganisatoriske systemer ble tatt opp. Grunnideene til EDIFACT er at alles behov for og krav til datautveksling skal dekkes i en felles global standard. [UN-Rapport] kritiserer EDIFACT med argumenter som jeg støtter.
De understående problemområder vil være kilder for en oversikt av faktorer som påvirker utbredelse av EDI, og senere i oppgaven som kilde for å kunne skissere en systemutviklingsmetode som baserer seg på bruk av Åpen-edi referansemodellen: