Von SAP-IDoc zu cXML: Eine EDI-Umstellung mit einem Pharma-Grosskunden

Der Auslöser

Vendor-Managed Inventory funktioniert nur, wenn der Lieferant regelmässig weiss, was beim Kunden auf Lager ist und was verbraucht wurde. Bei einem Fertigungsbetrieb mit zwei Standorten lief dieser Austausch mit einem Pharma-Grosskunden seit Jahren stabil: Der Kunde schickte SAP-IDocs vom Typ PROACT01 per SFTP, ein EDI-Dienstleister übersetzte sie, und die Daten landeten im ERP.

Dann führte der Kunde eine neue Beschaffungsplattform ein. Die Vorgabe: Ab einem Stichtag kommen die Bestandsdaten nicht mehr als IDoc, sondern als cXML ProductActivityMessage per HTTPS-POST über die Plattform. Der Lieferant hat da wenig Verhandlungsspielraum. Man baut um, oder man verliert die Automatisierung.

Ist und Soll sauber trennen

Der erste Schritt war nicht technisch. Wir haben den bestehenden Ablauf vollständig beschrieben: welches System sendet wann was, welche Felder das ERP tatsächlich nutzt, wo der EDI-Dienstleister umwandelt, was bei Fehlern passiert. Das klingt banal, aber niemand hatte diese Beschreibung. Sie existierte verteilt über drei Parteien und einige E-Mails aus der Zeit der Ersteinrichtung.

Erst mit dem Ist-Bild konnten wir das Soll definieren. Die Unterschiede zwischen den beiden Formaten sind grösser, als man denkt:

• Transport: SFTP mit Datei-Polling versus HTTPS-POST mit sofortiger Antwort. Das Fehlerverhalten ist grundverschieden.
• Struktur: IDoc-Segmente sind flach und positionsbezogen; cXML ist ein XML-Dokument mit verschachtelten Elementen.
• Semantik: Was im IDoc ein Segmentfeld mit Kennzeichen ist, ist in cXML ein eigener Elementtyp.

Das Feldmapping ist die eigentliche Arbeit

Der Kern des Projekts war eine Mapping-Spezifikation: für jedes Feld, das das ERP braucht, die Quelle im alten und im neuen Format. Wir haben sie in vier Blöcke gegliedert:

1. Header: Absender, Empfänger, Zeitstempel, Nachrichten-ID. Klingt einfach, aber die Identifikatoren des Kunden haben in der neuen Plattform ein anderes Format.
2. Positionen: Artikelnummer des Kunden, Artikelnummer des Lieferanten, Einheit. Die Zuordnung der Artikelnummern musste geprüft werden – nicht jede Nummer, die im IDoc kam, kommt in cXML gleich.
3. Mengenarten: Der heikelste Teil. Lagerbestand, Verbrauch, offene Bestellungen, Mindestbestand – jede Mengenart hat im cXML eine eigene Kennzeichnung, und die Zuordnung zu den IDoc-Feldern war nicht eins zu eins. Hier haben wir am längsten mit dem Kunden abgestimmt.
4. Adressen: Lieferstellen und Lagerorte. In cXML sind das strukturierte Adressblöcke, im IDoc waren es Kennungen, die das ERP intern auflöste.

Für jedes Feld steht in der Spezifikation: Pflichtfeld oder optional, Format, Beispielwert, und was passiert, wenn es fehlt.

Drei Parteien koordinieren

Technisch hätte man das Mapping an einem Nachmittag umsetzen können. Real dauerte das Projekt Wochen, weil drei Parteien beteiligt waren:

• Der Kunde mit seiner Plattform und deren Vorgaben – und einem Testfenster, das nicht verschoben werden konnte
• Der EDI-Dienstleister, der die Übersetzung in das ERP-Format vornimmt und für den cXML ebenfalls eine Anpassung bedeutete
• Die ERP-Seite, wo geprüft werden musste, ob die bestehende Importschnittstelle die neuen Daten ohne Änderung verarbeitet

Unsere Rolle war die des Übersetzers zwischen diesen dreien. Die Mapping-Spezifikation war das gemeinsame Dokument, an dem sich alle orientierten – das hat mehr Missverständnisse verhindert als jede Telefonkonferenz.

Was wir anders machen würden

• Früher mit Testnachrichten des Kunden arbeiten, statt nur mit der Dokumentation der Plattform. Die Realität wich in Details ab.
• Das Fehlerverhalten von Anfang an mitplanen: Was passiert, wenn der HTTPS-POST fehlschlägt? Wer sieht das? Beim SFTP-Verfahren blieb die Datei einfach liegen; bei HTTPS ist sie weg.
• Die Ist-Beschreibung schon vor dem Auslöser haben. Sie wäre bei jeder Störung nützlich gewesen.

Fazit

EDI-Umstellungen sind selten technisch schwierig, aber fast immer organisatorisch anspruchsvoll. Der Wert liegt in einer sauberen Mapping-Spezifikation, die alle Beteiligten verstehen, und in der Disziplin, Ist und Soll getrennt zu beschreiben. Wer das hat, kann den nächsten Formatwechsel – und er kommt – mit deutlich weniger Aufwand bewältigen.