380 lines
7.5 KiB
Markdown
380 lines
7.5 KiB
Markdown
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 |