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
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
Logo
Das Programmlogo (Wolke mit Paragraphenzeichen) steht jetzt rechts in der
Kopfleiste - damit sich die beiden Werkzeuge auf einen Blick unterscheiden.
bauen.py
Der Weg von der Quelle zur Setup-Datei war eine Folge von Befehlen, die
jemand von Hand eintippen musste. Wer einen Schritt vergisst, liefert eine
Setup-Datei mit einer alten EXE aus - und sieht es ihr nicht an. Jetzt ist
es ein Befehl, die Nummer kommt aus version.py, und am Ende stehen die
SHA256-Summen fuer den Release-Text.
pruef_start_exe.py
Prueft, was kein anderer Pruefstand prueft: ob die GEBAUTE EXE ein
sichtbares Fenster zeigt. Alle uebrigen fahren das Programm aus der Quelle,
dort trat der Fehler nie auf.
pruef_einzelinstanz.py wieder gruen
Der Erprobungshinweis haette in jedem der drei Starts ein echtes Fenster
geoeffnet - in einem eigenen Prozess laesst sich kein Dialog abfangen, es
klickt niemand. Geprueft wird dort die SPERRE, nicht der Hinweis (der hat
einen eigenen Pruefstand). Die Kenntnisnahme wird deshalb vorher
eingetragen, und zwar mit genau dem Code, den auch der Klick auf "Ja"
ausfuehrt. Das trifft nur die Kopie im Temp-Ordner: im echten Journal
entsteht keine Zustimmung, die niemand gegeben hat.
Aufgeraeumt
Beherbergungssteuer.exe und die gleichnamige .spec sind raus - das Programm
heisst jetzt anders. Gebaute Dateien gehoeren ins Release, nicht ins Repo;
die .spec-Dateien dagegen schon.
Fassung 1.8.0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax
NAME
Das Programm heisst jetzt Steuerrechnungstool - wie sein Repository
(https://git.pcore.de/TheMockTv/Steuerrechnungstool). Umgestellt: Fenstertitel,
Kopfzeile, "laeuft bereits"-Meldung, Startdatei, Spec-Datei (EXE-Name), Logzeile.
NICHT umbenannt, mit Absicht:
* "Beherbergungssteuer" als NAME DER STEUER - das ist ein Rechtsbegriff und
steht weiter so in Berichten, Anmeldung und Oberflaeche.
* LOCALAPPDATA\Beherbergungssteuer in ablage.py - dort liegt der Zeiger auf
den Datenordner. Wer den umbenennt, kappt bestehenden Installationen den
Weg zu ihren Daten.
* Der lokale Ordner C:\claude\beherbergungssteuer - steht in Pruefstaenden
und Spec-Dateien fest, eigener Schritt.
HINWEIS
hinweis.py aus dem Rechnungstool uebernommen (liegt in beiden Programmen
gleich). Der Hinweis kommt beim Start, Ablehnen beendet das Programm ohne
etwas zu vermerken, die Kenntnisnahme wird mit Benutzer, Zeit und Fassung in
der Einstellungstabelle des Journals gespeichert. Neu: Menue Hilfe -> Info mit
dem Text und der Signaturzeile.
PRUEFSTAENDE
Vier Prueflaeufe hatten gar keinen Dialogabfang - bisher fragte das Programm
beim Start nichts. Jetzt bleiben sie sonst vor einem echten Fenster stehen.
pruef_doppelte und pruef_storno_verrechnet haben einen bekommen, der bei
UNBEKANNTEN Fragen abbricht statt still "ja" zu sagen. pruef_storno_journal und
pruef_wache melden Hinweis und Freigabe ausdruecklich an. pruef_wache treibt
ausserdem die Ereignisschleife an (update), sonst kaeme after_idle nie dran.
pruef_wache: die Erwartung "im gemeinsamen Ordner liegt genau EINE Datei" ist
auf die richtige Menge gebracht - Nummernbuch UND Schluessel der Mini-API, der
seit dem 05.09.2026 dorthin gehoert. Alles darueber hinaus faellt weiter auf.
⚠️ pruef_wache bleibt ROT an einer Stelle, die NICHT von diesen Arbeiten kommt
(vor dem Umbau gemessen, war schon rot): die Statuszeile soll nach einem Push
"Rechnungstool meldet" zeigen, wird aber vom Ergebnis des Einlesens
ueberschrieben. Dokumentiert in AUFGABE_BEWEISKETTE_PRUEFBAR.md.
5 von 6 Pruefstaenden gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax
Das Journal macht beim Start einen winzigen Server auf 127.0.0.1 auf und traegt
Port und PID in die gemeinsame SQLite ein (Tabelle "laeuft"). Das Rechnungstool
sieht daran, dass jemand zuhoert, und klopft nach jeder Rechnung an: "schau in
die sqlite". Dann wird sofort nachgelesen, statt bis zum naechsten Durchgang zu
warten. Faellt die API aus, findet die Wache die Meldung trotzdem - ein os.stat
auf die eine Datei, alle zwei Sekunden und sofort beim Zurueckklicken.
Die Proforma-Rechnung wird NICHT gebucht: keine_buchung() kennt jetzt
Berichtigung und Proforma. Der Scan fragt wieder keine_buchung() - seit dem
Berichtigungs-Umbau tat er das nicht mehr, und die Proforma waere als Buchung
im Journal gelandet (der Pruefstand hat es gefunden).
Pruefstand pruef_wache.py: 31 Pruefungen ueber BEIDE Programme - Anmeldung mit
PID, ping ("hallo, bin noch da"), genau eine Datei im gemeinsamen Ordner, Push
nach Rechnung und nach Storno, Einlesen samt Anzeige, Rueckfallebene ohne API,
tote PID wird weggeraeumt, kein Melden an ein geschlossenes Journal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYeAfLtccFrbU3MTj1MMTx
Stehen beide Programme offen und wird im Rechnungstool eine Rechnung
geschrieben, erscheint sie hier ohne Zutun. Das Journal traegt sich dafuer beim
Start mit seiner PID in der gemeinsamen SQLite ein (Tabelle "laeuft") und traegt
sich beim Schliessen wieder aus; das Rechnungstool sieht daran, dass jemand
zuhoert, und legt eine Zeile in die Tabelle "nachrichten".
Nachgesehen wird nur dort - erst ein os.stat auf die eine Datei, und nur wenn
sich etwas geruehrt hat, wird sie geoeffnet. Kein Absuchen des
Rechnungsordners, kein Server, kein Port. Beim Zurueckklicken ins Fenster wird
sofort nachgesehen statt zwei Sekunden zu warten.
Die Wache faengt jeden Fehler ab und stirbt nie - ein Netzlaufwerk, das kurz
weg ist, darf das Fenster nicht lahmlegen.
⚠ Ein Denkfehler daraus gleich behoben: der erste Blick nach dem Start merkt
sich den Stand AUCH dann, wenn es die Datei noch gar nicht gibt. Sonst galt die
erste Meldung danach als "schon gesehen" und wurde verschluckt.
Pruefstand pruef_wache.py (faehrt BEIDE Programme): 23 Pruefungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYeAfLtccFrbU3MTj1MMTx
