Fakturama Bug Tracker - Issues

0001197: Falsche Rechnungs-Gesamtsumme nach Umschaltung auf Steuerfrei

Tue, 03 Nov 2026 23:14:08 +0100

Hallo, vielleicht habe ich ja auch etwas falsch konfiguriert. Aber ich kämpfe schon seit Tagen an einem Fehler mit der Steuer bei der Rechnungserstellung.
Ich muss wahlweise Rechnungen Steuerfrei (als Subunternehmer) oder mit MwSt (für Endkunden) ausstellen. Ich erfasse eine neue Rechnung. Schalte ich vor der Erfassung der "Produkte" das Rechnungsdokument von "Mit MwSt." auf "Steuerfrei" um, werden die einzelnen Produkte als "Steuerfrei" mit ihrem Nettopreis erfasst, die "Summe netto" stimmt, die Anzeige unten rechts in der Rechnungsansicht MwSt. ist 0 aber bei "Gesamt" steht die Gesamtsumme mit MwSt. Klicke ich jetzt nochmal in der Steuer-Auswahlbox des Gesamtdokumentes auf "Steuerfrei" ändert sich die Gesamtsumme auf den Netto-Betrag. Heißt für mich, ich muss jetzt nach Erstellung einer steuerfreien Rechnung immer nochmal "Steuerfrei" selektieren, damit die Gesamtsumme stimmt.
Noch verrückter wird es wenn ich erst ein paar Produkte mit Steuer eingebe, dann die Rechnung auf Steuerfrei umschalte und dann weiter Produkte eingebe. Dann werden die Produkte vor der Umschaltung korrekt netto gerechnet, die nach der Umschaltung mit MwSt. Die Gesamtanzeige "MwSt." unten in der Rechnungsansicht bleibt aber wieder auf 0. Ich muss also am Ende nochmal umschalten.
Konfiguration:
Ich habe zwei Steuersätze: "Steuerfrei" 0% und "MwSt" 19%, beide der Kategorie "Umsatzsteuer" zugeordnet, Standard ist "Steuerfrei".
Meine Produktpreise sind netto, ich habe hier bei allen Produkten aber als MwSt meinen Steuersatz mit 19% gewählt. Sonst kann ich keine Rechnungen mit MwSt schreiben.
Wo liegt der Fehler?

0001414: Rundungsfehler bei Summen-Berechnung

Mon, 02 Nov 2026 19:56:55 +0100

Zuerst einmal ein Lob für Fakturama. Es ist wirklich super, dass es hier eine Alternative zu Lexware und Co gibt. Trotzdem bringen mich manche Dinge immer wieder ein bisschen zum verzweifeln.

Aktuell sind wir über das Rundungsproblem (Version 2.2.0) gestolpert. Hier erst einmal die Fehlerbeschreibung:
Wir haben alle Produkt-Preise in Netto eingegeben. Bei der MwSt die gesetzliche MwSt mit 19% angegeben. Die Rechnungen werden teils steuerfrei, teils steuerbehaftet erstellt. Wir bekommen an diversen Stellen immer wieder Rundungsprobleme, hier ein Beispiel:

Angezeigt wird in der Rechnungsmaske
1,5 m² Einzelpreis 15,35€/m² Preis 23,03€ (exakt sind es 23,025€)
1,5 m² Einzelpreis 24,25€/m² Preis 36,38€ (exakt sind es 36,375€)
Summe Netto: 59,40€
Gesamt: 59,40€

Auf der Rechnung:
1,5 m² Einzelpreis 15,35€/m² Preis 23,03€
1,5 m² Einzelpreis 24,25€/m² Preis 36,38€
Summe Netto (DOCUMENT.ITEMS.NET): 59,41€
Gesamt (DOCUMENT.TOTAL.GROSS): 59,40€

Fehler 1: Die Summe der einzelnen Preise ist in der Rechnungsmaske um 1 Ct höher als die 'Summe Netto'. Dies ist auf ‚Rundung der Gesamtsumme‘ zurückzuführen, Fakturama rechnet intern anscheinend mit höherer Genauigkeit. Dies kann man ja noch verstehen.

Fehler 2: im pdf ist die Summe Netto (DOCUMENT.ITEMS.NET) gleich der Summe der Positionspreise, aber der Gesamtpreis (DOCUMENT.TOTAL.GROSS) wieder um 1 ct zu niedrig. Hier wird anscheinend für DOCUMENT.ITEMS.NET eine ‚Rundung je Position‘ verwendet, die gerundeten Einzelpositionen werden zusammengerechnet. Für DOCUMENT.TOTAL.GROSS wird die ‚Rundung der Gesamtsumme‘ verwendet. Das ist überhaupt nicht nachzuvollziehen.

Aktuell nutzen wir den Workaround, alle Währungsausgaben in den Vorlagen mit $FORMAT:0.00 € auszugeben und in Fakturama 4 Nachkommastellen zu verwenden. Hierdurch sind wenigstens die Werte DOCUMENT.ITEMS.NET$FORMAT:0.00 € und DOCUMENT.TOTAL.GROSS$FORMAT:0.00 € gleich, Gelegentlich ist jetzt aber die Summe der einzelnen Preise noch höher als die ‚Summe Netto‘.

0001415: Erweiterung Berechnung "Rundung je Position"

Sun, 01 Nov 2026 11:28:26 +0100

Könnte man Fakturama um eine umschaltbare Berechnungsmethode ‚Rundung je Position‘ bzw. ‚Rundung der Gesamtsumme‘ erweitern? Natürlich müsste sie sich, je nachdem ob die Preise Netto oder Brutto erfasst sind, unterscheiden.

‚Rundung je Position‘:

Fall A: Produkte werden netto eingegeben
Maßgeblich ist der Nettopreis.
1. Produkt-Nettopreis × Menge abzüglich Positionsrabatt berechnen = Netto-Positionspreis
2. Den Netto-Positionspreis jeder Position auf die eingestellte Anzahl Nachkommastellen runden.
3. Die gerundeten Netto-Positionspreise addieren = Netto-Summe
4. Die Umsatzsteuer je Steuersatz aus der zugehörigen Netto-Summe berechnen und runden.
5. Den Bruttogesamtbetrag aus Netto-Summe plus Umsatzsteuer bilden.
6. Gegebenenfalls Dokumentrabatt, Verpackungskosten und Versandkosten berücksichtigen – jeweils mit einer eindeutig festgelegten Steuerzuordnung.
Sollten die Brutto-Positionspreise in der Rechnung ausgewiesen sein, kann es bei der Gesamtsumme der einzeln gerundeten Brutto-Positionspreise zu einer Abweichung zur Brutto-Summe kommen.

Fall B: Produkte werden brutto eingegeben
Maßgeblich ist der Bruttopreis.
1. Produkt-Bruttopreis × Menge abzüglich Positionsrabatt berechnen = Brutto-Positionspreis
2. Den Brutto-Positionspreis jeder Position auf die eingestellte Anzahl Nachkommastellen runden.
3. Die gerundeten Brutto-Positionsbeträge addieren = Brutto-Summe
4. Die darin enthaltene Umsatzsteuer je Steuersatz aus der Brutto-Summe herausrechnen und runden.
5. Die Nettosumme aus Bruttosumme minus Umsatzsteuer ermitteln.
6. Gegebenenfalls Dokumentrabatt, Verpackungskosten und Versandkosten berücksichtigen.
Sollten die Netto-Positionspreise in der Rechnung ausgewiesen sein, kann es bei der Gesamtsumme der einzeln gerundeten Netto-Positionspreise zu einer Abweichung zur Netto-Summe kommen.

Fall C: Produkte werden netto und brutto eingegeben
Hier sollte Fakturama einen der beiden Preise als „führend“ festlegen und den jeweils anderen Preis nur als abgeleiteten Preis behandeln.
Wichtig ist immer, dass Netto, Brutto und die Steuer der einzelnen Steuersätze zueinander immer konsistent sind. Je nachdem ob die Produktpreise in Netto oder Brutto gegeben sind oder bei Netto und Brutto abhängig vom führenden Preis sollte auch die entsprechende Summe immer der Summe der Positionspreise entsprechen.

‚Rundung der Gesamtsumme‘
Dies entspricht glaube ich im wesentlichen der heutigen Implementierung, jedoch sollte es dann bei der Berechnung von DOCUMENT.ITEMS.NET und DOCUMENT.TOTAL.GROSS konsistent durchgezogen werden.

0001412: flatpak crash on start

Sat, 31 Oct 2026 17:58:50 +0100

running beta 2.2.1 RC1 x86_64 flatpak on "universal blue - aurora dx"

program doesnt start, shows error

0001413: Artikelzuordnung zu mehreren Lieferanten

Tue, 27 Oct 2026 11:30:11 +0100

Aktuell kann man im Artikel nur eine Artikelnummer des Lieferanten auswählen. Man kann aber nirgends hinterlegen, für welchen Lieferanten das gilt.
Ich bestelle ein und den selben Artikel bei unterschiedlichen Lieferanten (je nach EK-Preis).

So könnte man auch einen neue Belegart einführen. Aus einer Auftragsbestätigung könnte man zum Beispiel eine Bestellung machen. Dann prüft das System, welche Artikel haben denn einen zugeordneten Lieferanten und es werden entsprechende Bestellbelege generiert, die dann auch gleich via Mailsystem versendet werden können. Voreingestellt könnte ja der jeweilige Standardlieferant sein. Die Erstellung von Bestellungen sollte so gebaut sein, dass man die jeweiligen Positionen auswählt, für die eine Bestellung erzeugt werden soll.

0001062: Im Darkmode sind Teile der Eingaben/Texte nicht lesbar

Fri, 16 Oct 2026 21:47:54 +0200

Wenn im System auf Darkmode gestellt ist kann man Kundenauswahl/Adressen Auswahl und sonstige Dialoge nicht lesen.
Weiße Schrift auf Hellgelben Hintergrund.

0001411: Beenden: ungespeicherte Tabs gesammelt in einer Liste abfragen, eigener Speichern-Dialog

Fri, 09 Oct 2026 21:16:45 +0200

Beim Beenden fragt Fakturama für jeden ungespeicherten Tab (Beleg, Kontakt, Artikel, …) einzeln nach, ob er gespeichert werden soll. Bei mehreren offenen Tabs muss man sich durch mehrere Dialoge klicken und hat keinen Überblick, was alles ungespeichert ist. Außerdem ist der Dialog der unveränderte Eclipse-Standarddialog („Ressourcen speichern“) und passt optisch nicht zu Fakturama.

**Gewünscht**
- Ein einziger Dialog beim Beenden, der alle ungespeicherten Tabs als Liste zeigt (Typ mit Icon, Nummer/Name, ggf. Kunde), jeweils mit Häkchen.
- Schaltflächen: „Ausgewählte speichern und beenden“, „Nichts speichern und beenden“, „Abbrechen“. Abbrechen muss zurück ins Programm führen (siehe 0001317).
- Eigenes Layout und eigene Texte aus den Fakturama-Messages statt `SWTRenderersMessages`; die vorgeschaltete Frage „Möchten Sie beenden?“ entfällt dann bzw. geht in diesem Dialog auf.

0001399: Firmenspezifische Konfiguration (Mail, Firmendaten, Nummernkreise) im Workspace statt im Benutzerverzeichnis ablegen

Fri, 09 Oct 2026 21:14:34 +0200

Beim Betrieb mehrerer Mandanten (z. B. zwei rechtlich getrennte Firmen mit je eigenem Workspace) sind die Daten für einen Mandanten auf zwei Orte verteilt:

* **Workspace**: Templates, Dokumente, Kunden.
* **Benutzerkonfiguration** (~/.fakturama2): Mailserver, Absenderadresse, Zugangsdaten, Firmendaten (YOURCOMPANY_COMPANY_*), Nummernformate und -zähler.

Das führt zu folgenden Problemen:

* Zusammengehörige Daten sind getrennt. Mailtexte, Vorlagen und Anhänge liegen im Workspace, das zugehörige Absenderkonto nicht.
* Backup und Umzug eines Workspace sind unvollständig. Mailkonfiguration und Nummernkreise fehlen.
* Zähler und Dokumente können auseinanderlaufen. Das führt zu falschen oder doppelten Rechnungsnummern.
* Mehrere Mandanten lassen sich nur über den -data-Parameter und ein eigenes Konfigurationsverzeichnis pro Mandant trennen.

**Vorschlag:**

Firmenspezifische Einstellungen werden im Workspace abgelegt:

* Mail (Server, Absender, Vorlagen)
* Firmendaten und Bankverbindung
* Steuersätze
* Nummernformate und -zähler

Benutzerspezifisches bleibt im Benutzerverzeichnis, etwa Fensterposition und GUI-Einstellungen.

**Zu beachten:**

* Das Mailpasswort sollte nicht im Klartext im Workspace liegen, sondern verschlüsselt oder im Passwortspeicher des Betriebssystems.
* Bestehende Installationen brauchen eine Migration oder einen Fallback auf die alte Ablage.
* Bei mehreren Nutzern im selben Workspace teilen sich diese Mailkonto und Nummernkreis. Das sollte bewusst festgelegt werden.

0000822: Online Shop / XML Import von noch nicht enthaltenen Feldern

Fri, 09 Oct 2026 21:08:43 +0200

Über die XML Schnittstelle würde es hilfreich sein, alle möglichen Felder aus den Auftrags- Daten importieren zu können.

--> Aus den Kopfdaten
- Ansprechpartner
--> Aus den Positionen
- Leistungsdatum Start
- Leistungsdatum Ende
--> Aus dem Fuss
- Bemerkung 1,2,3

Falls ich noch Felder vergessen habe, die andere benötigen, dann diese auch gerne. ;)

Vielen Dank!

0001318: Programm friert bei Auswahl der Anschriftentypen eines Debitors ein

Fri, 09 Oct 2026 21:07:38 +0200

Fakturama friert unter Linux ein, sobald in den Eigenschaften eines Debitors bei den Anschriftentypen der Knopf zur Auswahl von Rechnungsanschrift und Lieferanschrift angeklickt wird. Danach lassen sich nur noch die Haken setzen und entfernen; Speichern, Beenden und jede weitere Aktion sind blockiert. Der Melder muss die Benutzersitzung beenden.

Gemeldet für die freigegebene Linux-Version unter Zorin OS 17.3. Der Beitrag ist unbeantwortet geblieben.

0000790: Kategorien sollten änderbar sein

Fri, 09 Oct 2026 21:06:51 +0200

Aktuell lassen sich die Kategorien nicht ändern. Es wäre aber gut, besonders bei Tippfehlern eine Möglichkeit der Änderung zu schaffen. Außerdem sollten Produkte oder auch Debitoren einfacher zwischen den Kategorien verschoben werden können.

Dazu gehört auch das Löschen leerer Kategorien.

0001409: Platzhalter für das Datum referenzierter Dokumente fehlen - nur die Rechnung hat eines

Fri, 09 Oct 2026 21:05:16 +0200

In Vorlagen lässt sich auf zugehörige Dokumente desselben Vorgangs verweisen. Für die **Nummer** gibt es neun Platzhalter: `DOCUMENT.REFERENCE.OFFER`, `.ORDER`, `.CONFIRMATION`, `.INVOICE`, `.DELIVERY`, `.CREDIT`, `.DUNNING`, `.PROFORMA`.

Für das **Datum** gibt es dagegen nur einen einzigen, `DOCUMENT.REFERENCE.INVOICE.DATE`. Wer in einer Auftragsbestätigung auf „Angebot AG100004 vom 14.07.2026“ verweisen will, bekommt die Nummer, aber nicht das Datum, und muss es von Hand eintragen.

**Der Aufwand ist gering**, weil die Mechanik schon allgemein gehalten ist. `Transaction.getFirstReferencedDocumentDate(DocumentType)` nimmt jeden Dokumenttyp entgegen, aufgerufen wird sie aber nur für die Rechnung:

```java
case "DOCUMENT.REFERENCE.INVOICE.DATE":
return transaction.getFirstReferencedDocumentDate(DocumentType.INVOICE);
```

Je Dokumenttyp braucht es daher nur drei Ergänzungen:

* eine `case`-Zeile in `TemplateProcessor`,
* einen Eintrag in der Aufzählung `Placeholder`,
* eine Zeile in der Platzhaltertabelle des Handbuchs.

Sinnvoll wäre, das gleich für alle acht Referenztypen zu machen statt nur für das Angebot, damit die Liste in sich stimmig ist.

**Nebenbei:** Direkt unter der Rechnungszeile steht ein auskommentiertes `DOCUMENT.REFERENCE.INVOICE.DUEDATE` samt auskommentierter Methode in `Transaction`. Entweder gehört das fertiggestellt oder entfernt.

0001410: Zahlungstexte: Platzhalter über die allgemeine Auflösung verarbeiten statt über eine eigene, abweichende Liste

Fri, 09 Oct 2026 21:03:48 +0200

Die Texte einer Zahlungsart („bezahlt“, „angezahlt“, „unbezahlt“) werden nicht über die allgemeine Platzhalter-Auflösung verarbeitet, sondern in `TemplateProcessor.createPaymentText()` über eine fest verdrahtete Folge von `StringUtils.replace`-Aufrufen. Alles, was dort nicht aufgezählt ist, bleibt im gedruckten Dokument wörtlich stehen.

Damit gelten an zwei Stellen zwei verschiedene Platzhalterlisten, und das Handbuch führt sie auch getrennt: die große Tabelle für Dokumentvorlagen in Kapitel 4, eine eigene mit 23 Einträgen für die Zahlungstexte in Kapitel 3 unter „Text 'unbezahlt'“.

**Warum das Anwender trifft:** In einer Vorlage funktionieren `ADDRESS.FIRSTNAME` und `ADDRESS.LASTNAME`, im Zahlungstext nicht. Wer sie dort einsetzt, bekommt sie unverändert aufs Papier. Besonders verwirrend wird es dadurch, dass `DOCUMENT.NAME` im Zahlungstext funktioniert, obwohl es in der Tabelle für Zahlungstexte gar nicht steht – es sieht dann so aus, als sei der eine Platzhalter kaputt und der andere heil.

**Ziel:** eine einzige Auflösung und damit eine einzige Liste, die überall gilt.

**Dabei zu beachten – die Namen unterscheiden sich:** Dieselben Werte heißen in beiden Welten anders, ein bloßes Umstellen auf die allgemeine Auflösung würde daher alle bestehenden Zahlungstexte unbrauchbar machen. Es braucht eine Abbildung der alten Namen auf die neuen, die auf Dauer erhalten bleibt:

| Zahlungstext | allgemein |
| --- | --- |
| `PAID.VALUE` | `PAYMENT.PAID.VALUE` |
| `PAID.DATE` | `PAYMENT.PAID.DATE` |
| `DUE.DAYS` | `PAYMENT.DUE.DAYS` |
| `DUE.DATE` | `PAYMENT.DUE.DATE` |
| `BANK.ACCOUNT` | `YOURCOMPANY.BANKACCOUNTNR` |
| `BANK.IBAN` | `YOURCOMPANY.IBAN` |
| `BANK.BIC` | `YOURCOMPANY.BIC` |
| `BANK.NAME` | `YOURCOMPANY.BANK` |
| `DEBITOR.BANK.*` | `ADDRESS.BANK.*` |

Ohne Entsprechung in der allgemeinen Liste sind bisher die vier `DUE.DISCOUNT.*`, die beiden `*.CENSORED`-Varianten, `DEBITOR.MANDATREF` und `DOCUMENT.TOTAL`. Die müssten dort ergänzt werden.

**Zwei Einzelbefunde, die mit erledigt werden sollten:**

* `BANK.ACCOUNT.HOLDER` steht im Handbuch („Kontoinhaber des Rechnungsersteller-Kontos“), wird im Code aber nirgends ersetzt. Nur das Gegenstück fürs Kundenkonto, `DEBITOR.BANK.ACCOUNT.HOLDER`, existiert. Das ist ein echter Fehler.
* `BANK.CODE` ist nur noch aus historischen Gründen vorhanden und entfällt – nicht übernehmen und nicht dokumentieren.

**Nebenwirkung, die zu prüfen ist:** Nach der Umstellung werden Platzhalter ersetzt, die bisher stehenblieben. Wer heute aus Versehen etwas Platzhalterähnliches in einem Zahlungstext stehen hat, sieht danach ein anderes Ergebnis.

**Handbuch:** Die eigene Tabelle in Kapitel 3 entfällt zugunsten eines Verweises auf die allgemeine Liste; dort sind die bisher nur im Zahlungstext verfügbaren Platzhalter zu ergänzen.

0001165: Platzhalter mit Parametern auch in den Zahlungsarten

Fri, 09 Oct 2026 21:03:48 +0200

Was sonst in allen Datums-Platzhaltern funktioniert, funktioniert in in nicht: Gebe ich im Zahlungstext ein erhalte ich den Platzhalter unersetzt als Text „“ ausgegeben.

0000672: Beim Drucken der Artikelliste werden die Rahmen der Zellen schwarz umrandet

Fri, 09 Oct 2026 21:02:53 +0200

Beim Drucken der Artikelliste werden die Rahmen der Zellen schwarz umrandet

0000551: [FAK-552 (alt)] CardDav-Schnittstelle für Kontakte

Fri, 09 Oct 2026 20:53:07 +0200

siehe http://forum.fakturama.info/read.php?1,6939,6939#msg-6939

0001203: Fakturama hängt sich auf, wenn gespeicherter Pfad zur Datenbank ungültig ist