Schnelleinstieg in SAP S/4HANA Finance

2.1 Einführung in das Universal Journal

Mit dem Universal Journal (Tabelle ACDOCA) ändert sich die Art und Weise, wie Bewegungsdaten für die Finanzberichterstattung gespeichert werden, erheblich. Es bietet enorme Vorteile, was die Möglichkeiten zur Harmonisierung der Anforderungen an das interne und externe Berichtswesen anbelangt, indem es aus demselben Belegspeicher liest, in dem das Konto das verbindende Element für alle Formen der Finanzberichterstattung darstellt. Sie werden aber auch weiterhin die verschiedenen Anwendungen verstehen müssen, in dem Maß, in dem Sie unterschiedliche Geschäftsvorgänge in jeder Anwendung ausführen müssen. D.h., Sie müssen nach wie vor Hauptbuchbelege in der Hauptbuchhaltung und Anlagenzu- und -abgänge in der Anlagenbuchhaltung erfassen, Verrechnungen und Abrechnungen im Controlling ausführen, Forschungs- und Entwicklungskosten im Investitionsmanagement aktivieren usw. Im Berichtswesen lesen Sie jedoch aus einer Quelle, unabhängig davon, ob Sie Daten für Ihr Konsolidierungssystem bereitstellen, das Berichtswesen für die Finanzbehörden erstellen oder interne Managemententscheidungen treffen.

Abbildung 2.1 verdeutlicht, wie das Universal Journal die Reporting-Dimensionen aus den separaten Anwendungen (Hauptbuchhaltung, Ergebnis- und Marktsegmentrechnung, Controlling, Anlagenbuchhaltung und Material-Ledger) kombiniert, um eine einheitliche Datenstruktur für Auswertungen bereitzustellen, bei der alle relevanten Dimensionen berücksichtigt werden.

Abbildung 2.1: Kombinieren von Berichtsdimensionen im Universal Journal

Die Schlüsselfelder des Universal Journal haben Sie bereits in Abbildung 1.3 gesehen. Wenn wir nun die Details der neuen Einzelpostentabelle in Abbildung 2.2 betrachten, sehen wir, wie die bestehenden Felder der Hauptbuchhaltung, der Anlagenbuchhaltung, des Material-Ledgers und des Controllings über eine Reihe von Include-Strukturen im Universal Journal vereint werden und so Daten aus den vielen verschiedenen Geschäftsvorgängen zu einer Single Source of Truth, also einer einzigen Quelle der Wahrheit, für die Finanzberichterstattung in SAP S/4HANA zusammenführen.

Abbildung 2.2: Zusammenführung der SAP-ERP-Anwendungen im Universal Journal

Die enorme Vereinfachung, die diese Struktur mit sich bringt, besteht darin, dass Sie statt auf separate Erlöszeilen in der Ergebnis- und Marktsegmentrechnung, der Profitcenter-Rechnung und der Finanzbuchhaltung zuzugreifen, die jeweils einen unterschiedlichen Detaillierungsgrad desselben Geschäftsvorgangs aufweisen, aus einem einzigen Quellbeleg in der Tabelle ACDOCA berichten können. Für das interne Berichtswesen können Sie beispielsweise Erlöszeilen für ein bestimmtes Produkt oder einen konkreten Kunden auswählen (Informationen, die als Merkmale erfasst werden und die Sie bei der Erstellung des Ergebnisbereichs in der Ergebnisrechnung auswählen können), und für das externe Berichtswesen wählen Sie dieselben Erlöszeilen über das Profitcenter oder den Buchungskreis im Beleg aus.

Wenn wir von einer »Single Source of Truth« sprechen, ist damit gemeint, dass wir anstelle von Datensätzen in mehreren Anwendungen verschiedene Aggregationen desselben Datensatzes betrachten, indem wir Felder aus den verschiedenen in Abbildung 2.2 gezeigten Include-Strukturen auswählen. Wie ich es bereits in Abschnitt 1.2.1 angesprochen habe, ist hier die Idee der spaltenorientierten Datenbank von Bedeutung. Selbst wenn wir Hunderte von Buchungskreisen, Tausende von Profitcentern und Zehntausende von Kunden haben, können diese viel effizienter abgefragt werden als in der Vergangenheit, als jede Anwendung noch ihren eigenen Datenspeicher aufbaute, um Informationen über diese Entitäten zu speichern.

In diesem Zusammenhang ist es lohnend, wenn Sie die verschiedenen Anwendungen verstehen, die in der Vergangenheit zur Aggregation der Daten verwendet wurden. Obwohl viele der relevanten Felder in der BSEG-Tabelle enthalten waren, konfigurierten Unternehmen ihre Finanzbuchhaltungsanwendungen mithilfe der Verdichtung so, dass die einzelnen Kostenstellen aus großen Personalabrechnungsbelegen bzw. die einzelnen Materialien aus großen Rechnungen entfernt wurden und nur das Kostenstellendetail in der Kostenstellenrechnung bzw. das Materialdetail in der Ergebnisrechnung beibehalten wurde. Diese unterschiedliche Granularität brachte beim Abgleich der verschiedenen Anwendungen ihre eigenen Herausforderungen mit sich, da bei der Aggregation wichtige Informationen verloren gingen.

Bevor wir uns den Neuerungen widmen, rufen wir uns noch einmal die allgemeinen Unterschiede zwischen den Datenbeständen in den verschiedenen Anwendungen ins Gedächtnis. Alle Anwendungen im Rechnungswesen aggregieren nach Periode und Geschäftsjahr, doch die anderen Berichtsdimensionen unterscheiden sich in jeder Anwendung. Das erschwert die Abstimmung und hat zur Folge, dass in Management-Meetings viel darüber diskutiert wird, wessen Version der Wahrheit korrekt ist, anstatt darüber zu sprechen, wie man auf die durch die Zahlen abgebildete Geschäftssituation reagieren soll.

Wenn SAP S/4HANA Finance ganz neu für Sie ist, können Sie direkt mit Abschnitt 2.2 fortfahren, da Sie sich dann nicht mit den historischen Unterschieden zwischen den verschiedenen Anwendungen befassen müssen.

2.1.1 Struktur der Hauptbuchhaltung

Hier kommt es darauf an, welche Version der SAP-Software Sie einsetzen. Wenn Sie eine Umstellung auf SAP S/4HANA anstreben, gibt es zwei verschiedene Optionen für die Hauptbuchhaltung:

• Die Klassische Hauptbuchhaltung ist ab SAP R/3 verfügbar und speichert Daten nach Konto, Buchungskreis und Geschäftsbereich, wie wir bei der Betrachtung von Tabelle GLT0 in Abbildung 1.2 sehen können. Wenn Sie andere Reporting-Dimensionen als den Buchungskreis und den Geschäftsbereich benötigen, können Sie zusätzliche Anwendungen für die Profitcenter-Rechnung und die Konsolidierungsvorbereitung aktivieren oder eigene Spezielle-Ledger-Anwendungen für die Kosten des Umsatzes, die Segmentberichterstattung usw. entwickeln.
  Die separaten Ledger für die Profitcenter-Rechnung, die Konsolidierungsvorbereitung usw. werden nicht mehr benötigt, da die Informationen im Universal Journal stehen. Dennoch werden diese Ledger fortgeschrieben und können aktuell weiterverwendet werden. Diese speziellen Ledger sind Teil des Kompatibilitätsumfangs. Das bedeutet, dass sie für eine Übergangszeit, aber nicht über das Jahr 2025 hinaus unterstützt werden.
  Zusätzlich zu diesen Ledgern speichert ein Abstimmledger die Ergebnisse sämtlicher buchungskreisübergreifenden Verrechnungen oder Abrechnungen im Controlling, die zum Periodenabschluss in der Hauptbuchhaltung erfasst werden müssen, indem die Transaktion KALC zur Generierung der entsprechenden Buchungsbelege ausgeführt wird. Die Umstellung auf das Universal Journal macht das Abstimmledger und die Transaktion KALC obsolet, da es nur noch einen Beleg im Rechnungswesen und Controlling gibt.
  Die Tabelle COFIT wird jedoch nicht mehr aktualisiert und die für das Kostenarten-Reporting angebotenen Legacy-Berichte werden nicht mehr unterstützt.
• Das SAP-ERP-Hauptbuch (früher unter der Bezeichnung neues Hauptbuch bekannt) ist seit SAP ERP verfügbar. Damit können Sie den grundlegenden Ansatz mit Konten, Buchungskreisen und Geschäftsbereichen erweitern, indem Sie zusätzliche Szenarien zur Unterstützung von Profitcenter-Rechnung, Kosten des Umsatzes, Konsolidierungsvorbereitung, Segmentberichterstattung usw. aktivieren. Die Aktivierung dieser Szenarien erweitert die Tabelle FAGLFLEXA für die Speicherung der Detailinformationen zu Profitcentern und Partner-Profitcentern, Funktionsbereichen und Partnerfunktionsbereichen, verbundenen Unternehmen und Partner-verbundenen Unternehmen, Segmenten und Partnersegmenten usw. Im Prinzip aktivieren diese Szenarien die Recherche für diese Dimensionen innerhalb des Hauptbuchs. Technisch betrachtet, haben Sie für alle Szenarien, die Sie zum Hauptbuch hinzugefügt haben, zusätzliche Aggregate angelegt. Mit der Aktivierung der Echtzeit-Integration in CO wurde das Abstimmledger obsolet, sodass jede buchungskreisübergreifende (oder auch Profitcenter-übergreifende, funktionsbereichsübergreifende usw.) Verrechnung oder Abrechnung eine Buchung im Hauptbuch auslösen würde, um die Änderung widerzuspiegeln. Dies ist im Vergleich zur klassischen Hauptbuchhaltung ein Fortschritt, allerdings ist die Anzahl der Dimensionen, die Sie sicher zur Aggregatstabelle FAGLFLEXA hinzufügen können, beschränkt.
  Mit dem Universal Journal müssen Sie die verschiedenen Szenarien des Berichtswesens nicht mehr separat aktivieren – die Spalten werden automatisch aktualisiert, wenn Sie die richtigen Zuordnungen in Ihren Stammdaten vornehmen, und Sie können ganz nach Ihrem Bedarf weitere Dimensionen zum Kontierungsblock hinzufügen.

Oft wird fälschlicherweise angenommen, dass das Universal Journal die einzige Tabelle ist, die für die Hauptbuchhaltung eingesetzt wird. Tatsächlich existieren neben dem Universal Journal die alte Belegkopftabelle (BKPF) und die Belegpositionstabelle (BSEG) weiter, wie in Abbildung 2.3 dargestellt. Die Tabelle BSEG wird nach wie vor für den Ausgleich offener Posten und die damit verwandten Aufgaben verwendet. Die Einträge können aber verdichtet werden, um Entitäten wie das verkaufte Produkt oder die Kostenstellen zu entfernen, wenn die detaillierten Informationen nur im Universal Journal (ACDOCA) benötigt werden. Da die BSEG jedoch für die Verrechnung genutzt wird, müssen Sie das Material für die Waren-/Rechnungseingangsverrechnung aufbewahren.

Abbildung 2.3: Datenmodell für Journalbuchungen

2.1.2 Struktur der Anlagenbuchhaltung

SAP S/4HANA Finance beinhaltet die neue Anlagenbuchhaltung. Deren neue Funktionen wurden zunächst als Business Function FIN_AA_CI_1 in EhP6 und FIN_AA_PARALLEL_VAL in EhP7 eingeführt. Die ursprüngliche Motivation entstand durch den Bedarf, zwischen Rechnungslegungsgrundsätzen zu wechseln, da US-Kunden ihre führende Bewertung zunehmend von US-GAAP (Generally Accepted Accounting Principles) auf IFRS (International Financial Reporting Standards) umstellten. Wenn Sie auf Abbildung 1.3 zurückblicken, werden Sie feststellen, dass das Ledger eines der Schlüsselfelder im Universal Journal ist. Während die Anlagenbuchhaltung durch das Angebot verschiedener Bewertungsbereiche für eine Anlage schon immer unterschiedliche Bewertungen unterstützt hat, werden im neuen Ansatz die unterschiedlichen Anlagenbewertungen für IFRS und die lokalen GAAPs in separaten, voneinander unabhängigen Ledgern gespeichert. In früheren Versionen der Software wurde die zweite Bewertung als Delta (oder Differenz) zur ersten Bewertung gespeichert und beim Periodenabschluss aktualisiert. Jetzt ist es möglich, die separaten Ledger in Echtzeit zu aktualisieren, sofern für den Bewertungsbereich Echtzeitbuchungen aktiviert wurden.

Die Anlagenbuchhaltung war von jeher mit der Hauptbuchhaltung integriert, in dem Sinne, dass Journalbuchungen für den Erwerb, den Abgang und die Neubewertung einer Anlage erstellt oder die Abschreibung des Anlagegutes im Hauptbuch verbucht werden konnten. Die Anlagenbuchhaltung war jedoch ein Nebenbuch, in dem detaillierte Informationen zur Anlagenbewertung gespeichert wurden. Die Hauptbuchhaltung speicherte aggregierte Informationen über die Anlagen im Hauptbuch (Tabellen GLT0 oder FAGLFLEXA). In der Einzelpostentabelle der Anlagenbuchhaltung (Tabelle ANEP) waren weder das Konto, das Profitcenter noch alle von mir aufgeführten Positionen für das Hauptbuch enthalten, und in der Finanzbuchhaltung wie auch im Controlling waren die anlagenbezogenen Felder nicht verfügbar. Die einzige gemeinsame Berichtsdimension von Hauptbuchhaltung und Anlagenbuchhaltung ist – neben Periode und Jahr – der Buchungskreis. Um die Anwendungen abzugleichen, mussten die Buchungen im Hauptbuch, die sich auf das Anlagevermögen bezogen (Kontenart A), gefunden und mit der Summe der Posten in der Anlagenbuchhaltung verglichen werden. Wenn Sie also beispielsweise eine manuelle Journalbuchung für ein Anlagenkonto erstellt haben, gab es keine Übereinstimmung, weil diese manuelle Buchung in der Anlagenbuchhaltungstabelle nicht existierte.

Inzwischen gibt es kein separates Nebenbuch für die Anlagenbuchhaltung mehr, und die Anlage ist ganz einfach eine zusätzliche Dimension im Hauptbuch, die sich neben Buchungskreis, Kostenstelle, Profitcenter usw. im Buchungsstring befindet. Dass das die anwendungsübergreifende Berichterstattung wesentlich erleichtert, werden wir sehen, wenn wir uns die Summen- und Saldenliste in Abschnitt 2.3.1 ansehen.

2.1.3 Kontierungen im Controlling

Obwohl die Kostenstellenrechnung, die Auftragsrechnung und die Projektrechnung im Controlling in der Regel als separate Anwendungen betrachtet werden, ist das Grundprinzip der Zuordnung von Kosten zu einer Kontierung (Kostenstelle, Auftrag, PSP-Element usw.) bei allen gleich.

Das Controlling bietet zwei Arten der Buchung für Istkosten:

• Die erste Buchungsart ist die Primärkostenbuchung. Dies bedeutet lediglich, dass die Hauptbuchbuchung gleichzeitig eine Zuordnung zur Kostenstelle, zum Auftrag oder zum Projekt, das für die Kosten verantwortlich ist, umfasst – so können z.B. Lohnbuchungen, Reisekosten und Anlagenabschreibungen einer Kostenstelle bzw. Materialaufwendungen einem Auftrag oder Projekt zugeordnet werden. Jedes für die Aufzeichnung dieser Buchungen verwendete Sachkonto ist mit einem Gegenstück in Form einer Primärkostenart im Controlling verknüpft, mit der solche Kosten erfasst werden. Zwischen den Primärkostenbuchungen und den zugehörigen GuV-Buchungen im Hauptbuch besteht eine Eins-zu-Eins-Beziehung. Die Buchungsposten in den beiden Anwendungen haben jedoch nicht unbedingt die gleiche Granularität. Das liegt daran, dass die Hauptbuchposten oft so konfiguriert sind, dass die Kostenstellen, Aufträge oder das Projekt verdichtet (also entfernt) werden, um das Datenvolumen zu reduzieren. Das ist häufig bei den Materialpositionen in der Rechnung der Fall, die gerne verdichtet werden, damit das Limit von 999 Einzelposten für die BSEG-Tabelle nicht überschritten wird.
• Die zweite Buchungsart ist die Sekundärkostenbuchung. Sie bedeutet, dass die Kosten weiterverrechnet oder abgerechnet werden. In unserem Beispiel könnten die der Kostenstelle zugeordneten Lohn-, Reise- und Abschreibungskosten mithilfe der Zeiterfassung, der Auftragsrückmeldung oder eines Gemeinkostenzuschlags auf Aufträge und Projekte verrechnet werden. Dies hätte zur Folge, dass die Kostenstelle entlastet und der Auftrag oder das Projekt unter einer sekundären Kostenart belastet werden. Die Auftrags- und Projektkosten können an Marktsegmente abgerechnet werden, wodurch der Auftrag oder das Projekt entlastet und die Marktsegmente belastet werden, wiederum unter einer sekundären Kostenart. Es gab nie eine Eins-zu-Eins-Beziehung zwischen diesen sekundären Kostenarten und den Sachkonten, da sie in ein einziges Abstimmkonto für den relevanten Geschäftsvorgang aggregiert wurden, unabhängig davon, ob Sie die Transaktion KALC oder die Echtzeit-Integrationsfunktionen in der SAP-ERP-Hauptbuchhaltung verwendeten. Bei der Umstellung auf SAP S/4HANA werden die Ergebnisse der Verrechnungen und Abrechnungen unter den sekundären Kostenarten gespeichert. Stellen Sie also sicher, dass Sie alle Konsolidierungssysteme, die auf Kontoinformationen zugreifen, entsprechend anpassen.

Am einfachsten kann man sich die Umstellung auf SAP S/4HANA so vorstellen: Bei Primärkostenbuchungen erweitern die Informationen zur Kontierung die Journalbuchung, um zu verdeutlichen, wo und warum Kosten angefallen sind. So erkennen wir, dass Gehälter auf eine Kostenstelle und Rohstoffkosten auf einen Fertigungsauftrag gebucht wurden. Sekundärkostenbuchungen hingegen erfassen die Beziehungen zwischen den Sendern und Empfängern von Verrechnungen oder Abrechnungen. Diese Beziehungen können zu Aktualisierungen der betroffenen Profitcenter, Funktionsbereiche usw. führen, was wiederum Journalbuchungen nach sich zieht, in denen die Auswirkungen der Verschiebung auf die zugehörigen Partnerobjekte aufgezeichnet werden. In Abschnitt 1.3 bin ich auf den Wegfall der Summentabellen für Primärkosten (COSP) und Sekundärkosten (COSS) eingegangen. Mit der Einführung des Universal Journal existieren diese Summensätze nur noch als Kompatibilitätssichten, bis die SAP alle Programme für eine direkte Selektion aus dem Universal Journal umgeschrieben hat. Die Reimplementierungsbemühungen ermöglichen zudem die Einführung des Ledgers zur Unterstützung unterschiedlicher Rechnungslegungsvorschriften und zusätzlicher Währungen durch Hinzufügen neuer Felder, die in den alten Tabellen nicht ohne Weiteres untergebracht werden konnten.

Das Controlling leistet jedoch mehr, als nur primäre Kosten und Erlöse zu sammeln und sekundäre Kosten zu erfassen. Für die statistischen Kennzahlen (COSR), die Tarife (COST), die Abweichungen (COSB) und das Obligo (COOI) existieren weiterhin getrennte Tabellen. In Kapitel 3 werden wir uns ansehen, wie die Berechnung dieser Elemente schrittweise umgestaltet wurde, um den neuen Strukturen gerecht zu werden.

2.1.4 Margenanalyse

Auch die Ergebnis- und Marktsegmentrechnung (CO-PA) galt im Allgemeinen als eine separate Anwendung innerhalb des Controllings. SAP ERP unterstützt zwei Arten von Ergebnis- und Marktsegmentrechnung: Die Margenanalyse (früher als »buchhalterische Ergebnisrechnung« bezeichnet) und die kalkulatorische Ergebnisrechnung.

Bevor SAP HANA ausgeliefert wurde, verwendeten jedoch die meisten Unternehmen zugunsten einer besseren Performance nur die kalkulatorische Ergebnisrechnung: Heutzutage ist die Margenanalyse die bevorzugte Wahl in SAP S/4HANA.

• Die Margenanalyse erfasst die Erlöse, Erlösschmälerungen und Umsatzkosten unter Primärkostenarten sowie das Ergebnis von Verrechnungen und Abrechnungen unter Sekundärkostenarten. Der Unterschied zur Kostenstellenrechnung, Auftrags- oder Projektbuchhaltung besteht darin, dass es sich bei der Kontierung nicht um eine eindimensionale Kostenstelle oder einen Auftrag handelt, sondern um ein mehrdimensionales Marktsegment oder eine Gruppe von Merkmalen, wie z.B. das verkaufte Produkt, den Kunden, der das Produkt gekauft hat, das Verkaufsbüro, den Vertriebskanal usw. Da der Ergebnisbereich konfigurierbar ist, verwendet jede Organisation ihre eigenen CO-PA-Merkmale. Mit dem Umstieg auf das Universal Journal wird für jedes der Merkmale in Ihrem Ergebnisbereich eine Spalte angelegt, und Berichtsdimensionen wie Kunde, Produkt und Vertriebsbüro stehen gleichberechtigt neben Buchungskreis, Profitcenter und Funktionsbereich.
• Die kalkulatorische Ergebnisrechnung verwendet dagegen den gleichen Ergebnisbereich mit denselben Merkmalen, wandelt aber die Konten/Kostenarten in Wertfelder um. Hier führt eine technische Begrenzung dazu, dass nur 200 Wertfelder unterstützt werden (in früheren Releases waren es 120). Aus diesem Grund gibt es typischerweise weit weniger Wertfelder als Konten, und es existieren Wertfelder für Positionen ohne Kontierung, wie z.B. statistische Frachtkosten oder Erlösschmälerungen. Da es gängige Praxis ist, in Rechnungen nicht nur die Kostenstelle, sondern auch die Materialnummer zu verdichten, weisen die Zeilen in der Hauptbuchhaltung häufig eine andere Granularität auf als die Zeilen in der Ergebnis- und Marktsegmentrechnung.
  Die kalkulatorische Ergebnisrechnung wird in SAP S/4HANA Finance weiterhin unterstützt, jedoch können die Daten aufgrund der Wertfelder nicht im Universal Journal zusammengefasst werden, und die Tabelle CE1 (die Einzelpostentabelle für die kalkulatorische Ergebnisrechnung) existiert weiterhin neben dem Universal Journal. Es gibt keinen Migrationsdienst, mit dem man von einem kalkulatorischen zu einem buchhalterischen Modell wechseln kann, da beide Modelle auf grundlegend verschiedenen Ansätzen beruhen (Konten vs. Kennzahlen).

Zur Veranschaulichung des neuen Ansatzes zeigt Abbildung 2.4 die App »Produktprofitabilität«. Zu den Dimensionen auf der linken Seite gehören Felder für die Marktsegmente (Branche, Geschäftsjahr, Geschäftsperiode usw.), aber auch Dimensionen aus der Hauptbuchhaltung, einschließlich Buchungskreis und (nicht dargestellt) Sachkonto und Ledger etc. Dies ist ein Beispiel dafür, wie Informationen aus den ehemals getrennten Anwendungen in SAP S/4HANA zusammengeführt werden. Sie werden feststellen, dass dieser Bericht nicht alle Sachkonten präsentiert, sondern eine aggregierte Sicht, in der fakturierte Forderungen (Faktur. Forderung), realisierte Erlöse usw. zu sehen sind. Diese Aggregationen ähneln den in der kalkulatorischen Ergebnisrechnung verwendeten Wertfeldern, werden aber über semantische Tags erstellt. Wir werden uns in Abschnitt 6.7 ansehen, wie Sie Ihre Konten diesen semantischen Tags zuordnen. Wenn es Sie interessiert, welche Sachkonten hinter jedem semantischen Tag stehen, können Sie aus der Liste der Dimensionen auf der linken Seite die Dimension »Sachkonto« in die Berichtszeilen ziehen. So erkennen Sie, aus welchen Sachkonten die fakturierte Erlösbuchung besteht.

Abbildung 2.4: App »Produktprofitabilität«

2.1.5 Strukturen im Material-Ledger

Die Verwendung des Material-Ledgers in SAP S/4HANA sorgt immer wieder für Verwirrung. In SAP S/4HANA Finance ist die Nutzung des Material-Ledgers optional, aber seit SAP S/4HANA muss das transaktionale Material-Ledger obligatorisch verwendet werden. Wie wir bei der Margenanalyse gesehen haben, unterstützt SAP ERP zwei Ansätze für das Material-Ledger: das transaktionale Material-Ledger und die Istkalkulation. Die meisten Unternehmen sprechen allerdings vom Material-Ledger und meinen damit eigentlich, dass sie die zweite Option, die Istkalkulation, einsetzen.

• Das vorgangsbezogene Material-Ledger ist ein Nebenbuch wie die Anlagenbuchhaltung, jedoch gegliedert nach Buchungskreis, Bewertungskreis und Material. Aus Sicht des Material-Ledgers gilt für Materialien die Preisfindung 2, was ganz einfach bedeutet, dass bestandsbezogene Transaktionen in verschiedenen Währungen und nach unterschiedlichen Wertansätzen (Konzernbewertung, legale Bewertung und Profitcenter-Bewertung) erfasst werden. Sie können weiterhin mit dem gleitenden Durchschnittspreis arbeiten, der bei jeder Transaktionsaktualisierung berechnet wird, und Sie müssen zum Periodenabschluss keinen Kalkulationslauf durchführen. Die Verwendung des vorgangsbezogenen Material-Ledgers wird mit SAP S/4HANA On-Premise Edition 1511 obligatorisch, auch wenn sie bereits seit SAP R/3 Release 4.0 verfügbar ist.
• Die Istkalkulation wird dagegen in Regionen und Branchen eingesetzt, für die eine gesetzliche oder betriebswirtschaftliche Anforderung besteht, Kaufpreis- und Produktionsabweichungen etc. zum Periodenabschluss den verkauften Waren und Waren im Bestand zuzuordnen. Bei dieser Option müssen Sie einen oder mehrere Kalkulationsläufe durchführen, um die Istkosten zum Periodenabschluss zu ermitteln. Die Istkalkulation wird in SAP S/4HANA weiterhin als Option unterstützt und kann zusätzlich in der Cloud aktiviert werden. Die Daten können nicht vollständig im Universal Journal zusammengefasst werden, und die Istkalkulationstabellen existieren weiterhin neben dem Universal Journal. SAP S/4HANA 1610 enthält eine neue, optimierte Version der Istkalkulation mit einer einfacheren Datenstruktur und weniger Abschlussschritten.

Abbildung 2.5 zeigt die App »Materialbewertungen verwalten«, in der Sie sehen können, dass die Bestandswerte für das Lager in zwei Währungen verfügbar sind: der Buchungskreiswährung (BWähr) und der Konzernwährung (KonzWährng).

Abbildung 2.5: App »Materialbewertungen verwalten«

2.1.6 Andere Nebenbuchhaltungen

In Abbildung 2.1 sehen Sie, dass das Anlagen- und das Material-Nebenbuch zwar mit dem Hauptbuch verschmelzen, einige wichtige Nebenbücher aber separat bleiben. Die Debitoren- und Kreditorenbuchhaltung werden als getrennte Nebenbücher für die Offene-Posten-Verwaltung und den Zahlungsausgleich weitergeführt. Im Hauptbuch finden Sie nur das Abstimmkonto für den Lieferanten oder den Kunden. Dies hängt teilweise mit der Ausgleichslogik in der Kreditoren- und Debitorenbuchhaltung zusammen, wo mehrere Rechnungslegungsvorschriften und Währungen einander im Weg stehen., wenn Sie versuchen, einen offenen Posten für einen bestimmten Betrag auszugleichen. Die Debitoren- und Kreditoren-Vertragskonten bleiben ebenfalls getrennt, damit alle Details für die nutzungsbasierte Abrechnung usw. gespeichert werden können. Einige Branchenlösungen haben zudem ihre eigenen Nebenbücher, so etwa der SAP Bank Analyzer bzw. der SAP Insurance Analyzer für Finanzdienstleister oder das SAP Customer Activity Repository (CAR) in der Retail-Lösung. Diese sind auf der Ebene des Kontos und einiger wichtiger Berichtsdimensionen weiterhin mit dem Hauptbuch integriert.

Natürlich gibt es noch mehr Unterschiede zwischen den Anwendungen als die oben aufgeführten Berichtsdimensionen. Historisch gesehen, wurde im Finanzwesen mit drei Währungen gearbeitet, während es im Controlling nur zwei Währungen gab. Auch die Rechnungslegungsvorschriften wurden in jeder Anwendung unterschiedlich gehandhabt (Ledger in der Hauptbuchhaltung, Bewertungspläne in der Anlagenbuchhaltung, Versionen im Controlling, Währungstypen im Material-Ledger). Vielen dieser Unterschiede wird auch in SAP S/4HANA Finance Rechnung getragen. Ich werde die relevanten Änderungen in den folgenden Abschnitten behandeln.