275acd3285
Neuer Schalter „Bewusst ohne Kategorie“ in der Buchungsmaske für Abschreibungen und rein rechnerische Solarerträge. Solche Buchungen erscheinen nicht unter den offenen Vorgängen im Cockpit, nicht im Prüflauf des Monatsabschlusses, setzen das Konto in der Kontenübersicht nicht fett und werden von der Regelanwendung sowie dem automatischen Zusammenführen zu Umbuchungen ausgelassen. Kommt eine Kategorie, ein Gegenkonto oder eine Splitbuchung hinzu, entfällt die Markierung. Migration 028_bewusst_ohne_kategorie.sql, Test 59 und E2E-Test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
91 lines
4.5 KiB
Markdown
91 lines
4.5 KiB
Markdown
# Stammdaten
|
||
|
||
Konten, Kontengruppen, Kategorien und Klassen – die Grundlage aller Buchungen und
|
||
Auswertungen. Die Begriffe entsprechen dem Lexware FinanzManager.
|
||
|
||
## Kontengruppen und Konten
|
||
|
||
Kontengruppen gliedern die Kontenübersicht (etwa „Anlage“). Konten ohne Gruppe erscheinen
|
||
unter **Nicht gruppiert** – das ist keine eigene Gruppe, sondern `kontengruppe_id IS NULL`.
|
||
Wird eine Gruppe gelöscht, bleiben ihre Konten erhalten und rutschen dorthin
|
||
(`ON DELETE SET NULL`).
|
||
|
||
Gruppen werden wie Konten und Kategorien auf einer eigenen Formularseite gepflegt
|
||
(*Verwaltung → Kontengruppen*). Dort hängt auch die Zuordnung: Die Konten der Gruppe werden
|
||
angekreuzt, `Kontengruppe::kontenZuordnen()` setzt sie in einem Zug. Ein Konto gehört zu
|
||
genau einer Gruppe – wird es hier angehakt, verlässt es seine bisherige.
|
||
|
||
Der QIF-Export enthält **keine** Kontengruppen (siehe `docs/import-export.md`); nach einem
|
||
Import stehen deshalb alle Konten unter „Nicht gruppiert“ und werden einmalig zugeordnet.
|
||
|
||
Kontoarten (`Konto::ARTEN`) und ihre Herkunft aus dem QIF-Export (`Konto::QIF_ARTEN`):
|
||
|
||
| Kontoart | Bezeichnung | QIF-Typ |
|
||
|---|---|---|
|
||
| `bank` | Bank | `Bank` |
|
||
| `kreditkarte` | Kreditkarte | `CCard` |
|
||
| `bar` | Bar | `Cash` |
|
||
| `sparkonto` | Tagesgeld/Sparkonto | `Oth T` |
|
||
| `vermoegen` | Vermögen | `Oth A` |
|
||
| `verbindlichkeit` | Verbindlichkeit | `Oth L` |
|
||
| `rente` | Rentenversicherung | `Oth P` |
|
||
| `sonstiges` | Sonstiges Vermögen | `Oth E`, `Oth F` |
|
||
| `depot` | Depot | `Port`, `Invst` |
|
||
|
||
Die **Kontenübersicht** (`Konto::uebersicht()`) bündelt nach Gruppe, bildet je Gruppe eine
|
||
Summe und darunter die Gesamtsumme. Sie führt schon jetzt die drei Saldospalten des
|
||
FinanzManagers:
|
||
|
||
* **Online-Saldo** – Stand des letzten Bankabrufs, bleibt bis Phase 5 leer
|
||
* **Aktueller Saldo** – gebuchte Umsätze bis heute
|
||
* **Erwarteter Saldo** – einschließlich künftig datierter Buchungen
|
||
|
||
Solange es keine Buchungen gibt (bis Phase 2), entsprechen alle drei dem Anfangssaldo.
|
||
Die Werte entstehen zentral in `Konto::mitSalden()`; dort kommen in Phase 2 die Buchungen
|
||
dazu, ohne dass die Aufrufer sich ändern.
|
||
|
||
**Fett gedruckt** steht ein Konto, in dem Buchungen aus dem laufenden Jahr ohne Kategorie
|
||
liegen (`Buchung::unkategorisierteJeKonto()`, Zahl im Titel des Kontonamens). Gezählt wird
|
||
wie im Cockpit: keine Kategorie, kein Gegenkonto, nicht gesplittet – eine Umbuchung und eine
|
||
Splitbuchung sind zugeordnet, eine bewusst ohne Kategorie gebuchte Buchung liegt nicht als
|
||
Arbeit an. Das ist vor allem die Gegenprobe zum Online-Banking, das
|
||
abgerufene Umsätze selbst bucht (siehe `docs/banking.md`).
|
||
|
||
**Anfangssalden** stehen nicht im QIF-Export. Sie werden nach dem Import je Konto im
|
||
Kontoformular nachgetragen.
|
||
|
||
## Kategorien
|
||
|
||
Hierarchisch, Trenner ist `:` wie im FinanzManager. `name` hält den Blattnamen, `pfad` den
|
||
vollständigen Namen (`400 - Leben:B-Essen alleine`). Der Pfad steht redundant in der
|
||
Tabelle, weil praktisch jede Anzeige, jede Auswahl und der gesamte Import darüber laufen;
|
||
Umbenennen und Verschieben schreiben die Pfade des ganzen Teilbaums neu
|
||
(`Kategorie::pfadeNeuAufbauen()`).
|
||
|
||
Regeln:
|
||
|
||
* Die **Art** (Einnahme/Ausgabe) gilt für den ganzen Ast. Unterkategorien erben sie, und
|
||
ein Wechsel an der Wurzel zieht alle Nachfahren mit.
|
||
* Ein Name darf keinen Doppelpunkt enthalten – der trennt die Ebenen.
|
||
* Eine Kategorie kann nicht unter ihren eigenen Teilbaum verschoben werden.
|
||
* **Zusammenführen** hängt die Unterkategorien der Quelle unter das Ziel und löscht die
|
||
Quelle. Ab Phase 2 wandern dort auch die Buchungen mit.
|
||
* **Löschen** nimmt die Unterkategorien mit (`ON DELETE CASCADE`). Wer eine Kategorie nur
|
||
aus den Auswahllisten nehmen will, setzt sie auf inaktiv.
|
||
|
||
Die Oberfläche hat die vier Register des Originals: *Alle*, *Einnahmen*, *Ausgaben*,
|
||
*Umbuchungskonten*. Umbuchungskonten sind keine Datensätze – dort stehen die Konten, weil
|
||
sie in der Kategorieauswahl einer Buchung an derselben Stelle erscheinen (in eckigen
|
||
Klammern).
|
||
|
||
## Klassen
|
||
|
||
Flach, ohne Hierarchie – die zweite Auswertungsdimension neben der Kategorie (Ehemann,
|
||
Ehefrau, Haus 1, Projekt …). Im QIF hängen sie mit `/` an der Kategorie:
|
||
`400 - Leben:B-Essen alleine/Privat`. `Kategorie::zerlegeQifAngabe()` trennt beides.
|
||
|
||
## Mandantenfähigkeit
|
||
|
||
Alle Stammdatentabellen führen `benutzer_id`. Die Oberfläche ist einbenutzerig; die
|
||
Kennung liefert `Mandant::id()` – aus der Session, im CLI ersatzweise der erste aktive
|
||
Benutzer. `Mandant::setze()` gibt sie in Skripten und Tests fest vor.
|