EDI ist in vielen mittelständischen Unternehmen über fünfzehn oder zwanzig Jahre gewachsen. Jeder Großkunde hat seine Sonderwünsche bekommen, jeder neue Lieferant eine eigene Partnervereinbarung, jedes Z-Segment eine pragmatische Erweiterung „für jetzt mal“. Dieses „für jetzt mal“ steht in den meisten ECC-Systemen heute noch.
In der S/4HANA-Migration kommt all das auf den Prüfstand. Nicht weil EDI selbst grundlegend neu wäre, sondern weil die darunterliegende Welt (Business Partner statt KU/LI, neue Adressmodelle, neue Konvertierungsregeln) Annahmen verändert, die jahrelang gehalten haben.
Hier sind die fünf Stellen, an denen wir in fast jedem Mittelstandsprojekt Bremsspuren sehen.
1. Partnerprofile, die niemand mehr versteht
Die Transaktion WE20 ist in vielen ECC-Systemen ein Friedhof. Aktive Partner stehen neben Karteileichen aus dem Jahr 2009. Logische Systeme verweisen auf Subsysteme, die längst abgeschaltet sind. Test-Partner laufen in der Produktion mit, weil sie irgendwann mal kurzfristig angelegt wurden und niemand sie wieder herausgenommen hat.
Mit der S/4HANA-Migration und der Umstellung auf Business Partner ändert sich, wie Partner referenziert werden. Konkrete Folgen:
- KU-Partner und LI-Partner in der Partnervereinbarung verweisen auf neue BP-Nummern.
- Customer-Vendor-Integration verändert, welche Stammdaten welche Partnerseite halten.
- Logische Systeme im neuen System haben oft neue Namen, was tausende Partnerprofile gleichzeitig berührt.
Realistische Vorgehensweise: Vor dem Cutover eine WE20-Inventur machen. Welcher Partner ist wirklich aktiv (mit IDocs in den letzten zwölf Monaten), welcher gehört abgeschaltet, welcher braucht neue Zuordnung. Diese Arbeit dauert Tage, nicht Stunden, ist aber die Voraussetzung dafür, dass der erste Tag nach Go-Live ruhig bleibt.
2. Z-Mappings ohne Dokumentation
Praktisch jedes mittelständische EDI-Setup hat im Hintergrund Z-Tabellen mit Mappings. Mengeneinheiten, Materialnummern, Werkscodes, Ländercodes, Zahlungsbedingungen, Incoterms. Über die Jahre haben verschiedene Berater und interne Entwickler hier ergänzt, korrigiert und workaround-mäßig erweitert.
Die typischen Probleme:
- Niemand weiß mehr genau, welche Z-Tabelle für welchen Partner gilt.
- Konversionsexits (CONVERSION_EXIT_ALPHA_INPUT und ähnliche) verstecken sich an Stellen, die im Mapping-Diagramm nicht auftauchen.
- Mappings für ausgeschiedene Partner laufen seit Jahren leer mit.
- Werte werden bei manchen Partnern hart codiert, statt aus dem Customizing zu kommen.
In der Migration zeigt sich das schmerzhaft. Im Testsystem laufen die IDocs durch, aber mit subtil anderen Inhalten. Mengenangaben weichen ab. Preise werden gerundet. Texte erscheinen in anderer Sprache. Der Wirtschaftsprüfer fragt, warum die Mengen auf dem Wareneingang nicht zu dem passen, was der Kunde bestellt hat.
Pragmatischer Ansatz: Jede Z-Tabelle, die im IDoc-Datenfluss eine Rolle spielt, gehört in eine schriftliche Übersicht. Wer, was, wann, warum. Zwei Tage Aufwand für eine Tabelle, die zehn Jahre Stolpergefahr verhindert.
3. Segment-Erweiterungen, die kein Standard mehr sind
Hier liegt einer der unangenehmsten Bereiche. Über die Jahre haben Unternehmen ZE1EDP01, ZE1EDL20 und andere Z-Segmente an Standard-IDocs angehängt, weil ein Kunde ein zusätzliches Feld brauchte oder ein Lieferant eine Sonderlogik forderte. Diese Erweiterungen sind technisch sauber gemacht. Dokumentiert sind sie selten.
Beim Wechsel auf S/4HANA passieren zwei Dinge:
- SAP hat einige Standard-Segmente erweitert. Eigene Z-Segmente können mit den neuen Feldern kollidieren oder redundant werden.
- Mappings im Subsystem (oft eine Middleware wie SAP PI/PO, Seeburger oder ein klassischer EDI-Konverter) müssen für jedes Z-Segment einzeln geprüft werden.
Die Standardmigration testet das nicht automatisch. Wer hier nicht aktiv prüft, geht mit Z-Segmenten live, die teilweise leer laufen, teilweise doppelt füllen, teilweise gegen geänderte Standardlogik laufen.
Empfehlung: Liste aller eingesetzten Z-Segmente erstellen, pro Segment den fachlichen Eigentümer benennen, pro Segment einen Testfall im SIT durchspielen. Klingt aufwendig, ist aber genau das, was niemand sonst übernimmt.
4. ORDERS mit Kundenspezifika, die im Code stecken
Eingehende Kundenaufträge (Nachrichtentyp ORDERS, Bearbeitungsbaustein IDOC_INPUT_ORDERS) sind in fast jedem SD-System der Punkt, an dem die meiste eigene Logik hängt. Typische Beispiele aus echten Projekten:
- Kundenspezifische Preisfindung, die Partner-IDs auf bestimmte Konditionssätze mappt.
- Lieferadressen, die nicht aus dem Kundenstamm, sondern aus dem IDoc kommen, mit eigenen Plausibilitätsprüfungen.
- Materialerkennung über Kunden-Materialnummern (Tabelle KNMT) plus zusätzliche Fallback-Logik in Z-Code.
- Versandbedingungen, die je nach Werk und Kunde dynamisch gesetzt werden.
In der Migration laufen diese Sonderlogiken nicht automatisch weiter. BAdIs wandern, Erweiterungspunkte verändern sich, Standardvalidierungen in S/4HANA sind teilweise strenger. Was in ECC stillschweigend durchging, wird in S/4 abgewiesen.
Konkrete Empfehlung: Den eingehenden ORDERS-Prozess mit echten Produktionsdaten von mindestens drei verschiedenen Großkunden im SIT durchspielen. Nicht stichprobenartig, sondern als End-to-End-Test bis zur Auftragsbestätigung und idealerweise bis zur ersten Lieferung.
5. DESADV-Sonderausgaben und das fehlende Monitoring
Die Lieferavise (DESADV, DELVRY) ist meist das Segment mit den meisten kundenspezifischen Ausprägungen. Automotive-Kunden erwarten andere Felder als Handelsketten, Pharma andere als Maschinenbau. Über die Jahre entstehen Varianten je Großkunde, oft kombiniert mit Handling Units, SSCC-Nummern (NVE), Verpackungshierarchien.
Zwei typische Stolperfallen:
Erstens: Nach der Migration ändert sich die Reihenfolge oder Belegung einzelner Segmente. Der Kunde reklamiert nicht sofort. Er reklamiert drei Wochen später, wenn die ersten Rechnungen nicht passen, weil die Wareneingangsbuchungen auf seiner Seite falsch sind.
Zweitens, und das ist der noch unangenehmere Punkt: In den meisten Mittelstandssystemen läuft das IDoc-Monitoring auf der Logik „rote IDocs werden täglich angeschaut, gelbe ignorieren wir“. Damit gehen nach der Migration genau die Fälle unter, die der Standard zwar verarbeitet, der Kunde aber als fehlerhaft empfindet.
Was in jedes Migrationsprojekt gehört: ein DESADV-Monitoring, das nicht nur den IDoc-Status prüft, sondern den fachlichen Inhalt. Wurden alle Positionen avisiert? Stimmen die Mengen mit dem Lieferschein überein? Sind alle Handling Units enthalten? Erst dann ist der Prozess wirklich abgesichert.
Fazit
EDI in der S/4HANA-Migration ist kein technisches Risiko, weil die Technik gut bekannt ist. Es ist ein Dokumentations- und Disziplinrisiko. Genau die Stellen, an denen Mittelständler in den letzten zwanzig Jahren pragmatisch ergänzt haben, fallen jetzt auseinander, wenn niemand sie systematisch durchgeht.
Die richtige Reihenfolge ist überschaubar. Erst Partnerprofile aufräumen. Dann Z-Mappings inventarisieren. Dann Z-Segmente dokumentieren und testen. Dann den eingehenden ORDERS-Prozess mit echten Daten validieren. Und schließlich das fachliche Monitoring für ausgehende DESADV einrichten.
Wer diese fünf Punkte vor dem Cutover sauber durchhat, geht in eine Migration, in der EDI nicht die erste Eskalationsstufe ist. Das allein rechtfertigt den Aufwand.