ACDOCA – Das Universal Journal | S/4HANA Material Ledger

(Last Updated On: 1. Oktober 2018)

Mit der Umstellung auf S/4HANA Finance bzw. S/4HANA Enterprise Management holen Sie sich die neue Datenhaltung über das Universal Journal ins Haus. In diesem Beitrag gehen wir auf einige wichtige Besonderheiten in der Vorbereitung und Nachbereitung einer S/4HANA Einführung ein. Denn S/4HANA schlägt bei der Migration eine Brücke zwischen der alten ECC-Welt und dem neuen Central Finance Ansatz. Die Tabelle ACDOCA ist dabei von besonderem Interesse, da sie die NewGL Positionstabelle FAGLFLEXA ablöst. Die Positionstabelle des neuen Hauptbuches wird stattdessen über Felder in der ACDOCA abgebildet.

Was ist das Universal Journal?

Das Universal Journal ist ein logischer Ansatz zur zentralen Belegaufbewahrung in einem SAP System. Es ist Bestandteil von SAP Simple Finance bzw. SAP S/4HANA Finance. Im Zuge der Implementierung von SAP Simple Finance wurde ein neues Datenmodell eingeführt.

Unter dem Buzzword „SAP Accounting powered by SAP HANA“ verbirgt sich im Endeffekt die zentrale Haltung von Finanzdaten in einem SAP System. Dies wird auch als Central Finance bezeichnet, weil nun alle Anwendungsbelege in einem einzigen Journal gespeichert sind. Dieses Journal dient als Single Point of Truth. Das heißt, es werden im System keine redundanten Daten mehr gespeichert.

In der alten SAP-Welt ist dies nämlich durchaus noch der Fall. So werden beispielsweise Sekundärindizes in den Tabellen BSIS und  BSAS geschrieben, um einen schnellen Zugriffauf FI-Belege zu gewährleisten. Auch Daten in den Tabellen BSEG und BSEG_ADD enthalten redundante Daten, die zur Anzeige von Belegen aus dem Archivsystem in den Transaktionen FB03 und FB03L verwendet werden. Ohne diese Indizes finden diese Standard-Transaktionen die Belege nicht, sobald sie einmal archiviert wurden. Und selbstverständlich werden Daten sowohl im externen Rechnungswesen als auch im Controlling redundant gespeichert. Dabei werden die Belege einmal in den entsprechenden FI-Tabellen auf der einen und den CO-Tabellen auf der anderen Seite hinterlegt.

Das Problem bei redundanter Datenhaltung: Sie führen zu unnötigem Speicherplatzverbrauch. Nicht nur auf Storage-Ebene, also im Sekundärspeicher. Sondern vor allem im Arbeitsspeicher, also auf Ebene des Primärspeichers. Die SAP adressiert dieses Problem mit der Zentralisierung dieser Daten. Außerdem beschleunigt das Herunterbrechen von Daten auf weniger Datensätze (und damit weniger Speicherblöcke) die Abfragezeit all dieser Daten, insbesondere im in-Memory Umfeld.

Wie ist die Tabelle ACDOCA aufgebaut?

Dazu aggregiert das SAP System die Anwendungsdaten aus den Bereichen Hauptbuchhaltung (FI-GL), Anlagenbuchhaltung (FI-AA), Controlling (CO) und aus dem Material Ledger in ein zentrales Journal. Technisch geschieht diese Zusammenfassung in einer großen Cluster-Tabelle namens ACDOCA. Diese enthält in der neuen Simple Finance Welt alle Einzelpostenbelege aus den Berecihen FI, FI-AA und CO. Alle Buchungen in diesen Modulen werden bei einer S/4HANA Migration in diese Tabelle geschrieben. Dabei ändert sich auch das Schema dieser Daten. Die folgende Abbildung zeigt ungefähr die Zusammenstellung der Daten im Universal Journal.

SAP Tabelle ACDOCA Bestandteil von SAP Central Finance

Zusammensetzung der Tabelle ACDOCA

die Tabelle besteht aus über 360 Feldern. Die verschiedenen Dokumentarten bekommen unterschiedliche Präfixe vor der eigentlichen Dokumentnummer. B steht für gespeicherte Salden, C für alte CO Dokumente und D für Korrekturen im Rahmen der Migration auf Simple Finance oder S/4HANA Finance.

Welche Tabellen ersetzt die ACDOCA?

Das Universal Journal ersetzt durch seine Datenhaltung einige SAP-Tabellen aus der alten ECC-Welt. Jedoch werden diese nicht einfach aus dem SAP-System gelöscht, sondern durch sogenannte SAP HANA Views abgelöst. Dadurch soll sichergestellt werden, dass Programme, die noch lesend auf diese Tabellen verweisen, zum Großteil weiterhin funktionieren. Folgende Tabellen werden durch Views ersetzt, ihre Daten werden unter Central Finance in Form von Feldern in der Tabelle ACDOCA abgebildet:

  • Die Tabellen für Einzelposten, Salden und Applikationsindizes aus der Hauptbuchhaltung (FI-GL). Darunter fallen insbesondere viele bekannte Indextabellen aus dem FI-Bereich. Darunter GLT0, BSIS, BSAS, FAGLFLEXA, FAGLFLEXT, FAGLBSIS und FAGLBSAS.
  • Summen- und Applikationsindextabellen aus der Debitor- und Kreditorbuchhaltung. Darunter beispielsweise LFC1, LFC3, BSID, BSIK, SAD, BSAK, KNC1 und KNC3.
  • Die Saldo und Einzelposten Tabellen des Controllings. Betroffen sind hier beispielsweise die Tabelle COEP (nur für bestimmte Werttypen), COSP und COSS.
  • Die Tabellen für den Material Ledger. Die Tabellen MLIT, MLPP, MLPPF, MLCR, MLCD, CKMI1 und BSIM werden nun in der ACDOCA gespeichert. Die Inhalte der MLHD werden in der BKPF gespeichert.
  • Die Tabelle BSEG gibt es weiterhin. Sie speichert Posten aus den klassischen FI Buchungen (FB01, FB50, FB60, FB70 usw.)
  • Tabellen aus der Anlagenbuchhaltung (FI-AA). Darunter fallen die Tabellen ANEK, ANEP, ANEA, ANLP und ANLC.

Die folgende Abbildung liefer eine technische Sicht darauf, welche Tabellen im Universal Journal übergehen. Im Wesentlichen finden sich diese in der Tabelle ACDOCA, jedoch auch in der tabelle BKPF und einigen Nebentabellen wieder.

Das Universal Journal besteht aus den Tabellen ACDOCA und BKPF

All diese roten Tabellen (und weitere) aus der alten ECC-Welt finden unter Central Finance ihren Einzug in die grün markierten Tabellen.

Über den SAP Hinweis 2156822 können Sie sich ein Mapping der alten ECC Tabellen zub den Feldern in der Tabelle ACDOCA herunterladen. Weitere Tabellen und Views, die unter den neuen Releases nicht mehr exisiteren, können über die SAP Note 2431747 gefunden werden. Die Header Daten eines Journal-Eintrags werden in der Tabelle BKPF gespeichert. Die Positionstabellen wandern in die ACDOCA.

Voraussetzungen für das Universal Journal

Um das Universal Journal unter Cenral Finance nutzen zu können, benötigen Sie ein Simple Finance on-Premise Edition 1503 System oder neuer. Dies entspricht einem Business Suite on HANA System mit installiertem SAPFIN Addon. Auch eine Migration auf SAP S/4HANA Finance oder SAP S/4HANA Enterprise Management führt zu einer Belegmigration in das Universal Journal. Hinweis: Die SAP empfiehlt mittlerweile nicht mehr den Zwischenschritt auf Simple Finance, sondern explizit die Migration auf ein S/4HANA Release.

Dies setzt logischerweise wiederum voraus, dass das zu konvertierende System bereits auf Unicode basiert und bereits das neue Hauptbuch implementiert ist. Wenn Sie noch die klassische Hauptbuchhaltung verwenden, müssen Sie erst eine Migration auf das neue Hauptbuch unternehmen. Des Weiteren wird von Ihnen gefordert, einen Periodenabschluss und eine entsprechende Schließung der laufenden Buchungsperioden durchzuführen. Führen Sie hierzu einen periodischen Abschreibungslauf über den Report RAPOST2000 bzw. Transaktion AFAB durch.

Stellen Sie iim Anschluss über den Report RAPERB2000 sicher, dass alle periodischen Anlagenbuchungen fehlerfrei abgeschlossen sind  und ein aktueller Zeitstempel gesetzt wird. Wenn Sie bisher unter ERP 6.0 die klassische Anlagenbuchung im Einsatz hatten, stimmen Sie nun das Hauptbuch mit der klassischen Anlagenbuchhaltung über den Report RAABST01 bzw. Transkation ABST ab und korrigieren Sie Abstimmdifferenzen.

Wenn Sie hingegen unter ERP 6.0 bisher die neue Anlagenbuchhaltung im Einatz hatten, stimmen Sie das Hauptbuch mit der neuen Anlagenbuchhaltung über den Report FAA_GL_RECON bzw. Transaktion ABST/ABSTL ab und korrigieren Sie Abstimmdifferenzen. Weitere Informationen hierzu erhalten Sie im angehängten PDF Dokument in SAP Hinweis 2309893.

Weiterhin sind bestimmte Komponenten, Industrielösungen und Business Functions von SAP ERP nicht kompatibel mit der neuen Anlagenbuchhaltung. Dazu gehören beispielsweise die Lease Accounting engine (EA-FIN: LAE) oder Immobilien (RE). Diese werden im neuen Release durch neue Komponenten ersetzt. Beispielsewise können Sie in der neuen Anlagenbuchhaltung das Flexible Immobilienmanagement (RE-FX) verwenden.

Außerdem wird von Ihnen mitunter die Installation von HANA Live Paketen über den HANA Lifecycle Manager (HLM) gefordert. Die Pakete liefern einige Views aus, welche auf das Universal Journal zeigen.

Wenn Sie bereits ein S/4HANA System Life haben und stattdessen einen Buchungskreis eines ECC-Systems in dieses S/4HANA System überführen möchten, ist der SAP Hinweis 2522155 – Company Code Specific Conversion ot S/4HANA sowie alle Folgehinweise richtig für Sie.

Besonderheiten für die neue Anlagenbuchhaltung

Wenn Sie die neue Anlagenbuchhaltung (New Asset Accounting) nutzen wollen, müssen Sie vor der Installation von SAP Simple Finance bzw. S/4HANA Finance die Enterprise Extension EA-FIN aktivieren. Sie benötigen in diesem Zusammenhang dann auch eine neue Abschreibungsrechnung (AfA-Rechnung, Report AFAR). Diese ist in einem separaten Teilprojekt einzuführen.

Außerdem müssen Sie, wenn Sie bisher im führenden Ledger parallele Währungen eingeführt haben, diese parallelen Währungsbereiche auch in allen Bewertungsbereichen der Anlagenbuchhaltung einführen, bevor Sie Simple Finance installieren.

Sobald Sie Simple Finance bzw. S/4HANA Finance installiert haben, können Sie in den Buchungsperioden nicht mehr buchen. Erst nachdem die Belege erfolgreich migriert wurden, können Sie in den einzelnen Bereichen wieder Buchungen vornehmen. Daher ist vor der Migration ein kompletter Periodenabschluss empfehlenswert.

Eine Migration auf das Universal Journal erfolgt im Moment der Migration auf einen der oben genannten Releases. Eine Trennung dieser Prozesse ist nicht möglich.  Vor der Migration auf eines der genannten Ziel-Releases müssen Sie über diverse Reports Vorabprüfungen durchführen. Diese überprüfen, ob

  • die technischen Voraussetzungen für eine Migration vorliegen (beispielsweise Unicode-System, Einsatz des New General Ledger (NewGL, neues Hauptbuch)
  • das Customizing den Vorgaben für Simple Finance bzw. S/4HANA Finance entspricht
  • die zu konvertierenden Buchhaltungsbelege technisch konsistent und formell richtig im System verbucht sind. Falls dem nicht so ist, werden entsprechende Inkonsistenzen aufgezeigt.

Stellen Sie außerdem manuell sicher, dass es im System keine Verbuchungsabbrüche aus der direkten Buchung gibt

Sicherstellung der Konsistenz der Tabelle ACDOCA

Bei der Migration auf das Universal Journal muss sichergestellt werden, dass die Daten richtig in das neue Format überführt werden. Deswegen werden bei der Migration nacheinander die folgenden Schritte durchgeführt.

  1. Bevor die Salden- und Indextabellen gelöscht werden, werden Backup-Tabellen abgelegt. Im FI Bereich bekommen diese den Suffix _BCK und im CO den Suffix _BAK
  2. Nach der Kopie der Originaltabellen in diese Backup-Tabellen werden die Originale gelöscht
  3. Nach der Löschung der Originaltabellen werden gleichnamige HANA-Views angelegt.
  4. Nachdem die View steht, wird der Buchungsbeleg in die ACDOCA bzw. in die Tabelle BKPF migriert.

Besonders wichtig auf Seiten der Migrationsdurchführung: Führen Sie auf gar keinen Fall neue Buchungen durch, bevor Sie nicht die Migration im Software Update Manager abschließen. Dies führt, je nach Fortschritt der Migration, zu verschiedenen Inkonsistenzen oder Nebeneffekten gemäß SAP Hinweis 2530178.

 

Vorab- und Nachprüfung der Belege im Universal Journal

Die SAP liefert einige Reports zur Vorabprüfung der Belegmigration aus. Der Report RASFIN_MIGR_PRECHECK aus SAP Hinweis 1939592 ist zuständig für die Prüfung der Voraussetzungen der neuen Anlagenbuchhaltung. SAP Note 2333236 enthält hierbei die aktuellen Korrekturen für diesen Report. Weitere Informationen sind außerdem in SAP Hinweis 2220152 hinterlegt.

Für eine Konvertierung nach SAP S/4HANA Finance und SAP Simple Finance gibt es einen Sammelhinweis (SAP Note 2176077) für durchzuführende Prüf-Reports. Für eine Konvertierung nach S/4HANA Finance (sFIN) müssen Sie die Transkation FINS_MIG_PRECHECK bzw. den Report FINS_MIG_PRECHECK_CUST_SETTINGS (SAP Note 2129306) ausführen. Dieser Report führt Prüfungen auf dem Hauptbuch aus.

Für eine Konvertierung nach SAP S/4HANA für Releases kleiner 1709 führen Sie die Checks aus dem S/4HANA System Conversion Check Framework aus. Hierzu sehen Sie bitte SAP Note 2182725 für das gesamte Check Framework und speziell 2240666 für die FI-spezifischen Checks ein.

Für eine System Conversion nach SAP S/4HANA 1709 oder später werden die erforderlichen Checks bereits durch den Software Update Manager durchgeführt. Ein Fehler mit Return Code 7 kann hierbei übersprungen und als Nacharbeit nach dem S/4HANA Upgrade nachgezogen werden.

Unter jedem Release können Sie das SI-check Framework über SAP Note 2503309 implementieren. Führen Sie danach die Checks über den Report /SDF/RC_START_CHECK aus. Der Report spuckt Ihnen eine Liste an Fehlern mit einer entsprechenden Sub-ID aus. Der Sammelhinweis 2245333 ermöglicht es Ihnen, nach diesen Sub-IDs zu suchen und dadurch eine Lösung zu ermitteln.

Für bestimmte S/4HANA Release gibt es außerdem eine sogenannte Follow-On Note. Diese behandelt die Lösung von Problemen nach einer S/4HANA System Conversion. Als Beispiel sei hier die Note 2389807 für das Relase 1610 genannt. Kunden berichten außerdem bei einer Migration auf bestimmte SAP S/4HANA Releases über redundante Einträge in der Tabelle ACDOCA. Im Beispiel S/4HANA 1709 FPS02 wird dies durch den SAP Hinweis 2661437 adressiert. Einige Kunden haben auch Probleme mit korrupten Werten im HVKWRT Feld der ACDOCA. Spielen Sie hierbei jedoch nur auf Aufforderung des SAP Supports den Hinweis 2586000 ein.

Debitoren und Kreditoren einem Geschäftspartner zuweisen

In der alten SAP ECC Welt können Sie einen Debitor und einen Kreditor (Customer and Vendor) immer nur jeweils einem Geschäftspartner (Business Partner) zuweisen. Dies bedeutet in der alten ERP Welt, dass Sie zwei Geschäftspartner für den selben Debitor bzw. Kreditor anlegen müssen. In der neuen Welt unter Central Finance ist dem nicht mehr so. Sie können nun einen debitorischen Kreditor bzw. einem kreditorischen Debitor anlegen und beide Entitäten einem einzigen Geschäftspartner zuweisen.

Hierzu müssen Sie das zum selben Geschäftspartner gehörende Debitoren/Kreditoren-Paar miteinander verbinden. Diese dürfen dazu nicht bereits verschiedenen Geschäftspartnern zugewiesen sein. Einer der beiden Entitäten darf bereits mit einem Geschäftspartner verbunden sein, aber nicht beide. Die Verbindung muss vor der Initial Load Phase einer S/4HANA Migration geschehen. Der Workflow hierzu wird in SAP Hinweis 2363892 beschrieben. Hinweis: Diese SAP Note hat eine Post Upgrade Tätigkeit als Follow Up nach der S/4HANA Conversion.

Geschäftspartner Logik Besonderheiten

Durch die Zusammenlegung von Debitoren und Kreditoren unter Central Finance werden einige Debitor- bzw. Kreditor-spezifische Transkationen obsolet. Diese werden in der neuen S/4 Welt über hartkodierte Rollen umgeleitet. Im Falle von Z-Rollen schlägt dieser Workflow jedoch fehl. Implementieren Sie zur Lösung dieses Problems SAP Hinweis 2523563.

Mitarbeiter in Geschäftspartner konvertieren unter Central Finance

Wenn es nach der SAP geht, würden alle Kunden zusätzlich zur Einführung von S/4HANA auch einen Wechsel von SAP HCM on Premise nach SAP SuccessFactors wagen. Gut, dass viele Kunden sich weiterhin dazu entscheiden, SAP HCM on-Premise zu betreiben. Wenn Sie zu diesem glücklichen Kreis gehören, müssen Sie jedoch Ihre Mitarbeiter in Geschäftspartner umwandeln. Nur so ist eine nahtlose Integration mit SAP S/4HANA möglich.

Diese Umwandlung müssen Sie nur durchführen, wenn Sie SAP HCM als dediziertes System betreiben. Wenn Sie SAP HCM als Modul innerhalb von SAP S/4HANA betreiben, ist die Integration bereits durch den Kompatibilitätsmodus gegeben. Um die Konvertierung in einem verteilten Szenario durchzuführen, führen Sie nach der System Conversion den Report /HCM/RH_SYNC_BUPA_FROM_EMPL aus und planenn Sie ihn danach täglich als Job ein. Weitere Informationen erhalten Sie im SAP Hinweis 2340095.

S/4HANA Migration auf den Material Ledger

Unter SAP S/4HANA 1610 und höher ist eine Migration auf den neuen Material Ledger notwendig. Dies ist auch dann der Fall, wenn der Material Ledger im Quell-Release nicht verwendet wurde. Vor dieser Migration müssen Sie eine Reihe von SAP Hinweisen aus dem Sammelhinweis 2345739 implementieren.

Danach müssen Sie bestimmte IMG-Aktivitäten durchführen. Eine Anleitung hierzu finden Sie im SAP Hinweis 2352383 bzw. 2267834. Diese Migration aktiviert jedoch noch nicht die Nachkalkulation (Actual Costing), denn diese Option ist selbst unter S/4HANA optional. Um die Zeit der Migration zu reduzieren, sollten Sie so viele Daten wie möglich auf den Tabellen MBEWH, EBEWH, QBEWH, OBEWH, CKMLPP, CKMCLR, EKBE, EKBEH, EKBZ, EKBZH, MLAUFCR und MLAUFCRH archivieren. Sie können des Weiteren die Paketgröße von 20.000 auf einen höheren Wert anheben. Dies geht über den Parameter FML_MIG_PKG_SIZE.

Die folgende Abbildung zeigt, welche Tabellen im neuen S/4HANA Material Ledger welche Tabellen aus der ECC-Welt ersetzen.

SAP S/4HANA Material Ledger MLDOC MLDOCCS

Nach der Migration auf den Material Ledger können Sie über die Hinweise 2354768 und 2416935 die entsprechenden Hinweise für die Nachkalkulation (Actual Costing) implementieren.

Neues S/4HANA Material Inventory Management

Unter S/4HANA erwartet Sie außerdem eine neue Lagerwaltung (MM-IM), die sich vom klassischen ECC Inventory Management unterscheidet. Auch hier ändert sich das zugrunde liegende Datenmodell. Die folgende Tabelle ist aus SAP Note 2206980 entnommen und zeigt die Veränderungen übersichtlich auf.

Table
Table description
DDL Source of CDS View for redirect
View to read the content of the database table (w/o redirect to compatibility view)
View to read the master data attributes only
MKPFMaterial document headerNSDM_DDL_MKPFNSDM_MIG_MKPF
MSEGMaterial document itemNSDM_DDL_MSEGNSDM_MIG_MSEG
MARCPlant Data for MaterialNSDM_DDL_MARCNSDM_MIG_MARCV_MARC_MD
MARDStorage Location Data for MaterialNSDM_DDL_MARDNSDM_MIG_MARDV_MARD_MD
MCHBBatch stocksNSDM_DDL_MCHBNSDM_MIG_MCHBV_MCHB_MD
MKOLSpecial Stocks from VendorNSDM_DDL_MKOLNSDM_MIG_MKOLV_MKOL_MD
MSLBSpecial Stocks with VendorNSDM_DDL_MSLBNSDM_MIG_MSLBV_MSLB_MD
MSKASales Order StockNSDM_DDL_MSKANSDM_MIG_MSKAV_MSKA_MD
MSSATotal Customer Orders on HandNSDM_DDL_MSSANSDM_MIG_MSSA
MSPRProject StockNSDM_DDL_MSPRNSDM_MIG_MSPRV_MSPR_MD
MSSLTotal Special Stocks with VendorNSDM_DDL_MSSLNSDM_MIG_MSSL
MSSQProject Stock TotalNSDM_DDL_MSSQNSDM_MIG_MSSQ
MSKUSpecial Stocks with CustomerNSDM_DDL_MSKANSDM_MIG_MSKUV_MSKU_MD
MSTBStock in TransitNSDM_DDL_MSTBNSDM_MIG_MSTB
MSTEStock in Transit to Sales and Distribution DocumentNSDM_DDL_MSTENSDM_MIG_MSTE
MSTQStock in Transit for ProjectNSDM_DDL_MSTQNSDM_MIG_MSTQ
MCSDDIMP: Customer StockNSDM_DDL_MCSDNSDM_MIG_MCSDMCSD_MD
MCSSDIMP: Total Customer StockNSDM_DDL_MCSSNSDM_MIG_MCSSMCSS_MD
MSCDDIMP: Customer stock with vendorNSDM_DDL_MSCDNSDM_MIG_MSCDMSCD_MD
MSCSDIMP: Customer stock with vendor – TotalNSDM_DDL_MSCSNSDM_MIG_MSCSMSCS_MD
MSFDDIMP: Sales Order Stock with VendorNSDM_DDL_MSFDNSDM_MIG_MSFDMSFD_MD
MSFSDIMP: Sales Order Stock with Vendor – TotalNSDM_DDL_MFSNSDM_MIG_MSFSMSFS_MD
MSIDDIMP: Vendor Stock with VendorNSDM_DDL_MSIDNSDM_MIG_MSIDMSID_MD
MSISDIMP: Vendor Stock with Vendor – TotalNSDM_DDL_MSISNSDM_MIG_MSISMSIS_MD
MSRDDIMP: Project Stock with VendorNSDM_DDL_MSRDNSDM_MIG_MSRDMSRD_MD
MSRSDIMP: Project Stock with Vendor – TotalNSDM_DDL_MSRSNSDM_MIG_MSRSMSRS_MD
MARCHHistoryNSDM_DDL_MARCHNSDM_MIG_MARCH
MARDHHistoryNSDM_DDL_MARDHNSDM_MIG_MARDH
MCHBHHistoryNSDM_DDL_MCHBHNSDM_MIG_MCHBH
MKOLHHistoryNSDM_DDL_MKOLHNSDM_MIG_MKOLH
MSLBHHistoryNSDM_DDL_MSLBHNSDM_MIG_MSLBH
MSKAHHistoryNSDM_DDL_MSKAHNSDM_MIG_MSKAH
MSSAHHistoryNSDM_DDL_MSSAHNSDM_MIG_MSSAH
MSPRHHistoryNSDM_DDL_MSPRHNSDM_MIG_MSPRH
MSSQHHistoryNSDM_DDL_MSSQHNSDM_MIG_MSSQH
MSKUHHistoryNSDM_DDL_MSKAHNSDM_MIG_MSKAH
MSTBHHistoryNSDM_DDL_MSTBHNSDM_MIG_MSTBH
MSTEHHistoryNSDM_DDL_MSTEHNSDM_MIG_MSTEH
MSTQHHistoryNSDM_DDL_MSTQHNSDM_MIG_MSTQH
MCSDHHistoryNSDM_DDL_MCSDHNSDM_MIG_MCSDH
MCSSHHistoryNSDM_DDL_MCSSHNSDM_MIG_MCSSH
MSCDHHistoryNSDM_DDL_MSCDHNSDM_MIG_MSCDH
MSFDHHistoryNSDM_DDL_MSFDHNSDM_MIG_MSFDH
MSIDHHistoryNSDM_DDL_MSIDHNSDM_MIG_MSIDH
MSRDHHistoryNSDM_DDL_MSRDHNSDM_MIG_MSRDH

Die Daten werden also nicht mehr in den Kopf- und Positionstabellen MKPF und MSEG gehalten. Dies bringt einige Veränderungen in der Transaktion DB15 mit sich. Wichtiger ist jedoch der Einfluss auf kundenseitige Eigenentwicklungen. Insbesondere wirkt sich diese Änderung des Datenmodells auf Appends an die Tabellen MKPF und MSEG aus. Diese werden mit der Einführung von S/4 obsolet und müssen durch einen sogenannten Customer Include (CI) ersetzt werden.

In diesem Zusammenhang sollten Sie es auch tunlichst unterlassen, während der Laufzeit einer S/4HANA Conversion, auch während der Parallellaufzeit im Schattensystem,  MM Dokumente (insbesondere über das Archivierungsobjekt MM_MATBEL) zu archivieren. Weitere Informationen hierzu finden Sie in SAP Note 2493434.

Archivierung von FI Belegen im Universal Journal

Mit der Einführung der zentralisierten Belegverwaltung im Universal Journal kommt ein Problem einher. In der klassischen SAP-Archivierung wurden FI Dokumente beispielsweise über das Archivierungsobjekt FI_DOCUMNT archiviert. Nach erfolgreichem Schreibvorgang konnten die Daten dann über einen entsprechenden Lösch-Job aus der Datenbank gelöscht werden. Dies ist nicht mehr der Fall, denn zum Datensatz des archivierten FI-Beleges gehören noch andere Felder. Diese Felder wiederum werden von anderen Transaktionen des SAP-Systems noch benötigt und würden in der klassischen ECC-Welt zu einem anderen Archivierungsobjekt gehören.

Daher können die soeben erfolgreich durch das Schreibprogramm archivierten Daten nicht aus der Tabelle ACDOCA gelöscht werden. Deswegen wurde die Archivierungsoption unter Central Finance zunächst deaktiviert. Sie als SAP-Kunde wollen aber archivieren, um regulatorische und rechtliche Vorgaben zu erfüllen. Beispielsweise möchten Sie mitunter Anwendungsbelege in ein GoBD-konformes Archivsystem verschieben oder auch die Funktionalitäten von ILM zur Sperrung von Daten nutzen.

Zu diesem Zweck hat die SAP die Funktionalität aus SAP Hinweis 2332670 implementiert. Demnach werden nach einem erfolgreichen Schreibvorgang die relevanten Daten in der ACDOCA geflaggt. Diese Daten werden dann aggregiert und komprimiert (was ihre Größe reduziert) nicht mehr von den Standard FI-Transaktionen angezeigt (es sei denn Sie greifen explizit auf das Archiv zu), obwohl sie noch in der Tabell ACDOCA vorhanden sind. Dadurch wird es einfacher, Datenschutzanforderungen der EU-DSGVO zu erfüllen.

Zu den Archivierungsobjekten, deren Archivierung nicht zu einer Löschung aus der ACDOCA führt, sondern nur zu einer Komprimierung und Markierung, sind beispielsweise

  • FI_DOCUMNT
  • AM_ASSET
  • CO_ML_BEL
  • CO_ALLOST
  • viele Archivierungsobjekte sind hingegen nicht betroffen, beispielsweise FI-SL

Mehr Informationen zur Archivierung von FI Belegen unter S/4 und die dazu einzuhaltende Archivierungsreihenfolge finden Sie in SAP Hinweis 2346296. Insbesondere sollten Sie zuerst Daten aus der CO Welt archivieren. Hierzu liefert die SAP außerdem einen Prüfreport namens FINS_CO_ARCH_PREP_ANALYZE aus. Bei der Archivierung werden die Anwendungsbelege dabei im Format der alten SAP-Welt gespeichert. Das bedeutet die Anwendungsbelege aus der ACDOCA werden on-the-fly in das alte Format konvertiert. So werden FI-Belege beispielsweise noch so archiviert, als würden sie noch in der Tabelle FAGLFLEXA persisiert sein. Dadurch können bestehende Reports für die Anzeige von Anwendungsbelegen aus dem Archiv weiterhin genutzt werden. Im Falle des Archivierungsobjektes FI_DOCUMNT werden die Anwendungsbelege jedoch zusätzlich auch im ACDOCA-Format gespeichert.

Der Zugriff auf die FI-Daten ist jedoch nur für die SAP-Standardtranskationen gegeben. Im Gegensatz dazu ist es nicht möglich, mit neueren Programmen, die auf dem ODATA- oder InA-Protokoll basieren (typischerweise Fiori Apps) auf die archivierten Belege zuzugreifen.

Ein weiteres Problem taucht im Zusammenhang mit der Summenberechnung auf. In der alten SAP-Welt wurden die Salden noch gespeichert und waren über dedizierte Archivierungsobjekte wie beispielsweise CO_TOTAL archivierbar. In der neuen Welt des Universal Journal werden Summensätze (Totals) on the fly über die CPU berechnet und nicht mehr gespeichert.

Wenn Sie nun beispielsweise Ihre Posten über das Archivierungsobjekt CO_ITEM archivieren, haben Sie keine Möglichkeit mehr, die Summensätze über CO_TOTAL zu archivieren, da diese nicht mehr berechnet werden können. Es kann nun aber sein, dass steuerrechtlich relevante Transaktionen und Reports weiterhin davon ausgehen, dass CO-Totals als separater Datensatz gespeichert sind.

Um dieses Problem zu umgehen, erklärt SAP die Archivierungsobjekte CO_ITEM und CO_TOTAL als obsolet. Stattdessen sollen Sie mit Einführung von S/4 das Archivierungsobjekt CO_TRANS verwenden. Dieses Archivierungsobjekt schreibt sowohl die Posten als auch die Summensätze der einzelnen Kostenstellen gesammelt weg.

Die Archivierung von Totals im FI Bereich über die Archivierungsobjekte FI_TF_CRE, FI_TF_DEB , FI_TF_GLC, FI_TF_GLN und FI_TF_GLF wird über die Hinweise in SAP HInweis 2346296 geregelt.

In der klassischen SAP ERP Welt gab es die Option, nach der Archivierung von FI Belegen über das Archivierungsobjekt FI_DOCUMNT noch sekundäre Anwendungsindizes in einigen Indextabellen zu belassen (BSIS, BSAS, BKPF, BSEG, BSEG_ADD usw.). In der neuen S4 Welt des Universal Journal werden diese Indizes nicht mehr gespeichert, sondern on-the-fly aus den Dokumenten generiert. Wenn die Dokumente nun archiviert werden, ist diese on the fly Generierung nicht mehr möglich. Für diese Belege werden dann Einträge in den Tabellen BSIS_BCK, BSAS_BCK usw. angelegt. Wie schon in der alten SAP ERP Welt gibt es einen Report für die Löschung dieser Sekundärindizes in den _BCK tabellen. Dieser heißt nun FI_DOCUMNT_PST. Ebenso gibt es einen Report zur nachträglichen Erzeugung dieser Sekundärindizes aus den archivierten Dokumenten (SAPF048S).

Um den Einfluss auf den Arbeitsspeicherverbrauch auf der HANA Datenbank sowie die Performance des Systems nicht zu stark zu beeinträchtigen, können diese Sekundärindizes über das SAP HANA Data Aging auf eine kalte Partition verschoben werden. Damit werden die Indizes in den _BCK Tabellen nicht mehr in den Primärspeicher (Arbeitsspeicher) des Systems geladen, sondern nur noch auf Platte persistiert und nur noch von dieser gelesen. Hierzu muss Data Aging aktiv sein und das Partitionierungsobjekt FI_INDEX gepflegt werden. Ein Aging Objekt ist nicht notwendig.

Wichtig zu verstehen: Da einige Dokumente sind nicht mehr in den Tabellen BSEG und BSEG_ADD wiederfinden, gibt es mitunter Probleme bei der Anzeige einiger archivierter Belege in den Transkationen FB03 und FB03L. Welche Belege davon betroffen sind, können Sie über die Hinweise in SAP Note 2297729 herausfinden.

Performanceprobleme im FI-Bereich unter S/4HANA

„Ich dachte, unter HANA läuft alles rasend schnell“. Das kriegt man zu hören, wenn sich Kunden nach einer S/4HANA System Conversion über die Performance im FI-Bereich beschweren. Dem Kunden fällt hierbei bei der Ausführung kundeneigener Reports häufig auf, dass die Performance sich eher verschlechtert als verbessert hat.

Wenn Sie allerdings in diesem Beitrag aufgepasst haben, wissen Sie, woran es liegt. Die Reports des Kunden zeigen noch auf die Tabellen aus der alten ECC-Welt, und dahinter verbirgen sich jedoch unter S/4 nur noch einfache Views, die auf die eigentlichen Einträge in der ACDOCA zeigen (SAP Hinweis 2575530). Diese Views stellen aus den Original-Daten in der ACDOCA das alte Datenmodell on the fly wieder her. Die Zeit, welche die CPU für diese Konvertierung braucht, fühlt der Kunde mit.

Zur Behebung dieses Problems gilt es einfach, die Erweiterungen des Kunden auf das neue Datenmodell der ACDOCA anzupassen. Sobald die Reports auf die eigentliche Cluster-Tabelle durchgreifen, vergehen die Performance Probleme im Flug.

Kundeneigene Entwicklungen für die ACDOCA

Als SAP Kunde sollten Sie alleine schon aus Performancegründen Ihr Coding möglichst schnell an das Universal Journal anpassen. Für die Nutzung der Views GLT0, FALFLEXT, FMGLFLEXT, PSGLFLEXT und JVGLFLEXT in kundeneigenen Entwicklungen unter S/4HANA gibt es den SAP Hinweis 2221298. HInweise für die Compatibility Views COSP, COSS, COEP und COVP finden Sie in SAP Hinweis 2185026.

 

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.

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 …

3 Antworten

  1. Roland sagt:

    Guten Tag Herr Loibl,

    vielen Dank für diesen sehr hilfreichen Artikel. Wir befinden uns aktuell noch in der Oracle Welt und haben vor, erst im Jahr 2024 auf S/4HANA zu gehen. Ist eine Migration auf Suite on HANA ein sinnvoller Zwischenschritt?

    P. S. ich bin etwas verwirrt über Ihr Profil. Sind Sie derzeit als Freelancer oder als Angestellter unterwegs?

    Viele Grüße

    Roland

    • DaFRK sagt:

      Guten Tag,

      das ist eine sehr gute Frage. Eine Migration auf SoH kann ein sinnvoller Zwischenschritt sein. Insbesondere wenn Sie noch ein Non-Unicode System haben oder allgemein sehr viel Customer Coding mitnehmen wollen. Dann teilen Sie nämlich die Nachbearbeitung Ihres Codings auf. Im ersten Schritt nach Suite on HANA Unicode-enablen Sie Ihr Coding und fügen HANA-spezifische Änderungen ein. Im zweiten Schritt, nach der Umstellung auf S/4, kümmern Sie sich im Coding um die neue Datenhaltung des Universal Journal – stellen also auf ACDOCA und Co. um. Das bricht die ganze Sache ein wenig auf.

      Ebenfalls empfehlen kann ich Ihnen den Zwischenschritt auf SoH:
      – Wenn Sie sich noch auf der klassischen Hauptbuchhaltung bzw. Anlagenbuchhaltung befinden. Der Zwischenschritt auf SoH eignet sich perfekt, um hier auf die neue Buchhaltung umzustellen. Zwar haben Sie dann im Endeffekt zweimal eine Belegdatenmigration (erst vom alten ins neue Hauptbuch, und dann vom neuen Hauptbuch in die ACDOCA), jedoch geht es hier um die prozedurale Umstellung, die Ihnen hier erleichtert wird.
      – Wenn Sie erstmal Erfahrung mit der HANA Datenbank und den ganzen Satellitentechnologien sammeln wollen (In der ABAP Entwicklung ändert sich einiges – angefangen im Transportwesen, SAP HANA System Replication und Host Auto-Failover, SAP HANA Enterprise Search ersetzt den TREX usw.)
      – Wenn Sie schon heute die Features der neuen EHPs mitnehmen, aber eben erst später auf S/4 gehen wollen.

      Es kann jedoch auch besser sein, wenn Sie einen Big Bang Releasewechsel machen.
      – Bedenken Sie: Je länger Sie mit der System Conversion warten, desto größer wird Ihr System und desto länger somit auch die Downtime (mitunter trotz Datenarchivierung, wenn Ihr Unternehmen stark wächst). Ausnahme: Sie installieren S/4 neu und migrieren nur die Stamm- und Bewegungsdaten aus den Altsystemen, denn können Sie die Downtime kurz halten.
      – Ein Zwischenschritt kann mitunter höhere Kosten bedeuten. Beispielsweise wenn Sie Ressourcen für den User Acceptance Test zweimal statt nur einmal bestellen müssen. Hier ist eine Abwägung zwischen der Risikomitigation aufgrund der schrittweisen Umstellung und den dadurch verursachten Kosten zu treffen.

      P. S. Sowohl als auch. Wenn es um SAP-Themen geht, erreichen Sie mich derzeit als Angestellter. Wenn es um Webentwicklung, Online Marketing, IT Schulungen und Support geht, erreichen Sie mich als Freelancer.

      Viele Grüße

      Andreas Loibl

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.