KoogleApp/deploy/kassenbuch.md

1. Allgemeine Rahmenbedingungen
Die Finanzverwaltung wird als Modul / Erweiterung der bestehenden Software umgesetzt.

Eine Benutzerverwaltung existiert bereits und wird genutzt.

Der Kegelverein ist kein eingetragener Verein, es bestehen keine steuerlichen oder rechtlichen Sonderanforderungen.

Es gibt ein Vereinskonto und eine Währung (EUR) pro angelegtem Verin.

2. Benutzer- und Rollenmodell
2.1 Rollen
Es wird eine zusätzliche Rolle für Finanzdaten integriert (z. B. „Kassenwart“ oder „Finanzverwaltung“).

Nur Benutzer mit dieser Rolle dürfen:

Einnahmen und Ausgaben erfassen

Kategorien verwalten

Korrekturbuchungen durchführen

Finanzdaten ändern oder löschen

Berichte exportieren

## 2.2 Zugriffsrechte
Benutzer ohne Finanzrolle haben Änderungsrechte auf Finanzdaten.

Leserechte und Schreibrechte müssen klar getrennt umsetzbar sein.

# 3. Kategorienverwaltung
## 3.1 Kategorien für Einnahmen und Ausgaben
Einnahmen und Ausgaben müssen kategorisiert werden.

Kategorien sind:
- frei definierbar
- beliebig erweiterbar
- editierbar (Name ändern)
- deaktivierbar, ohne bestehende Buchungen zu verändern

## 3.2 Kategorietypen
Es muss mindestens eine Unterscheidung geben zwischen:
- Einnahmen-Kategorien
- Ausgaben-Kategorien
- Kategorien sollten für bessere Usability zusätzlich mit einer Farbe und einer Gruppierung oder Icons versehbar sein

# 4. Buchungen (Kassenbuch)
## 4.1 Erfassung von Einnahmen und Ausgaben
Für jede Buchung müssen folgende Felder vorhanden sein:

- Buchungsart: Einnahme / Ausgabe
- Betrag (positiv, in EUR)
- Kategorie
- Buchungsdatum (frei wählbar, nicht zwingend aktuelles Datum)
- Optionaler Kommentar / Beschreibung
- Optionaler externer Belegverweis (z. B. Belegnummer oder Text)

## 4.2 Belege
Kein Upload von Dokumenten
Stattdessen:
- Freitextfeld oder Referenz zur Verknüpfung mit extern abgelegten Belegen

# 5. Kontostand und Kontenabgleich
## 5.1 Kontostand
Die Software führt einen internen Kontostand auf Basis der erfassten Buchungen.

Es existiert genau ein Konto pro Verein.

## 5.2 Manueller Abgleich
Der Abgleich mit dem realen Bankkonto erfolgt manuell.
Abweichungen können durch Korrekturbuchungen ausgeglichen werden.

Korrekturbuchungen:
- sind normale Buchungen
- müssen eindeutig als solche erkennbar sein (z. B. spezielle Kategorie oder Kennzeichnung)
- Dafür werden doe Kategorien "Korrekturbuchung" und "Saldoanpassung" mit ausgeliefert, die nicht löschbar ist

# 6. Auswertungen und Berichte
## 6.1 Standardberichte
Folgende Berichte müssen verfügbar sein:
- Monatsübersicht
- Jahresübersicht

## 6.2 Inhalt der Berichte
- Anfangs- und Endsaldo
- Summe der Einnahmen
- Summe der Ausgaben
- Aufschlüsselung nach Kategorien
- Optionale Detailansicht aller Buchungen im Zeitraum

## 6.3 Export
Berichte müssen exportierbar sein als:
- Excel (z. B. XLSX)
- PDF

# 7. Änderungsprotokoll (Audit-Log)
## 7.1 Protokollierung
Alle Änderungen an Finanzdaten müssen protokolliert werden:
- Neuanlage von Buchungen
- Änderungen an Buchungen
- Löschungen von Buchungen
Hierfür kann die BaseEntity genutzt werden. Es kein zusätzlicher Aufwand erforderlich.


# 8. Bedienbarkeit und Usability
Zielgruppe sind softwareerfahrene Benutzer.

Es wird kleine Benutzeranleitung benötigt.

Fokus liegt auf:
- klaren Masken
- übersichtlichen Tabellen
- schneller Datenerfassung

Konsistenz mit der bestehenden Software-Oberfläche ist wünschenswert.

# 9. Technische und funktionale Abgrenzungen (Nicht-Ziele)
Folgende Funktionen sind nicht Bestandteil der ersten Version:

- Automatische Zahlungserinnerungen
- Import von Bankumsätzen
- Schnittstellen zu anderen Systemen
- Dokumenten-Uploads
- Mehrere Konten oder Währungen
- Steuerliche oder rechtliche Auswertungen

# 10. Erweiterbarkeit (optional, aber empfehlenswert)
Die Architektur sollte so gestaltet sein, dass spätere Erweiterungen möglich sind, z. B.:

- Automatischer Kontoimport
- Mehrere Konten
- Erinnerungen
- Schnittstellen

# 11. Integration in bestehen Anwendung

## 11.1
Abschluss eines Spieltages erzeugt neue Buchung
- beim Abschluss eines Spieltages wird die Strafen-Summe pro Spieler und Tag dem Kassenbuch hinzugefügt
- Dafür wird eine Kategorie "Spielstrafe" mit ausgeliefert, die nicht löschbar ist
- Die Strafen die die Buchung auslösen werden damit als erledigt gekennzeichnet

## 11.2
Mitgliedsbeiträge
- Die Vereineinstellungen werden um einen monatlichen Mitgliedsbeitrag erweitert
- Dafür wird eine Kategorie "Mitgliedsbeitrag" mit ausgeliefert, die nicht löschbar ist
- Die Mitgliedsbeiträge können über einen Button für einen Montag ermittelt und ins Kassenbuch aufgenommen werden




2. User Stories (fachlich, umsetzungsnah)
Kategorien
Als Finanznutzer möchte ich Kategorien für Einnahmen und Ausgaben anlegen,
damit ich Buchungen sauber strukturieren kann.

Als Finanznutzer möchte ich Kategorien deaktivieren können,
ohne bestehende Buchungen zu verändern.

Buchungen
Als Finanznutzer möchte ich Einnahmen und Ausgaben erfassen,
damit das Kassenbuch aktuell ist.

Als Finanznutzer möchte ich ein freies Buchungsdatum eingeben können,
damit ich auch vergangene Vorgänge korrekt erfasse.

Als Finanznutzer möchte ich Kommentare und Belegreferenzen hinterlegen,
damit Buchungen nachvollziehbar bleiben.

Als Finanznutzer möchte ich Korrekturbuchungen erfassen können,
um Abweichungen zum Bankkonto auszugleichen.

Übersicht & Kontrolle
Als Finanznutzer möchte ich jederzeit den aktuellen Kontostand sehen,
um zu wissen, wie viel Geld verfügbar ist.

Als Finanznutzer möchte ich alle Buchungen eines Monats oder Jahres sehen,
um Einnahmen und Ausgaben nachzuvollziehen.

Berichte
Als Finanznutzer möchte ich Monats- und Jahresberichte erzeugen,
um diese dem Verein vorlegen zu können.

Als Finanznutzer möchte ich diese Berichte als Excel oder PDF exportieren,
um sie weiterzugeben oder zu archivieren.

Sicherheit & Nachvollziehbarkeit
Als Verein möchten wir, dass alle Änderungen an Finanzdaten protokolliert werden,
damit Transparenz und Nachvollziehbarkeit gewährleistet sind.