Die Haushaltsvisualisierung von Lübeck habe ich als Prototyp heruntergeschrieben. Dabei habe ich mich von der Struktur der Daten leiten lassen und die simpelste Art des Einlesens genommen die funktioniert hat. Zum Beispiel habe ich den Feldtrenner, ein Komma, direkt ins Programm geschrieben und Werte mit konkreten Strings verglichen.

Nun habe ich auch Daten aus Glückstadt bekommen und nun muss das etwas allgemeiner formuliert werden. Und die Struktur muss klar beschrieben werden, damit auch andere Gemeinden ihre Daten anpassen können.

Im Laufe der Zeit (2015-2020) kamen Daten mit verschiedenstem Aufbau dazu. Alle wurden in die Objektstruktur eingepasst, wobei die Objektstruktur immer wieder erweitert wurde, um die Variationen angemessen integrieren zu können.

Nun bin ich bereit für ein konsolidiertes grundlegendes Modell, dass alle Möglichkeiten der bisherigen Prototypen unterstützt. Dieses soll hier beschreiben werden.

Folgende Klassen definieren die sachlichen Strukturen (domain model) meiner Implementierung von Haushalten.

Die Klassen sind alle in English benannt, um auch eine Basis für die internationale Zusammenarbeit zu schaffen.

• Administration - die Verwaltung eines Gebiets (Gebietskörperschaft), die einen Haushalt zu erstellen hat.
• Budget - Der Haushalt. Das #product enthält die Wurzel-Productgroup. Hat keine Referenz zu der Administration zu der es gehört. Kann Haushalte von Tabellendateien lesen.
• Product - die Basiseinheit eines doppischen Haushalts für die eine Bilanz und eine Gewinn- und Verlustrechnung gemacht wird. Entspricht einer staatlichen Dienstleistung
• Productgroup - Gruppe von Product oder Productgroup, die als Product gesehen werden kann
• ProfitLossAccount - die Gewinn- und Verlustrechnung eines Product. Besteht aus einer Accountgroup die das Endergebnis repräsentiert
• Account - ein (Sammel-)Konto mit positiven (In) oder negativen (Out) Buchungen
• Accountgroup - Gruppe von Account oder Accountgroup, die als Account gesehen werden kann
• Series - Zeitreihe von Plan- und Istwerten für mehrere Jahre

Eine CSV-Datei enthält eine Tabelle mit Daten. Jede Zeile ist ein Datensatz, der eine feste Anzahl von Einträgen enhält, die durch ein Komma (oder ein [Tab] oder ein ;) getrennt sind.

Feld;2;Wert;3,50

entspricht

Ein Eintrag ist ein String, der ggf. auch als Zahl interpretiert werden kann. Die erste Zeile der Tabelle enthält die Spaltenüberschriften. Jede Spalte ist von einem einheitlichen Typ: Text oder Zahl.

Name;Art;Text;Zahl
Feld;2;Wert;3,50

entspricht

CSV-Dateien enthalten keine Metadaten, so dass z.B. die Kodierung nicht in der Datei selbst vermerkt werden kann. Da in Deutschland die Kodierung ISO 8859-15 üblich ist, wird dies vorausgesetzt. Die Lübecker und Glückstädter Daten sind mit der Kodierung lesbar.

Der Separator kann Komma „,“, Semikolon „;“ oder ein Tab sein. Ein Feld kann mit Anführungszeichen >„< eingeschlossen sein, und muss wenn es den Separator enthält.

Name;"Name1";"Name1;3";3,5

entspricht

Die 19 Spalten der Tabelle teile ich in folgende Bereiche:

  Produkt
      1-stelliger Produktbereich - Kennung
      1-stelliger Produktbereich - Bezeichnung
      2-stelliger Produktbereich - Kennung
      2-stelliger Produktbereich - Bezeichnung
      Produktgruppe - Kennung
      Produktgruppe - Bezeichnung
      Produkt - Kennung
      Produkt - Bezeichnung
  Position
      Ertrags- und Aufwandsarten - Gliederung 1
      Ertrags- und Aufwandsarten - Gliederung 2
      Ertrags- und Aufwandsarten - Beschreibung
  Konto
      Kontonummer
      Kontobezeichnung
  Werte
      Ergebnis Jahresabschluss 2012
      Haushaltsansatz 2013
      Haushaltsansatz 2014
      Mittelfristige Ergebnisplanung 2015
      Mittelfristige Ergebnisplanung 2016
      Mittelfristige Ergebnisplanung 2017

Ein Finanzplan sieht praktisch genauso aus, ausser dass die Werte noch eine Spalte zusätzlich für Verpflichtungsermächtigungen hat.

  Werte
      Ergebnis Jahresabschluss 2012
      Haushaltsansatz 2013
      Haushaltsansatz 2014
      Verpflichtungsermächtigungen
      Mittelfristige Ergebnisplanung 2015
      Mittelfristige Ergebnisplanung 2016
      Mittelfristige Ergebnisplanung 2017

Die Ergebnisrechnung eines Produkts besteht aus Positionen mit einer Beschreibung, einer Ordnungsnummer (Gliederung 2) und einem Typkennzeichen (Gliederung 1). Eine Position besteht aus positiven oder negativen Buchungen auf bestimmte Konten. Der Wert einer Position ist die Summe der enthaltenen Buchungen. Es gibt auch Positionen ohne Buchungen, die zusammengefasste Werte anderer Positionen enthalten.

Die Spalte „Ertrags- und Aufwandsarten - Gliederung 1“ enthält die Kontenart der Buchungen als 2- oder 3-stellige Zahl. Da die Kontonummer aber immer mit dieser Zahl beginnen, kann die Spalte ignoriert werden. Das erleichtert die Verarbeitung, da eine Position Schwierigkeiten macht: Zeile 5 „privatrechtliche Leistungsentgelte“ hat 3 Kontenarten zugeordnet: 441, 442 und 446. Lübeck schreibt das in einzelne Zeilen (die für 441 und 442 sind leer) und Glückstadt schreibt die Zahlen in eine Zeile „441, 442, 446“. Beide Varianten sind unbefriedigend. Da die Spalte aber redundant ist, wird sie ignoriert.

Die Gliederung der Ergebnis und Finanzrechnungen sind in dieser Landesverordnung detailliert beschrieben.

Am Ende stehen die eigentlichen Zahlen: 2 Vorjahre, das aktuelle Jahr (beim Finanzplan noch die Ermächtigungen) und 3 Folgejahre. Alle Zeilen, die in allen Spalten keine Werte oder nur Nullen hat, wird ignoriert, da sie keine Bedeutung haben und sich die Struktur auf andere Weise ergibt.

Bei Aufwänden oder Ausgaben gibt es 2 Möglichkeiten: man notiert eine positive Zahl als die Höhe des Aufwandes und weiss, dass diese Zahl bei Verrechnung mit anderen Beträgen negativ interpretiert werden muss. Oder, man schreibt solche Zahlen als negative Zahl, wodurch alle Berechnungen mit simplen Additionen durchgeführt werden können.

Als Programmierer ist mir das letztere lieber, da einfacher, aber auch die andere Sichtweise, wie in den Daten von Glückstadt, ist genauso legitim. Auch solche Daten werden richtig eingelesen, aber nur durch eine konkrete Annahme: die Interpretation richtet sich nach der ersten Zahl bei einem Aufwand. Ist die Zahl negativ, wird „negativ“ als Standard übernommen und umgekehrt. Ist diese erste Zahl eine Erstattung, werden die nachfolgenden Daten nicht richtig interpretiert. Da diese erste Zahl aber immer Personalaufwendungen für die interne Verwaltung enthält, kann diese Zahl niemals eine Erstattung sein .

Im gedruckten Haushalt wird jeder Posten der Ergebnisrechnung in einer Zeile dargestellt. Im Beispiel ist das für der Posten 11:Personalaufwendungen die erste Zeile der Posten. Diese Zeile ist die Summe der nachfolgenden Buchungen. Diese haben jeweils ein Konto (mit Nummer und Name) und die Zeitreihe. Die Buchungen sind der echte Mehrwert der maschienenlesbaren Daten: sie können viel detaillierter sein als eine gedruckte Version.

Beim Einlesen der Daten werden nur die Daten mit Konto gespeichert. Die Summenzeilen werden aber genutzt, um die interne Konsistenz der Daten zu überprüfen. Beider Datensätze von Lübeck und Glückstadt sind sauber und geben keine Fehler:

75625 Zeilen (3207 Buchungen, 914 checks) in 14.084774 seconds
3094 Zeilen (823 Buchungen, 384 checks) in 835.174 milliseconds