RechnungsFee v0.5.1

💾 Downloads

Plattform	Download
🪟 Windows (x64)	⬇ RechnungsFee_0.5.1_x64-setup.exe
🐧 Linux (x86_64, versioniert)	⬇ RechnungsFee_0.5.1_amd64.AppImage
🐧 Linux (x86_64, via install.sh)	⬇ RechnungsFee_amd64.AppImage
🐧 Linux Installer	⬇ install-linux.sh
🍎 macOS (Apple Silicon, versioniert)	⬇ RechnungsFee_0.5.1_aarch64.dmg
🍎 macOS (Apple Silicon)	⬇ RechnungsFee_aarch64.dmg

🐧 Linux: install-linux.sh lädt die App nicht selbst herunter – zusätzlich die AppImage in denselben Ordner legen (empfohlen: die neutrale RechnungsFee_amd64.AppImage, bleibt bei Updates gleich benannt). Dann bash install-linux.sh ausführen (kein chmod +x nötig).

🍎 macOS: Nicht signiert – beim ersten Start Rechtsklick → Öffnen, oder:
xattr -cr RechnungsFee_0.5.1_aarch64.dmg

🔍 OCR für gescannte Belege & Kassenbons (Tesseract OCR):

• 🪟 Windows: automatisch durch den Installer
• 🐧 Linux: wird vom install-linux.sh-Skript angeboten; manuell: sudo apt install tesseract-ocr tesseract-ocr-deu
• 🍎 macOS: brew install tesseract tesseract-lang

Ohne Tesseract zeigt RechnungsFee einen Installationshinweis sobald ein gescannter Beleg importiert wird.

---

🔧 Verbesserungen

• SMTP-Versand – Fehlermeldungen beim Testversand waren rohe, technische Systemtexte wie „[Error 11001] getaddrinfo faild" und für die meisten kaum verständlich. Netzwerk-, Zertifikats- und Zeitüberschreitungsfehler werden jetzt in klare deutsche Hinweise mit Lösungsvorschlag übersetzt. Zusätzlich neuer Schalter „Selbstsigniertes Zertifikat akzeptieren" (Einstellungen → Unternehmen → Funktionen → SMTP) für Fälle, in denen der Mailserver ein Zertifikat verwendet, dem das Betriebssystem bereits vertraut, RechnungsFee aber nicht – z. B. bei TLS-Prüfung durch lokale Sicherheitssoftware. Das Zertifikat wird dabei beim ersten Versand gemerkt („Trust on First Use") statt dauerhaft ungeprüft akzeptiert: zeigt der Server danach ein anderes Zertifikat, bricht der Versand sicherheitshalber ab, bevor Zugangsdaten gesendet werden. Standardmäßig aus (Issue #336).
• Logo im PDF-Kopf durfte bisher maximal 18 mm hoch dargestellt werden – auf 25 mm vergrößert, angeglichen an die Höhe des danebenstehenden Firmentextblocks, ohne die auf 45 mm fixierte Empfängeradresse (DIN 5008) zu verschieben. Betrifft Rechnungen, Angebote, Lieferscheine, Aufträge, Proforma-Rechnungen und Mahnungen.

🐛 Bugfixes

• DATEV-Export – der Hinweis-Dialog auf fehlende Berater-/Mandantennummer (Issue #328) ließ sich nicht durch einfaches Bestätigen mit den DATEV-Standardwerten dauerhaft loswerden: Die Felder waren leer vorbefüllt, ein Klick auf „Speichern" ohne Eintippen speicherte leere Werte statt der Standardwerte 1001/1, wodurch der Hinweis beim nächsten Export erneut erschien. Die Felder sind jetzt mit den echten Standardwerten vorbefüllt – „Speichern" reicht jetzt aus, um sie zu übernehmen. Danke an Peter1061 fürs Nachtesten (Issue #328).
• Mahnwesen – der Link „aktueller Wert bei der Bundesbank" beim Basiszinssatz (Verzugszinsen §288 BGB) führte ins Leere, die Bundesbank hat die Seite unter einer neuen URL verschoben. Danke an Peter1061 (Issue #331).
• Rundungsfehler bei Rechnungen – ein eingegebener Preis konnte in der Rechnungsvorschau, in den Rechnungsdetails und auf dem PDF voneinander abweichen, weil Formular, Speichern und PDF unabhängig voneinander rundeten; bei größeren Stückzahlen konnte das sogar mehrere Cent ausmachen, weil die USt pro Stück statt pro Position gerundet wurde. Jetzt gibt es nur noch eine Berechnung auf Positionsebene: Netto-Rechnungen summieren die Netto-Positionssummen (Einzelpreis × Menge) und leiten die USt daraus ab, Brutto-Rechnungen summieren die Brutto-Positionssummen und leiten die USt als Differenz ab – Vorschau, Speichern und PDF verwenden garantiert dieselben Werte, in Rechnung, Angebot, Auftrag und Proforma. Zusätzlich rundet der Artikelstamm den aus dem Brutto-Verkaufspreis abgeleiteten Netto-Preis nicht mehr auf den Cent, und USt/Netto werden aus der ungerundeten Positionssumme statt aus dem bereits gerundeten Betrag abgeleitet – eine Netto-Rechnung mit Artikeln ergibt jetzt exakt denselben Betrag wie die entsprechende Brutto-Rechnung. Danke an gitmacer (Issue #332).
• Kundenstamm – das Feld „USt-IdNr." konnte für Kunden ohne EU-USt-IdNr. (z.B. Kleinunternehmer als B2B-Kunde) nicht für die Angabe einer Steuernummer genutzt werden, obwohl ZUGFeRD/XRechnung beides als gültige Verkäufer-/Käuferkennung akzeptiert. Für Kunden in Deutschland und im Drittland heißt das Feld jetzt „USt-IdNr. / Steuernummer" und akzeptiert beides. Bei EU-Kunden (außer Deutschland) bleibt es bewusst auf USt-IdNr. beschränkt, weil dieser Wert unverändert in die Zusammenfassende Meldung für innergemeinschaftliche Lieferungen übernommen wird – dort wäre eine Steuernummer falsch (Issue #335).
• Artikelstamm – beim Anlegen einer Dienstleistung wurden fälschlich die Felder „Lieferant" und „Lieferanten-ArtNr." angezeigt. Eine Dienstleistung ist eine eigene Leistung ohne Einkauf bei einem Lieferanten – die Felder gehören nur zu Artikel und Fremdleistung. Bestehende Dienstleistungen mit versehentlich hinterlegtem Lieferanten werden automatisch bereinigt (Issue #334).
• SVG-Logo-Upload unter Windows – die SVG-zu-PNG-Konvertierung schlug mit „no library called libcairo-2.dll was found" fehl, weil die dafür nötige Systembibliothek unter Windows nicht mitgeliefert wurde. Umgestellt auf resvg_py, das keine externen Bibliotheken mehr benötigt. Dabei zusätzlich behoben: SVGs mit width/height="0" im Wurzelelement (kommt bei manchen Export-Tools vor) wurden mit „SVG has an invalid size" abgelehnt, obwohl ein gültiges viewBox vorhanden war. Außerdem wurden SVGs mit Größenangaben in physischen Einheiten (z. B. width="25mm") komplett abgelehnt, selbst mit einem gültigen positiven Wert – werden jetzt automatisch in Pixel umgerechnet.
• Build-Absicherung: eine vorkompilierte Beschleunigungs-Variante von charset_normalizer (für den Bank-CSV-Import) hätte bei der nächsten Paketaktualisierung jeden Programmstart mit einem internen Fehler verhindern können. Vorsorglich auf die reine Python-Variante festgelegt.