SAP S/4HANA System Conversion: Line of Business Vorarbeiten

(Last Updated On: 7. August 2019)

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.

Was sind Simplifications und die Simplification List?

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

  • Die Vereinheitlichung des Datenmodells im FI und im Inventory Management Bereich. Siehe hierzu meinen entsprechenden Blog Post.
  • die Vereinheitlichung des Datenmodells befreit von der zwangsweisen Speicherung von Redunanzen und Aggregaten („No Aggregates“). Dadurch gibt es beispielsweise keinen Übertrag von Preisen mehr auf der Tabelle MBEW.
  • Customer Vendor Integration (CVI), wie oben bereits angesprochen.
  • Discrete Industry Mill Products (DIMP) ist wieder im Anwendungskern integriert.
  • Erweiterung des Datenelementes „MATNR“ in der Tabelle „MARA“ von 16 auf 40 Zeichen (Lange Materialnummer „LAMA“).
  • Die Embedded BW Funktionalität deckt viele Standard-Einsatzszenarien von Business Warehouse bereits im S/4HANA Kern ab, ohne die Notwendigkeit von ETL.
  • Replacement bzw. Konsolidierung operationeller Informationsssysteme, wie etwa des Logistics Information System (LIS), in die Analysemöglichkeiten von SAP HANA (SAP HANA Views, Operational Data Store ODS)
  • Integration von SAP Enterprise Warehouse Management (SAP EWM) in den S/4HANA Core
  • Integration grundlegender SAP Global Trade Services (GTS) Funktionalitäten in die Foreign Trade Komponente (SD-FT) von S/4HANA.
    Die wichtigsten Simplification Items werden zusätzlich in diesem Blogpost gesammelt.
  • Die Notwendigkeit der Nutzung eines externen Advanced planning and Optimization (APO) Systems für die detaillierte Produktionsplanung entfällt unter S/4HANA. Sie geht in die integrierte PP/DS Komponente von S/4 in den Standard über.

Line of Business Vorbereitungen in Business Uptime

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.

Customer Vendor Integration (CVI)

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

  • nur eine Adresse pro Geschäftspartner
  • keine Beziehung zwischen Objekten möglich, diese mussten stattdessen als getrennte Entitäten gepflegt werden.
  • Keine Personen pflegbar

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

  • SAP Collections Management (FSCM-COL)
  • SAP Credit Management (FSCM-CR)
  • SAP Treasury and Risk Management (TRM)
  • Loans Management (FS-CML)
  • sowie in weiteren strategischen Produkten der SAP, darunter CRM, SCRM, SRM und GTS.

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.

S/4HANA CVI Business Partner

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.

Datenmodell CVI Business Partner

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ätObsolete Transaktion unter S/4
Debitor anlegenXD01   VD01 FD01
Debitor ändernXD02   VD02 FD02
Debitor anzeigenXD03   VD03 FD03
Kreditor anlegenXK01   MK01 FK01
Kreditor ändernXK02   MK02 FK03
Kreditor anzeigenXK03   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.

Alternative zum manuellen Approach

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

  • 2336018 – BP S4HANA : Suppress Mandatory BP field groups checks via MDS_LOAD_COCKPIT transaction
  • 2345087 – BP_BAP: Missing values in required entry fields cause postin termination in mass processing
  • 2344034 – S/4HANA Automation for Master Data Migration

Notes und Business Functions

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

  • Note 2216176 – Precheck report from business partner (Report PRECHECK_UPGRADATION_REPORT)
  • Note 2211312 – S4TC SAP_APPL Pre-Conversion check for Business Partner
  • Note 1623677 – BP_VCI: Check report for checking CVI Customizing (Report CVI_FS_CHECK_CUSTOMIZING)
  • Note 974504 – Inconsistencies in link tables of master data sync. (Report ZCUSTOMER_LINK_CHECK_REPORT)
  • Note 2399368 – excel upload option in MDS_LOAD_COCKPIT (Erleichtert die Synchronisation von Customer/Vendor Datensätzen in BP Logik per Excel Upload)
  • Note 2309153 – Erweiterungen für Customer Daten in BP Logik (z. b. zusätzliche Tabellenfelder)
  • Note 2295823 – Erweiterungen für Vendor Daten in BP Logik (z. B. zusätzliche Tabellenfelder)

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).

Synchronisation aktivieren

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.

SAP activate PPO requests

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.

Business Partner Synchronization Options

Zu guter letzt aktivieren Sie unter Cross-Application Components – General Application Functions – Postprocessing Office – Business PRocesses – Activate Creation of Postprocessing Orders die PPOs.

Nummernzuweisung

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.

Kontogruppen (Account Groups) zu Business Partner Rollen mappen

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.

Synchronisation starten über MDS_LOAD_COCKPIT

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.

Check Reports CVI_FS_CHECK_CUSTOMIZING und PRECHEK_UPGRADATION_REPORT

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.

FI/SD – Kundeneigene Erweiterungen unter CVI

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.

MM/PP – Storage Location Material Requirements Planning (MRP)

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).

S/4HANA Storage Location MRP

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.

MM – Verlängerung des Datenelements MATNR in MARA

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.

SD – Sales Simplifications & International Trade Management

Unter S/4HANA  müssen Sie sich zunächst im Sales Bereich mit einigen Simplifications auseinander setzen.

  • Der Business Partner Approach (weiter oben bereits diskutiert im Kapitel Customer/Vendor Integration (CVI)) ersetzt den alten ERP SD customer master (SAP Note 2265093).
  • S/4HANA Finance Credit Management ersetzt das Business Suite SD Credit Management (SAP Note 2270544)
  • S/4HANA International Trade Management ersetzt das Modul SD Foreign Trade (SD-FT) (SAP Note 2223144). Dies ersetzt im Wesentlichen die Funktoinalitäten, die SD-FT damals schon geboten hat, sprich die Bereiche Intrastat, Präferenzabwicklung (Preference Handling – SD-FT-PRE), dokumentenbasierte Zahlung (z. b. über Kreditbrief – letter of credit, SWIFT-Integration, Pflege von Zahlungskonditionen) und die Compliance zu Exportverordnungen (z. B. EFTA). Wer darüber hinausgehende Funktionalitäten braucht, ist weiterhin dazu angehalten, SAP Global Trade Services (SAP GTS) zu nutzen, welches sowohl on-Premise, in der HANA Enterprise Cloud (HEC) oder über Partner Managed Cloud (PMC) verfügbar ist.
  • zur Migration der FI Dokumente aus SD-FT kosultieren Sie SAP Note 2520879
  • SAP Condition & Contract Settlement ersetzt das Business Suite SD rebates Modul (SD-BIL-RB) (SAP Note 2267377)
  • SAP Revenue Accounting ersetzt das Business Suite SD Revenue Recognition Modul (SD-BIL-RR) (SAP Note 2267342)
  • Mit S/4HANA können Sie mit Hilfe von ODATA und Open CDS Views einen komplett neuen Approach im Analytics Bereich fahren. Dieser Appraoch ersetzt die klassische Lösung über ERP LIS/ODP (SAP Note 2228056)
  • Das Datenmodell für die Preisfindung ändert sich (SAP Note 2267442)
  • Es gibt diverse Custom Code Checks für obsolte SD Transaktionen und SD BAPIs (SAP Note 2228098)
  • Optimieren Sie die parallele Ausführung von SD Konvertierungsreports für Ihre Conversion Downtime (SAP Note 2353814)
  • Optional können Sie das SAP S/4HANA New Output Management konfigurieren (SAP Note 2228611)

FI/CO – New General Ledger Accounting

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.

FI/CO – Harmonisierung Ihres Währungskonzeptes

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.

  • Transaktionswährung (transaction currency) bzw. Belegwährung (document currency): Die Währung, in welcher eine Transaktion bzw. ein Beleg verbucht wird. In der Regel ist dies die Währung, auf die ein Beleg (z. B. eine Eingangsrechnung) ausgestellt wurde. Obwohl das theoretisch auch eine Kryptowährung wie Bitcoin sein könnte, können im SAP-System nur Währungen nach internationalem ISO 4217 Währungsschlüssel ausgewiesen sind, definiert werden.
  • Landeswährung (local currency) bzw. Gesellschaftswährung (company code currency). Diese Währung hinterlegen Sie bei der Konzerngesellschaft (also dem Tochterunternehmen eines Konzerns, welches in der Regel eine Region, ein eine Divison oder eine Produktgruppe repräsentiert), die dem jeweiligen Buchungskreis zugeordnet ist. Dies ist in der Regel die Landeswährung des jeweiligen Firmensitzes der Gesellschaft.
  • Hartwährung (hard currency). Eine Hartwährung ist eine landesspezifische Zeitwährung, die in Hochinflationsländern verwendet wird. Sie werden in der Regel von der Bevölkerung – und daher auch im täglichen Geschäftsbetrieb – alternativ zur ursprünglichen Primärwährung bevorzugt verwendet. In vielen Ländern ersetzt beispielsweise der US-Dollar die eigentliche lokale Landeswährung. Sie können eine Hartwährung auf Landesebene definieren. Von dort aus können Sie die Hartwährung dann als Parallelwährung (=zusätzliche Hauswährung) führen und diese für einen Buchungskreis vereinbaren.
  • Indexwährung. Eine Indexwährung ist in einigen Hochinflationsländern zur Steuermeldung vorgeschrieben. Auch Sie wird im Detailbild des jeweiligen Landes gepflegt und kann als Parallelwährung (=zusätzliche Hauswährung) für einen Buchungskreis vereinbart werden.
  • Konzernwährung (group currency). Dies ist die Währung, in welcher der übergeordnete Mutterkonzern seinen Abschluss tätigt. Die einzelnen lokalen Abschlüsse der Konzerngesellschaften werden in diese zentrale Konzernwährung umgerechnet, damit der Konzern einen konsolidierten Abschluss vorlegen kann.
  • Funktionale Währung (functional currency). Eine funktionale Währung wird häufig definiert, wenn die verwendete Gesellschaftswährung (company code currency), welche dem Buchungskreis einer Konzerngesellschaft zugewiesen ist, nicht für einen US-GAAP bzw. IFRS Abschluss geeignet ist. Wenn Sie jedoch vor haben, im Zuge Ihrer S/4HANA Transition eine internationale Rechnungslegung und einen IFRS Unternehmensabschluss anzufertigen, müssen Sie diesen in einer zugelassenen Währung durchführen. Um dies zu bewerkstelligen, wird in der Regel eine sogennante funktionale Währung (functional currency) definiert. Die lokale Buchführung der Gesellschaft wird für den Zweck des IFRS Abschluss dann parallel in diese funktionale Währung überführt.

    Ein anderer Grund für eine funktionale Währung kann sein, dass die primäre Währung, in welcher die Gesellschaft seine Ausgaben und Einnahmen generiert und tätigt, sich von der lokalen Landeswährung unterscheidet. Nehmen Sie als Beispiel einen Konzern mit Firmensitz in den USA, der einen Subsidiär in Mexiko betreibt. Die Gesellschaft produziert Teile und Teilproduktionen für die deutsche Mutter und liefert diese aus. Obwohl die Gesellschaft hierfür zwar im mexikanischen Inland Rohstoffe über die lokale Landeswährung (MXN) einkauft, verschifft sie die Teilerzeugnisse an die Mutter in US-Dollar und erhält von dieser auch die Finanzierung in US-D. Der transaktionale Anteil des US-Dollars in den Cashflows des mexikanischen Fertigers überwiegt, deshalb der US-Dollar zur Erstellung der Steuermeldung verwendet wird.
  • Objektwährung (object currency). Eine Objektwährung wird einem Controlling-Objekt zugewiesen. Ein solches Objekt stammt also aus dem internen Rechnungswesen und stellt in der Regel einen Kostenfaktor dar. Es kann sich hierbei also beispielsweise um einen Innenauftrag oder um eine Kostenstelle handeln. Hält eine Gesellschaft beispielsweise Gebäude im Ausland, kann es Sinn machen, diesen Objekten die lokale Landeswährung des Objektstandortes zuzuweisen. Oder wenn die Cashflows eines Innenauftrags aufgrund größtenteils in Fremdwährung abgeleistet werden (etwa aufgrund von Nearshore-/Offshore-Anteilen in der Leistungserbringung), kann es Sinn machen eine gesonderte Objektwährung zuzuweisen.

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).

FI/CO – Simplification Checks

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.

FI-AA: Prüfen der Voraussetzungen für die neue Anlagenbuchhaltung

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

Standardisierung / Simplifizierung Ihrer Geschäftsprozesse

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.

Line of Business Vorbereitungen in Business Downtime

Alle offenen Belege durchbuchen oder löschen

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.

Periodenabschluss vorbereiten für den Cut-Over

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.

FI/CO: Consistency Checks

Sammeln Sie über folgende Reports Daten über ihre Finanzdaten – im Altsystem und im Neusystem.

  • Sachkontenstämme: Report RFSVKZ00
  • Bilanz- und GuV:Report RFBILA00
  • Kreditorenstämme: Report RFKKVZ00
  • Sachkontensalden: RFSSLD00
  • Kreditorensalden: Report RFKSLD00
  • Debitorensalden: RFSDLD00
  • Abstimmung der Ergebnisse der Kontenkorrentkontenschreibung: RFKKBU00 mit den Reports RFKSLD00 und RFDSLD00
  • Offene Posten Kreditoren: RFKOPO00
  • Offene Posten Debitoren: RFDOPO00
  • Belegkompaktjournal: RFBELJ10
  • Dauerbuchungsurbelege: RFDAUB00
  • Anlagen: RAGITT01 und RABEST01
  • Kostenstellenberichte und Bestellobligo
  • Materialbestand: RM07MBST / RM07MMFI
  • Abstimmprogramm Anlagenbuchhaltung: RAABST02
  • Umsatzprobe: TFC_COMPARE_VZ (TX FAGLF03, neues Hauptbuch) oder SAPF190 (große Umsatzprobe, klassisches Hauptbuch) – SAP Note 31875 beachten.
  • Änderungen der Sachkontenstammdaten: RFSABL00
  • Änderungen der Buchhaltungsbelege: RFBABL00 – besondere Vorsicht bei Dauerbuchungen
  • Auswertung abgebrochene Buchungssätze: RFVBER00
  • Auswertung vorerfasste Belege: RFPUEB00 – fertig buchen oder stornieren
  • Auswertung von gemerkten Belegen: RFTMPBEL
  • Kontrolle von Dauerbuchungen: RFDAUB00
  • Kontrolle von Kreditorenstammdatenänderungen: RFKABL00
  • Kontrolle von Debitorenstammdatenänderungen: RFDABL00
  • Kontrolle von Bankstammdatenänderungen: RFBKABL0
  • Kontrolle von Buchhaltungsbelegänderungen: RFBABL00
  • Auswertungen von FI-Buchungen: RFBELJ00
  • Änderungsanzeige Kredit-Management: RFDKLIAB
  • Vergleich Hauptbuchkonten mit Kostenstellen: RCOPCA44
  • Ledgervergleich: RGUCOMP4
  • Logistik-Auftragsbestand im Altsystem
  • Salden der Kostenstellen: Transaktion S_ALR_87013611
  • Vor- und Umsatzsteuer: RFUMSV00
  • Anlagebeschaffungen: RAZUGA01
  • Rückstellungen: RAABGA01
  • Report 1SIP (Voraussetzung: keine incremental Conversion darf laufen – prüfen über Transaktion ICNV)

Vergleichen Sie außerdem die folgenden Transaktionen sowohl im Alt- als auch im Neusystem

  • FAGLB03
  • FBL3N
  • FBL5N
  • FBL1N
  • ME2N
  • ME2L
  • MB5B
  • FD10N

Zusätzliche Vergleichs-Reports und -Transaktionen können im System Conversion Guide gelistet sein.

DaFRK

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.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.