Die Ausgangslage: ODTFINCC läuft aus
Wer im SAP-Umfeld Kostenstellen aus einem ERP-System in SuccessFactors Employee Central repliziert, kennt die klassische Lösung: Ein IDoc vom Typ ODTF_CCTR01 verlässt das ERP, landet über einen CPI-Iflow im Employee Central und hält dort die Kostenstellenhierarchie aktuell. Diese Integration läuft seit Jahren stabil, und genau das macht die Situation so tückisch.
SAP hat mit der Note 3255864 klargestellt, dass die Softwarekomponente ODTFINCC mit dem S/4HANA Release 2025 deprecated wird. Wer die Komponente noch einsetzt, sollte spätestens jetzt handeln, entweder beim nächsten Release-Upgrade oder proaktiv davor.
SAPs offiziell empfohlener Migrationsweg ist der Master Data Integration Service (MDI) auf der BTP, der laut SAP-Dokumentation die Kostenstellen-Replikation künftig übernehmen soll. Für viele Kunden ist das aber mehr Aufwand als nötig.
Warum MDI für kleine IT-Landschaften oft überdimensioniert ist
MDI ist ein mächtiger, zentraler Master-Data-Service auf der BTP. Er macht Sinn, wenn man viele Stammdatenobjekte aus mehreren Quellsystemen in verschiedene Cloud-Anwendungen verteilen will und eine zentrale Governance braucht. Für den Fall "Kostenstellen von einem ERP-System nach SuccessFactors" sieht die Rechnung meistens anders aus:
- MDI muss als neuer BTP-Service aufgesetzt, konfiguriert und betrieben werden, was Zeit kostet und Wissen erfordert, das im Team oft erst aufgebaut werden muss.
- Ein weiterer Service bedeutet ein weiteres Monitoring. Im Tagesgeschäft muss jemand wissen, wo er nachschauen muss, wenn die Replikation stockt.
- MDI ist lizenzpflichtig. Für ein einzelnes Integrationsobjekt lässt sich das gegenüber dem Kunden schwer rechtfertigen.
- CPI ist bei den meisten modernen SAP-Landschaften ohnehin vorhanden, die Infrastruktur für eine Alternative ist also bereits da.
Ich sage das nicht, um MDI schlecht zu reden. Aber ich halte es für wichtig, den Business Case ehrlich zu rechnen, bevor man die Plattform wechselt.
Die Idee: Das bewährte SAP-Integrationspaket weiterverwenden
Im CPI-Content-Katalog stellt SAP das Paket "SAP ERP or SAP S/4HANA Integration with SAP SuccessFactors Employee Central: Cost Center" bereit. Es ist seit Jahren produktiv im Einsatz, gut dokumentiert und für die meisten Kundenumgebungen bereits bekannt. Die Idee ist einfach: Dieses Paket nicht wegwerfen, sondern anpassen.
Statt des deprecated IDoc-Typs ODTF_CCTR01 (aus ODTFINCC) nutzt man den Standard-IDoc COSMAS01 — der von SAP-ERP und S/4HANA im Standard ausgeliefert wird und Kostenstellen über die klassische ALE-Verteilung transportiert. Im CPI-Paket wird lediglich das Mapping ausgetauscht: rein kommt COSMAS, raus geht weiterhin die SFSF-EC-API. Der Rest des Iflows (Routing, Fehlerbehandlung, Logging) bleibt unverändert.
Der Vorteil: Man bewegt sich auf bekanntem Terrain. Kein neuer Service, kein neues Konzept, kein neues Monitoring-Tool. Wer ALE und CPI kennt, kann diese Migration in wenigen Tagen umsetzen.
So geht man vor
1. SAP-Integrationspaket kopieren
Im Discover-Bereich des CPI-Tenants findet man das Kostenstellen-Paket über die Suche. Statt es direkt zu nutzen, kopiert man es in den eigenen Workspace — so behält man den SAP-Standard als Referenz und kann die Kopie frei anpassen. Das ist gängige Praxis und schützt vor unerwünschten Updates, die das Original überschreiben würden.
2. Mapping anpassen
Im kopierten Iflow ersetzt man das Quell-Mapping: Statt ODTF_CCTR01 erwartet der Iflow nun ein COSMAS01-IDoc als Eingang. Die relevanten Felder (Kostenstellennummer, Bezeichnung, Gültigkeitszeitraum, Buchungskreis, Kostenrechnungskreis, übergeordnete Kostenstelle, verantwortliche Person) sind in COSMAS vollständig vorhanden und lassen sich direkt auf das SuccessFactors-EC-Kostenobjekt mappen.
Worauf ich beim Mapping achte: Sprachabhängige Texte (Kurz- und Langtext) müssen separat behandelt werden, wenn EC mehrsprachig betrieben wird. Außerdem sollte man das Effective Dating im Blick behalten: EC arbeitet mit zeitabhängigen Datensätzen, und das Startdatum der Kostenstelle muss korrekt übertragen werden, damit historische Daten nicht verloren gehen.
3. ALE-Verteilung im ERP einrichten
Auf der ERP-Seite aktiviert man die Verteilung über die klassischen ALE-Mechanismen: Das Verteilungsmodell wird um den Nachrichtentyp COSMAS ergänzt, und man legt die Partnervereinbarung mit dem CPI-Endpunkt als Zielport an. Für die laufende Synchronisation empfehle ich die Änderungszeiger-basierte Verteilung, damit werden nur geänderte Kostenstellen ausgesendet, nicht bei jedem Lauf der komplette Bestand.
Das ist nichts Neues: Wer bereits andere Stammdaten per ALE verteilt, kennt diesen Mechanismus. Der einzige Unterschied ist, dass der Empfänger diesmal nicht ein anderes SAP-System ist, sondern der CPI-Iflow.
4. Testen und go live
Ich empfehle, mit einer einzelnen Testkostenstelle zu starten: Änderung im ERP vornehmen, IDoc manuell aussteuern, im CPI-Monitor verfolgen, Ergebnis in SuccessFactors prüfen. Wenn das Mapping stimmt und der Iflow fehlerfrei durchläuft, kann man die Änderungszeiger-basierte Verteilung aktivieren und auf die gesamte Kostenstellenhierarchie ausweiten.
Aufwand und Wirtschaftlichkeit
Realistisch betrachtet liegt der Umsetzungsaufwand (Paket kopieren, Mapping bauen, ALE konfigurieren, testen) bei wenigen Personentagen. In Projekten, in denen CPI bereits im Einsatz ist und ALE-Verteilung bekannt ist, kann man das noch kürzer halten.
Es entstehen keine zusätzlichen Lizenzkosten. Das Monitoring läuft über denselben CPI-Kanal wie alle anderen Iflows. Und weil es sich um ein bewährtes SAP-Paket handelt, ist das Risiko von Kinderkrankheiten überschaubar.
Wann MDI dennoch die richtige Wahl ist
Ich will fair bleiben: Es gibt Szenarien, in denen MDI klar die bessere Lösung ist. Wenn mehrere Quellsysteme Kostenstellen liefern, wenn neben Kostenstellen auch andere Stammdaten (Mitarbeiter, Profitcenter, Geschäftspartner) zentral synchronisiert werden sollen, oder wenn ein Unternehmen ohnehin auf eine BTP-zentrierte Master-Data-Strategie setzt — dann ist MDI der richtige Weg. Die Abwägung lohnt sich. Nur für ein einzelnes Objekt aus einem einzelnen Quellsystem ist MDI in meinen Augen selten gerechtfertigt.
Fazit
Die Deprecation von ODTFINCC ist kein Notfall, aber sie braucht eine bewusste Antwort. Wer MDI reflexartig als den einzigen Weg betrachtet, weil SAP ihn empfiehlt, verschenkt möglicherweise Zeit und Budget. Das bestehende CPI-Integrationspaket mit einem angepassten COSMAS-Mapping weiterzuverwenden ist technisch sauber, wirtschaftlich sinnvoll und in den meisten Projekten die pragmatischere Wahl.
Ich habe diese Lösung bereits in einem Kundenprojekt umgesetzt. Wenn du Fragen zur konkreten Umsetzung hast oder in einem ähnlichen Szenario steckst, meld dich gerne.