UN/EDIFACT
UN/EDIFACT steht als Abkürzung für “United Nations Electronic Data Interchange for Administration, Commerce and Transport” und gibt damit einen ersten Hinweis darauf, dass es sich bei diesem Format de facto um den einzig wirklich international gültigen EDI-Standard handelt, der darüber hinaus alle Branchen adressiert, in denen der EDI-Datenaustausch eine ernstzunehmende Rolle spielt.
Stete Verbesserung der Datenqualität durch regelmäßige neue Versionierungen
Bei EDIFACT handelt es sich zwar um einen global gültigen EDI-Standard, dieser unterliegt jedoch einer alternierenden Versionierung, so dass unter dem Dach UN/EDIFACT unterschiedliche Varianten subsummiert werden, die nach Jahrgängen differenziert werden. Pro Jahr werden so zwei unterschiedliche Varianten durch das den Vereinten Nationen angegliederte CEFACT-Board veröffentlicht. Neben der Jahreszahl der Veröffentlichung werden diese Varianten durch den Zusatz A (Veröffentlichung 1. April) und B (Veröffentlichung 1. Oktober) gekennzeichnet (z.B. D.96A, D.01B, D.07A etc.). Generell steigt mit jeder Veröffentlichung eines neuen EDIFACT-Verzeichnisses (= EDIFACT-Version) die Anzahl der inkludierten EDIFACT-Nachrichtentypen und die mögliche Bandbreite der zu übertragenden Informationen in Form von EDIFACT-Datenelementen. Dieser Umstand ist hauptursächlich dafür, dass es in bestehenden EDI-Anbindungen mit großen Marktteilnehmern im Abstand von 3-6 Jahren die Aufforderung gibt, auf eine neuere EDIFACT-Version zu wechseln, wie beispielsweise der Wechsel von D.96A auf D.01B im Zuliefererbereich der EZHG. Damit verbunden ist folglich nicht nur eine Änderung des EDIFACT-Austauschformats, sondern auch eine Ausweitung der semantischen Datenumfangs, also eine Verbesserung der EDI-Datenqualität.
Die Aufforderung, einen Wechsel auf eine neuere EDIFACT-Version vorzunehmen, ist oftmals allerdings auch gleichbedeutend mit einem kompletten EDIFACT-Formatwechsel innerhalb einer bestehenden EDI-Anbindung. Die EDI-Technologie der Mehrzahl der am Markt agierenden EDI-Anbieter ist als Flatfile-Konverter konzipiert, der mit IF-THEN-ELSE-Mechanismen eine starre Punkt-zu-Punkt Verbindung zwischen dem Ex- und Importformat der ERP-Schnittstelle und dem EDI-Format des Partners abbildet. Daher kommt diese Anforderung meist einer kostenintensiven Neuimplementierung einer bestehenden EDI-Anbindung gleich.
Einfacher Wechsel auf neue EDIFACT-Versionen mit Softzoll
Die Technologie der Softzoll EDI-Systeme nutzt zur Konvertierung die Original EDIFCAT-Regelwerke des UN/EDIFACT-Boards. Über eine Schnittstelle können die einzelnen EDIFACT-Jahrgänge und Versionen als *.xsd-Schemata in die zugrundeliegende EDI-Software importiert werden. Innerhalb kürzester Zeit wird dadurch eine neue Blaupause für die entsprechende EDIFACT-Version aktiviert. Diese EDIFACT-Rulesets stehen on demand als Komponente innerhalb eines partnerspezifischen EDI-Workflows zur Verfügung. Softzoll kann auf Basis dieser EDI-Technologie seinen Kunden benötigte EDIFACT-Regelwerke nicht nur kostenfrei zur Verfügung stellen, sondern tauscht bei einem Wechsel auf ein anderes EDIFACT-Format mit einem Mausklick lediglich das passende Regelwerk aus. Dies führt zu einer erheblichen Aufwandsreduktion bei den EDI-Folgekosten und beschränkt die nötigen Arbeiten auf die ggf. zusätzlich zu inkludierenden EDI-Datenelemente und deren Verarbeitung via ERP-Schnittstelle.
EDIFACT Subsets zur branchenspezifischen Standardisierung
Ferner ist zu berücksichtigen, dass innerhalb einzelner Branchen zusätzlich sogenannte EDIFACT-Subsets definiert werden. Dabei handelt es sich um Teilmengen eines EDIFACT-Verzeichnisses, bei denen besonderes Augenmerk auf der inhaltlichen Ausprägung einer EDIFACT-Variante liegt. Auf diese Weise wird versucht, für die betreffende Branche eine weitere Standardisierung zu erreichen – quasi einen branchenspezifischen Standard. Dadurch erhofft man sich eine Vereinfachung der EDI-Anbindungen zwischen den involvierten EDI-Austauschpartnern einer Branche zu ermöglichen.
Positives Beispiel für gelungene Standardisierung: EDITEC
Ein erwähnenswertes Beispiel für die gelungene Standardisierung einer EDIFACT-Kommunikation innerhalb einer Branche ist das EDIFACT-Subset EDITEC. Zwar existiert das EDITEC-Subset in verschiedenen Versionen (EDITEC 2.2, EDITEC 3.0, EDITEC 4.0 etc.), jedoch wurde innerhalb dieser Versionen darauf geachtet, dass der inhaltliche Umfang der in diesen Versionen inkludierten EDIFACT-Datenelemente in einer Maximalausprägung genau definiert wurde. Dies hat den Effekt, dass alle innerhalb des EDITEC-Subsets definierten EDIFACT-Nachrichtentypen (z.B. ORDERS, DESADV, REMADV etc.) je Version identisch sind. Die technische EDI-Implementierung einer auf EDITEC basierenden EDI-Anbindung ist somit reproduzierbar und damit für die Anbindung weiterer Partner wiederverwendbar.
EDIFACT-Nachrichtentypen
Ein weiteres wichtiges Charakteristikum des EDIFACT-Formats ist die Untergliederung einer EDIFACT-Version in einzelne EDIFACT-Nachrichtentypen. Die im EDIFACT-Standard abgebildeten Nachrichtentypen repräsentieren zum Teil branchentypische, aber auch branchenübergreifende EDI-Geschäftsprozesse. Die Benamung und Intention der einzelnen EDIFACT-Nachrichtentypen erinnern daran, dass oftmals der korrespondierende Papierbeleg als Quelle eines EDI-Geschäftsprozesses gedient hat. Bedeutung und Unterscheidung einzelner Nachrichtentypen sind grundlegend für das Verständnis des modernen EDI-Datenaustauschs, aus diesem Grund widmet Softzoll diesem Teilbereich eine eigenständige Betrachtung.
Ein bisschen was zur Syntax von EDIFACT-Nachrichten
Der syntaktische Aufbau einer EDIFACT-Nachricht wird oft mit einem Briefkuvert verglichen. Der Anfang einer EDIFACT-Nachricht wird von einem UNB-Segment gebildet. In diesem UNB-Segment werden Absender und Empfänger definiert. Um diese Identifikation möglichst eindeutig und gleichzeitig maschinenlesbar zu gestalten, hat sich hier die Verwendung von Identifikationsnummern durchgesetzt, die diese Angaben in codierter Form darstellen. Da die EDI-Datenaustausche im Zuge der Globalisierung zunehmend internationalisiert werden, nutzen viele EDI-Anwender an dieser Stelle eine GLN-Nummer (Global Location Number), die weltweit einmalig ist und der zweifelsfreien Zuordnung der am EDI-Datenaustausch Beteiligten dient (Firmen, Werksstandorte etc.). Zusätzlich werden im UNB-Segment Informationen zu Zeitangaben und Prüfelementen übertragen, mit deren Hilfe eine EDIFACT-Nachricht auf seine Konsistenz geprüft werden kann. Optional kann dem UNB-Segment ein UNA-Segment vorangestellt sein, in dem eine
Trennzeichendefinition für Segment-, Element- und Dezimaltrennzeichen erfolget. Das Ende einer EDIFACT-Nachricht bildet das UNZ-Segment; es umschließt zusammen mit dem UNB die eigentliche EDIFACT-Nachricht mit den Detailinhalten des betreffenden Geschäftsprozesses.
Auf die technischen Details der EDIFACT-Syntax soll an dieser Stelle nicht weiter eingegangen werden, entsprechende Ausführungen finden sich auf nahezu allen Seiten des Internets, die sich mit der EDI- und EDIFACT-Thematik befassen. Ein grundlegendes Verständnis der EDIFACT-Syntax und seiner fachgemäßen Anwendung kann allerdings nur durch langjährige Praxis gewährleitet werden. Für das Verständnis genügt es zu wissen, dass sich eine EDIFACT-Nachricht aus Segmenten zusammensetzt, deren einzelne Datenelemente sich über standardisierte Abkürzungen und Codelisten definieren. Der Inhalt eines Datenelements kann auf diese Weise exakt beschrieben werden und ermöglicht so das Verständnis und die automatisierte Verarbeitung einer EDIFACT-Nachricht über Sprachbarrieren und Ländergrenzen hinweg.
Im EDI-Alltag steckt der Teufel oftmals im Detail
Darüber hinaus sind die einzelnen Segmente und Datenelemente einer EDIFACT-Nachricht Beschränkungen hinsichtlich der maximalen Verwendbarkeit innerhalb einer Übertragungsnachricht unterworfen; auch die zur Qualifizierung eines Nachrichteninhalts eingesetzten Codes sind genau vorgegeben. Oftmals sind die Inhalte einer EDIFACT-Nachricht zusätzlich in Muss– und Kann-Elemente unterteilt. Diese Unterscheidung hilft v.a. bei der Anbindung und Integration von am EDIFACT-Datenaustausch beteiligten Quell- und Zielsystemen bzw. bei der Vermeidung unnötiger Aufwändungen im Zuge von EDI-Integrationsprojekten.
Nicht immer sind die im Standard formulierten Einschränkungen auch für die EDI-Praxis tauglich. Nicht zuletzt aus diesem Grund gibt es etliche Anwendungsszenarien, in denen Absender und Empfänger für einen praktikablen Ablauf des EDI-Datenaustausches die EDIFACT-Rahmenparameter untereinander bilateral gemäß den in situ-Erfordernissen definieren. Diese bilateralen Absprachen bilden oft die Keimzelle der o.a. brancheninternen EDIFACT-Varianten bzw. Subsets.
This post is also available in EN.