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.
Das Modell beschreibt die Festlegungen und Alternativen zu Sachverhalten und ihrer Entsprechung in den Daten. Dies betrifft verschiedene Ebenen vom physischen Format der Dateien bis zur logischen Definition von Haushalten. Folgende Ebenen sehe ich bisher:
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.
Die Verwaltung eines Gebiets (Gebietskörperschaft), für die der Haushalt gilt. Die Administration hat genau ein Budget, der alle Jahre umfaßt.
Verwaltungen haben unterschiedliche Regeln für den Haushalt. Jedes Bundesland hat verschiedene genaue Anforderungen für die Form und den Inhalt der Haushaltsdokumente ihrer Kommunen. Die Länder haben auch jeweils andere Regeln, insbesondere andere Regeln als sie ihren Kommunen aufgeben. Mann kann noch weiter gehen und die Haushalte von Staaten betrachten: alle anders - nur durch sehr allgemeine Vorgaben der WTO u.A. rudimentär vergleichbar gemacht.
Der Haushalt. Es gibt genau ein Budget für jede Administration. Er besteht aus einer Menge von Produkten, die in der Summe dem Gesamthaushalt entsprechen. Die Products sind hierarchisch in Productgroups zusammengefaßt. Die Wurzel der Produktgruppenhierarchie ist Teil des Budgets.
Hat keine Referenz zu der Administration zu der es gehört. Stattdessen sollen die unterschiedlichen Regeln der Verwaltungen deklarativ beschrieben werden.
Budgets entsprechen einer oder mehreren Dateien, die jährlich zu einem bestimmten Zeitpunkt als Haushaltsplan oder Ergebnis veröffentlicht werden. Ein Budget liest diese Daten, konstruiert einen einfachen Haushalt (in der Regel 6 Jahre: Vorvorjahresergebnis, Vorjahresplan, aktueller Plan, Folgejahresplan, Folgefolgejahresplan, Folgefolgefolgejahresplan) und integriert ihn in den vorhergehenden Haushalt.
Die Basiseinheit eines doppischen Haushalts für die eine Bilanz und eine Gewinn- und Verlustrechnung gemacht wird. Entspricht einer staatlichen Dienstleistung
Gruppe von Product oder Productgroup, die als Product gesehen werden kann
Die Gewinn- und Verlustrechnung eines Product. Besteht aus einer Accountgroup die das Endergebnis repräsentiert
(Sammel-)Konto mit positiven (In) oder negativen (Out) Buchungen
Gruppe von Account oder Accountgroup, die als Account gesehen werden kann
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
Feld | 2 | Wert | 3,50 |
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
Name | Art | Text | Zahl |
---|---|---|---|
Feld | 2 | Wert | 3,50 |
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
Name | Name1 | Name1;3 | 3,5 |
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