Wenn die Abruf- und Versandstrecke seit Jahren läuft, weiß im Haus meist niemand mehr vollständig, was darin konfiguriert ist. Partnerprofile sind über Jahre gewachsen, Nachrichtenarten sind dazugekommen, Fehler werden täglich abgearbeitet — aber den Bestand als Ganzes sieht sich niemand an. Der Health-Check ist genau diese Bestandsaufnahme: wenige Tage, rein lesend.
Rein lesend heißt: Ich brauche Anzeigeberechtigung im System und Einsicht in den EDI-Betrieb, aber ich ändere nichts. Es entsteht kein Transport, kein Customizing-Eintrag und keine Nachverarbeitung. Das Ergebnis ist ein Bericht mit Befund und Rangfolge — was zuerst angefasst gehört, was warten kann und was nur dokumentiert werden muss.
Was ich mir ansehe
- Partnerprofile und Nachrichtensteuerung. Die Partnervereinbarungen in WE20 je Partner und Nachrichtenart, die zugeordneten Vorgangscodes im Ein- und Ausgang und die Ausgabesteuerung dahinter.
- Die tatsächlich verkehrenden Nachrichtenarten. Lieferabruf und Feinabruf, JIT-Abruf, Lieferavis, Rechnung, Gutschriftsanzeige, Zahlungsavis. Dazu je Partner die Frage, ob noch die alten VDA-Satzarten laufen oder bereits die Global-Serie – 4984 für den Lieferabruf, 4985 für den JIT-Abruf, 4987 für das Lieferavis, 4938 für Rechnung und Gutschriftsanzeige, 4988 für den Zahlungsavis.
- Der Fehlerbestand. Welche Meldungen wie oft auftreten, bei welchen Partnern, und ob sie abgearbeitet oder nur weggeklickt werden.
- Das Customizing hinter der Lieferplanfindung. Ob je Partner ein Satz in T661W vorhanden ist und wie T663A eingestellt ist — dort entscheidet sich, ob Abladestelle und Bestellnummer überhaupt als Findungskriterium wirken.
- Einzelne Kennzeichen mit großer Wirkung. Ob die Packmittelart des Verpackungsmaterials über die Nummernvergabe in TVTY tatsächlich eine NVE erzeugt oder die Handling Unit ihre Nummer aus dem HU-Nummernkreis zieht — im zweiten Fall entsteht gar keine NVE. Oder ob beim Warenempfänger die Geschäftsjahresvariante in den allgemeinen Kundenstammdaten (KNA1-PERIV) gepflegt ist; fehlt sie, rechnet SAP den Fortschrittszahl-Jahreswechsel mit dem Kalenderjahr.
Der Abgleich, der am meisten findet
Der ergiebigste Teil ist der Abgleich zwischen den konfigurierten Partnerprofilen und den Partnern, die im letzten Jahr wirklich Verkehr hatten. Erfahrungsgemäß ist ein erheblicher Teil der Profile Karteileiche: Partner, die es so nicht mehr gibt, Nachrichtenarten, die abgelöst wurden, Vorgangscodes aus einem Testaufbau. Angefasst hat das niemand, weil es nicht weh tut.
Weh tut es später: Dieser Bestand wandert bei jeder Migration mit. Er wird getestet, dokumentiert und abgenommen, obwohl kein einziger Beleg darüber läuft. Wer vor einem Umstieg weiß, welche Profile lebendig sind, spart Testaufwand an genau der Stelle, an der er sonst blind entsteht.
Warum der Fehlerbestand mehr sagt als der Fehlerstatus
Der IDoc-Status ist als Maßstab zu grob. Zwei Beispiele aus der Lieferplanfindung, die auf demselben Fehlerstatus stehen: V4 034 heißt, dass es keinen Treffer im Index gibt. V4 035 heißt, dass es mehrere gibt und die Findung nicht eindeutig ist. Die Korrekturen laufen in entgegengesetzte Richtungen — einmal fehlt der Lieferplan, einmal gibt es zu viele.
Eine Auswertung auf Statusebene zeigt eine Zahl. Eine Auswertung auf Meldungsebene zeigt, welche Arbeit dahintersteckt — und ob es zehn Ursachen sind oder eine, die zehnmal auftritt.
Deshalb werte ich den Bestand nach Meldung aus, nicht nach Status. V4 032 und V4 033 zeigen fehlendes Customizing in T661W und T663A und sind damit sofort zuzuordnen. V4 073 bis 075 protokollieren die Findungswerte, mit denen sich ein 035 auch nachträglich noch auflösen lässt. Aus dieser Verteilung entsteht die Rangfolge im Bericht.
Konfigurationsstände, die auseinandergelaufen sind
Neben dem Standard laufen bei vielen Zulieferern Automotive-Add-ons für Abrufe, Etiketten, Packmittel und Gutschriftsprüfung. Wirksam wird eine solche Funktion erst über ihre Konfiguration je Kunde, Werk und Abrufart. Laufen Entwicklungs-, Test- und Produktivstand dieser Konfiguration auseinander, rechnet derselbe Abruf im Test anders als produktiv — und der Test bewertet dann etwas, das so nie live geht. Dieser Vergleich der Stände gehört in den Health-Check, weil er rein lesend möglich ist und die Aussagekraft aller späteren Tests bestimmt.
Rahmen und Ergebnis
| Umfang | Wenige Tage, abhängig von der Zahl der Partner und Nachrichtenarten |
| Zugriff | Anzeigeberechtigung im SAP-System, Einsicht in den Konverter-Betrieb |
| Eingriff | Keiner. Kein Transport, kein Customizing, keine Nachverarbeitung |
| Release | ECC 6.0 und S/4HANA |
| Ergebnis | Bericht mit Befund und Rangfolge |
| Danach | Die Punkte der Rangfolge einzeln, als Paket oder in eigener Hand |
Der Health-Check verpflichtet zu nichts. Er ist ausdrücklich auch als Zweitmeinung gedacht — vor einem Umstieg, vor einem Onboarding-Projekt oder wenn im Betrieb der Eindruck entsteht, dass immer dieselben Fehler wiederkommen.
Nächster Schritt
Am schnellsten kommen wir voran, wenn Sie in ein paar Sätzen beschreiben, was ansteht: welche Kunden oder OEM, welche Nachrichten, welches Release. Anfragen beantworte ich kurzfristig. Im ersten Gespräch sage ich, ob ich der Richtige bin und in welchem Zuschnitt; den Umfang klären wir dort ebenfalls.
