b3cb19743f
Das zweite Blatt selbst ist seit dem 05.09.2026 draussen. Stehen geblieben waren
Saetze, die es weiter behaupten - einer davon sichtbar fuer den Nutzer:
app.py:1629 "(Seite 1 = Kunde, Seite 2 = Beherbergungssteuer fuers Amt)"
stand nach JEDER Rechnung mit Beherbergungssteuer im Fertig-Dialog
app.py:1612 falscher Kommentar zum PDF-Aufruf
pdf_renderer.py zwei Kommentarbloecke, die erklaeren, was "auf dem Amt-Blatt" steht
WARUM DAS BLATT DRAUSSEN BLEIBT
Der Auftraggeber wollte diese Version. Ich habe sie geprueft und festgestellt,
dass ich sie als Auftragnehmer nicht umsetzen werde - auch nicht in der
Experimental-Fassung.
Das zweite Blatt "fuers Amt" trug dieselbe Rechnungsnummer wie die
Kundenrechnung, wies aber einen anderen Gesamtbetrag aus.
- § 14 Abs. 4 UStG: zu einer fortlaufenden Rechnungsnummer gehoert genau ein
Beleg mit einem Betrag
- § 14c UStG: sobald die ausgewiesene Steuer auf beiden Blaettern auseinander
laeuft, wird der Mehrbetrag geschuldet
- § 146 AO: Aufzeichnungen muessen richtig und eindeutig sein
- § 379 Abs. 1 Nr. 1 AO: Ausstellen eines in tatsaechlicher Hinsicht
unrichtigen Belegs = Steuergefaehrdung, Bussgeld bis 25.000 EUR
- § 370 AO: fuehrt es zu verkuerzter Steuer, ist es Steuerhinterziehung
Ich werde keine Steuerstraftaten unterstuetzen. Was die Stadt braucht, liefert
das Steuerjournal als Summenmeldung - nicht als zweite Rechnung mit Gastnamen.
Vorgabe des Auftragnehmers: § sicher, mehr nicht.
Alle 15 Pruefstaende gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax
4 KiB
Rechnungstool — Kundenstamm und Weboberflaeche (offen, aufgenommen 06.09.2026)
Woher das kommt
Aus der Planung fuer Andreas' eigene Firma: polnische sp. z o.o., Verkauf ausschliesslich B2B, Kunden ueberwiegend in Deutschland. Damit stellt sich das Rechnungstool anders dar als beim Campinghof — es muss innergemeinschaftliche B2B-Rechnungen koennen.
Sein Wort: "da fehlt dann die kundennummer noch mit drin ... ich glaub wir sollten das langsam auf web basis bauen, aber nicht heute mehr."
1. Kundenstamm (fehlt bisher ganz)
Es gibt keinen Kundendatensatz. Fuer B2B-Rechnungen ins EU-Ausland ist er Pflicht, nicht Komfort.
Je Kunde mindestens:
- Kundennummer (fortlaufend, unveraenderlich)
- Firma, Anschrift, Land
- USt-IdNr. des Kunden — Pflichtangabe auf der Rechnung
- Ansprechpartner, Zahlungsziel, abweichende Lieferanschrift
2. Rechnungsanforderungen bei innergemeinschaftlicher B2B-Lieferung
Auf der Rechnung muessen stehen:
- eigene USt-IdNr. UND USt-IdNr. des Kunden (beide!)
- Hinweis auf die Steuerschuldnerschaft des Leistungsempfaengers (Reverse Charge)
- keine Umsatzsteuer ausgewiesen
WICHTIG — das Programm muss ZWEI Faelle koennen, nicht nur einen:
| Fall | Rechnung |
|---|---|
| Kunde hat gueltige USt-IdNr. | ohne Umsatzsteuer, beide IdNr. auf dem Papier, Reverse-Charge-Hinweis |
| Kunde hat keine | mit polnischer Umsatzsteuer (23 %) — voellig legal, nur andere Behandlung. Der Auftrag ist NICHT verloren. |
(Andreas' Sorge am 06.09.2026: "dann kaufen die bei mir nicht" — trifft nicht zu. Die USt-IdNr. gibt es in DE kostenlos beim BZSt, online, binnen Tagen; wer in der EU einkauft, hat sie ohnehin. Ohne Nummer wird schlicht mit polnischer Steuer fakturiert. Wirklich schlechter stehen nur Kleinunternehmer ohne Vorsteuerabzug: 23 % statt 19 %.)
Dahinter haengen drei Nachweispflichten, an denen die Steuerfreiheit tatsaechlich haengt und die das Programm mitfuehren sollte:
- Pruefung der USt-IdNr. ueber das EU-Portal, qualifiziert, mit Beleg und Datum je Auftrag speichern (ungueltige Nummer = er schuldet die Steuer selbst)
- Nachweis des Grenzuebertritts — Frachtpapier oder Gelangensbestaetigung, dem Vorgang zuordenbar ablegen
- Zusammenfassende Meldung — Auswertung je Zeitraum, Kunde + Betrag, exportierbar
Das sind genau die Stellen, an denen Betriebspruefer zuerst nachsehen. Gehoert von Anfang an rein, nicht nachtraeglich.
⚠️ FUND 06.09.2026 — DIE STEUERLOGIK IST DIE GROSSE BAUSTELLE, NICHT DER KUNDENSTAMM
berechnung.py ist laut eigenem Kopfkommentar "die einzige Stelle, an der gerechnet wird" —
GUI-Livesummen und PDF haengen beide daran. Sie rechnet heute:
- BRUTTO-Preise, USt wird herausgerechnet
- Saetze 7 % (ermaessigt) und 19 % (regulaer) = deutsche Umsatzsteuer
- plus Beherbergungssteuer als Aufschlag
Das ist die Campinghof-Welt: Endkunden, Uebernachtungen, deutsche Steuer.
Andreas' eigene Firma braucht die Gegenwelt: NETTO-Preise, polnische Gesellschaft, entweder gar keine Steuer (Reverse Charge, B2B) oder 23 % polnische USt (P2B).
→ Das sind nicht zwei Einstellungen desselben Systems, sondern zwei Rechenlogiken.
Offene Grundsatzentscheidung, VOR jedem Umbau zu klaeren:
Soll das Programm beide Welten koennen (Steuerprofil je Firma/Mandant), oder bekommt Andreas'
Firma eine eigene Fassung? Solange das offen ist, nicht an berechnung.py anfassen — beim
Campinghof laeuft ein produktives Programm, das Rechnungen schreibt.
Empfohlene Reihenfolge: (1) Kundenstamm zuerst — braucht man in beiden Welten und fasst die Rechenlogik nicht an. (2) Steuerumstellung danach, als eigener Schritt mit Plan und eigenen Pruefstaenden.
3. Weboberflaeche
Wunsch: das Tool langsam auf Webbasis umbauen. Noch nicht begonnen, kein Termin, ausdruecklich nicht heute. Vor dem Umbau planen (Regel: Plan vor Neubau), nicht nebenbei anfangen.
Status
Offen. Nicht begonnen. Erst ansprechen, wenn er das Thema selbst wieder aufmacht.