Die Datenmeldung kann wiederum über verschiedene Wege erfolgen. Entweder wird das Standardverfahren – Erzeugung eines Extrakts an die Konsolidierung – im Rahmen des Bilanzreportings (RFBILA00) genutzt. Dann erfolgt hier – über eine entsprechende Bilanzstruktur – auch die Zuordnung der Konten zu den Konsolidierungspositionen. Oder die Tabelle wird programmtechnisch ausgelesen und ein Mapping auf Konsolidierungspositionen erfolgt dann über Programme und Mappingtabellen. Das kann im ERP –System oder auch im angeschlossenen BW erfolgen.
Eine– und aus meiner Sicht flexiblere Alternative – stellt die Verwendung eines eigenen kundendefinierten Ledgers dar.
Die Definition eines solchen Ledgers ist im Standard Customizing hinterlegt. Es gibt gegenüber dem Konsolidierungsvorbereitungsledger u.a. folgende Vorteile:
Es gibt sicher noch den einen oder anderen Vorteil. Allerdings muss das Mapping SAP-Konto auf Konzernposition noch vorgenommen werden. Das kann aber auch ein Vorteil sein, weil möglicherweise ein buchungskreisspezifisches Mapping erforderlich ist oder weil entsprechende Pflegetabellen zur Verfügung stehen, die es dem Fachbereich erlauben, dieses Mapping durchzuführen. Auch hier gilt: Das kann im ERP –System erfolgen oder auch in einem BW, weil man z.B. im BW bei mehreren angeschlossenen ERP-Systemen nur einmal die Pflege und Umsetzung des Mappings einzurichten hat anstatt dies in jedem ERP System zu tun.
Falls ein SEM-BCS oder SAP BO-PC (Netweaver) zur Anwendung kommt, besteht natürlich noch die Möglichkeit, die BW Cubes als direkte Datenquelle für das Konsolidierungssystem zu nutzen – sozusagen die Krönung – eine vollautomatische Anbindung auf Knopfdruck – ohne Medienbrüche . Änderungen im operativen System sind in wenigen Minuten an das Konsolidierungssystem übermittelt.
Beim BO-FC kann hier dann ein FIM angeschlossen werden oder man erzeugt entsprechende Flatfiles im BW.
Und wer will, kann sich die Daten im BW vorab reporten lassen – vielleicht auch schon bevor der Abschlussstress beginnt und eben ohne, dass die Daten schon in das Konsolidierungssystem geladen werden.
Die Daten der Nicht-SAP Systeme habe ich hier nicht berücksichtigt, weil natürlich auch hier wieder eine Unzahl an Möglichkeiten existiert (Flatfile, BW-Planungslayouts, Layouts im Konsolidierungssystem …), die den Rahmen hier sprengen würden.
Eine– und aus meiner Sicht flexiblere Alternative – stellt die Verwendung eines eigenen kundendefinierten Ledgers dar.
Die Definition eines solchen Ledgers ist im Standard Customizing hinterlegt. Es gibt gegenüber dem Konsolidierungsvorbereitungsledger u.a. folgende Vorteile:
- Es können problemlos zusätzliche – in der GLT3 nicht vorhandene – Felder in die Tabellenstruktur aufgenommen werden
Die Regeln, nach denen definiert wird welche Information wie an das kundendefinierte Ledger übergeben werden, können flexibel und sogar buchungskreisspezifisch ausgeprägt werden. Das geht bis zur Verwendung von Userexits bei der Befüllung der Felder.
Es können Einzelposten für alle oder nur bestimmte Buchungsvorgänge des FI auch in dem Ledger geführt werden.
Das Ledger kann bebucht werden. Das muss natürlich entsprechend berechtigt werden, es bieten sich aber hiermit verschiedene Einsatzzwecke, u.a. die Buchung von Anpassungen, falls diese nicht im originären FI gebucht werden sollen – und vor allem der Aufbau des initialen Anfangbestandes / Saldovortrags. Das kann manuell oder per Batch-Input erfolgen. Wer schon einmal versucht hat, im oben genannten Konsolidierungsvorbereitungsledger manuell Daten zu erfassen – das geht über die Transaktion GC41 – der weiß, was ich meine. Diese Transaktion ist ein wenig „anwenderunfreundlich“.
Oft wird der initiale Datenbestand dadurch erzeugt, indem die Salden aus dem Hauptbuch (Tabelle GLT0) als Basis genommen und per Programm eingespielt werden. Der Knackpunkt hier: Anschließend müssen die Salden im Bereich der Anlagen oder Forderungen / Verbindlichkeiten auch noch auf die Bewegungsarten bzw. Partnerunternehmen aufgeteilt werden, weil diese Information nicht in den Salden des Hauptbuchs vorhanden ist. Auch hier können wiederum – mit einfachen Programmen oder manuell – über die Bebuchbarkeit des Ledgers die entsprechenden Informationen erzeugt werden
Das eigendefinierte Ledger kann ein abweichendes Geschäftsjahr nutzen. Damit entsteht weniger Aufwand bei der Datenbereitstellung, weil z.B. der Ergebnisvortrag im Ledger in einer Periode erzeugt werden kann, welche den Konzernvorgaben entspricht.
Kundendefinierte Ledger können auch – wie die GLT3 per Standard mit dem FI-Hauptbuch abgeglichen werden. Damit kann zusätzlich die Datenqualität dokumentiert werden.
Das Ledger ist relativ schnell eingerichtet –mit deutlich weniger Aufwand als das Neue Hauptbuch – das natürlich immer eine weitere Option darstellt (siehe dazu weiter unten).
Es gibt sicher noch den einen oder anderen Vorteil. Allerdings muss das Mapping SAP-Konto auf Konzernposition noch vorgenommen werden. Das kann aber auch ein Vorteil sein, weil möglicherweise ein buchungskreisspezifisches Mapping erforderlich ist oder weil entsprechende Pflegetabellen zur Verfügung stehen, die es dem Fachbereich erlauben, dieses Mapping durchzuführen. Auch hier gilt: Das kann im ERP –System erfolgen oder auch in einem BW, weil man z.B. im BW bei mehreren angeschlossenen ERP-Systemen nur einmal die Pflege und Umsetzung des Mappings einzurichten hat anstatt dies in jedem ERP System zu tun.
Falls ein SEM-BCS oder SAP BO-PC (Netweaver) zur Anwendung kommt, besteht natürlich noch die Möglichkeit, die BW Cubes als direkte Datenquelle für das Konsolidierungssystem zu nutzen – sozusagen die Krönung – eine vollautomatische Anbindung auf Knopfdruck – ohne Medienbrüche . Änderungen im operativen System sind in wenigen Minuten an das Konsolidierungssystem übermittelt.
Beim BO-FC kann hier dann ein FIM angeschlossen werden oder man erzeugt entsprechende Flatfiles im BW.
Und wer will, kann sich die Daten im BW vorab reporten lassen – vielleicht auch schon bevor der Abschlussstress beginnt und eben ohne, dass die Daten schon in das Konsolidierungssystem geladen werden.
Die Daten der Nicht-SAP Systeme habe ich hier nicht berücksichtigt, weil natürlich auch hier wieder eine Unzahl an Möglichkeiten existiert (Flatfile, BW-Planungslayouts, Layouts im Konsolidierungssystem …), die den Rahmen hier sprengen würden.
Zuletzt bearbeitet am 30.04.12 09:53
