Konsolidierungskreisspezifische Buchungen
Auf Kontierungsebene 35 können Sie kreisspezifische manuelle Buchungen durchführen, die sich ausschließlich auf die Managementkonsolidierung beziehen und bei der externen Konsolidierung unberücksichtigt bleiben.
Sie haben die Business Function FIN_ACC_GC_BCOMB
aktiviert.
Im Customizing der Belegarten können Sie Belegarten anlegen, die auf Kontierungsebene 35 (Konsolidierungskreisspezifische Buchung
) buchen. Dies ist nur für manuelle Belegarten möglich (manuelle Buchung, Upload und Kopieren von Belegen).
Buchungen auf Kontierungsebene 35 funktionieren auf die gleiche Weise wie Buchungen auf Kontierungsebene 30, jedoch gibt es für Buchungen auf der Ebene 35 eine spezielle Reporting-Logik. Dank dieser Reporting-Logik können Sie manuelle Buchungen explizit auf bestimmten Konsolidierungskreisen vornehmen.
Die folgende Tabelle zeigt ein Beispiel für Buchungen und Reporting auf den Kontierungsebenen 30 und 35 in einer Konsolidierungskreishierarchie:
Konsolidierungskreishierarchie |
Buchung (30) |
Buchung (35) |
Reporting (30) |
Reporting (35) |
|
|---|---|---|---|---|---|
Übergeordneter Kreis |
50 |
50 |
150 |
50 |
|
Untergeordneter Kreis |
100 |
100 |
100 |
100 |
|
Im untergeordneten Kreis buchen Sie auf der Ebene 30 den Wert 100 und auf der Ebene 35 nochmals den Wert 100. Das Reporting zeigt die Werte entsprechend an.
Wenn Sie nun im übergeordneten Kreis auf der Ebene 30 den Wert 50 buchen, zeigt das Reporting auf der Ebene 30 den Wert 150 an, da das System die Werte aus untergeordneten Kreisen implizit in übergeordnete Kreise vererbt.
Wenn Sie hingegen im übergeordneten Kreis auf der Ebene 35 den Wert 50 gebucht haben, zeigt das Reporting bei Ausführung für den übergeordneten Kreis auf der Ebene 35 den Wert 50 an, den Sie explizit für diesen Kreis gebucht haben.
Um das oben beschriebene Verhalten im Reporting zu erreichen, führt die Reportinglogik eine virtuelle Rücknahme von Daten auf der Ebene 35 aus untergeordneten Konsolidierungskreisen durch. Das System führt diese Rücknahme ausschließlich im Arbeitsspeicher für die Anzeige der Daten mit Reportinglogik durch; es persistiert die Rücknahme jedoch nicht auf der Datenbank.