BOARD für Reporting, Analyse und Planung

Lesen Sie in unserem Fachbeitrag in vereinfachter Form, wie Sie mit der Reporting und Planungslösung BOARD eine Gewinn- und Verlustrechnung (GuV) aufbauen können und wie Sie eine konsolidierte Darstellung mehrerer GuV erreichen können.

Welche Fibu-Lösung eingesetzt wird, spielt dabei nur eine untergeordnete Rolle. Die Voraussetzung ist, dass der Kontenplan und das Buchungsjournal exportiert werden können. In unserem Beispiel haben wir Lexware eingesetzt und die darunterliegende SQL Anywhere Datenbank über eine ODBC-Verbindung direkt ausgelesen.

Datenmodell in BOARD

Zunächst definieren wir das Datenmodell in BOARD, welches aus Entitäten, Cubes, Relationen und Regeln besteht. Zusätzlich benötigen wir auch DataReader, um die Cubes und Entitäten aus den Lexware-Daten automatisch zu füllen.

Entitäten

Eine Entität in BOARD bestimmt, wonach etwas ausgewertet werden soll. Oftmals wird hierfür auch der Begriff Dimension verwendet. Ein Eintrag einer Entität hat immer eine eindeutige ID (Code) und eine Beschreibung. Falls Code und Beschreibung identisch sind, kann auf die Beschreibung verzichtet werden. Folgende Entitäten definieren wir:

Firma:

Das ist der Buchhaltungsmandant, da wir in unserem Beispiel zwei Mandanten darstellen möchten. Die erste Spalte ist der Code, die zweite der Kurzname der Firma.

Konto:

In diese Entität lesen wir den Kontenplan ein. Der Code wird dabei aus dem Code der Firma und der Kontonummer mit Bindestrich als Trennzeichen zusammengesetzt, damit der Code über alle Firmen hinweg eindeutig wird. Da wir die Kontenpläne von zwei Mandanten einlesen, kommen natürlich viele Konten doppelt vor. Mit dem Präfix der Firma wird der Code des Kontos eindeutig.

Schema Firma:

Für den Aufbau der GuV geben wir eine fest definierte Struktur vor. Da diese je Mandant unterschiedlich sein kann, lesen wir in dieser Entität das GuV-Schema je Firma aus einer CSV-Datei ein. Diese lässt sich einfach pflegen und kann nach einer Änderung jederzeit neu eingelesen werden. Wenn die Definition des GuV-Aufbaus mit vertretbarem Aufwand direkt aus der Fibu herausgelesen werden kann, dann kann die zusätzliche CSV-Datei entfallen. Den Aufbau der CSV-Datei schauen wir uns weiter unten an, da die Datei noch weitere Informationen enthält, dir wir zunächst erklären möchten.

Auch hier wird dem Zeilencode die Firma als Präfix vorangestellt, damit wir den Aufbau der zweiten Firma ebenfalls mit einlesen können und die Zeilennummern damit eindeutig werden.

Schema konsolidiert:

Das konsolidierte GuV-Schema soll dazu dienen, die unterschiedlichen GuV-Schemas der einzelnen Firmen in einer einheitlichen übergeordneten Struktur konsolidiert darzustellen. Dabei handelt es sich natürlich nicht um eine Konzernkonsolidierung in eine übergeordnete Holding, sondern um die einfache Zusammenführung von zwei GuV mit unterschiedlichem Aufbau in einen gemeinsamen Aufbau, um z.B. das Ergebnis zweier GmbH’s kombiniert darzustellen.

Der Code hat diesmal kein Firmenkürzel als Präfix, da das Schema ja für alle Firmen identisch sein soll und auch keine Nummerierung in der Beschreibung der Zeilen. Dies würde in einer konsolidierten Darstellung eher verwirren.

Periode:

Auswertungen in der Buchhaltung werden i.d.R. nicht nach Belegdatum getroffen, sondern nach Buchungsperioden. Eine Eingangsrechnung mit dem Rechnungsdatum 30.07.2017 könnte daher in die Buchungsperiode 8 gebucht werden und muss dann in den Auswertungen auch dort berücksichtigt werden. Buchungsperiode und Buchungsdatum können also abweichen.

Nachdem sich die Buchungsperioden praktisch nie ändern, haben wir es uns leichtgemacht und diese in BOARD einfach direkt in die Entität eingegeben, anstatt diese aus irgendeiner Datenquelle einzulesen. Da Entitäten immer vom Datentyp Text sind, muss für eine korrekte Sortierung der Code mit führender 0 eingegeben werden.

Hinweis für Nicht-Buchhalter: Es gibt meistens mehr Buchungsperioden als Monate im Jahr, da Abgrenzungen o.ä. gerne in Perioden jenseits der 12 gebucht werden. Für eine volle Jahresauswertung müssen daher alle Perioden selektiert werden.

Das Buchungsjahr definieren wir nicht als eigene Entität, da wir hierfür die Standard-Zeit-Entität von BOARD verwenden. Das bringt uns den Vorteil, dass Vorjahresvergleiche mit einem simplen Mausklick möglich sind und alle Standard-Zeitfunktionen darauf funktionieren.

Cubes

Nach den Entitäten definieren wir die Cubes. Cubes enthalten die Daten, die ausgewertet werden. Wir erinnern uns, Entitäten definieren, wonach wir auswerten und Cubes definieren, was wir auswerten. Ein Cube hat einen Datentyp und eine Struktur. Die Struktur ist eine Zuweisung der Entitäten, nach denen wir den Cube auswerten möchten.

Wir benötigen interessanterweise nur einen einzigen Cube. Diesen nennen wir Saldo, da dieser den jeweiligen Saldo eines Kontos beinhaltet. Gebildet wird der Saldo je Konto durch das Einlesen des Buchungsjournals. Die meisten Fibu-Lösungen bieten auch Tabellen, in denen der aktuelle Kontensaldo direkt ausgelesen werden kann. Dann würden wir aber die Möglichkeit verlieren, den Saldo für beliebige selektierte Perioden ausweisen zu können. Daher müssen wir jede einzelne Buchung aus dem Journal einlesen. Das Aufreißen des Saldos nach Konto, Periode und Jahr erledigt BOARD durch die Zuweisung der Entitäten an den Saldo-Cube für uns.

Relationen (Beziehungen)

Beziehungen zwischen Entitäten dienen der Definition automatischer Datenaggregationen. Wenn wir also Auswertungen benötigen, in denen Daten aus Cubes in mehreren hierarchischen Entitäten nach oben verdichtet werden, dann definieren wir hierfür eine Beziehung. In unserem Beispiel möchten wir die GuV von zwei Firmen in einer übergeordneten GuV verdichten. Außerdem möchten wir die Salden auch auf Ebene der Firmen verdichten. Kontoart und Konto Kategorie ignorieren wir für unser Beispiel.

Auf der linken Seite befindet sich die unterste (detaillierteste) Stufe, also das Konto. Nach rechts wird immer um eine Stufe verdichtet. Einem Zeileneintrag im „Schema Firma (GuV)“ können also mehrere Konten zugeordnet sein, deren Saldo verdichtet wird. Einem Zeileneintrag im „Schema konsolidiert (GuV)“ können wiederum mehrere Zeilen aus dem „Schema Firma (GuV)“ zugeordnet werden. Dadurch wird die einfache Konsolidierung erreicht.

Regeln

Regeln dienen in BOARD dazu, um vordefinierte Berechnungen innerhalb einer Entität ausführen zu lassen. Später erstellen wir ein DataView für die Darstellung der GuV und weisen die Regeln dort dem Cube „Saldo“ zu.

Die Regel bekommt eine Überschrift zur Identifikation und wird auf einer Entität definiert, in unserem Beispiel auf dem konsolidierten GuV-Schema. Die Notation der Berechnungen ist sehr einfach und summiert zeilenweise Abschnitte. Die Berechnung des Ergebnisses nach Steuern und das EBIT erfolgt ebenfalls hier. Regeln sind eine äußerst flexible Möglichkeit, um individuelle Berechnungen abzubilden, ähnlich wie in Excel.

Aber Achtung, wenn weitere Zeilen in die Entität eingefügt werden oder gelöscht werden, dann müssen die Berechnungen aktualisiert werden, da sonst die Zeilenbezüge nicht mehr passen. Regeln eignen sich daher primär für Entitäten, die sich nicht dynamisch durch Import o.ä. ändern.

Datenquellen und DataReader

Als Datenquellen dienen verschiedene SQL-Tabellen aus Lexware und eine manuell erstellte CSV-Datei. Die SQL-Tabellen werden über SQL-DataReader einmal nachts in BOARD eingelesen. Darauf gehen wir in diesem Beitrag allerdings nicht näher ein. Die CSV-Datei verdient einen genaueren Blick, da wir damit gleich mehrere Entitäten füllen und auch Beziehungen zwischen diesen herstellen.

Beim Einlesen der CSV-Datei werden die Entitäten „Schema Firma“ und „Schema konsolidiert“ gefüllt. Außerdem werden die Beziehungen zwischen Konto --> „Schema Firma“ --> „Schema konsolidiert“ hergestellt. Das bedeutet, dass wir damit gleichzeitig definieren, welche Konten zu welcher Zeile des GuV-Schemas zugeordnet werden und deren Saldo damit dort aggregiert wird.

Da das Konto parallel auch nach Firma aggregiert wird, müssen wir für eine spätere fehlerfreie Selektion auch den Code der Firma beim Einlesen mit zuordnen. Die Daten sind in der CSV-Datei über Tabulatoren getrennt.

Spalten in der CSV-Datei:

S1: Entspricht dem Code aus der Entität Konto (Bsp.: F2-99990) für die Herstellung der Beziehung
S2: Daraus wird der Code der Entität „Schema Firma“ erzeugt (Bsp.: F2-0010)
S3: Daraus wird der Text der Entität „Schema Firma“ erzeugt (Bsp.: 1. Umsatzerlöse)
S4: Daraus wird der Code der Entität „Schema konsolidiert“ erzeugt (Bsp.: 0010)
S5: Daraus wird der Text der Entität „Schema konsolidiert“ erzeugt (Bsp.: Umsatzerlöse)
S6: Entspricht dem Code aus der Entität Firma (Bsp.: F2) für die Herstellung der Beziehung

Auszug aus der CSV-Datei:

Im ASCII-DataReader weisen wir die Spalten der CSV-Datei zu den Feldern unserer Entitäten zu. Über die Aktion bestimmen wir, dass bei den Entitäten „Schema konsolidiert“ und „Schema Firma“ neue Sätze eingefügt und der Text bereits bestehender Sätze überschrieben wird. Bei der Zuordnung der Codes für Konto und Firma wurde keine Aktion ausgewählt, da hier nur eine Zuordnung zu bereits bestehenden Einträgen erfolgen soll und keine Änderungen durch den DataReader in diesen Entitäten erfolgen sollen. Diese kommen ja aus Lexware.

Darstellung der GuV in BOARD

Nachdem das Datenmodell erstellt und die Daten und Beziehungen über die DataReader eingelesen wurden, ist der Rest geradezu ein Kinderspiel. Wir verwenden für die Darstellung ein DataView, welches eines der mächtigsten Screenobjekte in BOARD ist. Ein DataView zeigt, vereinfacht ausgedrückt, Cubes nach Dimensionen in tabellarischer Form an.

Wir nehmen also unseren Saldo-Cube als Datenblock in das Layout des DataViews auf und nennen diesen „EUR“. Dann ziehen wir den Cube nochmal ins Layout, nennen diesen „VJ“ und aktivieren die Checkbox „Vorjahr“. Dadurch werden autom. die Vorjahreswerte der selektieren Entitäten für diesen Datenblock angezeigt. Praktisch oder? Außerdem erstellen wir eine Berechnung, in der wir EUR – VJ rechnen und das Ergebnis als Einfärbung darstellen. Grün, wenn akt. Jahr besser als VJ, andernfalls rot. Farbabstufungen nach Größe der Abweichung wären ebenfalls denkbar.

Den beiden Datenblöcken EUR und VJ weisen wir noch die weiter oben erstellte Regel "GuV" für die Entität "Schema konsolidiert" zu, damit die dort hinterlegten Berechnungen auf den Werten der Cubes ausgeführt werden. Wir erinnern uns, darüber errechnen wir Gruppensummen oberhalb der Detailzeilen, das Ergebnis nach Steuer und das EBIT.

Über die Achsen des Layouts (Zeilen und Spalten) definieren wir, nach welchen Entitäten die Cubes aufgerissen werden. In unserem Beispiel ist das „Schema konsolidiert“.

Verschiedene kleinere Formatierungseinstellungen lassen wir jetzt unter den Tisch fallen.

Als Ergebnis erhalten wir eine konsolidierte Darstellung von zwei Firmen in einer GuV mit Vorjahresvergleich und Abweichungsalarm. Natürlich handelt es sich um Daten aus unseren Demofirmen.

Eine weitere Darstellungsmöglichkeit wäre die Firmen als einzelne Spalten nebeneinander zu stellen und um eine konsolidierte Spalte zu ergänzen. So fällt der direkte Vergleich der Firmen sehr leicht.

Über Selektoren auf dem Screen können wir frei definieren, welche Firmen, welches Jahr und welche Perioden wir auswerten möchten. Natürlich werden die Vorjahresvergleiche auf die gleiche Periodenauswahl des Vorjahres angewendet.

Wir hoffen, dass wir Ihnen mit diesem Beitrag die unglaubliche Flexibilität von BOARD vermitteln konnten. BOARD geht weit über die üblichen Visualisierungsmöglichkeiten hinaus und bietet eine leistungsfähige Plattform für die Umsetzung einfacher und komplexer Auswertungen.

Eine Stärke von BOARD ist die Möglichkeit, auch Planungsanwendungen aufbauen zu können. Von der Vertriebsplanung, über die Kostenstellenplanung bis zur Finanzplanung oder der kompletten Unternehmensplanung ist alles möglich. Der universelle Ansatz unterstützt sowohl das herkömmliche Gegenstromverfahren, als auch treiberbasierte Modelle oder eine Kombination. Natürlich arbeitet die Planung auf dem gleichen Datenmodell wie das Reporting. Dadurch entsteht eine nahtlose Integration von Reporting, Analyse und Planung.