Bei der Abbildung über die Kontenlogik gibt es ein einziges Hauptbuch, sprich einen einzigen Datenspeicher, in welchem sowohl die Sachverhalte der lokalen Rechnungslegung (der Einfachheit halber ab hier auf HGB reduziert), als auch die Sachverhalte nach IFRS gebucht werden. Diese Variante wurde vom Kunden auch im ursprünglichen Rechnungswesen-System abgebildet, der im Projekt so genannten Micky-Mouse-Logik. Die meisten Sachverhalte werden sowohl nach IFRS und HGB gleich gebucht. Diese Sachverhalte werden auf den Sachkonten, die ausschließlich für gemeinsame Sachverhalte zulässig sind gebucht (Kopf der Micky Mouse). Das linke Ohr ist nur für die HGB-Sachverhalte (z.B. steuerrechtliche Anpassungen) das rechte Ohr nur für die IFRS-Sachverhalte (z.B. Aktivierung von eigenerstellter Software) reserviert. Somit sind nur für Sachverhalte, die zwischen den beiden Rechnungslegungsstandards unterschiedlich zu verbuchen sind, die Buchungen doppelt zu erfassen. Aufgrund der Hauptnachteile dieser schon beim Kunden bestehenden Lösung, nämlich die Verlängerung des Kontenplans um die doppelten Konten, welche gleiche Inhalte in den unterschiedlichen Ohren präsentierten und die Möglichkeit, durch versehentliche Buchungen zwischen den Rechnungslegungsstandards Wertverschiebungen zu erzeugen, wurde die Analyse der Abbildung über parallele Ledger mit großem Interesse betrieben.

Offensichtliche Vorteile sind dabei die klare Trennung der jeweiligen Rechnungslegungen in zwei unterschiedliche Datenspeicher und die Vermeidung von gedoppelten Konten, wenn gleiche Sachverhalte in unterschiedlicher Betragshöhe gebucht werden sollen. Eine Vermischung der Sachverhalte ist somit nicht mehr möglich. Der operative Buchungsaufwand ist mit dem der Micky-Mouse-Kontenlösung vergleichbar, da es dass neue Hauptbuch ermöglicht, gleiche Sachverhalte gleichzeitig in beide Ledger fortzuschreiben. Als nachteilig erwiesen sich in einem Release-Stand ECC6.0 ohne Enhancement Package 3 (das EHP3 war noch im Ramp-up) allerdings die Restriktionen, dass die offene Postenverwaltung nur im führenden Ledger möglich war (z.B. zum Ausziffern von Rückstellungskonten) und die Rückschreibung des Controlling-Ledger (z.B. für das UKV) auch nur in das führende Ledger möglich war. Aufgrund dieser Nachteile (die allerdings im Enhancement Package 3 durch die SAP teilweise behoben wurden) und des Komforts, die Buchungslogik während der Umstellung nicht ändern zu müssen, wurde sich letztendlich nach intensiven Überlegungen für die bewährte Kontenlösung entschieden.

Einführung der GuV nach Umsatzkostenverfahren mit Echtzeitintegration CO->FI
Bei der Einführung einer Gewinn- und Verlustrechnung nach dem Umsatzkostenverfahren stellt sich im Handel sofort die Frage, nach welchen Berichtsdimensionen wie z.B. Kundengruppe, Artikel, Warengruppe, Vertriebskanal, Filiale, usw. berichtet werden soll. Die Analyse beim Kunden ergab, dass für die für die detaillierte Deckungsbeitragsrechnung / Marktsegmentrechnung schon eine eigenentwickelte Lösung vorhanden war, weswegen sich die geforderten Berichtsdimensionen auf den Buchungskreis beschränkten. Alle weiteren Dimensionen der kundeneigenen Ergebnisrechnung wurden aus anderen operativen Systemen gefüllt. Als erstes schied somit die gerade für die kundenspezifische Multidimensionalität der Berichtsdimensionen geeignete Alternative der Abbildung über die Marktsegment und –ergebnisrechnung SAP CO-PA aufgrund des nicht unerheblichen Implementierungsaufwands und der notwendigen Prozessveränderungen beim Erfassen des Buchungsstoffs aus.Neben der Anzahl der Berichtsdimensionen musste die Anforderung des Führens eines so genannten Sub-Funktionsbereichs erfüllt werden. Dies bedeutete, dass unterhalb des eigentlichen Funktionsbereichs wie z.B. Verwaltungs- oder Vertriebskosten die Art des Kostenanfalls berücksichtigt werden sollte. Diese Anforderung konnte sowohl über eine Ausmultiplizierung der relevanten GuV-Konten mit den Funktionen als auch über die Verwendung der klassischen Variante über das Objekt Funktionsbereiche abgebildet werden.Die Variante, die Konten auszumultiplizieren, hätte zwangsläufig zu einer Verlängerung des Kontenplans geführt. Deswegen wurde diese Variante als nächstes verworfen, weil die notwendige Verlängerung des Kontenplans mit dem Projektziel, eine Reduzierung der Kontenanzahl zu erreichen, kollidierte. Außerdem ist durch die neue CO-FI-Echtzeit-Integration des New GLs insbesondere der ehemals exklusive Vorteil dieser Variante, dass durch die Bebuchung von ausmultiplizierten Konten die GuV nach UKV auch beiNutzung des klassischen Hauptbuch in Echtzeit vorlag (und nicht erst die Buchungen aus dem Abstimmledger abgewartet werden mussten), nicht mehr gegeben. Letztendlich wurde sich somit für die Abbildung über Funktionsbereiche und die Nutzung der neuen CO-FI-Echtzeitintegration entschieden, bei der die Funktionsbereiche entweder im Sachkostenstamm bzw. Kostenstellenstamm hinterlegt werden und somit alle relevanten Informationen für das UKV ohne weiteren operativen Aufwand bei der Erfassung der Buchhaltungsbelege automatisch im Hintergrund abgeleitet werden können. Die Informationen für den oben angesprochenen Sub-Funktionsbereich sind im FI-Sachkonto bzw. der CO-Kostenart enthalten, so dass die Kombination aus Sachkonto/Kostenart und Funktionsbereich die inhaltlichen Anforderungen an das UKV erfüllt.

Die kundeneigenen Felder des neuen Hauptbuchs
Bei der Verwendung der kundeneigenen Felder steht der Wunsch, gemäß dem Grundsatz „eine Wahrheit“ alle finanzwirtschaftlichen Auswertungen aus einer Datenquelle zu beziehen, in Konkurrenz zu dem Ziel, die Komplexität des Finanzbuchhaltungssystems gering zu halten und somit einen performanten Betrieb zu ermöglichen. Jede zusätzliche Berichtsdimension muss zusätzlich erfasst werden und sie erweitert die Summensatztabellen um eine zusätzliche Ebene. Somit gilt es während der Konzeptionsphase für jeden Kunden erneut diese beiden Zielrichtungen gegeneinander abzuwägen. In unserem Falle kam als Anforderung heraus, dass die Finanzbuchhaltung Daten bezüglich der Artikelnummer und der Warengruppe zu erfassen und an eine nachgelagerte Ergebnisrechnung weiterzuleiten hatte. Eine Übernahme der Stammdaten Artikel und Warengruppe in die Finanzbuchhaltung und somit eine Synchronisation zwischen diesen Systemen wurde jedoch aufgrund der Komplexität der Stammdaten ausgeschlossen. Die sinnvolle Voraussetzung für kundeneigene Felder ist jedoch das Vorhandensein von geeigneten im SAP abgelegten Stammdaten. Somit blieb in diesem Fall für den Kunden als beste Alternative die Verwendung eines freien Textfeldes (in diesem Fall Zuordnung) in welchem die Artikelnummer bzw. Warengruppe eingetragen werden kann. Dieser Ansatz ist keinesfalls eine für die breite Masse von SAP-Kunden zu empfehlende Lösung, soll aber zeigen, dass auch eine unkonventionelle Lösung ziel führend sein kann.