TheMockTv 9d7aa1eec7 Darstellung: das Programm hatte ueberhaupt kein Theme

Sein Befund
  "und beim steuertool fehlt das theam in genze oder wird nicht durch die
   automatik gesetzt"
  "nur die einstellunden hilfe leiste die ist noch hell und der icon und
   titel leiste auch"

  Er hatte recht, und zwar wortwoertlich: dieses Programm lief im
  Tk-Standard, mit dreimal fest eingetragenem foreground="black". Es gab hier
  gar keine theme.py.

Gebaut
  theme.py aus dem Rechnungstool uebernommen und dabei von config.py geloest
  - eine Datei, die in BEIDEN Programmen liegt, darf nichts aus einem der
  beiden importieren. Beim ersten Uebernehmen flog sie genau daran beim
  Import auseinander.

  Die Einstellungen liegen hier in der Journal-Tabelle, nicht in einer
  config.json. _einstellungen() ist die Bruecke: etwas mit .get() und []=,
  wie hinweis.py und theme.py es erwarten.

  Menueleiste aus menueleiste.py statt tk.Menu - ein natives Menue laesst
  sich unter Windows nicht einfaerben, das war der letzte helle Rest.
  Treeview-Stil in theme.py ergaenzt (ttk zeichnet Listen nicht ueber den
  Grundstil), Reiter schmaler, damit alle zwoelf Monatsnamen lesbar bleiben.
  Die Summenleisten in gui_monat.py holen ihre Farben jetzt vom Fenster statt
  sie fest zu tragen - sie waren ein weisser Block unten im dunklen Bild.

  Logo und Fenstersymbol werden fuer die dunkle Darstellung aufgehellt.

⚠️ Altfehler behoben: die Meldung des Rechnungstools stand nie
  pruef_wache lief mal gruen und mal rot - je nachdem, wann er hinsah. Das
  war kein Wackler im Pruefstand, sondern sein Symptom: meldet das
  Rechnungstool eine neue Rechnung, laeuft sofort das Einlesen an, und dessen
  Ergebnis landete in derselben Zeile. Der Benutzer sah NIE, dass etwas
  hereingekommen war. melde() kennt jetzt einen Vorrang in Sekunden; die
  Meldung des Rechnungstools bekommt sechs. Dreimal hintereinander stabil
  gruen.

  Ein wackelnder Pruefstand ist keine Nebensache, die man wegdrueckt.

AUFGABE_STEUERSAETZE_DYNAMISCH.md
  Seine naechste Ansage notiert: die festen Saetze sollen raus, dynamisch per
  Tabelle wie im Rechnungstool. Mit dem, worauf dabei zu achten ist - ein
  Satz gilt ab einem DATUM, und die Saetze bereits erfasster Buchungen
  bleiben stehen (§ 147 AO).

Fassung 1.9.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax

2026-09-07 00:34:38 +02:00

3 KiB

Raw Blame History

Steuersätze dynamisch statt fest

Stand 07.09.2026 — notiert, noch nicht gebaut.

Seine Ansage

„die festen steuern müssen aus dem steuertool eh raus das muss wie beim rechnungstool dynamisch per tabelle sein die man einfach eintragen kann"

Wie es heute ist

Es gibt einen Satz für alles:

Stelle	heute
`modell.py`	`STANDARD_SATZ` als Konstante
`app.py:101`	`self.satz = float(self.journal.hole("satz", str(STANDARD_SATZ)))`
Menü	Daten → Steuersatz ändern… — ein einzelnes Eingabefeld
`db.py`	Spalte `satz REAL NOT NULL DEFAULT 5` je Buchung
`db.py:243`	`scanne(..., standard_satz=5.0)` — greift, wenn im PDF keiner steht

Immerhin: der Satz steht je Buchung in der Datenbank, nicht nur global. Historische Buchungen behalten also ihren Satz, wenn er einmal geändert wird. Das ist die halbe Miete und darf beim Umbau nicht verlorengehen.

Das Rechnungstool kann es schon richtig: dort gibt es eine Tabelle von Sätzen (Einstellungen → Steuersätze), und jede Leistung im Katalog trägt ihren eigenen.

Was gebraucht wird

Eine Tabelle im Steuerrechnungstool, in die man Sätze einträgt — wie im Rechnungstool. Kein fester Wert mehr im Quelltext.

Worauf beim Bauen zu achten ist

⚠️ Ein Steuersatz gilt ab einem Datum, nicht „ab jetzt". Ändert die Gemeinde den Satz zum 1.1., dürfen die Buchungen des Vorjahres nicht mitwandern - sonst stimmt die Meldung ans Amt für abgeschlossene Zeiträume plötzlich nicht mehr. Die Tabelle braucht deshalb eine Spalte gültig ab, und die Zuordnung erfolgt über das Rechnungsdatum, nicht über das heutige.

⚠️ Die Sätze der bereits erfassten Buchungen bleiben stehen. Sie stehen in buchungen.satz und sind der Beleg dafür, womit damals gerechnet wurde (§ 147 AO). Eine Änderung an der Tabelle darf sie nie rückwirkend überschreiben. Wer alte Buchungen umrechnen will, muss das ausdrücklich anstoßen - und dann gehört es protokolliert.

⚠️ Was im PDF steht, gewinnt. Der Satz aus der Tabelle ist nur die Annahme für den Fall, dass die Rechnung selbst keinen nennt (scanne(..., standard_satz=...)). Umgekehrt wäre es falsch: das Steuertool soll abbilden, was abgerechnet wurde, nicht was hätte abgerechnet werden sollen.

Dazu passend die schon geltende Regel aus reference_beherbergungssteuer_monat_und_kein_flag: kein vom Menschen gesetzter Schalter in einer Rechnung, die er nicht nachprüfen kann.

Reihenfolge, wenn es losgeht

Tabelle steuersaetze (gültig ab, Satz, Bemerkung) im Journal anlegen - mit Migration wie bei den anderen Spalten.
Die Auswahl beim Einlesen über das Rechnungsdatum, nicht über „heute".
Den Dialog Steuersatz ändern… durch eine Tabelle ersetzen, wie im Rechnungstool unter Einstellungen → Steuersätze.
STANDARD_SATZ bleibt als letzter Rückfall für eine leere Tabelle - und nur dafür.
Prüfstand: eine Buchung von 2025 und eine von 2026, zwei verschiedene Sätze, und die Änderung der Tabelle darf die alte Buchung nicht anfassen.

3 KiB Raw Blame History