Die Runde vom 07.09.2026 hat neben den zwei echten Fehlern eine Reihe
Wiederholungen und stumme Stellen gemeldet. Abgearbeitet in Etappen, jede fuer
sich pruefbar - nach jeder liefen beide Pruefketten gruen.
* Menueleiste: der Wechsel von einem Titel zum anderen brauchte ZWEI Klicks.
Der grab_set der offenen Liste schluckt den ersten, die <Button-1>-Bindung
des Titels feuert gar nicht. Das native tk.Menu, das diese Leiste ersetzt
hat, wechselte schon beim blossen Ueberfahren - zwei Klicks waren also eine
Verschlechterung gegenueber dem, was vorher da war. Die Klappliste wird
ausserdem jetzt wie jede andere Position ueber theme.auf_bildschirm()
begrenzt; am unteren Fensterrand lief sie vorher hinaus.
Neu: pruef_menueleiste.py misst beides ueber echte Klickereignisse.
* %LOCALAPPDATA%/ravokk wurde an drei Stellen einzeln ausgerechnet. Jetzt
fragen alle gemeinsam.standard_ordner(). Laufen die je auseinander, fuehren
die beiden Programme zwei Nummernbuecher - und das faellt erst auf, wenn
eine Rechnungsnummer zum zweiten Mal vergeben ist (§ 14 Abs. 4 Nr. 4 UStG).
* pruefe() stand 35-mal im Quelltext, in sechs Fassungen -> pruefhelfer.py.
Die zwei Ausreisser sind mitgezogen: pruef_storno_verrechnet.py zaehlte in
einer Zahl und konnte am Ende nicht sagen, WAS fehlschlug, pruef_bilder.py
im Rechnungstool schrieb ein eigenes Format.
* dlg_darstellung() und die drei Handgriffe des Umschaltens standen in beiden
app.py fast wortgleich -> ThemeMixin in theme.py. Beide trugen inzwischen
denselben langen Kommentar zu demselben Fehler; das war der Beweis, dass es
eine Sache ist. Programmspezifisch bleiben der Hinweistext im Dialog (R31)
und die Frage, ob die Einstellungen ausdruecklich gespeichert werden muessen.
* pruef_gemeinsam_automatisch.py sagte im Text "genau ein Buch" und prueft
">= 1" mit einem any() - eine Pruefung, die nicht rot werden kann. Jetzt
== 1, und der Dateiname wird mitgeprueft.
Dazu neu: die neun Dateien, die im Kopf zusagen, sie laegen in beiden
Programmen gleich, werden byteweise verglichen. Bei hinweis.py stimmte die
Zusage seit dem 06.09. nicht mehr - gleicher Inhalt, CRLF gegen LF.
* .gitattributes, damit die Zeilenenden nicht von der Maschine abhaengen.
Ohne das meldet genau diese Pruefung nach einem frischen Checkout einen
Unterschied, den es im Repository gar nicht gibt.
* Die stummen "except OSError" in api.py, updater.py und einzelinstanz.py
sagen jetzt, warum sie schweigen duerfen. Die stummen tk.TclError bleiben:
dort wird ein Widget angefasst, das gerade zerstoert wurde, und eine Meldung
waere Rauschen.
* Tote Parameter und Variablen aus dem Umbau des Vortags: symbol_setzen(dunkel=),
kachel(grund=, radius=), mit_trennlinie, sechs x/y-Berechnungen, die von
theme.mittig() sofort ueberschrieben wurden, vier lokale "import ctypes".
39 Pruefstaende, 0 rot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax
Das Rechnungstool schreibt seit heute auch Storno- und Berichtigungsblaetter in
denselben Ordner. Zwei Fehler, die daraus entstanden waeren - beide still:
1. Ein Berichtigungsblatt (§ 31 Abs. 5 UStDV) traegt die Nummer DER RECHNUNG,
die es berichtigt, und lauter Nullen. Unter dem alten Schluessel
(jahr, rechnungsnummer) hat es die echte Buchung ueberschrieben - im
Amtsbericht fehlte die Uebernachtung dann. Wird jetzt uebersprungen
(pdf_parser.keine_buchung), in beiden Scannern.
2. Der Schluessel ist jetzt die DATEI. Zwei Rechnungen mit derselben Nummer -
der Altbestand, bevor das Rechnungstool eine Sperre bekam - ueberschrieben
sich sonst gegenseitig. Bestehende Journale werden beim Oeffnen einmalig
umgebaut, in einer Transaktion, mit Rueckfall auf den alten Stand.
Buchungen von Hand (kein PDF-Pfad) bleiben davon unberuehrt.
Stornos zaehlen weiter mit - sie sind negativ und heben die Uebernachtung im
Bericht genau so auf, wie es sein soll.
pruef_berichtigung.py (neu): schreibt mit dem echten Renderer des
Rechnungstools eine Rechnung, ein Berichtigungsblatt dazu und zwei Rechnungen
mit derselben Nummer, liest sie ein und prueft das Ergebnis in der Tabelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EKvGkdNW1vKdnMPAM9Bp3X
