SAP IDoc einfach erklärt: Aufbau, Verarbeitung, EDI und Monitoring

Ein SAP IDoc gehört seit vielen Jahren zu den wichtigsten technischen Grundlagen für den automatisierten Datenaustausch in SAP-Landschaften. Bestellungen, Auftragsbestätigungen, Lieferavise, Rechnungen und Stammdaten können mithilfe von IDocs strukturiert zwischen SAP-Systemen sowie zwischen SAP und externen Anwendungen ausgetauscht werden.

Auch mit SAP S/4HANA, Cloud-Integration, APIs und modernen Integrationsplattformen ist das Thema keineswegs verschwunden. Aktuelle SAP-S/4HANA-Dokumentationen führen weiterhin etablierte IDoc-Basistypen wie ORDERS05, INVOIC02 und DELVRY07. Gleichzeitig unterstützt die SAP Integration Suite eigene IDoc-Sender- und Receiver-Adapter sowie SAP IDoc als Type System im Integration Advisor. IDocs bleiben damit insbesondere für etablierte asynchrone Geschäftsprozesse und B2B-/EDI-Szenarien relevant.

Die Rolle des SAP IDoc verändert sich jedoch. In modernen Integrationsarchitekturen muss heute genauer entschieden werden, wann ein IDoc sinnvoll ist und wann APIs, Events, SOAP-, OData- oder andere Integrationsmechanismen besser geeignet sind.

Das Wichtigste zu SAP IDoc in Kürze

IDoc steht für Intermediate Document. SAP beschreibt IDoc als Standard-SAP-Format für den elektronischen Datenaustausch zwischen unterschiedlichen Systemen. Ein IDoc ist dabei kein Übertragungsprotokoll und auch nicht mit EDI oder EDIFACT gleichzusetzen. Vielmehr handelt es sich um eine strukturierte Nachricht, über die Geschäftsdaten transportiert und anschließend durch die Zielanwendung verarbeitet werden können.

Für das Verständnis der SAP IDoc Grundlagen sind insbesondere sechs Punkte wichtig:

• Ein IDoc besteht grundsätzlich aus Kontrollsatz, Datensätzen beziehungsweise Segmenten und Statusinformationen.
• Der Nachrichtentyp beschreibt die fachliche Bedeutung, beispielsweise ORDERS oder INVOIC.
• Der IDoc-Basistyp definiert die technische Struktur der Nachricht, beispielsweise ORDERS05 oder INVOIC02.
• Partnerprofile und Ports steuern, mit wem und auf welchem technischen Weg IDocs ausgetauscht werden.
• IDoc-Statusinformationen dokumentieren die einzelnen Verarbeitungsschritte und Fehler.
• Für EDI-Formate wie UN/EDIFACT wird das IDoc typischerweise über eine Middleware in das externe Format beziehungsweise aus diesem zurücktransformiert.

Damit bildet das SAP IDoc eine standardisierte Schnittstelle zwischen der SAP-Anwendungslogik und einer Integrations- oder Kommunikationsschicht.

Inhaltsverzeichnis

SAP IDoc Grundlagen: Was ist ein SAP IDoc?

Ein SAP IDoc ist ein strukturiertes Datenobjekt für den nachrichtenbasierten Austausch von Informationen zwischen Anwendungssystemen.

Der Begriff „Intermediate Document“ verdeutlicht seine Rolle: Das IDoc bildet eine standardisierte Zwischenstruktur zwischen einem Geschäftsprozess im sendenden System und der Verarbeitung im empfangenden System.

SAP beschreibt die IDoc-Schnittstelle mit drei wesentlichen Zielen: Geschäftsdokumente strukturiert auszutauschen und automatisiert zu verbuchen, unterschiedliche komplexe Anwendungsstrukturen auf eine standardisierte Schnittstellenstruktur abzubilden und eine detaillierte Fehlerbehandlung vor der Verbuchung zu ermöglichen.

Ein SAP IDoc kann beispielsweise Informationen zu folgenden Geschäftsvorgängen transportieren:

Bestellungen, Auftragsbestätigungen, Rechnungen, Lieferungen, Lieferavise, Materialstammdaten oder andere Geschäftsinformationen.

Dabei muss das empfangende System die fachliche Bedeutung der Nachricht und die verwendete Struktur kennen.

Ist ein IDoc eine Datei?

Nicht zwingend.

Innerhalb von SAP existiert ein IDoc zunächst als konkrete IDoc-Instanz in der Datenbank. Beim Austausch mit einem externen System kann diese Information anschließend in eine übertragbare Darstellung serialisiert werden. Ecosio unterscheidet deshalb sinnvoll zwischen der IDoc-Instanz im SAP-System und der IDoc-Datei für den externen Datenaustausch.

Diese Unterscheidung ist für die SAP IDoc Grundlagen wichtig: IDoc bezeichnet nicht nur eine physische Datei, sondern auch das im SAP-System gespeicherte Nachrichtenobjekt inklusive Verarbeitungsstatus.

Warum ist SAP IDoc auch 2026 noch relevant?

Moderne SAP-Architekturen setzen heute verstärkt auf APIs, OData, Events, SAP Integration Suite und cloudbasierte Integrationsmuster. Daraus lässt sich jedoch nicht ableiten, dass IDocs generell veraltet oder nicht mehr unterstützt wären.

Aktuelle SAP-S/4HANA-Dokumentationen für 2025 FPS01 beschreiben beispielsweise weiterhin ORDERS05 für Einkaufs- und Verkaufsprozesse, INVOIC02 für Rechnungen und DELVRY07 für Lieferprozesse. Selbst die Dokumentation der SAP S/4HANA Cloud Public Edition enthält aktuelle IDoc-Strukturen für bestimmte Geschäftsszenarien.

Gleichzeitig verfügt die aktuelle SAP Integration Suite über IDoc-Sender- und IDoc-Receiver-Adapter. SAP Integration Advisor unterstützt SAP IDoc außerdem als eigenes Type System neben Standards wie UN/EDIFACT und ASC X12.

Die richtige Frage lautet deshalb nicht:

„Werden IDocs durch APIs ersetzt?“

Sondern:

„Welches Integrationsmuster eignet sich für welchen Geschäftsprozess?“

Für etablierte asynchrone Transaktions- und B2B-Prozesse kann ein SAP IDoc weiterhin sehr sinnvoll sein. Für neue Echtzeitszenarien oder gezielte Datenservices können dagegen APIs oder eventbasierte Architekturen geeigneter sein.

Was ist der Unterschied zwischen SAP IDoc, EDI, EDIFACT und ALE?

Diese vier Begriffe werden häufig miteinander vermischt. Technisch beschreiben sie jedoch unterschiedliche Ebenen.

SAP IDoc

Das SAP IDoc ist das standardisierte SAP-Dokumentformat für den elektronischen Datenaustausch.

Es definiert, wie die zu übertragenden Daten innerhalb einer IDoc-Nachricht strukturiert werden. SAP weist ausdrücklich darauf hin, dass IDoc ein Format und kein Kommunikationskanal beziehungsweise Übertragungsmedium ist.

EDI

EDI steht für Electronic Data Interchange und beschreibt den strukturierten elektronischen Austausch von Geschäftsdokumenten zwischen Unternehmen oder Systemen.

EDI ist somit ein übergeordnetes Integrationskonzept. Bestellungen, Lieferavise, Rechnungen oder Auftragsbestätigungen werden automatisiert ausgetauscht.

EDIFACT

UN/EDIFACT ist ein internationaler Nachrichtenstandard für EDI.

Eine EDIFACT-Nachricht ist kein SAP IDoc. Soll beispielsweise ein SAP-System eine EDIFACT-Nachricht an einen Geschäftspartner senden, muss zwischen der internen SAP-Struktur und der externen EDIFACT-Struktur gemappt werden.

Die SAP Integration Suite unterstützt genau solche B2B-Szenarien. Integration Advisor stellt Type Systems für UN/EDIFACT und SAP IDoc bereit und kann Mapping Guidelines sowie Runtime-Artefakte für die Transformation erstellen. SAP liefert darüber hinaus Vorlagen für Szenarien wie „EDI to IDoc“ und „IDoc to EDI“.

ALE

ALE steht für Application Link Enabling und ist eine SAP-Technologie für verteilte Anwendungen und den Datenaustausch zwischen logischen Systemen.

ALE kann IDocs als Nachrichtenformat nutzen. SAP beschreibt das Verteilungsmodell in BD64 sowie Partnerprofile, Ports und Nachrichtentypen als zentrale Elemente der ALE-Konfiguration.

Vereinfacht gilt:

IDoc = Nachrichtenformat in SAP

EDI = elektronischer Geschäftsdokumentenaustausch

EDIFACT = externer EDI-Nachrichtenstandard

ALE = SAP-Technologie für verteilte Systemkommunikation

SAP IDoc Aufbau: Wie ist ein IDoc strukturiert?

Der SAP IDoc Aufbau ist einer der wichtigsten Punkte für das technische Verständnis.

SAP unterscheidet drei grundlegende Bereiche:

1. Kontrollsatz – Control Record

Jedes IDoc besitzt genau einen Kontrollsatz.

Dieser enthält administrative Informationen über die Nachricht. Dazu gehören beispielsweise Sender, Empfänger, IDoc-Typ, Nachrichtentyp, Richtung und aktueller Verarbeitungsstatus. SAP speichert die Control-Record-Informationen in der Tabelle EDIDC.

Wichtige Felder sind beispielsweise:

DOCNUM – eindeutige IDoc-Nummer
IDOCTYP – verwendeter IDoc-Basistyp
MESTYP – logischer Nachrichtentyp
SNDPRN – Sender
RCVPRN – Empfänger
STATUS – aktueller Status

Der Control Record definiert somit den technischen Kontext des SAP IDoc.

2. Datensätze und Segmente – Data Records

Die eigentlichen Geschäftsinformationen befinden sich in den Datensätzen.

Diese Datensätze sind in Segmente gegliedert. Ein Segment stellt eine logisch zusammengehörige Gruppe von Feldern dar, beispielsweise Kopf-, Positions-, Partner- oder Datumsinformationen.

SAP verwendet für die Datenrecords unter anderem die Struktur EDIDD. Das Feld SEGNAM identifiziert den Segmenttyp, während SDATA die eigentlichen Segmentdaten enthält. SAP dokumentiert für SDATA eine Länge von bis zu 1.000 Bytes.

Die aktuellen Datenrecords werden in der SAP-Datenbank typischerweise in EDID4 gespeichert.

3. Statussätze – Status Records

Der dritte Bereich des SAP IDoc Aufbau sind die Statusinformationen.

Ein IDoc kann während seines Lebenszyklus zahlreiche Statussätze erhalten. Dadurch lässt sich nachvollziehen, welche Verarbeitungsschritte erfolgreich waren und an welcher Stelle Fehler entstanden sind.

Statussätze werden in EDIDS gespeichert. SAP erläutert, dass diese Statushistorie nicht Bestandteil der eigentlichen Nachricht beim Systemaustausch sein muss, sondern den Verarbeitungsverlauf innerhalb des jeweiligen Systems dokumentiert.

Genau diese Statusinformationen bilden die Grundlage für ein professionelles SAP IDoc Monitoring.

Was ist der Unterschied zwischen IDoc-Basistyp, Nachrichtentyp und Erweiterung?

Diese Begriffe gehören zu den häufigsten Ursachen für Missverständnisse.

Nachrichtentyp

Der Nachrichtentyp beschreibt die fachliche Bedeutung der Nachricht.

Beispiele sind:

ORDERS für Bestellprozesse oder INVOIC für Rechnungsinformationen.

Der Nachrichtentyp sagt somit, was kommuniziert wird.

IDoc-Basistyp

Der Basistyp definiert dagegen die technische Segmentstruktur.

Ein Beispiel ist ORDERS05. SAP dokumentiert diesen Basistyp aktuell für Einkaufs- und Verkaufsdokumente. Auch INVOIC02 wird weiterhin als Standard-IDoc-Struktur für Rechnungen geführt.

Ein Basistyp kann mehreren Nachrichtentypen zugrunde liegen. Ecosio zeigt beispielsweise, dass ORDERS05 unter anderem als Basis für ORDERS, ORDCHG oder ORDRSP verwendet werden kann.

IDoc-Erweiterung

Reicht ein SAP-Standard-IDoc fachlich nicht aus, kann die Struktur erweitert werden.

Kundenspezifische Erweiterungen sollten jedoch bewusst eingesetzt werden. Je mehr Z-Segmente und individuelle Mappings entstehen, desto höher werden Wartungs-, Test- und Migrationsaufwand.

Für eine moderne Integrationsarchitektur gilt deshalb: Standard vor Erweiterung.

Welche wichtigen SAP IDoc-Typen gibt es?

SAP stellt eine große Anzahl von IDoc-Strukturen für unterschiedliche Prozesse bereit.

Beispiele sind:

Geschäftsprozess	Nachrichtentyp / Kontext	Beispiel Basistyp
Bestellung / Verkauf	ORDERS	ORDERS05
Auftragsbestätigung	ORDRSP	beispielsweise ORDERS05
Rechnung	INVOIC	INVOIC02
Lieferung	Delivery Interface	DELVRY07

Die konkreten Kombinationen hängen vom Geschäftsprozess, SAP-Produkt, Release und Customizing ab. SAP dokumentiert ORDERS05, INVOIC02 und DELVRY07 auch in der aktuellen S/4HANA-Dokumentation für 2025 FPS01.

Für die Dokumentation vorhandener IDoc-Typen und Segmente ist insbesondere die Transaktion WE60 relevant.

Wie funktioniert die eingehende und ausgehende SAP IDoc-Verarbeitung?

Grundsätzlich wird zwischen Outbound- und Inbound-Verarbeitung unterschieden.

Outbound – SAP IDoc senden

Beim Outbound-Prozess entsteht das IDoc aus einem Geschäftsvorgang im SAP-System.

Ein typisches Beispiel ist eine Bestellung. Nachdem der entsprechende Geschäftsbeleg angelegt beziehungsweise freigegeben wurde, kann die Ausgabesteuerung oder Anwendungslogik die Nachricht erzeugen.

Anschließend werden unter anderem Partnerprofil, Nachrichtentyp, Basistyp und Empfängerport bestimmt. Das IDoc wird erstellt und an den definierten Kommunikationsweg übergeben.

Vereinfacht lautet der Prozess:

SAP-Geschäftsbeleg → Nachrichtensteuerung / Anwendungslogik → IDoc → Port → Middleware oder Zielsystem

Partnerprofile definieren unter anderem Nachrichtentyp, IDoc-Typ, Empfängerport und Übertragungsmodus.

Inbound – SAP IDoc verarbeiten

Beim Inbound-Prozess erhält das SAP-System ein IDoc von einem anderen System oder einer Middleware.

Die IDoc-Schnittstelle analysiert zunächst die technischen Informationen. Ist das Dokument formal verarbeitbar, kann es an die Anwendungslogik übergeben werden.

Der im Partnerprofil hinterlegte Prozesscode bestimmt dabei, welche Verarbeitungslogik beziehungsweise welcher Funktionsbaustein angesprochen wird.

Erfolgreich verarbeitete Inbound-IDocs erhalten typischerweise Status 53. Tritt ein fachlicher oder technischer Fehler bei der Verbuchung auf, kann Status 51 entstehen. IDocs im Status 64 stehen zur Übergabe an die Anwendung bereit.

SAP IDoc einrichten: Welche Komponenten sind notwendig?

Wer ein SAP IDoc einrichten möchte, sollte nicht mit einzelnen Transaktionen beginnen, sondern zunächst den End-to-End-Prozess definieren.

Je nach Szenario sind mehrere Konfigurationselemente relevant.

Partnerprofile – WE20

Partnerprofile definieren, welche Nachrichten mit welchem Partner ausgetauscht und wie diese verarbeitet werden.

Für Outbound-Prozesse gehören dazu beispielsweise Nachrichtentyp, IDoc-Basistyp, Empfängerport und Versandmodus.

Für Inbound-Prozesse werden unter anderem Nachrichtentyp und Prozesscode definiert.

Ports – WE21

Ports beschreiben den technischen Übergabepunkt beziehungsweise die Kommunikationsart.

SAP dokumentiert WE21 als zentrale Transaktion für Ports in der IDoc-Verarbeitung. Je nach Architektur können beispielsweise RFC- oder dateibasierte Szenarien relevant sein.

RFC-Verbindungen – SM59

Werden RFC-basierte Verbindungen genutzt, müssen die entsprechenden RFC-Destinationen konfiguriert und getestet werden.

Nachrichtentyp und Basistyp – WE81 und WE82

WE81 dient der Verwaltung logischer Nachrichtentypen.

Über WE82 wird die Zuordnung zwischen Nachrichtentyp und IDoc-Typ gepflegt.

Prozesscodes – WE41 und WE42

Prozesscodes bestimmen die Verarbeitungslogik.

WE41 wird für Outbound-Prozesscodes und WE42 für Inbound-Prozesscodes verwendet.

ALE-Verteilungsmodell – BD64

Bei ALE-Szenarien legt das Verteilungsmodell fest, welche Nachrichten zwischen welchen logischen Systemen verteilt werden.

Die Konfiguration hängt immer vom konkreten Prozess ab. Ein allgemeines „IDoc-Customizing“, das für jede Schnittstelle identisch ist, gibt es nicht.

SAP IDoc senden: Wie funktioniert der Outbound-Prozess praktisch?

Um ein SAP IDoc senden zu können, müssen technische und fachliche Einstellungen zusammenspielen.

Zunächst muss feststehen, welcher Geschäftsvorgang die Nachricht auslöst. Anschließend muss das System den Geschäftspartner und den richtigen Nachrichtentyp bestimmen können.

Das Partnerprofil enthält die relevanten Outbound-Parameter. Dazu gehören typischerweise Nachrichtentyp, IDoc-Basistyp, Empfängerport und die Frage, ob IDocs unmittelbar oder gesammelt übertragen werden.

SAP dokumentiert beispielsweise für bestimmte ORDERS-Szenarien die Kombination aus Nachrichtentyp ORDERS, Basistyp ORDERS05 und einem definierten Empfängerport.

Bei einer Middleware-Architektur endet die fachliche Verarbeitung jedoch nicht am SAP-Port. Die Middleware muss das SAP IDoc gegebenenfalls transformieren, routen, technisch übertragen und überwachen.

SAP IDoc verarbeiten: Wie funktioniert der Inbound-Prozess?

Beim SAP IDoc verarbeiten müssen zwei Ebenen unterschieden werden:

die technische Annahme der Nachricht und die fachliche Verbuchung.

Ein technisch erfolgreich empfangenes IDoc ist noch kein erfolgreich verbuchter Geschäftsbeleg.

Nach dem Eingang analysiert die IDoc-Schnittstelle die Nachricht. Je nach Partnerprofil und Processing-Einstellung wird sie unmittelbar oder zeitversetzt an die Anwendung übergeben.

SAP beschreibt beispielsweise folgende typische Abfolge:

50 → IDoc hinzugefügt

64 → IDoc bereit zur Übergabe an die Anwendung

62 → IDoc an Anwendung übergeben

53 → Anwendungsbeleg gebucht

Tritt während der fachlichen Verarbeitung ein Fehler auf, entsteht häufig Status 51.

Damit liefert das Statusmodell eine sehr genaue Sicht darauf, an welcher Stelle ein Prozess steht.

SAP IDoc Monitoring: Wie lassen sich IDocs überwachen?

Ein professionelles SAP IDoc Monitoring ist für produktive EDI- und Integrationsprozesse unverzichtbar.

Die klassischen SAP-Werkzeuge bleiben dabei wichtig.

WE02

WE02 dient der Anzeige einzelner IDocs und ermöglicht die Analyse von Kontrollsatz, Segmentdaten und Statushistorie.

WE05

WE05 stellt IDocs in Listenform dar und eignet sich für die Selektion größerer Mengen.

BD87

BD87 ist ein zentraler Statusmonitor und ermöglicht abhängig vom Status auch die erneute Verarbeitung von IDocs. SAP verweist in aktuellen Troubleshooting-Dokumentationen ausdrücklich auf BD87 für die Nachverarbeitung fehlerhafter IDocs.

WE19

WE19 ist ein Testwerkzeug für IDocs. Die Transaktion eignet sich für Test- und Analysezwecke, sollte aber nicht mit einem normalen produktiven Reprocessing verwechselt werden.

WE60

WE60 liefert die technische Dokumentation zu IDoc-Typen und Segmenten.

WLF_IDOC und anwendungsspezifische Monitore

SAP S/4HANA enthält zusätzlich anwendungsspezifische und modernere Monitoring-Ansätze. SAP dokumentiert beispielsweise IDoc-Monitore für eingehende Aufträge, Lieferavise und Lieferabrufe sowie WLF_IDOC für bestimmte Verarbeitungsszenarien. Der konkrete Funktionsumfang ist jedoch anwendungs- und releaseabhängig.

Für hybride Architekturen reicht das SAP IDoc Monitoring im Backend alleine nicht aus. Zusätzlich sollte die Middleware überwacht werden, damit sich der gesamte Weg vom Sender über Mapping und Transport bis zur Verbuchung nachvollziehen lässt.

Was bedeuten die SAP IDoc-Statuscodes 51, 53 und 64?

Diese drei Statuscodes gehören zu den wichtigsten Statusinformationen für Inbound-IDocs.

Status 51 – Anwendungsbeleg nicht gebucht

Status 51 bedeutet, dass die Verarbeitung in der Anwendung nicht erfolgreich abgeschlossen wurde.

Ursachen können beispielsweise sein:

fehlende oder falsche Stammdaten, inkonsistentes Customizing, nicht zulässige Werte, falsche Prozesscodes oder Sperrkonflikte.

SAP dokumentiert beispielsweise, dass Sperrprobleme oder inkonsistente Inbound-Konfiguration zu Status 51 führen können.

Die richtige Vorgehensweise lautet nicht, das IDoc sofort erneut zu starten. Zunächst muss die Ursache verstanden und behoben werden.

Status 53 – Anwendungsbeleg gebucht

Status 53 bedeutet, dass der Anwendungsbeleg erfolgreich verbucht wurde.

Damit ist die fachliche Inbound-Verarbeitung grundsätzlich abgeschlossen. SAP ordnet Status 53 ausdrücklich „Application document posted“ zu.

Status 64 – Bereit zur Übergabe an die Anwendung

Status 64 bedeutet, dass das IDoc technisch vorliegt und zur Verarbeitung durch die Anwendung bereit ist.

Das ist nicht automatisch ein Fehler.

Je nach Partnerprofil kann die Verarbeitung bewusst zeitversetzt beziehungsweise im Hintergrund erfolgen. SAP nennt dafür beispielsweise Report RBDAPP01.

Bleiben ungewöhnlich viele IDocs dauerhaft im Status 64 stehen, sollten Jobplanung und Inbound-Verarbeitungsmodus geprüft werden.

Wie lassen sich fehlerhafte SAP IDoc-Nachrichten erneut verarbeiten?

Bei einem Fehler sollte zunächst die Ursache analysiert werden.

Eine sinnvolle Reihenfolge lautet:

1. Status und Fehlermeldung prüfen.

Öffnen Sie das IDoc in WE02, WE05 oder BD87 und analysieren Sie die Statusinformationen.

2. Segmentdaten prüfen.

Ermitteln Sie, ob Pflichtinformationen fehlen oder unzulässige Werte übertragen wurden.

3. Stammdaten und Customizing kontrollieren.

Viele Status-51-Fehler entstehen nicht durch das IDoc-Framework selbst, sondern durch die Anwendung.

4. Partnerprofil und Prozesscode prüfen.

Ein falscher Prozesscode kann dazu führen, dass das falsche Inbound-Funktionsmodul angesprochen wird. SAP dokumentiert entsprechende Fehlerfälle ausdrücklich.

5. Ursache beheben.
   
6. IDoc erneut verarbeiten.

Je nach Status und Szenario kann BD87 beziehungsweise eine geeignete Hintergrundverarbeitung eingesetzt werden.

Direkte manuelle Änderungen an produktiven IDoc-Inhalten sollten dagegen nur kontrolliert und unter Berücksichtigung von Berechtigungen, Auditierbarkeit und fachlicher Verantwortung erfolgen.

SAP IDoc EDIFACT: Wie hängen IDoc und EDIFACT zusammen?

Beim Neben-Keyword SAP IDoc EDIFACT ist eine fachliche Klarstellung besonders wichtig:

Ein SAP IDoc ist kein EDIFACT-Dokument.

UN/EDIFACT ist ein externer B2B-Nachrichtenstandard. IDoc ist das SAP-eigene Nachrichtenformat.

In einem klassischen Szenario kann beispielsweise folgende Verarbeitung stattfinden:

SAP → IDoc → Middleware → Mapping → EDIFACT → Geschäftspartner

Inbound entsprechend:

Geschäftspartner → EDIFACT → Middleware → Mapping → SAP IDoc → SAP-Anwendung

Die Middleware übernimmt dabei die Transformation zwischen den beiden Datenmodellen.

SAP Integration Advisor unterstützt aktuell sowohl UN/EDIFACT als auch SAP IDoc als Type Systems. Unternehmen können daraus Message Implementation Guidelines und Mapping Guidelines erstellen und Runtime-Artefakte für Cloud Integration generieren.

Die aktuelle SAP-Dokumentation beschreibt außerdem standardisierte Integration-Flow-Templates für EDI to IDoc und IDoc to EDI.

Für ein modernes SAP IDoc EDIFACT-Szenario ist deshalb nicht nur das technische Mapping relevant. Auch Partnerprofile, EDIFACT-Versionen und -Subsets, Qualifier, Code-Listen, Kommunikationsprotokolle und End-to-End-Monitoring müssen berücksichtigt werden.

Weiterführend: SAP Integration Suite

Wo lässt sich SAP IDoc einsetzen?

IDocs eignen sich vor allem für strukturierte, nachrichtenbasierte und häufig asynchrone Prozesse.

Typische Einsatzgebiete sind Procurement, Sales, Logistik, Finance, Stammdatenverteilung sowie EDI-Partnerkommunikation.

Ein klassisches Beispiel ist die Bestellung: Ein SAP-System erzeugt ein ORDERS-IDoc, eine Middleware transformiert die Nachricht in das vom Lieferanten benötigte Format und überträgt sie. Die Auftragsbestätigung oder der Lieferavis kann anschließend über den umgekehrten Weg wieder in SAP verarbeitet werden.

Auch Rechnungsprozesse können IDoc-basiert integriert sein. SAP dokumentiert INVOIC02 weiterhin als Standard-IDoc-Struktur für Rechnungen.

Bei modernen gesetzlichen E-Invoicing-Szenarien sollte allerdings geprüft werden, ob IDoc lediglich als internes Integrationsformat eingesetzt wird und die regulatorische Verarbeitung über Lösungen wie SAP Document and Reporting Compliance erfolgt.

Weiterführend: E-Rechnung mit SAP

Welche Rolle spielt SAP IDoc in SAP S/4HANA?

Das SAP IDoc bleibt in SAP S/4HANA relevant, muss aber im Kontext der jeweiligen Anwendung und des eingesetzten Output-Frameworks betrachtet werden.

SAP S/4HANA Output Control unterstützt elektronische Kommunikation über den EDI-Kanal. Dieser kann abhängig vom konkreten Geschäftsszenario IDocs oder SOA-Nachrichten übertragen. SAP weist gleichzeitig darauf hin, dass der eigenständige IDOC-Kanal innerhalb dieses Output-Control-Frameworks nur für bestimmte Zwecke, insbesondere Intercompany Billing, vorgesehen ist.

Diese Unterscheidung ist wichtig:

Sie bedeutet nicht, dass IDocs in SAP S/4HANA nur noch für Intercompany Billing verwendet werden können. Sie beschreibt den konkreten Umfang des IDOC-Ausgabekanals innerhalb der SAP-S/4HANA-Ausgabesteuerung.

Andere Anwendungen und Integrationsframeworks können weiterhin IDoc-basierte Schnittstellen bereitstellen.

Für ein S/4HANA-Projekt sollten bestehende SAP IDoc-Schnittstellen daher individuell analysiert werden. Basistypen, Segmente, Erweiterungen, Ausgabesteuerung, Middleware-Mappings und Folgeprozesse müssen gegen das Zielrelease geprüft werden.

SAP IDoc und SAP Integration Suite

Die SAP Integration Suite zeigt deutlich, dass IDocs auch Bestandteil moderner hybrider Architekturen sein können.

SAP stellt aktuell sowohl einen IDoc-Sender- als auch einen IDoc-Receiver-Adapter bereit. Die Adapter ermöglichen den Nachrichtenaustausch zwischen SAP Integration Suite und Systemen, die entsprechende IDoc-Kommunikation über SOAP Web Services unterstützen.

Darüber hinaus ermöglicht Integration Advisor die Modellierung und Transformation zwischen verschiedenen B2B-Standards.

Ein Unternehmen kann beispielsweise:

ein SAP IDoc aus SAP empfangen, es innerhalb der Integration Suite validieren und transformieren, in EDIFACT oder ein anderes Partnerformat umwandeln und über die passende B2B-Kommunikation weiterleiten.

Damit verschwindet IDoc nicht aus modernen Architekturen. Seine Rolle verschiebt sich vielmehr: vom alleinstehenden Punkt-zu-Punkt-Mechanismus hin zu einem Nachrichtenformat innerhalb einer stärker zentralisierten Integrationsplattform.

SAP IDoc oder API – welcher Ansatz ist besser?

Es gibt keine pauschale Antwort.

IDocs sind besonders stark bei etablierten, asynchronen Geschäftsbelegen und großen B2B-/EDI-Prozesslandschaften. APIs eignen sich dagegen häufig besser für gezielte synchrone Abfragen und transaktionale Echtzeitinteraktionen.

Events sind wiederum interessant, wenn Systeme lose gekoppelt auf Geschäftsereignisse reagieren sollen.

Für ein neues Integrationsszenario sollten daher mehrere Fragen gestellt werden:

Muss die Kommunikation synchron erfolgen? Muss sofort eine Antwort zurückgegeben werden? Wird ein vollständiges Geschäftsdokument übertragen? Gibt es bereits einen stabilen SAP-IDoc-Standard? Sind Geschäftspartner über EDI angebunden? Welche Integrationsschnittstelle stellt SAP für das konkrete S/4HANA-Szenario strategisch bereit?

Der Clean-Core-Gedanke spricht nicht dafür, IDocs grundsätzlich abzuschaffen. Er spricht dafür, Standardschnittstellen zu nutzen, kundenspezifische Eingriffe in den ERP-Kern zu minimieren und Integrationslogik kontrolliert zu kapseln.

Best Practices für SAP IDoc

Standard-IDoc vor Z-Entwicklung

Prüfen Sie zuerst, ob ein bestehender Basistyp und Nachrichtentyp den Prozess bereits abbilden.

Nachrichtentyp und Basistyp sauber trennen

Die fachliche Bedeutung gehört zum Nachrichtentyp, die technische Segmentstruktur zum Basistyp.

Middleware-Mapping dokumentieren

Bei SAP IDoc EDIFACT oder anderen B2B-Szenarien sollte jedes relevante Mapping nachvollziehbar dokumentiert und versioniert werden.

Monitoring Ende-zu-Ende aufbauen

Ein grüner Status 53 im SAP-System beweist nicht automatisch, dass der gesamte Partnerprozess korrekt abgeschlossen wurde. Umgekehrt kann eine erfolgreiche Übertragung in der Middleware noch vor der SAP-Verbuchung scheitern.

SAP IDoc Monitoring und Middleware-Monitoring sollten daher miteinander verknüpft werden.

Keine unnötigen kundeneigenen Segmente

Jede Erweiterung erhöht Abhängigkeiten bei S/4HANA-Transformationen, Releasewechseln und Partner-Mappings.

Große Mengen kontrolliert verarbeiten

Bei Massenszenarien sollten Paketgrößen, Parallelisierung, Sperrverhalten und Hintergrundjobs bewusst konfiguriert werden. SAP weist darauf hin, dass parallele Inbound-Verarbeitung zu Sperrkonflikten führen kann.

Do’s & Don’ts bei SAP IDoc

Do

Definieren Sie zuerst den Geschäftsprozess und anschließend die technische Schnittstelle. Verwenden Sie möglichst SAP-Standard-Basistypen, dokumentieren Sie Partnerprofile und Mappings, etablieren Sie automatisches SAP IDoc Monitoring und testen Sie sowohl technische als auch fachliche Fehlerfälle.

Don’t

Setzen Sie IDoc nicht automatisch mit EDI oder EDIFACT gleich. Bearbeiten Sie produktive IDocs nicht unkontrolliert manuell. Verwenden Sie WE19 nicht als Ersatz für ein geregeltes Reprocessing. Übernehmen Sie bestehende ECC-Schnittstellen nicht ungeprüft nach SAP S/4HANA und entwickeln Sie keine Z-Segmente, bevor die Standardmöglichkeiten vollständig bewertet wurden.

Schritt für Schritt – SAP IDoc einrichten

Schritt 1 – Geschäftsprozess definieren

Legen Sie fest, welches Geschäftsdokument zwischen welchen Systemen ausgetauscht werden soll.

Schritt 2 – Integrationsmuster auswählen

Entscheiden Sie, ob IDoc für das Szenario tatsächlich die richtige Schnittstelle ist oder eine API, ein Event beziehungsweise eine andere Standardschnittstelle geeigneter ist.

Schritt 3 – Nachrichtentyp und Basistyp auswählen

Prüfen Sie vorhandene SAP-Standardtypen über die SAP-Dokumentation und WE60.

Schritt 4 – Sender und Empfänger definieren

Richten Sie logische Systeme beziehungsweise Geschäftspartner entsprechend dem Szenario ein.

Schritt 5 – Port konfigurieren

Definieren Sie den technischen Kommunikationsweg in WE21 und gegebenenfalls die erforderliche RFC-Destination in SM59.

Schritt 6 – Partnerprofil konfigurieren

Pflegen Sie die erforderlichen Inbound- und/oder Outbound-Parameter in WE20.

Schritt 7 – Prozesslogik konfigurieren

Prüfen Sie Prozesscodes, Funktionsbausteine, Ausgabesteuerung und gegebenenfalls ALE-Verteilungsmodelle.

Schritt 8 – Middleware integrieren

Bei EDI-Prozessen müssen Mapping, Routing, technische Kommunikation und Partnerparameter konfiguriert werden.

Mit SAP Integration Advisor können beispielsweise Mapping Guidelines zwischen SAP IDoc und UN/EDIFACT aufgebaut und Runtime-Artefakte für Cloud Integration erzeugt werden.

Schritt 9 – End-to-End testen

Testen Sie nicht nur den Happy Path. Berücksichtigen Sie auch fehlende Stammdaten, fehlerhafte Partnerprofile, Mappingfehler, Sperrsituationen, doppelte Nachrichten und technische Verbindungsabbrüche.

Schritt 10 – SAP IDoc Monitoring produktiv etablieren

Definieren Sie Verantwortlichkeiten, Alerting, Wiederanlaufverfahren, SLAs und Eskalationswege.

Welche Rolle spielen IDocs bei E-Rechnungen?

IDocs können in Rechnungsprozessen weiterhin eine interne Integrationsrolle übernehmen. INVOIC02 ist beispielsweise auch in aktuellen S/4HANA-Releases dokumentiert.

Eine moderne gesetzliche E-Invoicing-Architektur sollte jedoch zwischen interner Nachrichtenstruktur und regulatorischem Austauschformat unterscheiden.

Ein IDoc ist nicht automatisch eine XRechnung, Peppol BIS Invoice oder ein anderes gesetzlich relevantes Rechnungsformat.

Für internationale E-Invoicing- und Reporting-Anforderungen unterstützt SAP mit SAP Document and Reporting Compliance die Erstellung, Verarbeitung und Überwachung elektronischer Dokumente. Für die operative Eingangsrechnungsverarbeitung können ergänzend Lösungen wie SAP Invoice Management by OpenText relevant sein.

Weiterführend: SAP Document and Reporting Compliance

Weiterführend: E-Rechnung in SAP empfangen

Fazit – Warum SAP IDoc weiterhin wichtig ist

Das SAP IDoc ist weit mehr als ein historisches Austauschformat aus der klassischen SAP-ERP-Welt.

Es bildet bis heute eine wichtige Schnittstelle für strukturierte, automatisierte und asynchrone Geschäftsprozesse. Aktuelle SAP-Dokumentationen für SAP S/4HANA führen etablierte Basistypen wie ORDERS05, INVOIC02 und DELVRY07 weiterhin. Auch die SAP Integration Suite stellt IDoc-Adapter und Unterstützung für SAP IDoc im Integration Advisor bereit.

Für eine erfolgreiche Nutzung sind jedoch die SAP IDoc Grundlagen entscheidend. Unternehmen müssen Nachrichtentyp, Basistyp, Segmentstruktur, Partnerprofil, Port und Prozesscode sauber voneinander unterscheiden.

Ebenso wichtig ist ein durchgängiges SAP IDoc Monitoring. Status 51, 53 oder 64 sind nicht nur technische Codes, sondern liefern wesentliche Informationen über den Zustand eines Geschäftsprozesses.

Auch beim Thema SAP IDoc EDIFACT ist eine klare Abgrenzung notwendig: IDoc ist das SAP-interne Format, EDIFACT ein externer B2B-Standard. Eine Integrationsplattform übernimmt das Mapping zwischen beiden Strukturen.

Mit SAP S/4HANA und Cloud-Technologien verändert sich die Integrationslandschaft weiter. Unternehmen sollten IDocs deshalb weder reflexartig abschaffen noch bei jeder neuen Schnittstelle automatisch weiterverwenden.

Die richtige Strategie besteht darin, für jeden Prozess das passende Integrationsmuster zu wählen: IDoc und EDI für robuste dokumentenbasierte B2B-Prozesse, APIs für gezielte Echtzeitkommunikation und Events für lose gekoppelte, ereignisbasierte Architekturen.

So bleibt SAP IDoc ein wichtiger Baustein – eingebettet in eine moderne, standardisierte und überwachte Integrationsarchitektur.

Häufig gestellte Fragen zu SAP IDoc