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.
Datenaustausch mit einem SAP®-System
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
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
© 2020. SAP SE oder ein SAP-Konzernunternehmen. Alle Rechte vorbehalten. Mit Genehmigung der SAP SE verwendet.
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
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.
© 2020. SAP SE oder ein SAP-Konzernunternehmen. Alle Rechte vorbehalten. Mit Genehmigung der SAP SE verwendet.
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
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.
SAP ERP und SAP S/4HANA sind die Marken oder eingetragenen Marken der SAP SE oder ihrer verbundenen Unternehmen in Deutschland und mehreren anderen Ländern.
