Im Zuge einer SAP S/4HANA System Conversion sind diverse geschäftslogische Vorbereitungen zu treffen, bevor Sie die Konvertierung durchführen. Viele dieser Änderungen haben mit der Integration von Softwarekomponenten und Line of Business Modulen im S4/HANA Core sowie mit einer Vereinfachung des Datenmodells zu tun. Diese Änderungen sind als sogenannte Vereinfachungen (Simplifications bekannt).
In diesem Beitrag sammele ich die am häufigsten benötigten Vorarbeiten und Überlegungen im Hinblick auf die betriebswirtschaftliche bzw. fachbereichsspezifische Vorbereitung eines SAP ERP Systems vor einer System Conversion. Das bedeutet, dass die hier aufgeführten Änderungen nur die gängigsten darstellen und ein Studium der Simplification List und eine Analyse mit Hilfe der entsprechenden Pre-Checks nicht ersetzen kann. Wir werden uns zunächst mit dem Begriff der Simplification Items und der Simplification List befassen und gehen danach sofort ans Eingemachte.
Simplifications bezeichnen die Zusammenführung von Entitäten und Softwaremodulen, die früher in mehreren Systemen unter verschiedenem Namen geführt wurden, unter S/4HANA – sowie Erweiterungen des Datenmodells. So wurden früher beispielsweise im SAP ERP System die Entitäten des Debitor/Kreditor Paares („Customer/Vendor“) und in SAP CRM der Geschäftspartner („Business Partner“) gepflegt. In SAP S/4HANA sind die Entitäten Customer/Vendor und Business Partner zusammengeführt – zu Einzelheiten kommen wir in diesem Bereich weiter unten im CVI-bezogenen Kapitel
Technisch ist das Ganze so umgesetzt, dass die alten Transaktionen (VA01 usw.) immer noch auf die klassischen Tabellen KNA1, LSA1 usw. zeigen können, die Daten in Wahrheit jedoch vom Business Partner Datenmodell abgerufen und vom Geschäftspartner-Datensatz gelesen werden. Ein verbildlichtes Datenmodell davon zeige ich weiter unten.
Derzeit gibt es ca. 500 dieser sogenannten Simplification Items. Dies bedeutet auch, dass die veschiedenen Transaktionen zusammengelegt wurden. Sie finden einen Überblick über diese Simplifikationen in der sogenannte Simplification List, die Sie hier betrachten können.
Zentraler Treiber dieser Simplifications ist die Implementierung des „Principle of One“. Demnach soll SAP S/4HANA eine einzige Business Lösung für Unternehmen sein, die verteilte Haupt- und Nebensysteme der Vergangenheit (z. B. ein Konstrukt aus SAP ERP, SAP CRM, SAP SRM und SAP EWM in jeweils getrennten Systemen) überflüssig machen soll.
Die wichtigsten Vereinfachungen (Top Simplification List Items) für den Anfang unter S/4HANA sind
Soweit möglich, sollten Sie die Line of Business Vorbereitungen vor den technischen Vorbereitungen durchführen. Zumindest, bevor Sie die S/4HANA Readiness Checks und andere vorbereitende Checks durchführen. Denn wenn Sie die Vorbereitungen schon jetzt durchführen, haben Sie später bei den Checks weniger Findings, die Sie vor der eigentlichen System Conversion auflösen müssen.
Schon seit einiger Zeit bietet die SAP die Logik des Geschäftspartners (Business Partner) an. In der klassischen getrennten Datenhaltung von Kreditoren und Debitoren gab es einige datenhalterische Limitierungen
Mit dem Datenmodell des Geschäftspartners werden diese Einschränkungen umgangen. Nicht nur ist es nun möglich, die selben Stammdaten sowohl für die Kreditoren- als auch die Debitoren-Sicht zu verwenden, es können nun mehrere Geschäftspartnerkategorien gepflegt werden – von der Organisation und der Person bis hin zu Gruppierungen. Ein Geschäftspartner kann sowohl als Debitor als auch als Kreditor auftreten und dabei mehrere Adressen, Zahlungsdaten und Beziehungen im Bauch haben, die in zeitlichem Kontext Anwendung finden können.
Auch sind nun Beziehungen zwischen Geschäftspartner Entitäten möglich. „Person X ist Kontaktperson für Organisation Y. Organisation Y ist Service Provider für Organisation Z etc.“ Das Geschäftspartnerkonzept ist bereits unter SAP ECC 6.0 nutzbar. Es wird unter ECC u. A. genutzt in den Bereichen
Neu an der Customer Vendor Integration ist im Endeffekt, dass die Geschäftspartnerlogik in die Objekte Debitor und Kredit integriert wird. Das heißt die alten, klassischen ECC Transaktionen der kreditorischen und debitorischen Buchhaltung, z. B. die VA01, zeigen mitunter weiterhin auf die Tabellen aus der klassischen Customer/Vendor Logik (z. B. KNA1, LFA1), diese holen sich die Daten aber aus den eigentlichen Master Stammdaten aus der Geschäftspartnerlogik.
Leider können nicht alle Daten redundanzfrei nur in der Geschäftspartnerlogik gespeichert werden. Einige Daten sind redundant vorgehalten, damit Nebensysteme, die noch mit der alten Customer/Vendor Logik arbeiten, kompatibel sind. Stattdessen werden die Daten über Linker Tabellen miteinander in Beziehung gesetzt. Geschäftslogik sorgt hierbei dafür, dass bei der Änderung eines klassischen Customer/Vendor Datensatzes der entsprechende Geschäftspartner Eintrag mit betroffen ist.
Die Verteilung von Business Partner Objekten an Nebensysteme kann über ALE/IDOCS geschehen. Die hierzu notwendige Logik kann über das Data Replication Framework (DRF) implementiert werden.
Dadurch erreichen Sie, dass Sie die Daten nun nur noch an einer Stelle, nämlich im Geschäftspartnerobjekt, pflegen – und trotzdem alle Softwarefunktionalitäten mit ihrer bisherigen Logik weiter funktionieren. Erst dadurch wird es möglich, dass diverse strategische Produkte der SAP in den S4CORE integriert werden. Zentrale Fragen über die Customer Vendor Integration werden in SAP Hinweis
2713963 beantwortet.
Nur mit implementierter Customer/Vendor Integration ist es einem Business Suite Quellsystem möglich, eine Konvertierung nach S/4HANA Enterprise Management zu erfahren. Für das Simple Finance 2.0 Addon (mittlerweile von der SAP nicht mehr empfohlen – gehen Sie direkt auf S/4HANA Finance oder S/4HANA Enterprise Management) oder eine Migration auf S/4HANA Finance ist die Implementierung der CVI NICHT notwendig. Alle Debitoren und Kreditoren müssen in diese Logik migriert sein. Zentraler Einstiegspunkt für die Geschäftspartnerpflege ist die Transaktion BP.
Unter S/4HANA läuft es dann so, dass alle bisherigen ECC Transaktionen, Reports, Formulare etc., die entweder Kreditoren oder Debitoren als Eingabeobjekt angenommen haben, auch weiterhin eine Debitor- bzw. Kreditor-Nummer erwarten – egal ob diese bereits zu einem Geschäftspartner verbunden wurden und die selbe Nummer tragen, oder unterschiedliche Nummern. Sie geben also die Nummer des Kreditoren/Debitoren an, NICHT die Nummer des Geschäftspartners. Der Vendor heißt im englischsprachigen Raum unter S/4 auch nicht mehr Vendor, sondern Supplier.
Es wird Ihnen aus Usability Gründen explizit empfohlen, die Geschäftspartnernummer identisch mit der entsprechenden Kreditoren- bzw. Debitoren-Nummer zu wählen. Um außerdem nicht all zu viele Datensätze konvertieren zu müssen, sollten Sie nicht mehr benötigte Customer/Vendor Sätze mit dem Deletion Flag archivieren. Alle nicht archivierten Debitoren und Kreditoren (trotz gesetztem Deletion Flag) MÜSSEN auf die CVI Logik konvertiert werden, bevor Sie Ihre System Conversion beginnen.
Trotzdem ist es so, dass sobald Sie auf CVI umgestellt haben, die folgende Liste an Transaktionen nicht mehr verfügbar sein werden. Dies soll verhindern, dass Sie Customer/Vendor Datensätze verändern oder hinzufügen, anstatt zentral in der Transaktion BP bzw. den zugehörigen Fiori Apps zu pflegen. Es gibt getrennte Fiori Apps für Customer und Supplier, die jedoch im Hintergrund Business Partner Daten ändern. Auch die Prospect to Customer Logik ist möglich. Sie können einen Geschäftspartner mit der Rolle „Prospect“ (Rolle BUP002) erstellen und später seine Rolle zum Kunden ändern (FLCU01).
| Aktivität | Obsolete Transaktion unter S/4 |
| Debitor anlegen | XD01 VD01 FD01 |
| Debitor ändern | XD02 VD02 FD02 |
| Debitor anzeigen | XD03 VD03 FD03 |
| Kreditor anlegen | XK01 MK01 FK01 |
| Kreditor ändern | XK02 MK02 FK03 |
| Kreditor anzeigen | XK03 MK03 FK03 |
Kundeneigener Code, welcher die oben benannten, obsoleten Transkationen betrifft, muss nicht umgeschrieben werden. Die Transkationsaufrufe werden unter S/4 automatisch an die Transkation BP weitergeleitet.
Weiterhin möglich werden jedoch Massenbearbeitungsverarbeitung über GUI-Transkationen sein (XD99, XK99 und MASS) sowie in den Fiori Apps (Customer Master Mass Maintenance, Mass Maitnenance, Supplier Master).
Es ist absolut empfehlenswert, dass Sie die Customer Vendor Integration und ihren Impact zuerst auf Basis einer Sandbox mit Produktivdaten austesten, bevor Sie den Schritt in Ihrer regulären Systemlinie durchführen!
Wenn Sie keine System Conversion vor haben, sondern die Daten in ein frisch aufgesetztes Greenfield S/4HANA synchronisieren wollen, müssen Sie diese Daten im Business Partner Zielformat importieren. Das bedeutet, es muss on the fly eine Transformation der Daten geschehen. Diese Transformation können Sie sowohl über die LSMW, über IDOCs, manuell oder über die Data Services des Solution Manager vornehmen. Weitere Informationen für die Migration von Customer/Bendor Identitäten finden Sie in den SAP Hinweisen 2287723, 2417298 und 2221398.
In den Unterkapiteln weiter unten zeige ich Ihnen Schritt für Schritt die manuellen Schritte zur Implementierung der Customer/Vendor Integration auf. Alternativ dazu können Sie sich durch die Implementierung von CVI führen lassen. Implementieren Sie hierzu die folgenden SAP Hinweise
Wenn ihr ERP System auf dem Release EHP0 – EHP4 ist, müssen Sie zuvor SAP Note 2383051 implementieren.
Weitere SAP Notes, die Sie als Vorarbeit in Ihre Recherche integrieren sollten, sind namentlich
Danach aktivieren Sie die Business Functions CA_SUPPLIER_SOA und CA_BP_SOA. Die Schalter „VENDOR_SFWS_SC1“ und „VENDOR_SFWS_SC2“ müssen beide aktiv (Global Status „on“) sein, damit Vendor Personen Datensätze mit Business Partner Kontaktpersonen synchronsieirt werden (Siehe SAP Note 1454441 – Development of contact person for vendors).
Als erstes aktivieren Sie über den IMG Pfad Cross-Application Components – Master Data Synchronization – Synchornization Control – Activate PPO Requests for Platform Objects in the Dialog den PPO Request für das BP Synchronisationsobjekt.
Danach stellen Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Synchronization Control – Activate Synchronization Options sicher, dass die Synchronisation zwischen Customer/Vendor und BP aktiv ist.
Zu guter letzt aktivieren Sie unter Cross-Application Components – General Application Functions – Postprocessing Office – Business PRocesses – Activate Creation of Postprocessing Orders die PPOs.
Sie müssen nun festlegen, welche Nummer der Geschäftspartner bekommen soll. Die gleiche Nummer wie der Kreditor/Debitor, und falls zutreffend, welche von den beiden? Ein guter Ansatz für die Vorgehensweise ist der S/4 Converison Guide, explizit das Kapitel „Introduce Business Partner Approach (CVI)“.
Die erste zentrale Frage, die Sie sich stellen müssen, ist: Überlappen sich die Nummernkreise für Debitoren und Kreditoren im Quellsystem? Falls nein, können Sie den Nummernkreis für Geschäftspartner genau so definieren wie für Customer/Vendor zusammen. Falls sie sich jedoch überlappen, sollten Sie den Nummernkreis so wählen, dass möglichst viele individuelle Customer/Vendor Identifikationsnummern in diesem enthalten sind.
Zunächst prüfen Sie den Debitoren Nummernkreis über den IMG Pfad Logistics – General – Business Partner – Customers – Control – Define and Assign Customer Number Ranges und den Kreditoren Nummernkreis über den IMG Pfad Logistics – General – Business Partner – Vendor – Control – Define Number Ranges for Vendor Master Records. Den Nummernkreis für die Geschäftspartner konfigurieren Sie dann im IMG Pfad Cross-Application Components – SAP Business Partner – Business Partner – Basic Settings – Number Ranges and Groupings – Define Number Ranges/Define Groupings and Assign Number Ranges.
Der Conversion Report MDS_LOAD_COCKPIT weist während der Konvertierung einer Kontaktpersonin eine Business Partner Person eine interne Business Partner Nummer zu. Der zugehörige Nummernkreis ist der für das Internal Standard Grouping (Feld Int Std.Grping) Wenn dieser Nummernkreis mit den gewünschten Ziel-Customer/Vendor-Nummernkreisen überlappt, muss dieser Nummernkreis für Kontaktpersonen außerhalb davon definiert werden. Es darf auf keinen Fall vorkommen, dass eine Business Partner Kontaktperson die Nummer eines Business Partners bekommt und damit dessen Nummer überschreibt. Dies kann ansonsten zum Fehler R11124 „Business partner with GUID XXXX does not exist“führen.
Business Partner Rollen müssen den einzelnen Kontogruppen (TX OBD4) zugewiesen werden. So sollten Sie beispielsweise die Kontogruppen für Debitorenkonten den Business Partner Rollen für Customer bzw. Debitoren zuweisen (BP Rollen FLCU00 und FLCU01). Dies machen Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration – Business Partner Settings – Settings for Customer Integration – Define BP Role for Direction Customer to BP.
Umgekehrt sollten Sie den Business Partner Rollen für Vendors bzw. Kreditoren (FLVN00 und FLVN01) der Kontogruppe für Kreditorenkonten zuweisen. Dies tun Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor INtegration – Business Partner Settings – settings for Vendor Integration – Define BP Role for Direction Vendor to BP.
Außerdem muss für jede Kontogruppe eine Nummernzuweisung existieren. Für Customer konfigurieren Sie dies im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration – Business Partner Settings – settings for Customer Integration – Field Assignment for CustomerIntegration – Assign Keys – Define Number Assignment for Direction Customer to BP. Für Vendors lautet der Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integraiton – Business Partner Settings – Settings for Vendor Integration – Field Assignment for Vendor Integration – Assign Keys – Define Number Asignment for Direction Vendor to BP.
Danach müssen Sie den gesamten IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration – Business PArtner Settings – Settings for Customer Integration – Field Assignment for Customer Integration – Assign Attributes durchlaufen – sowohl für die Kontaktperson als auch für den Debitor generell.
Jetzt, da Sie sicher sind, dass das Customizing passt, müssen Sie die eigentliche Daten Synchronisation anstarten. Nutzen Sie hierzu den Report MDS_LOAD_COCKPIT. Dieser erstellt einen Business Partner für jeden Kreditor oder Debitor im System. Damit Business Partner nicht doppelt erstellt werden, müssen Sie die zuvor beschriebenen Customizing Steps eben sauber durchgeführt und die beiden Entitäten miteinander verbunden haben.
Auch wenn für die Konvertierung keine Downtime notwendig ist, sollten Sie die Konvertierung zu einer Zeit durchführen, an welcher auf dem System nicht all zu viel los ist. Es empfiehlt sich außerdem, die Transkation BP für die Dialognutzung durch die Fachanwender ab diesem Zeitpunkt zu sperren, so dass vom Zeitpunkt der Konvertierung bis zur S/4 System Conversion keine Änderungen mehr durchgeführt werden und somit neue Showstopper für die Migration erzeugt werden können.
Der Report erstellt außerdem die jeweiligen Kontaktdaten, Adressen, BP Rollen sowie die Zahlungsinformationen. Im Report angekommen doppelklicken Sie auf den gewünschten Synchronisationsprozess – also Customer->Business Partner oder Vendor->Business Partner, filtern die affektierten Kreditoren/Debitoren über ihre Nummern oder Kontogruppen, und führen den Report aus. Es empfiehlt sich, beim ersten Lauf nur einige wenige Datensätze auszuwählen, zwischen 10 und 50 an der Zahl.
Nach der Migraiton können Sie im Reiter Monitor mögliche Replikationsfehler analysieren. Klicken Sie dazu im Reiter Monitor auf das PPO Icon, um sich den Status der PPO Orders anzusehen. Es ist wichtig, alle Stammdatenfehler zu beheben, um die Konvertierung abzuschließen.
Über den Report CVI_UPGRADE_CHECK_RESOLVE können Sie sich eine Liste aller Customer/Vendor Entitäten anzeigen lassen, die noch synchronsiiert werden müssen. Sie können sich diese Liste als Datei herunteralden und in das MDS_LOAD_COCKPIT hochladen, um nur die übrig gebliebenen Accounts zu verarbeiten
Nach der Konvertierung auf S/4HANA sollte es keinen Anwendungsfall mehr geben, der Sie dazu nötigt, erneut eine Synchronisation in der Richtung Customer/Vendor->Business Partner durchzuführen. Synchronisationen sollten nur noch in der umgekehrten Richtung statt finden. Eventuell sollten Sie diese Funktionalität also komplett im System sperren.
Nach dem Mapping lassen Sie einen Check-Report laufen. Diesen bekommen Sie über SAP Hinweis 1623677 und erreichen ihn dann im Anschluss über Transaktion CVI_FS_CHECK_UST bzw. über den Report CVI_FS_CHECK_CUSTOMIZING. Der Report prüft das Customizing in beide Richtungen. Dies ist genau der gleiche Report, der durch den Software Update Manager einmal im Preprocessing und einmal im Postprocessing ausgeführt wird. Sie sollten diesen vor der System Conversion ausführen, um Show Stopper an dieser Stelle zu verhindern.
Optional können Sie außerdem den Report FSBP_IND_SECTOR_MAPPING_CHECK ausführen, welche das Mapping der Industry Assignments prüft.
Zusätzlich ist der Report aus SAP Hinweis 2216176 auszuführen, den Sie nach Implementierung über die Transaktion CVI_PRECHECK_UPGRADE oder über den Report PRECHECK_UPGRADATION_REPORT erreichen. Dieser prüft, ob alle benötigten CVI Mappings erfolgreich abgeschlossen sind. Falls Ihnen Inkonsistenzen in den Linker Tabellen angezeigt werden, konsultieren Sie SAP Note 974504.
Jetzt haben Sie vielleicht schon auf Basis der klassischen Customer/Vendor Logik Erweiterungen implementiert, in denen Sie noch von der klassischen Logik ausgehen. Damit Sie nach erfolgter Konvertierung in die Customer/Vendor Integration weiterhin Ihre Logik abbilden können, stellt der Hersteller diverse BAdIs zur Verfügung, die Sie beispielsweise bei einem Exit nutzen können. Näheres finden Sie im IMG Pfad Cross-Application Components – Master Data Synchronization – Customer/Vendor Integration -> Business Partner Settings -> Business Add-Ins (BAdIs) bzw. in den SAP notes 2309153 und 2295823. Jedes Interface zum Erstellen oder Ändern eines Customer/Vendor Stammdatensatzes muss hierzu den Funktionsbaustein CVI_EI_INBOUND_MAIN aufrufen.
Kundeneigener Code, welcher die oben benannten, obsoleten Transkationen betrifft, muss nicht umgeschrieben werden. Die Transkationsaufrufe werden unter S/4 automatisch an die Transkation BP weitergeleitet.
Wenn Sie unter S/4 CRUD (löschen bedeutet hierbei nur das Deletion Flag zu setzen) Operationen auf Customer/Vendor Stammdatensätze über eine Webschnittstelle durchführen wollen, gibt es hierfür im SAP API Hub einen OData Service.
In SAP ERP ist es mögliche, Lagerplätze aus dem Material Requirements Planning auszuschließen oder separat zu planen. Das kann beispielsweise notwendig sein, wenn die Lager uterschiedliche Werke mit wiederum unterschiedlichen Losgrößen beliefern, oder nicht anhand des Materialverbrauchs eines Werks (engl.: Plant) beliefert werden sollen. In diesem Fall muss das Werk mit einer eigenen losgrößenspezifischen Planung versehen oder ganz von der losgrößenbasierten Planung ausgeschlossen werden.
Diese Planung wurde bereits unter der Business Suite vereinfacht, indem die alte Logik der Lagerplätze (Storage Locations) durch die Logik der MRP Areas ersetzt wird. Dadurch war es möglich, die verschiedenen Lager in verschiedene „MRP Areas“ unterzubringen, ohne ein zweites Werk erstellen zu müssen. Weitere Informationen finden Sie in SAP Note 2268045 – S4TWL – Storage Location MRP. Die Abbildung vergleicht das alte Prinzip (oben in grün) mit dem neuen (unten in blau).
Unter S/4HANA ist nur noch das neue Prinzip der MRP Areas unterstützt. Sie müssen also vor der Konvertierung auf S/4HANA die Umstellung durchführen. Wenn Sie in Ihrem ERP System noch die Storage Location MRP Logik nutzen, sollten sie den Report MRP_AREA_STORAGE_LOC_MIGRATION ausführen. Informationen zum Report erhalten Sie unter SAP Note 2216528.
Das Datenelement bzw. das Datenfeld MATNR, welches etwa in der Tabelle MARA genutzt wird, wird in der maximalen Länge von 18 auf 40 Zeichen verlängert. Die dadurch beeinflussten SAP Datenstrukturen, was Domänen, Strukturen, Tabellentypen, Datenbanktabellen und User Interfaces beinhaltet, müssen entsprechend adaptiert werden.
Diese Erweiterung wird jedoch nach einer Konvertierung nach S/4HANA nicht automatisch aktiviert. Sie muss explizit von Ihnen als Kunde aktiviert werden. Solange Sie die Erweiterung nicht aktivieren, gibt es auch keinen Business Impact. Wenn Sie jedoch die Erweiterung nutzen wollen, müssen Sie sich Gedanken darüber machen, ob Ihre Nebensysteme, die mit dem S/4HANA System kommunizieren, mit längeren Materialnummern umgehen können. Für die Kommunikation mit anderen Business Suite Systemen wie SRM und CRM können Sie SAP Note 2232396 konsultieren.
Des Weiteren könnte es sein, dass Sie in Ihren Eigenentwicklungen Anpassungen vornehmen müssen, um mit dieser verlängerten Materialnummer umgehen zu können. Dazu können Sie die entsprechenden Customer Coding Checks durchführen. Weitere Informationen finden Sie in SAP Note 2267140. Es gibt außerdem einen Pre-Check Report (MFLE_CLS4H_CHECKS_CC), den Sie ausführen können, in SAP Note 2216958.
Unter S/4HANA müssen Sie sich zunächst im Sales Bereich mit einigen Simplifications auseinander setzen.
Die zentrale Finance Note zur Prüfung der Konvertierungsvorbareiten ist der Hinweis 2332030. Wie aus meinem damaligen Blog Post ersichtlich, verändert sich vor allem im FI/CO Bereich das Datenmodell durch die Einführung des Universal Journal erheblich. Diese Änderungen im Datenmodell müssen berücksichtigt und vorbereitet werden.
Eine wesentliche Grundvoraussetzung ist die Migration auf das neue Hauptbuch (New General Ledger Accounting). Grundsätzlich müssen Sie vor einer System Conversion auf S/4HANA Finance bzw. S/4HANA Enterprise Management NICHT auf die neue Hauptbuchhaltung migrieren. Sie können grundsätzlich die Migration auf die neue Hauptbuchhaltung zusammen mit der S/4HANA System Conversion durchführen. Dies bringt jedoch einige Nachteile mit sich. Wenn Sie über die S/4HANA System Conversion auf das neue Hauptbuch migrieren, findet eine rein technische Migration statt. Es werden dabei keine neuen Funktionalitäten wie die Belegaufteilung (Document Splitting) oder die parallele Rechnungslegung (Parallel Ledgers) implementiert. Diese Funtionalitäten müssen Sie im Nachhinein implementieren, und beides innerhalb von ein und dem selben Fiskaljahr durchzuführen könnte einen ziemlich großen Einfluss auf Ihren Geschäftsbetrieb bedeuten.
Es ist daher grundsätzlich empfehlenswert, die Migration auf das neue Hauptbuch und die Einführung des Belegsplittings auf der einen Seite, und die Konvertierung auf S/4HANA auf der anderen Seite, auf zwei verschiedene Fiskalperioden aufzuteilen. Es empfiehlt sich in diesem Zusammenhang, zusammen mit der neuen Hauptbuchhaltung auch die neue Anlagenbuchhaltung einzuführen. Über beide Themen habe ich mich in diesem Beitrag bereits ausgelassen.
Wenn Sie jedoch die entsprechenden Ressourcen freihalten, um innerhalb eines einzigen Projektes beide Schritte (S/4HANA Systemkonvertierung und Einführung der neuen Hauptbbuchalltung) zu stemmen, spricht grundsätzlich nichts dagegen, beides innerhalb des System Conversion Projektes und somit innerhalb ein und derselben Fiskalperiode durchzuführen. Sie sparen damit mitunter sogar Projektkosten. Im Endeffekt ist es also ein Abwägen zwischen der Reduzierung von Komplexität und Risiko auf der einen Seite und der Reduktion der TCO auf der anderen Seite.
Sie wissen noch nicht, ob Sie die neue oder klassische Hauptbuchhaltung verwenden? Die einfachste Möglichkeit, dies zu prüfen, ist die Tabelle FAGL_ACTIVEC. Steht dort im Feld „ACTIVE“ ein X, sind Sie schon auf dem neuen Hauptbuch.
Damit wir diesen Abschnitt erklären können, müssen wir uns erst einmal die wichtigsten Begrifflichkeiten in der Währungskonfiguration unter SAP klären. Bereits unter SAP ECC ist die Funktionalität des Hauptbuchs unter SAP bekannt, mit internationalen Währungstransaktionen umgehen zu können. Darunter fällt beispielsweise die Möglichkeit, die in der lokalen Unternehmenswährung geführten Abschlüsse einzelner Tochterunternehmen, die in der Regel innerhalb von gesonderten Buchungskreisen hinterlegt sind, in einen konsolidierten Konzernabschluss in der Währung des darüberliegenden Mutterkonzerns zu überführen. Dieser wird dann in der Regel auf Ebene des Mandanten definiert. Zu dieser Währungskonsolidierung gehört auch die Echtzeit-Umrechnung von Werten zum Zeitpunkt ihrer Verbuchung in die jeweilige Zielwährung. Um das Konzept nun zu verstehen, hier kurz die Auflistung der wichtigsten Begriffe.
Viele Kunden haben bei der Transition nach S/4HANA das Problem, dass Sie die Führung von parallelen Währungen und die Führung einer Konzernwährung im Quellsystem noch nicht aktiviert haben. Ihre Umstellung auf SAP S/4HANA dient in diesem Zusammenhang als Chance, Ihr Währungskonzept zu harmonisieren und zu konsolidieren. Gleichzeitig stellt diese Chance aber auch eine Herausforderung dar. Denn Belege in einer offenen Periode, die Sie in der Vergangenheit beispielsweise in einer Altwährung gebucht haben, müssen nach der Umstellung nach S/4HANA konvertiert werden, wenn Sie sich beispielsweise dazu entscheiden, eine neue Konzernwährung zu aktivieren. Grund für diese Entscheidung könnte zum einen das Erstellen eines konsolidierten Konzernabschlusses, zum Anderen die Erfüllung buchhalterischer Regelungen bei der internationalen oder lokaeln Rechnungslegung (z. b. US FASB 52), oder die simple Tatsache sein, dass Ihre Financial Analysts dazu in der Lage sein sollen, zu jedem Beleg sofort den Betrag in Konzernwährung sehen zu können.
Nun kann es aber sein, dass sich Ihre Organisation ursprünglich gegen die Aktivierung der Konzernwährung entschieden hat. Unter SAP ECC war die hierzu notwendige Datenhaltung nämlich redundant und erhöhte damit das Datenvolumen Ihres Systems und die Abfragezeiten. Unter S/4HANA können Sie jedoch dank des neuen Datenmodells und der in-Memory Fähigkeit von SAP HANA ohne redundante Datenhaltung nun mehrere parallele Währungen führen. Ein anderer Grund für die ursprüngliche Entscheidung gegen die parallele Währungsführung könnte sein, dass Ihr Unternehmen ursprünglich nur in einer Region mit einer lokalen Währung tätig war. Über die Jahre könnten Sie aber mittlerweile expandiert sein, was die Notwendigkeit für die Konzernwährung aufkommen lässt.
Vielleicht haben Sie aus historischen Gründen bereits die Erstellung eines konsolidierten Konzernabschlusses ohne die Aktivierung der Konzernwährung etabliert. Mögliche Workarounds, die dies ermöglichen, sind beispielsweise die Reportingfunktionalitäten von SAP BI, die Erstellung eines Special Purpose Ledger (SPL bzw. FI-SL) oder die Installation diverser Drittanbieteraddons. Vielleicht würden Sie aber gerne diese Workarounds loswerden und zum Standard zurückkehren. Ihre S/4HANA Conversion ist die Gelegenheit dafür.
Dabei muss jeder Beleg von seiner jeweiligen ihm eigenen Transaktionswährung einmal in die Gesellschaftswährung, einmal (falls notwendig) in die funktionale Währung und einmal (falls aktiviert) in die Konzernwährung umgewandelt werden. Diese 1-3 Transformationsvorgänge geschehen nicht automatisch, wenn Sie die Konzernwährung aktivieren. Nach Aktivierung der Konzernwährung werden lediglich künftige Transaktionen und Belege in der Konzernwährung gebucht, nicht jedoch die alten Belege konvertiert. Sie können also nicht einfach mal so im Live-System das Customizing ändern und denken, alles wird gut.
Nun gibt es grundsätzlich zwei Ansätze dafür, das Prinzip der Konzernwährung in ein SAP Live-System zu implementieren. Die klassische Methode wird in SAP Note 39919 erläutert. Ein alternativer Approach ist die Durchführung einer S/4 Conversion nach dem sogenannten System Landscape Optimization (SLO) oder auch „Shell“ Ansatz genannt. Dabei wird eine leere S/4HANA Greenfield Hülle erstellt und gecustomized, und erst im Nachhinein werden die entsprechenden Stamm- und Bewegungsdaten aus dem Quellsystem mit entsprechenden Transformationsregeln in diese Hülle übertragen.
Der wesentliche Unterschied zwischen den beiden Vorgehensweisen: Die erstere Umstellung führen Sie VOR der S/4HANA System Conversion durch (und zwar mit mehreren Monaten Vorlaufzeit im Rahmen eines Vorprojekts), die zweitere nach der Implementierung der eigentlichen S/4HANA Hülle (im Rahmen des S/4HANA Conversion Projekts).
Vor der Durchführung der Konvertierung sollten Sie außerdem diverse Prüfungen durchführen. Einige davon dienen der Evaluierung der Simplification Items, andere sammeln Daten für den Abgleich der FI-Daten nach erfolgter Konvertierung. Führen Sie den Report /SDF/RC_START_CHECK (ersetzt den älteren Report FINS_MIG_PRECHECK_CUST_SETTINGS) aus, um die Implementierung der notwendigen Simplification Items im Quellsystem zu prüfen, bevor Sie mit der System Conversion beginnen.
Alles zum Thema neue Anlagenbuchhaltung werde ich an dieser Stelle nicht nochmal wiederholen, weil ich auf das Thema bereits in diesem Blog Post eingegangen bin. Einige der dort erwähnten Tätigkeiten müssen ausgeführt werden, um die notwendigen Voruassetzungen für den Umstieg auf die neue Anlagenbuchhaltung unter S/4 zu schaffen. Dies beinahltet auch die Vorarbeiten für die Aktivierung der neuen Abschreibungsrechnung sowie die Prüfung der Währungseinstellungen
Ihre Umstellung auf SAP S/4HANA ist die Gelegenheit für eine Vereinfachung Ihrer Geschäftsprozesse. Ein typisches Beispiel könnte etwa der Umgang mit nicht-auftragsbezogenen Eingangsrechnungen sein (non-purchase order invoices, Non-PO invoices). Vielleicht ist es derzeit bei Ihnen so, dass jedwede Eingangsrechnung ohne vorherigen Auftragsausgang immer von einem Vorgesetzten genehmigt werden muss, bevor sie ausgezahlt wird, und das unabhängig von ihrem Betrag.
Ein Ansatz in diesem Beispiel wäre etwa, non-PO invoices nur noch zur Genehmigung vorzulegen, wenn entweder die Einzelrechnung einen gewissen Betrag überschreitet oder der hinterlegte Lieferant im Laufe einer Fiskalperiode einen gewissen Gesamtumsatz übersteigt. Dadurch werden die genehmigenden Ressourcen freier und können Ihre Aufmerksamkeit mehr auf das wesentliche richten. Ein derartiges Prozess-Redesign lässt sich wunderbar in ein S/4HANA Transitionsprojekt.
Nach der Isolation des Systems (Schnittstellen und Useranmeldungen wurden gekappt) sollten Sie noch einmal prüfen, ob es im System noch offene Belege gibt. Diese sind in Vorbereitung auf den darauffolgenden periodenabschluss entweder zu buchen oder mit dem Löschzeichen zu versehen.
Es ist empfehlenswert, die S/4HANA System Conversion mit einem Periodenabschluss zu verbinden. Schließen Sie die Fiskalperiode über Transkation OB52 und die Controlling Periode über OKP1 und dokumentieren Sie die Ergebnisse.
Sammeln Sie über folgende Reports Daten über ihre Finanzdaten – im Altsystem und im Neusystem.
Vergleichen Sie außerdem die folgenden Transaktionen sowohl im Alt- als auch im Neusystem
Zusätzliche Vergleichs-Reports und -Transaktionen können im System Conversion Guide gelistet sein.
Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.
In SAP Projekten gibt es häufig Probleme bei der Übersetzung von SAP-spezifischen Begrifflichkeiten in den Geschäftsmodulen. Häufig spucken die typischen…
In diesem Beitrag geht es um die Optimierung der Business Downtime bei einem Ugprade oder einer Migration. Dies ist ein…
Der Software Update Manager (SUM) liefert neben der klassischen Upgrade-Funktionalität mittlerweile eine Vielzahl an unterschiedlichen Approaches für die Kombination aus…
Der sogenannte Side-by-Side Ansatz bezeichnet eine architektonische Nutzung einer SAP HANA Datenbank als Beschleuniger eines klassischen SAP-Systems, welches noch auf…
Mit SAP HANA 2.0 SP01 ist der Betriebsmodus der Multi Database Containers (MDC) der einzige aktiv empfohlene Betriebsmodus, mit der…
Oft werde ich gefragt, was denn die einzelnen Sicherheitseinstellungen bei der Erstellung und Konfiguration von Web Services bedeuten, insbesondere wenn…
