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.

© 2020. SAP SE oder ein SAP-Konzernunternehmen. Alle Rechte vorbehalten. Mit Genehmigung der SAP SE verwendet.

Themen

Meistgelesen

Weiterlesen

7 min Lesezeit

XML-Checker in das ERP-System integrieren – warum und wie?

Welche Vorteile bringt die Integration eines XML-Checkers direkt in das ERP-System des Unternehmens? Das und wie die Umsetzung funktioniert lesen Sie in diesem Artikel.

2 min Lesezeit

Wie kann ich einen SAP-Transaktionscode anlegen?

Wie kann ich für ein bestehendes ABAP-Programm einen SAP-Transaktionscode anlegen, damit ich das Programm einfach aufrufen kann? Wir stellen im Folgenden eine kurze Anleitung vor.

10 min Lesezeit

EDI-Onboarding von Lieferanten in 7 Schritten

Das EDI-Onboarding von Lieferanten muss nicht kompliziert sein. In diesem Artikel zeigen wir Ihnen 7 Schritte zur erfolgreichen Lieferantenanbindung.

2 min Lesezeit

ecosio am DSAG-Thementag „X&E-Rechnung mit SAP“

Der DSAG lädt zum Thementag "X&E-Rechnung mit SAP" mit einem praxisnahen Vortrag zur Umsetzung von XRechnung mit ecosio und Philipp Liegl.

9 min Lesezeit

Wie setze ich EDI mit SAP PI und SAP PO um?

In diesem Artikel zeigen wir Ihnen die drei Möglichkeiten, elektronischen Datenaustausch (EDI) in SAP Process Integration bzw SAP Process Orchestration (SAP PI/PO) im Unternehmen umzusetzen.

4 min Lesezeit

Aufbau einer ANSI ASC X12-Datei

Wie sehen Aufbau und Segmente einer ANSI ASC X12-Datei im Detail aus? Was hat es mit dem Interchange Control Header auf sich? Und wie können mit Repeating Data Elements EDI-Nachrichten...

5 min Lesezeit

Wie kann ich einen Eintrag zu einer SAP-Tabelle hinzufügen?

Wir zeigen im folgenden Artikel, wie man mit einer paar einfachen Handgriffen Einträge zu einer bestehenden SAP-Tabelle hinzufügen kann – auch wenn diese über keinen eigenen Pflegedialog verfügt.

6 min Lesezeit

EDI via API – die beste Lösung für mein Unternehmen?

API-Integration unterscheidet gute EDI-Lösungen von ausgezeichneten EDI-Lösungen. Finden Sie heraus, warum!

8 min Lesezeit

Was eine EDI-Implementierung wirklich braucht

Wie komplex ist eine EDI-Implementierung wirklich? Dieser Artikel klärt Sie über die einzelnen Schritte auf.

7 min Lesezeit

Ist Web EDI der Schlüssel zu optimierter Lieferantenanbindung?

Wie kann intelligentes Web EDI die üblichen Probleme in der Lieferantenanbindung lösen? Erfahren Sie, welche Vorteile Web EDI bringt.

Webinar - Die Vorteile einer Fully Managed EDI-Lösung für neue und bestehende EDI-ProzesseJetzt anmelden!
+

Wir verwenden Cookies, um ein optimales Website-Erlebnis zu bieten. Sie entscheiden, welche Sie zulassen möchten. Je nach Einstellung stehen Ihnen aber womöglich nicht alle Funktionalitäten zur Verfügung. Datenschutzhinweise & Impressum.