Division-Reporting auf dem neuen Hauptbuch (NHB) im SAP BW

Division-Reporting im SAP BW

Sie führen im ERP das neue Hauptbuch (NHB) ein und fragen sich, welche Extraktoren Sie im SAP BW in Zukunft auf Basis des NHB nutzen sollen, um Ihr bisheriges internes und externes Reporting in den Bereichen Haupt- und Nebenbuch abzulösen und um divisionale Aspekte zu erweitern?

Sie stellen sich des Weiteren die Frage, ob die klassische Profit Center Rechnung im SAP BW durch die Extraktoren des NHB vollständig abgebildet werden kann und inwiefern die Debitoren- und Kreditorenrechnung vom Umstieg aufs NHB betroffen ist?

Sie beziehen auch die Frage mit in Ihre Überlegungen ein, ob die Extraktoren des NHB kompatibel mit S/4HANA sind?

Dann wird Ihnen dieser Blogbeitrag wertvolle Einsichten vermitteln, die Sie darin unterstützen werden, Ihr Transitionsprojekt effizient und effektiv zu meistern!

Einordnung des NHB in die SAP Finance Welt

Das NHB unterstützte ab ERP-Version 6.0 im Gegensatz zum klassischen Hauptbuch die Segmentberichterstattung (hier i. S. v. Divisions-Reporting) sowie die parallele Rechnungslegung (z. B. nach HGB und IFRS). Gleichzeitig ist die Profit Centers Rechnung ins NHB integriert.

Die parallele Rechnungslegung war über verschiedene Workarounds wie der Einführung spezifischer Buchungskreise, Konten oder Ledger auch schon in der Vergangenheit unter R/3 möglich. Die Segmentberichtserstattung über die gesonderte Profit Center Rechnung auch.

Dies allerdings zum Preis einer redundanten Datenhaltung und eines daraus resultierenden hohen Abstimmungsaufwandes. Gleichzeitig waren Belegsplits nur in nächtlichen Batchläufen, also nicht in real-time möglich! Die nachfolgende Grafik gibt einen Überblick über die zeitliche Einordnung des NHB in die SAP Finance Welt:

Zeitliche Einordnung des NHB in die SAP Finance Welt mit SAP-Extraktoren für BW, BW on HANA, BW/4HANA

Was verstehen wir unter Division-Reporting?

Wir verstehen darunter die Aufteilung eines Unternehmens nach spezifischen Kriterien zum Zweck der Berichterstattung für das interne sowie das externe Reporting.

Mögliche Gliederungen für das interne Reporting:

1. Nach Geschäftsbereich (Felder RBUSA/GSBER) zum Beispiel organisiert nach

  • a. Produktgruppen
  • b. Geographischen Regionen
  • c. Kundengruppen

2. Nach Funktionsbereich (Feld RFAREA) (Forschung & Entwicklung, Produktion, Vertrieb, etc.)

Profit Center (Feld PROFIT_CENTER) werden dazu verwendet, um die Divisionen des Unternehmens zum Zwecke des internen Reportings in ergebnisverantwortliche Teilbereiche weiter nach Geschäfts- oder Funktionsbereich aufzusplitten. Über die Profit Center ist damit eine detaillierte Messung des Unternehmenserfolgs hinsichtlich der Größen Umsatz, Kosten und Gewinn auf Profit Center Ebene möglich.

Das externe Reporting

Für das externe Reporting z. B. nach IFRS-8 (International Financial Reporting Standards), kann eine weitere Gliederung des Unternehmens auf Basis des Feldes SEGMENT sinnvoll sein. Dies ist dann der Fall, wenn die definierte Profit Center-Struktur nicht die Struktur der externen Segmentberichterstattung widerspiegelt!

Werden die Segmente fürs externe Reporting hingegen nach den gleichen Kriterien wie die Divisionen fürs interne Reporting gebildet, ist die Versorgung des Feldes SEGMENT optional. In diesem Fall besteht – wie in folgendem Bild – eine 1⇔N Beziehung zwischen Division/Segment [hier der Geschäftsbereich (GB)] und Profit Center (PC):

Beispielgliederung nach GB & PC

Wird hingegen fürs externe Reporting beispielsweise eine regionale Gliederung anstelle der Gliederung nach Produktgruppen verwendet, wird die Versorgung des Feldes SEGMENT zwingend. Es besteht dann eine M ⇔N Beziehung zwischen Segment und Profit Center. Anders ausgedrückt, können die Segmente in solchen Fällen nicht durch die Profit Center eindeutig beschrieben werden (siehe nachfolgendes Bild), wo Umsatz, Gewinn etc. der Profit Center ohne die Segmentdefinition nicht regional abgegrenzt werden könnten):

Regionale Segmente vs Gliederung PC nach Produktgruppe

Belegsplits als Voraussetzung/Grundlage für Divison-Reporting

FI-Belege werden zunächst ohne Split nach Profit Center erfasst (Erfassungssicht). Diese Sicht ermöglicht noch kein Division-Reporting. Dazu müssen die FI-Belege zunächst nach bestimmten Kriterien auf einzelne Divisionen (Profit Center) heruntergebrochen werden.

Durch diese Verteilung, den sogenannten Belegsplit, auf Profit Center wird dann die sogenannte NHB-Sicht erzeugt. Im ERP muss dazu zunächst der Belegsplit und damit die Profit Center Rechnung des NHB aktiviert werden! Gleichzeitig müssen Split-Regeln im ERP definiert werden.

Es können eine Vielzahl von Gründen existieren, warum man einen FI-Beleg aufsplitten möchte.

  • Verteilung von Kosten z. B. einer Marketing-Kampagne, falls mehrere Produktlinien davon profitierten.
  • Verteilung einer Rechnung für Büromaterialien auf mehrere Regionen.
  • Interne Leistungsverrechnung von Kosten und Erlösen (z. B. Verteilung IT-Aufwand).
  • Verteilung von Verkaufserlösen, falls mehrere Geschäftsbereiche am Verkauf beteiligt waren (Maschine wird mit Zubehör verkauft, das in der Verantwortung eines anderen GBs liegt).

Debitoren- & Kreditorenrechnung

Hier interessiert generell nur die Erfassungssicht. Die zugehörigen Extraktoren können bzw. müssen daher 1 zu 1 weiter genutzt werden.

Vorgehenstemplate für ein Transitionsprojekt vom klassischen auf das neue Hauptbuch

Für einen möglichst reibungslosen Umstieg hat ORBIS für Sie ein Vorgehenstemplate – bestehend aus elf Schritten – zusammengefasst, an dem Sie sich gerne orientieren können


1. Identifikation von Vergleichskriterien für den Vergleich der verfügbaren Extraktoren wie:

  • a. Unterstütze Ledger (Nur führendes oder alle?)
  • b. Gelieferte Datentypen (Nur „Ist“ oder auch „Plan“ etc. ).
  • c. S/4HANA Kompatibilität.
  • d. Performanz bei großem Datenvolumen (> mehrere 100 Millionen z. B. Saldo-Vortrag).
  • e. Delta-fähig?
  • f. Startroutine für Bilanz erforderlich?
  • g. DSO erforderlich?
  • h. Buchung während Init möglich?
  • i. Parallele Extraktion in mehrere BW-Systeme möglich?
  • j. Extraktion von Plandaten im Deltamodus möglich?

2. Sortierung dieser Kriterien nach Relevanz für ihr Unternehmen

3. VerAgleich der verfügbaren Extraktoren nach diesen Kriterien beginnend mit den relevantesten

4. Treffen einer Vorauswahl der einzusetzenden Extraktoren.

5. GAP-Analyse: Liefern die gewählten Extraktoren alle Felder, die fürs Reporting benötigt werden?
Falls nein,

  • i. Analyse, wie die Extraktoren geeignet erweitert werden können
  • ii. oder Untersuchung alternativer Extraktoren.

6. Analyse von BAdIs (Business Add-In), die im Zusammenhang mit der Klassischen Hauptbuchhaltung verwendet werden. Werden diese auch unter der NHB gebraucht?
Beispiel: Informationen zum Gegenkonto über BAdI oder zukünftig über Erweiterung der Tabelle FAGLFLEXA im ERP?

7. Analyse zur Optimierung der auf Basis der neuen Extraktoren neu aufzubauenden Datenflüsse:
Welcher Ballast aus den Datenflüssen zum klassischen Hauptbuch kann über Bord geworfen werden? Beispiel: Informationen für Werks-G&Vs (inkl. zugehöriger Lookups und Ableitungen im SAP BW) könnten mit der Einführung der Profit Center Belegsplits irrelevant werden.

8. Finale Festlegung der zu verwendenden Extraktoren / Spezifikation der darauf aufsetzenden Datenflüsse.

9. Implemetierung der Extraktoren und Datenflüsse.

10. Vor Initalisierung im SAP BW im ERP intensive Testphase einplanen:

  • a. Wichtig: Im ERP muss der Belegsplit (die Profit Center Rechnung des NHB) aktiv sein!
  • b. Abweichungen zwischen der Klassischen Hauptbuchhaltung & Profit Center Rechnung mit dem Neuen Hauptbuch identifizieren
  • c. Abweichungen erklären (in vielen Fällen sind diese durch die unterschiedliche Strukturierung wie Gemeinkosten- versus Umsatzkostenverfahren in der G&V oder die unterschiedliche Granularität der Daten zu erklären).
  • d. SAP-Korrektur-Reports identifizieren und im ERP zur Behebung von Differenzen implementieren.

11. Parallelbetrieb der Klassischen Hauptbuchhaltung und Profit Center Rechnung mit dem NHB über den Zeitraum von mindestens einem Jahr empfohlen.
Weitere Abweichungen identifizieren, erklären und auflösen.


Wir begleiten Sie von der Analyse bis hin zur Implementierung und Hyper-Care-Phase!

Im folgenden Abschnitt zeigen wir eines von mehreren möglichen Ergebnissen der Auswahl der Extraktoren gemäß der Punkte 1 bis 8 des oben gezeigten Vorgangstemplates.

Unsere Empfehlung für die Verwendung von Extraktoren für das NHB

Eine generelle Empfehlung kann nur schwer ausgesprochen werden, da es stark von den Gegebenheiten in Ihrem Unternehmen abhängt, welche Extrakoren eingesetzt werden sollten. Ich fasse daher im Folgenden Empfehlungen für die wahrscheinlichsten Szenarien zusammen.

1. FI-Salden

Szenario 1: Das Datenvolumen beim Jahresabschluss beträgt deutlich unter mehreren hundert Millionen.

  • 0FI_GL_10 für Ist-&Planzahlen des führenden Ledgers:
    • Ersetzt 0FI_GL_6
  • 0FI_GL_20 für Ist-Zahlen der relevanten Nebenbücher (Beispiel: HGB-Ledger):
    • Ersetzt den nicht voll S/4HANA kompatiblen 3FI_GL_<XX>_TT.
    • Weniger Druck bei der S/4HANA-Migration.

Szenario 2: Das Datenvolumen beim Jahresabschluss beträgt mehr als mehrere hundert Millionen.

  • 0FI_GL_12 für Ist-&Planzahlen des führenden Ledgers:
    • Ersetzt 0FI_GL_6.
    • OSS 1429281 beachten!
  • 3FI_GL_<XX>_TT für Ist-Zahlen der relevanten Nebenbücher (Beispiel: HGB-Ledger):
    • Nicht voll S/4HANA kompatibel
    • Vor S/4HANA Migration OSS 2302508 beachten
    • 0FI_ACDOCA_20 muss bei Neuinstallation verwendet werden!

2. FI-Einzelposten

  • 0FI_GL_14 für Ist-Zahlen des führenden Ledgers:
    • Ersetzt 0FI_GL_4
  • 3FI_GL_<XX>_SI für Ist-Zahlen der relevanten Nebenbücher
    • S/4HANA kompatibel!
  • 0FI_GL_50 Planzahlen

Bemerkung: Den Extraktor 0FI_GL_40 für Ist-Zahlen für alle Ledger hatten wir von vorneherein ausgeschlossen, da er nicht delta-fähig ist. Für Unternehmen mit recht geringem Datenvolumen könnte er hingegen eine Alternative darstellen!

3. Profit-Center-Rechnung

Die Frage, ob sich das Klassische Profit-Center-Reporting vollumfänglich vom NHB abgelöst werden kann, kann eigentlich nur im Rahmen einer Einzelfallanalyse entschieden werden.

Die Klassische Profit-Center-Rechnung bietet à priori erst einmal mehr Information als die o.g. Standard-Extraktoren fürs NHB. So fehlt dort zum Beispiel die Leistungsart. Hier muss geprüft werden ob, und mit welchem Aufwand diese erweitert werden können, um spezielle Reporting-Anforderungen in diesem Bereich weiterhin abdecken zu können.

Definitiv sollten im Rahmen der Einführung des NHB kritisch geprüft werden, an welcher Stelle das Reporting entschlackt und verschlankt bzw. modernisiert werden kann. Ein Beispiel stellen Werks-G&Vs da, die eigentlich mit den Profit Centern im NHB obsolet werden.

Technische Empfehlung für die Umstellung aufs NHB

Es empfiehlt sich vor der Einführung des neuen Hauptbuchs, falls noch nicht geschehen, das SAP BW auf die HANA-Datenbank aufzusetzen.

Die SAP-HANA-Datenbank ist notwendige Voraussetzung für die Nutzung von ODP (Operational Data Provisioning), was wiederum notwendige Voraussetzung für die Verwendung des neuen SAP BW Datenfluss ist. Also z. B. die Verwendung von ADSOs anstelle von DSOs und Cubes und DTPS anstelle von InfoPackages.

So erspart man sich eine später bei Umstieg auf BW/4HANA notwendig werdende Migration der gerade erst neu aufgebauten Datenflüsse.

Fazit zum neuen Hauptbuch im SAP BW

Unser Vorgehenstemplate unterstützt Sie dabei das für Ihr Unternehmen optimale Set an Extraktoren für das Neue Hauptbuch zu identifizieren und Sackgassen in der Transition vom klassischen zum neuen Hauptbuch frühzeitig zu erkennen und zu vermeiden.

Die intensive Abwägung der Vor- und Nachteile der zur Auswahl stehenden Extraktoren im Kontext Ihres Unternehmens stellt dabei einen zentralen Faktor für den Erfolg Ihres Transitionsprojekts dar.

Schließlich empfehlen wir Ihnen einen Parallelbetrieb der klassischen mit der neuen Lösung von mindestens einem Jahr. Dies ermöglicht es Ihnen, Abweichungen, die erst im Laufe der Zeit zu Tage treten, zu erkennen und entweder zu erklären oder durch geeignete Maßnahmen zu beheben.

Ein besonderer Dank an dieser Stelle gilt meinem Co-Autor Günter Lehmann! Durch seine Expertise und sorgfältige Arbeit hat er maßgeblich zur Erstellung dieses Blogbeitrages beigetragen.

AUTOR
Christian Weber, ORBIS SE
AUTOR Christian Weber Senior Manager Business Intelligence, ORBIS SE
Ähnliche Beiträge
Reporting SAP Datasphere und Analytics Cloud

Optimales Reporting mit SAP Datasphere und SAP Analytics Cloud (SAC)

Wie optimales Reporting mit zwei Tools (SAP Datasphere & SAC), die fortschrittliche Reporting- und Datenanalysemöglichkeiten besitzen, aussehen kann, erfahren Sie anhand eines spannenden Anwendungsbeispiel aus der Industriebranche.
30.04.2024
SAP|Business Analytics|SAP Data Warehouse
Housekeeping in SAP BW/4HANA Vorteile

Housekeeping in SAP BW/4HANA – die Top 5 Vorteile

In unserem Beitrag erfahren Sie, was Business Warehousing und Haushalt gemeinsam haben und, was es eigentlich mit dem Housekeeping in SAP BW/4HANA auf sich hat! Erhalten Sie wertvolle Insights zur Bedeutung und den Vorteilen.
26.10.2023
SAP|Business Analytics|SAP Data Warehouse
SAP Datasphere – Bedeutung & Vorteile!

SAP Datasphere – die Top 5 Vorteile

Große Datenmengen verarbeiten, analysieren und daraus wertvolle Erkenntnisse ziehen ist eine Herausforderung etlicher Unternehmen, die es nicht zu unterschätzen gilt. Die zukunftsorientierte Lösung SAP Datasphere kann hierbei Abhilfe schaffen!
19.09.2023
SAP|Business Analytics|SAP Data Warehouse
ABAP Core Data Services Views

ABAP Core Data Services Views im SAP BW oder BW/4HANA

Bei der Anwendung von Core Data Services im SAP Business Warehouse Umfeld begegnen Ihnen häufig vier Anwendungsfälle. In Teil 1 dieser Blogreihe stellen wir Ihnen zwei dieser Anwendungsfälle genauer vor.
10.04.2023
SAP|Business Analytics|SAP Data Warehouse