Chat with us, powered by LiveChat
7 min Lesezeit

Warum IDoc kein gutes EDI-Format ist

Datenaustausch mit einem SAP-System

Eines gleich vorweg — in diesem Beitrag geht es nicht darum das SAP IDoc-Format schlecht zu reden. Im Gegenteil — wenn man mit einem SAP-System arbeitet, ist das IDoc-Format eine große Hilfe, denn es dient als zentrales Austauschformat zum Exportieren und Importieren von Geschäftsdokumenten aus und in ein SAP-System. Auf was wir im Folgenden eingehen möchten, sind die potentiellen Nachteile die sich ergeben können, wenn man das IDoc-Format als EDI-Format einsetzt und es auf die selbe Stufe wie EDIFACT, ANSI X12 etc. hebt.

Die folgende Abbildung veranschaulicht das bei IDocs zur Anwendung kommende Prinzip. Über definierte Schnittstellen im SAP-System, wie zum Beispiel eine Dateischnittstelle oder den EPO Connector, können IDoc-Dokumente mit dem SAP-System ausgetauscht werden.


IDoc-Austausch mit einem SAP-System
IDoc-Austausch mit einem SAP-System

IDocs gibt es dabei in zwei unterschiedlichen Varianten — in einer textbasierten älteren Variante und in einer neueren XML-basierten Darstellung. Für die XML-basierte Darstellung stellt SAP auch die entsprechenden XML-Schemata zur Verfügung, die wir bereits in einem früheren Beitrag vorgestellt haben. Die folgende Abbildung zeigt die Struktur eines ORDERS01-IDocs, also einer Bestellung.


Ausschnitt eines ORDERS IDoc XML-Schema
Ausschnitt eines ORDERS IDoc XML-Schema

IDoc-Dokumente können nach dem Export an andere unternehmensinterne Anwendungen übergeben werden oder für die Kommunikation mit anderen Geschäftspartnern verwendet werden. Die direkte Weitergabe von IDoc XML-Instanzen an andere Geschäftspartner kann jedoch problematisch sein.

Warum ist ein IDoc für EDI nicht gut geeignet?

Nehmen wir im Folgenden an, dass für die Kommunikation von Bestell- und Rechnungsdaten IDocs verwendet werden sollen. Anstatt mit Papierbelegen zu arbeiten, soll die Geschäftsinformation mit den einzelnen Geschäftspartnern somit automatisch ausgetauscht werden.


Kommunikation mit verschiedenen Geschäftspartnern
Kommunikation mit verschiedenen Geschäftspartnern

Die Problematik lässt sich bereits an den fünf exemplarischen Geschäftspartnern auf der rechten Seite erkennen.

IDoc ist ein SAP-spezifisches Format

Nicht alle der Geschäftspartner haben SAP im Einsatz, wodurch die nahtlose Übernahme des IDoc-Dokuments in das ERP-System des Geschäftspartners schwierig wird. Selbst wenn der Geschäftspartner ein SAP-System im Einsatz hat, ist eine Übernahme des IDoc-Dokuments nicht gewährleistet, da IDocs in unterschiedlichen Versionen vorliegen können. Unterstützt der Geschäftspartner nur ein älteres IDoc-Format, so ist eine Datenübernahme nicht möglich.

Bei anderen ERP-Systemen, wie Mesonic oder BMD, kommt man um eine Dokumentenkonvertierung in das Importformat des Geschäftspartners nicht umher. Größere Geschäftspartner, wie beispielsweise EDEKA, setzen zur Kommunikation mit Geschäftspartnern ausschließlich auf den Einsatz von EDI auf Basis von EDIFACT. Eine direkte Übergabe von IDocs ist hier nicht möglich. Noch schwieriger wird die Integration von Services von Dritten — zum Beispiel mit Hilfe von RESTful Web Services. Hier müssen die Formate verwendet werden, welche das RESTful Service akzeptiert. Wenn man Glück hat, ist IDoc dabei. Ein Blick auf moderne Service-Interfaces zeigt jedoch, dass zumeist JSON oder andere XML-basierte Konzepte als IDoc zum Einsatz kommen.

IDocs sind interne Formate mit internen Daten

Ein IDoc-Export aus einem SAP-System enthält die gesamten Nutzdaten eines bestimmten Belegtyps – z.B. einer Bestellung. Dies inkludiert SAP-interne Dinge im EDI_DC40-Element, wie beispielsweise den Verarbeitungsstatus, interne Partnernummern, Portdefinitionen usw. Unter Umständen will man aber nicht den gesamten Umfang dieser Informationen an den externen Geschäftspartner weitergeben. Im Gegenteil — im Normalfall bildet das Unternehmen eine Facade (dt. Fassade) und reicht durch diese Fassade nur jene Dinge nach außen, welche für die Geschäftspartner relevant sind. Umgekehrt werden durch diese Fassade auch nur relevante Dinge nach innen gereicht.

Der Ausdruck der Fassade ist hier dem Software-Engineering entnommen — im Zusammenhang mit Unternehmen spricht man eher von einer API. Eine API ist dabei eine Schnittstelle, die über ein Netzwerk ansprechbar ist und über die bestimmte Services für Geschäftspartner zur Verfügung gestellt werden.

In ihrer einfachsten Form ist eine API ein Geschäftsdokument, welches ein Unternehmen einem anderen Unternehmen zur Verfügung stellt. Unabhängig von der Einfachheit gelten hier jedoch die selben Regeln wie bei einer regulären API — es werden keine unnötigen internen Details weiterkommuniziert.

IDocs fehlen EDI-spezifische Segmente

Die Übermittlung von EDI-Nachrichten zwischen verschiedenen Geschäftspartnern nennt man Routing. Für das Routing von EDI-Nachrichten muss ein EDI-Dokumentenformat bestimmte Anforderungen erfüllen.

So muss es beispielsweise auf Basis des EDI-Dokumentenformates möglich sein zu bestimmen:

  • Wer ist der Sender der Nachricht?
  • Wer ist der Empfänger der Nachricht?
  • Um welchen Nachrichtentyp handelt es sich?
  • Ist die Nachricht eine Testnachricht?
  • Wie ist die eindeutige ID der Nachricht?
  • Wann wurde die Nachricht erzeugt?

Obwohl sich einige dieser Fragen mit den Daten im EDI_DC40-Element beantworten lassen, ist beispielsweise die Identifikation von Sender und Empfänger problematisch. Im SAP-Export finden sich hier zumeist die internen Partnernummern, welche jedoch im EDI-Betrieb ungeeignet sind. Hier kommen keine anwendungsinternen Nummern zur Anwendung ,sondern global eindeutige und überschneidungsfreie Nummern, wie zum Beispiel GLN oder DUNS-Nummern.

IDocs verwenden interne Qualifier

Eine zentrale Problematik beim Austausch vom Daten im Rahmen des elektronischen Datenaustausches ist die Verwendung von Qualifiern und von Maßeinheiten.

Qualifier sind Zeichenketten, die zur Identifikation der Bedeutung einer anderen Zeichenkette dienen. z.B. deutet der Qualifier 14 an, dass es sich bei der Nummer 4260304620007 in einem UNB-Segment um eine GLN handelt. Festgelegt wird dies in einem entsprechenden Standard — zum Beispiel im EDIFACT-Standard.

Maßeinheiten dienen dazu die Einheit einer numerischen Angabe festzulegen, z.B. Liter. In den meisten Fällen werden jedoch auch hier normierte Qualifier verwendet, wie z.B. LTR (Liter), LD (Liter pro Tag) etc. Auch dies ist in entsprechenden Standards, wie EDIFACT festgehalten.

Auch im IDoc-Format werden Qualifier eingesetzt, wie z.B. der folgende Ausschnitt zeigt. Abgebildet sind in diesem Fall Qualifier für die Partnerrolle, die ein bestimmter Geschäftspartner im Rahmen einer IDoc-Nachricht einnehmen kann.


SAP-spezifische Qualifier
SAP-spezifische Qualifier

Diese Angaben sind SAP-spezifisch und müssen vor der Übernahme in ein externes Drittsystem entsprechend in die entsprechenden Zielqualifier übersetzt werden.

IDocs liegen in unterschiedlichen Versionen vor

Wie schon eingangs erwähnt, liegen IDocs auch in unterschiedlichen Versionen vor, die nicht notwendigerweise untereinander kompatibel sein müssen. Die Versionsunterschiede können sich dabei durch das Alter des SAP-Systems ergeben. Exportformate aus einem neueren System können nicht einfach 1:1 in ein älteres SAP-System übernommen werden.

Zum anderen verwenden viele Unternehmen neben den Standard-Elementen in IDocs auch noch unternehmensspezifische Erweiterungen (so genannte Z-Extensions). Diese Extensions sind unternehmensspezifisch und können von anderen Unternehmen nur nach Umsetzung von Anpassungen in deren eigenem SAP-System übernommen werden.

Zuletzt bleibt noch ein weiteres, vermeidbares und dennoch weit verbreitetes Problem. Werden Datenfelder im ERP-System missbräuchlich verwendet (z.B. Speichern von Freitextbemerkungen in einem Feld, in welchem eine GLN-Nummer gespeichert werden soll), so ist auch der Datenexport entsprechend unsauber. Dies ist aber nicht IDoc-spezifisch, sondern kann in jedem ERP-System auftreten.

Wie Abhilfe schaffen?

SAP IDocs sind die Technologie der Wahl, wenn es um die Datenübernahme in und aus einem SAP-System geht. Im Falle von EDI kommen jedoch andere, besser geeignete Standards zum Einsatz. Dass aber auch hier IDocs eine absolute Notwendigkeit sind, zeigt die folgende Abbildung.


Einsatz von IDocs in einem EDI-Szenario
Einsatz von IDocs in einem EDI-Szenario

Geschäftsdokumente werden im IDoc-Format aus dem SAP-System exportiert und an einen EDI-Dienstleister übergeben. Dieser übersetzt die Daten in ein einheitliches plattformunabhängiges EDI-Format (z.B. EDIFACT) und stellt die Daten an den EDI-Dienstleister des Geschäftspartners zu.

Der EDI-Dienstleister des Geschäftspartners wandelt die erhaltenen EDIFACT-Daten in das Importformat des Ziel-ERP-Systems um, sodass diese importiert werden können. Die gesamte Kommunikation funktioniert dabei auch in die andere Richtung.

Wie aus dieser Abbildung hervorgeht, sind Import- und Exportformate wie IDoc unabdinglich für EDI-Verbindungen. Jedoch sind sie nicht optimal für den direkten Einsatz bei EDI-Verbindungen zwischen Unternehmen geeignet.

Noch Fragen zum Thema EDI und IDocs?

Sie haben noch Fragen zum Thema EDI und IDocs? Nehmen Sie mit uns Kontakt auf oder benutzen Sie unseren Chat — wir helfen Ihnen gerne bei allen Fragen rund um SAP, EDI und IDocs weiter.

Themen

Meistgelesen

Weiterlesen

Cookie Einstellungen

Hier sind alle Cookies aufgelistet die für Marketing Zwecke eingesetzt werden
LinkedIn (cn_LinkedINActive)
LinkedIn verwendet Cookies unter anderem um Ihre Einstellungen zu nutzen, Ihnen eine personalisierte Nutzererfahrung bieten zu können, und Ihnen auf Sie zugeschnittene Werbung anzeigen zu können.
Google Analytics (cn_AnalyticsActive)
Wird verwendet um Daten über das Nutzerverhalten und das Gerät des Nutzers an Google Analytics zu senden. Trackt den Besucher über verschiedene Geräte und Marketing Kanäle
Facebook (cn_FacebookActive)
Wird von Facebook genutzt, um eine Reihe von Werbeprodukten anzuzeigen, zum Beispiel Echtzeitgebote dritter Werbetreibender.
Google Adwords (cn_AddWordsActive)
Wird verwendet um Benutzer zu identifizieren, die die Website via Google Werbeanzeigen besuchen.
Pardot (cn_PardotActive)
Pardot verwendet Cookies, um Ihre Interaktion mit unserer Website sinnvoller zu gestalten. Sie helfen uns, die Nutzung unserer Websites besser zu verstehen, damit wir die Inhalte für Sie maßschneidern können.