Am liebsten steige ich am Fehlerbild ein. Nicht bei der Frage, wie ein Prozess idealerweise aussehen sollte, sondern bei der Meldung, die heute im Eingang steht — mit Belegnummer, Nachrichtenart und Systemstand. Von dort aus arbeite ich rückwärts zur Ursache und von der Ursache aus vorwärts zum Konzept.
Einstieg am Fehlerbild
Ein Beispiel aus der Lieferplanfindung: Ein Abruf bleibt mit der Meldung V4 035 stehen, kein eindeutiger Lieferplan. Der Anwender antwortet, es gebe doch nur einen — und hat damit recht, ohne dass die Meldung falsch wäre.
Findet der Standard mit dem vollen Schlüssel nichts, sucht er ein zweites Mal, nur noch über Kundennummer und Kundenmaterial. Dieser zweite Zugriff endet immer in 035, auch bei genau einem Treffer — SAP behandelt den Einzeltreffer aus der Notsuche bewusst so, als wären es mehrere. Die Ursache liegt deshalb eine Ebene früher: Kundenwerk oder Abladestelle passen nicht zum Index, oder in der Partnertabelle T663A ist eingestellt, dass die Abladestelle geprüft werden soll.
Wer 035 als „mehrere Lieferpläne“ liest und im Beleg nach dem zweiten sucht, sucht an der falschen Stelle. Auflösen lässt sich der Fall über das Protokoll: Die Meldungen V4 073, 074 und 075 zeigen die Findungswerte, mit denen der Standard tatsächlich gesucht hat.
V4 034 ist das gegenteilige Bild, gar kein Treffer. Häufig, weil eine Lieferplanposition einen Absagegrund trägt: Sie steht weiter im Index, fällt aber aus der Trefferliste und wird nur als Warnung protokolliert. Von außen sieht das aus, als sei der Lieferplan über Nacht verschwunden.
Symptome, die gleich klingen
Dasselbe gilt für Beschwerden, die sich ähnlich anhören und verschiedene Ursachen haben. „Die Position taucht in VL10 nicht auf“ und „es entsteht kein Bedarf“ sind zwei getrennte Schalter im Einteilungstyp mit zwei getrennten Datenspuren:
| Schalter im Einteilungstyp | Füllt | Symptom, wenn er fehlt |
|---|---|---|
| Lieferrelevanz | Lieferfälligkeitsindex VEPVG | Die Einteilung erscheint nicht in VL10 — der Bedarf kann trotzdem stehen |
| Bedarfsübergabe | Bedarfssatz in VBBE | Die Disposition sieht nichts — geliefert werden kann die Einteilung trotzdem |
Wer beides zusammenwirft, dreht am falschen Kennzeichen und wundert sich, dass das Symptom bleibt. Solche Unterscheidungen sauber zu treffen, ist der eigentliche Inhalt der Analyse — das Customizing danach ist meist eine Sache von Minuten.
SAP-Seite und EDI-Vorgabe in einer Hand
Bei EDI liegen SAP-Seite und Spezifikation bei mir: Partnervereinbarung, Vorgangscodes, Nachrichtensteuerung und die Fehlerbestände im Eingang. Für den Konverter schreibe ich die Vorgabe je Feld, prüfe das Ergebnis und teste es gegen den Beleg im System.
Das erspart die Schleife, in der sich zwei Zuständigkeiten denselben Fehler gegenseitig zuschieben — der Konverter verweist auf das SAP-Customizing, das Customizing auf das Mapping, und dazwischen liegt eine Woche. Was nicht bei mir liegt, ist Betrieb und Administration der Konverterplattform.
Was am Ende schriftlich vorliegt
Ein Konzept halte ich erst dann für fertig, wenn der Fehlerfall darin steht. Entsprechend sieht das aus, was ich übergebe:
- Fachkonzept mit dem Sollprozess und den Fällen, in denen er nicht greift.
- Customizing-Dokumentation: was wo eingestellt ist und warum.
- Testfälle mit Protokoll — nachvollziehbar, nicht nur abgehakt.
- Schulungsunterlage für die Anwender, die danach damit arbeiten.
- Eine Übergabe, mit der ein AMS-Team oder ein Inhouse-Nachfolger weiterarbeiten kann.
Jede transportfähige Änderung geht über einen Transportauftrag, auch die kleine. Nichts wird direkt im Zielsystem nachgezogen.
Allein, mit Partnern wo nötig
Ich arbeite als Einzelberater. Konzept, Customizing, Test und Abnahme bleiben bei mir, und Sie haben einen Ansprechpartner.
Wo eine Aufgabe mehr als eine Person braucht — ABAP-Entwicklung im Vertriebs-, Versand- und EDI-Umfeld, Basis-Themen, Testunterstützung in einem Rollout —, ziehe ich Partner hinzu, mit denen ich bereits gearbeitet habe. Wer das ist, sage ich vorher, und Sie entscheiden mit.
Was ich nicht zusage: einen Betriebsdienst mit Rufbereitschaft und Vertretung. Dafür braucht es eine Mannschaft, und die stelle ich nicht. Wenn ein Mandat darauf hinausläuft, sage ich das im ersten Gespräch.
Nützlich für den ersten Anruf
Welche Nachrichtenart betroffen ist, welche Meldung im IDoc steht und ob das System auf ECC oder S/4HANA läuft. Mit diesen drei Angaben lässt sich im ersten Gespräch meist schon sagen, wo der Fehler sitzt. Telefon +49 173 7611960, E-Mail robert@lissack.de.