Elektronischer Datenaustausch

Elektronischer Datenaustausch (englisch electronic data interchange, EDI) bezeichnet innerhalb der elektronischen Datenverarbeitung (EDV) als Sammelbegriff den Datenaustausch unter Nutzung elektronischer Transferverfahren. Direkt beteiligt (als Absender, Transporteur und Empfänger der versendeten Nachrichten) sind dabei Anwendungssysteme der beteiligten Unternehmen/Organisationen.

In einem engeren Sinn werden mit EDI-Standards konkrete Verfahren und Vereinbarungen zum Datenaustausch bezeichnet, die zwischen Unternehmen oder durch Normierungsvorschläge von Branchenverbänden entwickelt wurden. In diesem Zusammenhang steht der Begriff nur für unternehmensübergreifenden Transfer standardisierter Geschäftsdaten.[1]

Merkmale

Asynchron
Bei asynchronen Verfahren des Datenaustausches erfolgt die Datenübertragung in voneinander getrennten Schritten. Die Daten werden unterwegs mehrere Male zwischengespeichert, es wird keine sofortige inhaltliche Antwort erwartet und übertragen. Man nennt diese Verfahren auch store and forward. Typisches Beispiel für ein asynchrones Verfahren ist die Übertragung von E-Mail. Häufig wird E-Mail als Transportmittel für EDI benutzt.[2]
Synchron
Im Gegensatz dazu stehen synchrone Datenaustauschverfahren, bei denen auf eine Anfrage hin noch in der laufenden Verbindung beziehungsweise Session vom Gegenüber eine betriebswirtschaftlich-inhaltliche Antwort erfolgt. Ein Beispiel dafür ist die Abfrage eines Lagerbestandes zu einem Artikel. Die gewünschte Information wird dabei dem Pull-Prinzip folgend eingeholt. Die synchrone und automatische Kommunikation zwischen verteilten Anwendungssystemen ist eine Einsatzmöglichkeit für Warteschlangen (engl. Queue).
Vollautomatisch
Wesentlicher Grundgedanke von EDI ist die vollständig automatisch ablaufende Kommunikation. Das sendende Anwendungssystem initiiert die Übertragung und bis zur Verbuchung beziehungsweise Vorerfassung im Empfängersystem erfolgt kein menschlicher Eingriff, kein menschlicher Arbeitsschritt. Dadurch sinkt die Zahl der Eingabe- und Datenfehler wesentlich.
Versand
Bei EDI-Verfahren erfolgt die Kommunikation immer in einer Richtung: Der Sender sendet Nachrichten an einen Empfänger. In vielen Anwendungen von EDI sendet später der ursprüngliche Empfänger seinerseits eine Nachricht zurück, aber dies ist ein anderer Prozess, der zeitlich getrennt abläuft und wiederum ein reiner Sendevorgang ist. Anders ausgedrückt erfolgt die Kommunikation bei EDI nach dem Push-Prinzip.
Strukturierte Nachrichten
Eine (elektronische) Nachricht ist eine abgeschlossene Datenmenge, die aus dem Nutzinhalt und Metainformation besteht. Der Nutzinhalt sind genau die Daten, die vom Empfängersystem verbucht werden. Die Metainformation gibt vor allem die Information über die Verarbeitung, speziell über das Routing an den Empfänger vor. Beispiel für Nachrichten sind E-Mails. Im Gegensatz zu E-Mails, die Personen einander senden, werden für EDI strukturierte Nachrichten verwendet, das heißt, diese Nachrichten genügen den Vorschriften beziehungsweise der Syntax einer festen Struktur. Eine solche Struktur besteht aus Elementen, die zu Segmenten zusammengesetzt sind. Die Elemente der Struktur sind mit ihren Eigenschaften wie Länge, Position im Segment, Typ numerisch/alphanumerisch, muss/kann auftreten, eventuell Feldtrennzeichen und Maskierungszeichen vorgegeben. Ebenso gibt die Struktur vor, welche Segmente in welcher Reihenfolge wie oft auftreten dürfen oder müssen. Durch die Struktur und die damit vorgegebene Syntax wird gewährleistet, dass im Empfängersystem jedes Datum, jedes Element an die richtige Stelle gebucht werden kann.
Teilstrukturierte Nachrichten
Da man manche Daten, wie CAD-Daten, nicht strukturiert verschicken kann, muss man eine sogenannte Header- oder Metadatei erstellen, in der die Namen der eigentlichen Dateien aufgeführt und weitere strukturierte Informationen je Datei eingestellt sind. Dies praktiziert man beispielsweise bei ENGDAT.
Anwendungssystem
Mit Anwendungssystem ist hier eine Anlage aus Hard- und Software gemeint, welche die empfangenen Daten betriebswirtschaftlich verarbeitet. Beispiele sind Enterprise Resource Planning (ERP)-Systeme, Bankenbuchungssysteme, Produktionsplanungs- und -steuerungssysteme (PPS-Systeme), Lagerverwaltungssysteme, Verkaufs- oder Einkaufssysteme oder viele andere mehr. Direkter Empfänger von Nachrichten sind keine Personen; erst die vom Anwendungssystem verarbeiteten oder zumindest vorerfassten Daten werden bei Bedarf zweckspezifisch aufbereitet und menschlichen Anwendern, zum Beispiel in Listenform als Eingangs-, Fehler-, Verarbeitungsprotokoll zugeleitet.
Unterschiedliche Institutionen
Datenaustausch innerhalb einer Institution, der ansonsten jedoch obiger Definition entspricht, fällt unter den Begriff Enterprise Application Integration (EAI). EDI bedeutet dagegen immer die Beteiligung mindestens zweier verschiedener Institutionen. Es besteht eine große Ähnlichkeit der für EDI und EAI eingesetzten Werkzeuge, deswegen werden viele Werkzeuge gleichzeitig für beide Zwecke hergestellt und eingesetzt. Unterschiede zwischen EDI und EAI bestehen jedoch in organisatorischer Hinsicht dadurch, dass nicht ein einziges Management über alle betroffenen Systeme herrscht, sondern Rücksicht auf den jeweiligen Partner und seine individuelle Situation genommen werden muss. Zwischen den EDI-Partnern muss ein Vertrag geschlossen werden, der die Verbindlichkeit der ausgetauschten Daten und weitere Aspekte der elektronischen Kommunikation verbindlich festlegt. Auch müssen im Falle EDI eher größere Schwierigkeiten, bedingt durch die im Durchschnitt eher heterogene Infrastrukturen, Bedarf zusätzlicher Verschlüsselung, größere Entfernungen und/oder unterschiedliche Kompetenz und Motivation der beteiligten Personen, überwunden werden. Häufig wird die Zahl der erforderlichen Ansprechpartner durch die Einbeziehung von EDI-Service-Anbietern oder anderen IT-Dienstleistern noch größer. Institutionen, die EDI nutzen, sind vor allem größere Unternehmen, aber zunehmend auch kleine und mittlere Unternehmen sowie Behörden und andere Organisationen, wie Krankenkassen, Verbände und Vereine; nicht aber Privatleute.

Implikationen

Die obige Definition von EDI ist unabhängig von der Anwendung, der Branche und dem Standort der Beteiligten, den eingesetzten Produkten, Strukturen und Protokollen. Folglich ist es insbesondere kein Ausschlusskriterium für EDI, wenn das Internet oder XML-Strukturen für die konkrete Umsetzung verwendet werden, obwohl diese Meinung gelegentlich anzutreffen ist – zum Beispiel in Werbeaktionen für internetbasierte Datenaustauschprodukte, in denen suggeriert wird, das angeblich „teure EDI“ werde durch das einfache, billige Internet und insbesondere durch XML abgelöst. Dieser Gedanke ist aber falsch, weil die Herausforderungen (siehe unten) an EDI-Implementierungen immer in erster Linie fachlicher/geschäftlicher Natur sind, nicht werkzeug- oder technologieabhängig – und auch unabhängig davon, ob der Datenaustausch „EDI“ genannt wird oder nicht. Beispielsweise ist die semantische Klärung eines Begriffes wie „Lieferbedingung“ zwischen Kunde und Lieferant immer gleich aufwändig, unabhängig davon, ob nun eine XML-Nachricht oder eine EDIFACT-Nachricht verwendet wird.

Abgrenzung

Im Gegensatz zu EDI gibt es eine Reihe anderer Verfahren und Standards für den elektronischen Datenaustausch. Um EDI von einigen dieser Verfahren abzugrenzen, wird deshalb genauer von klassischem EDI gesprochen, im Gegensatz zum Beispiel zu WebEDI oder Internet-EDI. Allerdings wird selbst in der Fachwelt keine saubere Unterscheidung zwischen EDI als Überbegriff und zum Beispiel EDIFACT als konkreter Ausprägung gemacht. RosettaNet als neuer XML-Standard wird normalerweise nicht als EDI-Standard angesehen, wobei eine klare Abgrenzung schwierig ist.

Geschichte

  • Vermutlich wurde in den 1960er Jahren in den USA zum ersten Mal EDI eingesetzt. Es wurden Nachrichtenstrukturen für den konkreten Bedarf definiert, Standards gab es noch nicht. Die Übertragung der Daten erfolgte mit den damals verfügbaren Mitteln über Telefon- und Telex-Leitungen.
  • Das Aufkommen der Value Added Networks (VAN), privatwirtschaftlich betriebener Netzwerke, ermöglichte Institutionen durch einen einzigen Anschluss an das Netz anschließend EDI-Nachrichten mit allen an dem Netz beteiligten Partnern austauschen zu können. Außerdem wurde durch die Betreiber der Netze Beratung und Unterstützung angeboten.
  • 1977 wurde SEDAS als Standard-Nachrichtenformat für den Austausch von Rechnungen und Aufträgen (Bestellungen) im Konsumgüterhandel eingeführt.
  • Als erster bedeutender Nachrichtenstandard erschien 1978 die erste Nachrichtennorm für Lieferabrufe, die VDA 4905, erster Datenaustausch zwischen VW und Hella.
  • 1988: erste Verabschiedung des Nachrichtenstandards UN/EDIFACT durch die Vereinten Nationen (UN)
  • Das Aufkommen des Internets (des WWW) löste die E-Business-Euphorie aus. Das neue gemeinschaftliche Netz induzierte ganz neue Ideen für elektronischen Geschäftsdatenaustausch über bisherige Grenzen hinaus.
  • Elektronische Marktplätze, insbesondere B2B-Marktplätze, nutzten die Idee der Value Added Networks, diesmal unter Verwendung der neuen Möglichkeiten des Internets, erneut als Geschäftsmodell.
  • Es bildeten sich abgeschlossene Netzwerke für einzelne Branchen und Anwendungen unter Zuhilfenahme von Internet-Technologien. Bekannte Beispiele dafür sind RosettaNet, ANX und sein europäischer Ableger ENX.
  • Neue Initiativen wie ebXML, RosettaNet und neue Technologien wie Web-Services erweitern die Möglichkeiten der elektronischen Kommunikation zwischen Institutionen in Richtung synchroner Verfahren, die über EDI hinausgehen.

Grundidee und Potenzial

Der grundlegende und entscheidende Vorteil bei der Nutzung von EDI liegt in der hohen Geschwindigkeit der elektronischen Übertragung in Verbindung mit der Vermeidung menschlicher Fehler bei der Übertragung von Informationen von der einen zu der anderen Institution. Durch EDI wird es möglich, Geschäftsdaten interventionsfrei zwischen den Anwendungsprogrammen der beteiligten Partner auszutauschen. Daraus ergibt sich die maximale Rationalisierung eines Geschäftsprozesses wie zum Beispiel der Übermittlung einer Bestellung: Die Bestellung des Kunden ist fast augenblicklich, zuverlässig und exakt übereinstimmend als Auftrag im System des Lieferanten erfasst. Es entfällt die Postlaufzeit gegenüber der Verwendung von Papier und gegenüber Fax oder E-Mail entfällt die manuelle Erfassung des Auftrages im Lieferantensystem, ebenso wie die Nachbearbeitung einer Quote von fehlerhaft erfassten Aufträgen. EDI wird in aller Welt eingesetzt, in allen Branchen, für unterschiedlichste Anwendungen. Es ist trotz seiner für EDV-Verhältnisse langen Geschichte immer noch modern, seine Nutzung nimmt weiter zu.

Herausforderungen

Die Realisierung von EDI ist von den Voraussetzungen der beteiligten Partner abhängig. Da diese sehr unterschiedlich sein können und häufig auch gegenseitig unbekannt sind, ist die Realisierung immer ein Projekt. Es bestehen große Unterschiede zwischen EDI in der deutschen oder der japanischen Automobilindustrie, im Lebensmittelhandel in Spanien, im Interbankenverkehr in Österreich oder der amerikanischen Industrie.

Daher ist ein Projektmanagement erforderlich. In der Praxis wird dieser Punkt häufig unterschätzt, was zu langen Projektlaufzeiten, Budgetüberschreitungen und allseitiger Frustration führen kann. Grundsätzlich sind neben einer Projektorganisation zunächst organisatorische Absprachen aller Beteiligten erforderlich: Welche Geschäftsprozesse sollen durch EDI unterstützt werden, wie sind für diese Geschäftsprozesse ist und soll auf beiden Seiten definiert, was geschieht im Falle eines Fehlers?

Ein häufig nicht ausreichend betrachteter Punkt sind auch die notwendigen Stammdaten. Bei manueller Bearbeitung von Geschäftsprozessen sind viele Informationen über den Geschäftspartner und seine Gepflogenheiten „im Kopf“ der Bearbeiter vorhanden. Bei der Automatisierung über EDI stellt man dann häufig fest, dass Stammdaten im Anwendungssystem nicht vollständig vorhanden sind. Ein weiteres Problemfeld stellen zum Beispiel Materialnummern in logistischen Abläufen dar. Es tauchen Fragen auf, wie: Verwendet der Kunde die Materialnummer des Lieferanten oder seine eigene? Kennt der Lieferant die beim Kunden verwendete Materialnummer? Gibt es eine eindeutige Zuordnung zwischen Kunden- und Lieferantenmaterialnummern? Probleme in diesem Umkreis haben zum Beispiel in der Konsumgüterindustrie zur Entwicklung von EAN (später abgelöst durch GTIN) geführt, einem europaweiten System von Stammdaten für Artikel und Handelspartner.

Werden Unklarheiten im manuellen Prozess durch Rückfrage geklärt, so ist im automatischen Prozess dafür keine Chance. Alle Daten müssen vorab harmonisiert werden, sonst kann der automatische Prozess nicht funktionieren.

Hilfe bei der Harmonisierung der Stammdaten bietet der Stammdatenpool SINFOS (heute GDSN bzw. atrify) als ECR-Tool. Der Pool bietet einen multilateralen Stammdatenaustausch zwischen Lieferanten und Händler sowie umfangreiche Validierungsinstrumente.

Im technischen Teil des Projektes sind folgende Punkte zu erledigen:

  1. Vereinbarung von Struktur und Semantik der Nachricht
    Die Nachricht muss Byte für Byte exakt den Vorgaben und Vereinbarungen genügen, damit eine automatische Verbuchung im Empfängersystem möglich ist. Wichtige Einzelpunkte, die zu vereinbaren sind:
    1. Verwendung eines Standards wie EDIFACT, oder Entwicklung einer eigenen Struktur
    2. Identifikation/Bezeichnung von Sender und Empfänger
    3. Klärung von Eigenschaften und Semantik zu jedem Feld der Struktur
      Fast immer stimmen die Struktur der Nachricht, die das Sendersystem abgibt und die Struktur, die das Empfängersystem verarbeiten kann, nicht überein. Dann benötigt man mindestens einen weiteren Verarbeitungsschritt:
  2. Abbildung einer Struktur auf eine andere, das heißt Erstellung eines Mappings zur Konvertierung der Nachrichten
    Häufig verwendet man Standards, zum Beispiel EDIFACT, als Zwischenformat. Der Sender konvertiert seine Struktur, die vom Anwendungssystem vorgegeben ist, in EDIFACT. Der Empfänger konvertiert dann die EDIFACT-Nachricht in die Struktur, die sein Anwendungssystem „versteht“. Es werden also zwei Konvertierungen angewendet. Der Grund für die Verwendung eines standardisierten Zwischenformates liegt darin, dass es viel zu kompliziert wäre, jede individuelle Struktur aller möglichen Partner durch eine direkte Konvertierung zu erzeugen.
  3. Nachrichtentransport und -Verarbeitung
    Es muss bei einer sehr kleinen Fehlerquote gewährleistet werden, dass jede gesendete Nachricht den Empfänger einmal und nur einmal erreicht. Bei manchen Anwendungen ist dabei zusätzlich die Reihenfolge (Serialisierung) mehrerer Nachrichten einzuhalten oder es sind zusätzliche Schritte in Abhängigkeit von bestimmten Ereignissen oder Inhalten durchzuführen.
    1. eventuell Umsetzung Codierung/Codepage
    2. Verwendung von Übertragungsprotokoll und -medium
    3. Verwaltung der Parameter für Sender und Empfänger je nach Protokoll
    4. eventuell Komprimierung
    5. eventuell Verschlüsselung
    6. eventuell Signatur/Authentifizierung von Sender oder Empfänger
    7. eventuell Statusrückmeldungen über Verarbeitung und Versand an den Sender
  4. Notmaßnahmen bei Ausfall des Systems oder Teilen davon
    Speziell bei zentralen Systemen ist der Ausfall eines Systems vom Benutzer oft gar nicht leicht zu erkennen. Ausfälle können von einem lokalen Programmabsturz bis zu Leitungsschäden im öffentlichen Bereich zwischen den Partnern reichen. E-Mails können verloren gehen oder ausgefiltert werden, bevor der Empfänger diese erhält. Da es sich bei EDI oft um zeitkritische Anwendungen handelt bzw. ein Geschäftsprozess davon abhängt, ist es wichtig, Mechanismen vorzusehen, mit denen der jeweilige Partner über Probleme zeitnah informiert wird und Ersatzmaßnahmen treffen kann, die idealerweise bereits vorher miteinander vereinbart werden.

Abrechnung im EDI-Verfahren

Das EDI-Verfahren wird auch immer häufiger im Bereich der elektronischen Abrechnung eingesetzt, da hier mitunter hohe Einspareffekte erzielt werden können. Während einer Studie der Europäischen Kommission zufolge die herkömmliche Papierrechnung Kosten von EUR 16,60 verursacht, lassen sich die Kosten durch Abrechnung im EDI-Verfahren um über 70 Prozent senken. Bei deutschlandweit rund sechs Milliarden Rechnungen im Jahr, von denen bislang lediglich sechs Prozent elektronisch versandt werden, ist das ein Einsparvolumen von rund 60 Milliarden Euro pro Jahr. Bei der Abrechnung in elektronischer Form sind jedoch die umsatzsteuerlichen Anforderungen des § 14 Abs. 3 UStG zu beachten. Hier stehen verschiedene Umsetzungsvarianten zur Auswahl. Eine häufige Umsetzungsvariante ist das sogenannte EDI-Verfahren, das auf einer EDI-Vereinbarung zwischen Rechnungsersteller und Rechnungsempfänger basiert zur Anerkennung des Vorsteuerabzuges.

Aufgaben eines EDI-Systems

Für die laufende Verarbeitung, den Transport und gegebenenfalls die Konvertierung der Nachrichten und Statusmeldungen, also die Ausführung der EDI-Funktionalitäten gemäß den Punkten 2 und 3 wie oben beschrieben, ist auf Seiten des Senders und des Empfängers jeweils ein EDI-System oder ein EDI-Dienstleistungsunternehmen erforderlich.

Einschränkungen

Gleichartigkeit
Die volle Automatisierung, welche die Grundidee des EDI ist, lässt sich ideal erreichen, wenn die Datensendevorgänge möglichst gleichartig sind. Häufig wird EDI daher in Prozessen der produktionsrelevanten Logistik, also zum Beispiel für Abrufe von Rohmaterialien, die über Monate oder Jahre immer gleich sind, genutzt. Auch Banken tauschen untereinander und mit ihren Geschäftskunden vielfach Transaktions- oder Kontostandsdaten per EDI aus. Dagegen sind beispielsweise Prozesse mit Bezug auf ständig wechselnde Güter, mit wechselnden Materialnummern oder etwa täglich schwankenden Preisen, nur bedingt tauglich. Auch Prozesse wie Ausschreibungen und Auktionen mit vorher unbekannten Geschäftspartnern lassen sich allein mit EDI nicht abbilden.
Mindestanzahl
EDI stellt ein hohes Maß von Integration der beteiligten Systeme dar. Es entstehen ein gewisser einmaliger Aufwand für die Herstellung dieser Integration sowie laufende Aufwände für den Betrieb des EDI-Systems. Diese Faktoren sind relativ unabhängig von der Anzahl der Übertragungen. Die Kosten der Implementierung und des laufenden Betriebs einer EDI-Anwendung sind nicht mit einem Faktor Hundert verbunden, je nachdem, ob später Zehn oder Tausend Übertragungen pro Tag stattfinden. Die Optimierungspotentiale korrelieren dagegen direkt mit der Anzahl der Datensendevorgänge. Je mehr Vorgänge betroffen sind, desto höher der Nutzen und desto eher lohnt sich der Einsatz von EDI. Für einen wirtschaftlichen Einsatz muss also eine Mindestanzahl von Übertragungen pro Partner gegeben sein.
Vielfältigkeit
Die Normen lassen ein weites Spektrum innerhalb jedes Geschäftsfalles zu. Dabei wird von jedem Anwender ein anderer Teil des Spektrums ausgenutzt. Dabei kommt es meist auf die wirtschaftliche Stärke eines Partners an, wie die Vereinbarung der Nachrichten aussieht. So geben in der Regel die Automobilhersteller gegenüber ihren Lieferanten den jeweiligen Dateninhalt an. Die Zulieferer hingegen müssen bei einer größeren Kundenzahl sehr flexibel reagieren, um alle Kunden zufriedenzustellen, was andererseits oft wieder eine Verteuerung des Systems darstellt.

Nachrichtenstandards

Damit EDI-Nachrichten vom Empfänger verarbeitet werden können, müssen sie einer vorher bekannten Struktur („Austauschformat“) entsprechen. Es gibt weltweit unzählige verschiedene Strukturen für EDI-Nachrichten. Einige wichtige Standards werden im Folgenden aufgelistet:

  • SWIFT – für Banken
  • UN/EDIFACT – der umfassendste und weltweit gebräuchlichste Standard, wird von der Wirtschaftskommission für Europa (UN/ECE) der Vereinten Nationen verantwortet. Innerhalb EDIFACT gibt es branchenspezifische Subsets wie z. B. EDIFICE und EANCOM
  • ANSI ASC X12 – hauptsächlich in den USA verbreiteter Standard
  • GTDI (Guidelines for Trade Data Interchange) – ein von der UN/ECE in Genf entwickeltes und in Großbritannien heute noch stark vertretenes Standardformat. Es war gemeinsam mit ANSI ASC X12 die Basis für UN/EDIFACT.
  • VDA – Standard der deutschen Automobilindustrie. Es findet keine Weiterentwicklung mehr statt. Ersatz sind EDIFACT-Nachrichten.
  • GAEB – für das Bauwesen (Gemeinsamer Ausschuss Elektronik im Bauwesen)
  • ODETTE – Standard der europäischen Automobilindustrie. Es existieren noch Odette-eigene Formate. Heute werden Neuentwicklungen nur noch auf Basis der EDIFACT-Syntax entwickelt und veröffentlicht.
  • GALIA – Automobilstandard vor allem in Frankreich, sehr ähnlich ODETTE
  • ebXML – offener Standard von OASIS und CEFACT
  • Fortras – für den Datenaustausch zwischen Speditionen
  • XBRL – Finanzberichterstattung
  • railML – Offenes Datenaustauschformat im Bahnsektor für Fahrpläne, Zugskompositionen und Streckenmerkmale
  • RosettaNet – Ein Non-Profit-Konsortium, an dem sich über 600 Firmen vorwiegend aus der Elektronikbranche beteiligen. Ziel ist die Entwicklung und Einführung von offenen e-Business-Standards und -Services in der Industrie.
  • myOpenFactory – deutscher Standard für den elektronischen Datenaustausch zur überbetrieblichen Auftrags- und Projektabwicklung
  • openTRANS – Transaktionsstandard zum Austausch von Geschäftsdokumenten wie zum Beispiel Rechnung, Bestellung oder Lieferavis und Zahlungsavis. Es gibt für jede Dokumentenart eine Spezifikation.
  • UNIDOC – XML-Standard zum Austausch von Geschäftsdokumenten aller Art, mit der Besonderheit, dass für alle Dokumentenarten dieselbe Datenstruktur verwendet wird.

Darüber hinaus gibt es unzählige nationale, produkt- oder branchenspezifische Nachrichtenstandards sowie Standards im Rahmen von Marktplätzen und VANs wie

  • SEDAS für den Konsumgüterhandel
  • e-CODEX für den grenzüberschreitenden Zugang zu Recht und Justiz
  • xCBL – XML Common Business Library (xCBL), ursprünglich von Commerce One definiert
  • Datenträgeraustauschverfahren (DTA): Standard zur Übermittlung von Zahlungsaufträgen an ihre Banken (in Deutschland)
  • ELSTER: Die Elektronische Steuererklärung der deutschen Finanzverwaltungen
  • E-Rates: Übermittlung von Luftfrachtraten der Fluggesellschaften an Luftfrachtspeditionen
  • eXTra-Standard: Bundesstandard des BMWi, wird z. B. als alleiniger Übertragungsstandard für Arbeitgeber-Meldungen in der deutschen Sozialversicherung genutzt

Übertragungsprotokolle

Für EDI ist erforderlich, die Nutzdaten vom Sender über eventuelle Zwischenstellen zum Empfänger zu transportieren. Dazu gibt es eine Vielzahl von Netzwerkprotokollen, von denen hier einige besonders gebräuchliche aufgezählt werden:

Ältere EDI-Übertragungsprotokolle

  • X.400 E-Mail-Standard der ITU
  • OFTP Odette File Transfer Protocol 1, kann auf ISDN, TCP/IP, X.25 oder X.31 aufsetzen
  • FTAM File Transfer Access and Management

Außerdem sind einige Protokolle aus der Internetprotokollfamilie gebräuchlich, vor allem:

  • SMTP Simple Mail Transfer Protocol
  • HTTP / HTTPS Hypertext Transfer Protocol
  • FTP / SFTP File Transfer Protocol

Auf den Internetprotokollen basierend gibt es Kommunikationsstandards, die neben dem reinen Datentransport zusätzliche Eigenschaften wie Verschlüsselung, Authentifizierung und Komprimierung beinhalten. Beispiele dafür sind:

  • AS1 Internet EDIINT Protokoll (Applicability Statement 1) (SMTP)
  • AS2 Internet EDIINT Protokoll (Applicability Statement 2) (HTTP)
  • AS3 Internet EDIINT Protokoll (Applicability Statement 3) (FTP)
  • AS4 (Applicability Statement 4), basiert auf AS2 und ebMS 3.0
  • EBICS Electronic Banking Internet Communication Standard (HTTP)
  • OFTP2 Odette File Transfer Protocol 2.

Bei den älteren Protokollen wird meist auf eine Verschlüsselung verzichtet, weil entweder eine Punkt-zu-Punkt-Verbindung genutzt wird oder dem Netzwerk vertraut wird. Bei Nutzung des Internets wird dagegen meist eine Verschlüsselung eingesetzt. Die EDIINT Protokolle können dabei sowohl die Leitung als auch die Datei verschlüsseln. Eine Komprimierung ist ebenfalls mit den EDIINT-Protokollen möglich. Darüber hinaus gibt es eine unbekannte Anzahl nationaler, produkt- oder branchenspezifischer Protokolle oder Kommunikationsstandards, etwa im Rahmen von Marktplätzen und VANs.

Siehe auch

Weblinks

Einzelnachweise

  1. ↑ G. Nöcker: Die beleglose Spedition. 2002, S. 11.
  2. ↑ RFC3335 – MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet. September 2002 (englisch).