1. Allgemeine Rahmenbedingungen
Die Finanzverwaltung wird als Modul / Erweiterung einer 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).

2. Benutzer- und Rollenmodell
2.1 Rollen
Es wird eine zusätzliche Rolle für Finanzdaten integriert (z. B. „Kassenwart“, „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 keinen Zugriff auf Finanzdaten.

Leserechte und Schreibrechte müssen klar getrennt umsetzbar sein (falls von der bestehenden Software unterstützt).

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

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.

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)

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

Änderungen an Kategorien

7.2 Protokollinhalt
Das Protokoll enthält mindestens:

Datum und Uhrzeit der Änderung

Benutzer

Art der Änderung (Anlage / Änderung / Löschung)

Alte und neue Werte (soweit sinnvoll darstellbar)

7.3 Einsicht
Das Änderungsprotokoll ist für berechtigte Benutzer einsehbar.

8. Bedienbarkeit und Usability
Zielgruppe sind softwareerfahrene Benutzer.

Es wird keine 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

Wenn du möchtest, kann ich dir im nächsten Schritt z. B.

ein Datenmodell (Tabellen / Entitäten)

User Stories

oder eine Minimal-Feature-Liste für ein MVP
ableiten – sag einfach Bescheid.

Du:
ja, mach das
ChatGPT:
Perfekt 👍
Dann liefere ich dir alle drei Punkte in sinnvoller Reihenfolge und aufeinander aufbauend:

Datenmodell (Entitäten & Felder)

User Stories

MVP-Feature-Liste (klar abgegrenzt)

So kannst du direkt mit Design oder Implementierung starten.

1. Datenmodell (fachlich / logisch)
1.1 Benutzer
Existiert bereits – wird hier nur referenziert

User

user_id (PK)

name

… (bestehende Felder)

rolle_finanz (Boolean oder Rollenreferenz)

1.2 Kategorien
Kategorie

kategorie_id (PK)

name

typ (EINNAHME | AUSGABE)

aktiv (Boolean)

erstellt_am

erstellt_von (user_id)

1.3 Buchungen (Kassenbuch)
Buchung

buchung_id (PK)

buchungsart (EINNAHME | AUSGABE)

betrag (Decimal, > 0)

buchungsdatum (Date)

kategorie_id (FK)

kommentar (Text, optional)

belegreferenz (Text, optional)

ist_korrekturbuchung (Boolean)

erstellt_am (Timestamp)

erstellt_von (user_id)

geändert_am (Timestamp, optional)

geändert_von (user_id, optional)

gelöscht (Boolean, Soft Delete empfohlen)

1.4 Änderungsprotokoll (Audit-Log)
Finanz_Audit_Log

log_id (PK)

entität (BUCHUNG | KATEGORIE)

entität_id

aktion (CREATE | UPDATE | DELETE)

feldname (optional, bei UPDATE)

alter_wert (Text)

neuer_wert (Text)

zeitpunkt (Timestamp)

benutzer_id (user_id)

Empfehlung: bei UPDATE pro Feld ein Logeintrag

1.5 Abgeleitete Werte (kein persistentes Objekt)
Kontostand

wird dynamisch berechnet:

Summe(Einnahmen) – Summe(Ausgaben)
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.

3. MVP – Minimal Viable Product
3.1 Muss-Funktionen (Version 1.0)
✅ Pflicht

Finanzrolle integrieren

Kategorien anlegen / bearbeiten / deaktivieren

Einnahmen & Ausgaben erfassen

Buchungen bearbeiten & (soft) löschen

Korrekturbuchungen

Kontostandberechnung

Monats- & Jahresübersichten

Export als Excel & PDF

Vollständiges Änderungsprotokoll

3.2 Sollte-Funktionen (Version 1.1)
🔶 Optional, aber sinnvoll

Filter (Zeitraum, Kategorie)

Summen pro Kategorie

Kennzeichnung auffälliger Buchungen (z. B. hohe Beträge)

Schnellanlage über Standardkategorien

3.3 Explizit ausgeschlossen (vorerst)
❌ Nicht Teil des MVP

Bankimport

Mehrere Konten

Mehrere Währungen

Dokumentenupload

Automatische Erinnerungen

Externe Schnittstellen