IDoc im Fehlerstatus: vom Statusmonitor zur Ursache und zurück
Der Status sagt, wo es steht, nicht warum. Wer die drei Orte kennt, an denen ein IDoc hängen bleibt, sortiert einen Fehler in Minuten ein und wiederholt ihn ohne zweite Buchung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Beleg fehlt, und niemand hat ihn vermisst
Der typische Fall beginnt nicht mit einer Meldung, sondern mit einer Frage aus dem Fachbereich: Wo ist die Bestellung des Kunden, die gestern hätte kommen sollen? Danach beginnt die Suche, und sie dauert deshalb so lange, weil niemand weiß, an welcher Stelle der Kette zuerst zu schauen ist. Das IDoc kann in der Übertragung stehen, es kann an der Steuerung gescheitert sein, oder die Anwendung hat es abgelehnt. Drei völlig verschiedene Orte mit drei verschiedenen Zuständigen.
Der eigentliche Schaden entsteht durch die Zeit, die vergeht, bis jemand hinsieht. Für Fehler im IDoc-Eingang gibt es eine vorgesehene Benachrichtigung: Bei Fehlern werden Arbeitsvorräte erzeugt, die im Business Workplace des vorgesehenen Empfängers erscheinen, und wer dieser Empfänger ist, wird aus den Partnervereinbarungen gelesen. Wenn dort niemand gepflegt ist oder die hinterlegte Person das Haus verlassen hat, läuft die Benachrichtigung ins Leere, und ein Fehler kann tagelang unbemerkt liegen.
Der dritte Punkt ist die Wiederholung selbst. Sie ist die Stelle, an der aus einem behebbaren Fehler ein zweites Problem wird. Wenn nicht geprüft wird, ob im Zielsystem bereits ein Anwendungsbeleg entstanden ist, entsteht bei der Wiederholung ein zweiter. Eine doppelte Rechnung oder eine doppelte Bestellung ist deutlich unangenehmer als eine fehlende, weil sie zunächst niemandem auffällt und im Zweifel bezahlt wird.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Fälle, die im Betrieb wirklich auflaufen
Sortiert nach dem, was du im Monitor siehst, und nicht nach der Technik dahinter. Zu jedem Fall steht, an welchem der drei Orte er sitzt und wie er abgeschlossen wird, ohne einen zweiten Beleg zu erzeugen.
Symptom
Das IDoc ist angekommen und steht im Fehler, weil die Anwendung den Beleg nicht buchen konnte.
Ursache
Das ist der häufigste Fall überhaupt und meint den Status 51, den SAP als Anwendungsbeleg nicht gebucht führt. Die Ursache ist fast immer fachlich: ein Stammsatz fehlt oder ist gesperrt, eine Zuordnung ist nicht gepflegt, ein Wert im Beleg passt nicht zu dem, was im System hinterlegt ist. Das IDoc selbst ist in Ordnung, die Anwendung hat es abgelehnt.
Lösung
Statussätze aufklappen und die Meldung lesen, denn dort steht der fachliche Grund. Danach die Ursache im Stammsatz oder in der Einstellung beheben, nicht am IDoc. Anschließend wird das IDoc erneut verarbeitet. Für das Erkennen und Bearbeiten solcher Fehler ist die Ausnahmebehandlung im Eingang ausdrücklich vorgesehen: Der Empfänger des Arbeitsvorrats kann den Fehler beheben und die Verarbeitung erneut anstoßen oder das IDoc zum Löschen vormerken.
Symptom
Das IDoc wird beim Eingang abgewiesen, bevor eine Anwendung überhaupt beteiligt war.
Ursache
Das sind die formalen Fehler, und der klassische darunter ist die Partnervereinbarung, die nicht gefunden wird. Typische Auslöser sind ein neues Partnersystem, ein neuer Nachrichtentyp, ein umbenannter logischer Systemname oder eine Vereinbarung, die zwar besteht, aber nicht für diese Kombination aus Partnertyp, Partnernummer und Nachricht.
Lösung
Die Partnervereinbarungen über die Transaktion WE20 aufrufen und den Eintrag für die betroffene Kombination prüfen. Dort gibt es eine eingebaute Prüffunktion, die die Einträge je Partner automatisch kontrolliert, unter anderem darauf, ob die zulässigen Bearbeiter und die angegebenen Vorgangscodes vorhanden sind. Nach der Korrektur lässt sich das IDoc erneut verarbeiten, ohne dass der Partner es noch einmal senden muss.
Symptom
Das IDoc scheitert an der Syntaxprüfung, obwohl der Partner nach eigener Aussage nichts geändert hat.
Ursache
Die Syntaxprüfungen für IDocs lassen sich in den Partnervereinbarungen aktivieren, und ein Fehler daraus wird einer eigenen Aufgabe zugeordnet. Ausgelöst wird er, wenn ein Segment oder ein Feldinhalt nicht zu dem passt, was der verwendete Basistyp erwartet, etwa weil ein Feld länger geworden ist oder ein Segment in einer Wiederholung auftaucht, die so nicht vorgesehen ist.
Lösung
Das eingegangene IDoc auf Segmentebene ansehen und die Abweichung gegen den Basistyp bestimmen. Danach ist es eine Absprache mit dem Partner und keine Systemarbeit. Wichtig ist die Reihenfolge: erst feststellen, welches Segment betroffen ist, dann melden. Eine Rückmeldung, dass ein IDoc einen Syntaxfehler habe, führt beim Partner zu derselben Suche, die du gerade schon gemacht hast.
Symptom
Der Fehler liegt seit Tagen im System und niemand hat davon erfahren.
Ursache
Die Benachrichtigung hängt an den Partnervereinbarungen. Die zulässigen Bearbeiter werden von dort gelesen: Sind für die betreffende Nachricht Bearbeiter eingetragen, werden diese benachrichtigt, andernfalls die für diesen Partner allgemein hinterlegten. Ist niemand gepflegt oder ist der Eintrag veraltet, entsteht zwar ein Arbeitsvorrat, er landet aber bei niemandem, der noch hinsieht.
Lösung
Die Bearbeiter in den Partnervereinbarungen pflegen und wie eine Rufbereitschaft behandeln, also mit einer Vertretung und einer jährlichen Prüfung. Ergänzend lässt sich festlegen, welchem Status welche Behandlung zugeordnet ist, dafür gibt es die Zuordnung von Vorgangscodes zu Aufgaben über die Transaktion WE46. Wer beides gepflegt hat, findet Fehler über die Aufgabe und nicht über eine Nachfrage aus dem Fachbereich.
Symptom
Das IDoc taucht im Zielsystem gar nicht auf, im Quellsystem sieht alles unauffällig aus.
Ursache
Dann sitzt der Fall in der Übertragung und nicht in der Verarbeitung. Der Statusmonitor zeigt die IDocs nach Status geordnet, und dazu gehören auch die Einträge in der tRFC-Queue. Genau dieser Knoten ist der, den man aufklappen muss, und die SAP-Dokumentation weist ausdrücklich darauf hin, dass diese Anzeige lange dauern kann und deshalb nur bei Bedarf aufgeklappt werden sollte.
Lösung
Zuerst im sendenden System prüfen, ob das IDoc überhaupt versandbereit war oder ob es in der Übertragung feststeckt. Die Selektion im Statusmonitor über Änderungsdatum, Status und Nachrichtentyp ist dafür die schnellste, während die Auswahl über Geschäftsobjekttypen die Anzeige deutlich verlangsamt. Erst wenn feststeht, dass das IDoc das System verlassen hat, wird im Zielsystem weitergesucht.
Symptom
Nach der Wiederholung steht der Beleg doppelt im System.
Ursache
Die Verarbeitung war beim ersten Lauf weiter gekommen, als der Status vermuten ließ, oder jemand hat parallel von Hand nachgebucht, weil es eilig war. Beides ist im Betrieb normal und wird nur dann zum Problem, wenn vor der Wiederholung niemand nachgesehen hat. Ein IDoc erneut zu verarbeiten, ist ein Vorgang ohne eingebaute Rückfrage.
Lösung
Vor jeder Wiederholung im Zielsystem nach dem Anwendungsbeleg suchen, über Referenznummer, Partner und Datum. Existiert er bereits, wird das IDoc nicht wiederholt, sondern als erledigt gekennzeichnet oder zum Löschen vorgemerkt. Nimm diese Prüfung fest in den Ablauf auf, denn unter Zeitdruck wird sie sonst zuverlässig übersprungen, und der doppelte Beleg fällt erst bei der Zahlung auf.
Drei Orte, an denen ein IDoc hängen bleibt
- 01 Übertragung: das IDoc hat das System noch nicht verlassen oder ist nicht angekommen.
- 02 Steuerung: Partnervereinbarung, Vorgangscode oder Syntaxprüfung lassen es nicht weiter.
- 03 Anwendung: der Beleg konnte fachlich nicht gebucht werden, meist wegen Stammdaten oder Einstellungen.
- 04 Benachrichtigung: ob jemand davon erfährt, entscheiden die Bearbeiter in der Partnervereinbarung.
- 05 Wiederholung: erst prüfen, ob bereits ein Anwendungsbeleg entstanden ist, dann erneut verarbeiten.
Danach ist ein IDoc-Fehler eine Aufgabe von Minuten
Die Arbeit besteht aus drei Fragen und einer Prüfung vor der Wiederholung. Wenn diese Reihenfolge steht, wird aus einem Fall, der zwischen drei Teams wandert, ein Vorgang, den eine Person abschließt.
Zuerst den Ort bestimmen, nicht die Ursache
Übertragung, Steuerung oder Anwendung, das sind die drei Orte. Der Statusmonitor ordnet die IDocs nach Status in einer Hierarchie und lässt sich zusätzlich nach Nachrichtentyp, Objekttyp oder Partnersystem gliedern. Diese Einordnung entscheidet, wer den Fall überhaupt bearbeitet.
Den Statussatz lesen statt den Status zu deuten
Die Statussätze protokollieren die Stationen, die ein IDoc durchlaufen hat. Die Meldung im Statussatz nennt in aller Regel den fachlichen Grund, etwa ein fehlendes Konto oder einen unbekannten Partner. Wer nur die Statusnummer weitergibt, gibt die Hälfte der Information weiter.
Die Partnervereinbarung als erste Verdächtige behandeln
Formale Fehler im Eingang entstehen zum Beispiel dann, wenn die Partnervereinbarung nicht gefunden wird. Für die Einträge gibt es eine eingebaute Prüfung, die unter anderem kontrolliert, ob die zulässigen Bearbeiter und die angegebenen Vorgangscodes vorhanden sind.
Vor jeder Wiederholung nach dem Anwendungsbeleg suchen
Die Frage lautet nicht, ob das IDoc fehlerhaft ist, sondern ob im Zielsystem bereits ein Beleg entstanden ist. Diese eine Prüfung verhindert die doppelte Buchung, und sie kostet weniger Zeit als die Suche nach dem doppelten Beleg drei Wochen später.
Dafür sorgen, dass ein Fehler ankommt
Die zulässigen Bearbeiter werden aus den Partnervereinbarungen gelesen. Sind für eine Nachricht Bearbeiter eingetragen, werden diese benachrichtigt, sonst die für den Partner allgemein hinterlegten. Diese Einträge gehören gepflegt wie eine Rufbereitschaft und nicht wie eine Altlast.
Massenfehler anders behandeln als Einzelfälle
Wenn hundert IDocs desselben Nachrichtentyps gleichzeitig scheitern, ist die Ursache nicht hundertmal derselbe Fehler, sondern eine Änderung an einer Stelle. Erst die Ursache beheben, dann wiederholen, sonst produziert die Nacharbeit denselben Zustand noch einmal.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was ein Status sagt und was er nicht sagt
Die Statussätze protokollieren die Stationen, die ein IDoc auf seinem Weg durchläuft, etwa erzeugt oder versandbereit. Sie sind damit die Ablaufverfolgung eines einzelnen Belegs, und sie sind der Grund, warum sich der Weg eines IDocs im Nachhinein lückenlos nachvollziehen lässt. Was der Status allein nicht sagt, ist das Warum. Diese Auskunft steht in der Meldung des Statussatzes, und genau die wird beim Weiterreichen eines Falls am häufigsten weggelassen.
Für den Eingang gibt es dabei einen Status, den man kennen sollte, weil er den Großteil der Fälle abdeckt. SAP beschreibt die Ausnahmebehandlung im Eingang ausdrücklich als um eine Behandlung in der Anwendung erweitert, die auf den Status 51 reagieren kann, also auf den Zustand, dass der Anwendungsbeleg nicht gebucht wurde. Das ist der fachliche Fehler, und er ist in aller Regel nicht im IDoc zu beheben, sondern in den Stammdaten oder in einer Einstellung.
Welche Statuswerte überhaupt als Fehler gelten und was daraufhin geschieht, ist nicht in Stein gemeißelt. In der ALE-Konfiguration lässt sich festlegen, welcher Status als Fehler eingestuft wird und damit die Ausnahmebehandlung auslöst. Für den Betrieb heißt das: Wenn bei euch bestimmte Fehler nie auffallen, kann das an dieser Einstellung liegen und nicht daran, dass es sie nicht gibt.
Die drei Orte, an denen es hängen bleibt
Der erste Ort ist die Übertragung. Das IDoc ist erzeugt, hat das sendende System aber nicht verlassen, oder es ist unterwegs steckengeblieben. Der Statusmonitor, den du über Tools, IDoc-Schnittstelle und ALE, Administration, Monitoring erreichst, ordnet die IDocs nach Status in einer Hierarchie und lässt dabei auch die Einträge in der tRFC-Warteschlange sehen. Für die Selektion lohnt der Hinweis aus der Dokumentation: Änderungsdatum, Status und Nachrichtentyp sind die schnellste Kombination, die Auswahl über Geschäftsobjekttypen ist deutlich langsamer.
Der zweite Ort ist die Steuerung. Hier entscheidet sich, ob ein eingegangenes IDoc überhaupt einer Verarbeitung zugeordnet werden kann. Formale Fehler entstehen zum Beispiel, wenn die Partnervereinbarung nicht gefunden wird, und ebenso, wenn eine aktivierte Syntaxprüfung anschlägt. Fehler an diesem Ort sind gute Nachrichten, weil sie sich im eigenen Haus beheben lassen und der Partner nichts erneut senden muss.
Der dritte Ort ist die Anwendung. Das IDoc ist vollständig, es ist zugeordnet, und der Versuch, daraus einen Beleg zu erzeugen, ist an einer fachlichen Prüfung gescheitert. Diese Fälle machen den größten Teil aus, und sie haben eine unangenehme Eigenschaft: Ihre Ursache liegt oft weit weg, nämlich in einem Stammsatz, den jemand anders pflegt. Deshalb ist die Rückmeldung an die pflegende Stelle Teil der Bearbeitung und nicht ein zusätzlicher Gefallen.
Wiederholen, ohne doppelt zu buchen
Die Wiederholung ist technisch der einfachste Teil und im Betrieb der gefährlichste. Über den Statusmonitor lassen sich IDocs auch von Hand verarbeiten, einzeln oder nach einer Einschränkung, und die Ausnahmebehandlung sieht ausdrücklich vor, dass der Empfänger eines Arbeitsvorrats den Fehler beheben und die Verarbeitung der empfangenen IDocs erneut anstoßen oder das IDoc zum Löschen vormerken kann. Was das System nicht tut, ist nachzufragen, ob es den Beleg vielleicht schon gibt.
Deshalb gehört vor jede Wiederholung eine Prüfung im Zielsystem: Gibt es den Anwendungsbeleg bereits, über Referenznummer, Partner und Datum gesucht? Diese Prüfung dauert eine Minute. Der doppelte Beleg, den sie verhindert, kostet im ungünstigen Fall eine Rückabwicklung mit Buchhaltung, Zahlungsverkehr und einem Gespräch mit dem Partner. Das Verhältnis ist so eindeutig, dass diese Prüfung in die Arbeitsanweisung gehört und nicht in das persönliche Vorgehen einzelner Leute.
Die zweite Regel betrifft das Ändern von Inhalten. Ein IDoc mit korrigierten Daten neu zu verarbeiten, ist möglich und manchmal die einzige Lösung, aber es verändert die Beweislage: Danach steht im System etwas anderes, als der Partner gesendet hat. Wenn das nötig ist, gehört es dokumentiert, mit dem Grund und der Person. Bei wiederkehrenden Fällen ist die Änderung ohnehin die falsche Antwort, denn dann stimmt etwas an der Vereinbarung mit dem Partner nicht.
Dafür sorgen, dass ein Fehler überhaupt ankommt
Bei Fehlern werden Arbeitsvorräte erzeugt, die mit SAP-Aufgaben verknüpft sind und im Business Workplace des vorgesehenen Empfängers erscheinen. Die Aufgaben werden über Vorgangscodes identifiziert. Wer der Empfänger ist, wird aus den Partnervereinbarungen gelesen: Sind für die betreffende Nachricht Bearbeiter eingetragen, werden diese benachrichtigt, andernfalls die für den Partner allgemein hinterlegten. Findet sich gar keine passende Vereinbarung, werden die Bearbeiter auf anderem Weg bestimmt.
In der Praxis ist genau das die Stelle, an der Häuser blind werden. Die Einträge stammen aus dem Einführungsprojekt, die dort genannten Personen sind versetzt oder ausgeschieden, und niemand hat je geprüft, ob die Benachrichtigung noch bei jemandem ankommt. Die Partnervereinbarungen bringen dafür eine automatische Prüfung mit, die je Partner unter anderem kontrolliert, ob die zulässigen Bearbeiter und die angegebenen Vorgangscodes existieren. Diese Prüfung einmal im Jahr über alle Partner laufen zu lassen, ist eine Stunde Arbeit.
Ergänzend lässt sich festlegen, welchem Fehler- oder Statuscode welche Behandlung zugeordnet ist. Über die Zuordnung von Vorgangscodes zu Standardaufgaben, erreichbar über die Transaktion WE46, wird geprüft und gepflegt, welche Aufgabe bei welchem Fehlertyp anspringt. Wer eigene Verarbeitungen gebaut hat, muss diese Zuordnung dort ausdrücklich mitpflegen, sonst gibt es die Verarbeitung, aber keine Benachrichtigung, wenn sie scheitert.
Massenfehler sind ein anderer Fall
Wenn hundert IDocs desselben Nachrichtentyps innerhalb einer Stunde scheitern, ist das kein hundertfacher Einzelfall. Irgendetwas hat sich geändert: eine Einstellung, ein Stammsatz, ein Umrechnungskurs, ein Feldinhalt beim Partner. Die Nacharbeit eines nach dem anderen ist an dieser Stelle die teuerste Reaktion, weil sie den Zustand wiederherstellt, aus dem heraus die nächsten hundert scheitern werden.
Die richtige Reihenfolge ist deshalb: erst ein einzelnes IDoc aufmachen und die Meldung im Statussatz lesen, dann prüfen, ob alle betroffenen IDocs dieselbe Meldung tragen, dann die Ursache beheben, und erst danach die Menge wiederholen. Der Statusmonitor unterstützt das, weil er die IDocs nach Status in einer Hierarchie anordnet und sich zusätzlich nach Nachrichtentyp, Objekttyp oder Partnersystem gliedern lässt. Damit ist in wenigen Minuten sichtbar, ob ein Muster vorliegt.
Für die Wiederholung großer Mengen gilt die Prüfung auf bestehende Belege genauso, nur eben in Listenform. Wenn sich das nicht mit vertretbarem Aufwand prüfen lässt, ist die kleinere Portion die bessere Wahl: erst zehn wiederholen, das Ergebnis ansehen, dann den Rest. Das dauert eine halbe Stunde länger und erspart im Zweifel eine Woche Aufräumarbeit in der Buchhaltung.
Dazu passende Kurse
Weil die Fehlersuche voraussetzt, dass jemand den ganzen Weg eines Belegs kennt, sind SAP-Kurse zu Schnittstellen und Datenübernahme der schnellste Weg aus der Abhängigkeit von einzelnen Personen.
Und wo eigene Verarbeitungen im Spiel sind, gehören ABAP-Kurse für die Arbeit an eigenen Verarbeitungsbausteinen dazu, denn dort entscheidet sich, ob ein Fehler überhaupt eine Meldung erzeugt.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Was bedeutet der Status 51 genau?
Wo finde ich fehlerhafte IDocs am schnellsten?
Muss der Partner das IDoc noch einmal senden?
Wie verhindern wir doppelte Belege bei der Wiederholung?
Warum bemerkt bei uns niemand die Fehler?
Sollen wir Inhalte im IDoc korrigieren und dann neu verarbeiten?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Schnittstellen so betreiben, dass ein Fehler auffällt
Wie IDoc, Partnervereinbarung und Verarbeitung zusammenhängen und wie eine Wiederholung sauber läuft, arbeitest du bei cmt am System durch, mit echten Fehlerfällen statt mit einer Ablaufgrafik.