Phase 9: Kassenverwaltung (#14)

This commit was merged in pull request #14.
This commit is contained in:
2026-09-05 02:30:51 +00:00
parent d70acad4cd
commit 2b53556175
78 changed files with 12314 additions and 42 deletions
+12 -2
View File
@@ -39,8 +39,8 @@ Faktoren, die in die Schätzung eingehen:
| 6 | Kartenmodule | 14–18 PT | 3,5–4,5 h | **2:50 h** |
| 7 | Benachrichtigungen und Termine | 10–13 PT | 2,5–3,5 h | **3:10 h** |
| 8 | Lokale KI | 9–12 PT | 2,5–3 h | **3:40 h** |
| 9 | Kassenverwaltung | 8–11 PT | 2–3 h | offen |
| | **Summe** | **123–164 PT** | **28–37 h** | |
| 9 | Kassenverwaltung | 8–11 PT | 2–3 h | **4:10 h** |
| | **Summe** | **123–164 PT** | **28–37 h** | **28:30 h** |
123–164 Personentage entsprechen etwa **6 bis 8 Monaten Vollzeitarbeit** einer
einzelnen Person. Zum Vergleich: eine kommerzielle Feuerwehrverwaltung kostet
@@ -422,6 +422,16 @@ Die Unveränderlichkeit festgeschriebener Buchungen kostet hier fast nichts —
das Muster steht seit Phase 0 mit dem Audit-Log-Trigger und lässt sich
übernehmen.
**Tatsächlich: 4:10 h** — die längste Phase bisher. Beide Schätzungen oben
haben sich bestätigt und zugleich verschoben: MT940 kostete weniger als
gedacht, weil beide Formate ohne Fremdbibliothek auskommen. Dafür war die
Unveränderlichkeit nicht das Übernehmen eines Musters, sondern drei
Trigger mit drei genau begründeten Ausnahmen — und die Ausnahmen sind der
Teil, der Zeit gekostet hat. Zwei davon sind erst im Test aufgefallen:
der Prüfbericht, der nach dem Festschreiben entsteht, und die
DSGVO-Löschung einer Wehr, die an ihren eigenen festgeschriebenen Buchungen
scheiterte.
---
## Was hier nicht drin ist