Das kommt immer drauf an, wie Du Deine Preise erfaßt hast. Das Thema kommt hier immer mal wieder auf, läßt sich aber nicht gänzlich beseitigen...

habe einige Beiträge im Forum gefunden, aber leider keine Lösung.
scheint unabhängig davon zu sein, wie ich den Pries festlege. Z.B. Eingabe des Bruttopreises 4 € ergibt bei Menge 5 den Gesamtpreis 19,99, gleicher Effekt als wenn ich den Netto-Preis mit 3,36 € angebe. Auch wenn es sich nur um einen Cent-Betrag handelt unschön ...

Das ist aktuell wirklich sehr problematisch in Fakturama gelöst. Ich habe Tests gemacht, indem ich wahlweise bei den Produkten den Netto oder Bruttopreis eingegeben habe und dann auf der Rechnung entweder Brutto- oder Nettopreise habe aufaddieren lassen. Entgegen meiner Erwartung bekomme ich je nach Kombination unterschiedliche Zwischen- und Endsummen auf der Rechnung. Schuld ist immer der Preis, der von Fakturama berechnet wurde.
Ich habe hier Produkt1 mit 2,24/2,40€ (netto/brutto) und Produkt2 mit 2,15/2,30€ (netto/brutto) - 7% MWSt. Dann eine Rechnung mit 16x Produkt1 + 11x Produkt2. Die Rechnungsvorlage habe ich angehängt: Alles als Netto, erst am Schluss wird das Brutto ausgerechnet. Je nachdem, wie ich die Preise eingegeben habe (also Brutto oder Netto), kommt eine andere Rechnung raus mit bis zu 5 Cent Unterschied. Ich kann natürlich auch eine reine Brutto-Rechnung machen (mit ausgewiesener MWSt), aber auch dort kriege ich unterschiedliche Rechnungsbeträge abhängig davon, ob ich bei den Produkten einen Brutto- oder einen Nettopreis eingegeben hatte. In der Produktmaske ist das nicht ersichtlich, weil dort bei der Ansicht der Betrag gerundet (oder abgeschnitten?) wird.

Es ist nicht akzeptabel, eine Rechnung zu haben, bei der die Summen offensichtlich nicht stimmen. Dafür hat kein Kunde Verständnis und da hilft auch der Hinweis nicht, dass es "nur" ein Rundungsfehler ist.

Meiner Meinung nach darf Fakturama an keiner Stelle mit mehr als 2 Nachkommastellen rechnen, sonst ist die Chance auf Rundungsfehler extrem hoch. Das gilt schon für die Umrechnung Brutto-Preis -> Netto-Preis (und andersrum) oder bei Rechnungen, die in Netto berechnen und erst ganz am Schluss Steuer + Brutto-Rechnungsbetrag ausgeben. Das müsste eine Kleinigkeit im Programmcode sein.

Man kann in den Einstellungen angeben, mit wie viel Stellen Fakturama rechnen soll. Ich kann aber nicht nur mit 2 Nachkommastellen intern rechnen, weil dann die Abweichung noch viel größer sein würde. Deswegen muß man sich eigentlich auch am Anfang beim Einrichten darauf festlegen, wie man die Preise eingibt. Wenn man die von Brutto- auf Nettopreise herunterrechnet, kommen zwangsläufig Rundungsfehler zustande. Es gibt auch irgendwo eine Vorschrift, was wann wie zu runden ist, ich hab's bloß gerade nicht parat. Werde das Thema aber weiter im Auge behalten. Scheinbar betrifft es aber nicht alle Anwender...

Ja, da ist natürlich was dran. Mein Kunde hat das wild durcheinander gemacht, ich dränge den jetzt, das endlich einheitlich zu handhaben und dann sind wir das Problem hoffentlich los.

@Marcel2 

Hallo Marcel,

die grundsätzliche Regelung in Österreich lautet, dass es in den Einzelpositionen zu Rundungsfehlern kommen darf, solange die Gesamtsumme und USt/MwSt korrekt ausgewiesen ist.

Ich habe einige Kunden und Lieferanten, bei welchen folgender Satz (oder eine sinngemässe Formulierung) auf der Rechnung steht:

"Durch Rundungsfehler können leichte Fehler in den Summen entstehen, entscheidend ist die Gesamtsumme"

Ich habe solche Dinge bisher eher oberflächlich betrachtet, und mir nie Gedanken dazu gemacht, aber offensichtlich wird sowas aus gutem Grund verwendet.

Eine einheitliche Handhabung wird da sicher weiterhelfen können.
Zugegebenermassen verwende ich selbst keine "krummen" Preise und arbeite ausschliesslich mit 2 Nachkommastellen, mir ist daher in diese Richtung nie etwas aufgefallen.

LG
Jürgen

Hallo in die Runde,

leider ist das Rundgungsproblem bei mir ein Dauerbrenner, so daß ich die Rechnungen manuell berichtigen muss.

Beispiel: Artikel mit 3-Nachkommastellen (Gewicht)

12,157 t * 230,95 € = Summe Artikel 2.807,66 € + USt. 533,46 € = Gesamtbetrag 3.341,11 € (so sieht die Rechnung aus). 3.341,12 € müssten in Summe rauskommen.

Die 3.341,11 € des Gesamtbetrags kommt zustande, wenn ich 3-stellig rechne (2.807,659 € + 533,455 € = 3.341,114 €). Hierbei wird der Gesamtbetrag nach unten gerundet.

Bei normaler Addition des Nettobetrags und der USt. würden die 12 Cent stehen.

Für mich ein Zeichen, dass 3-stellig gerechnet aber anders dargestellt wird.

Viele Grüße

Bernd Neumann

Hi, 

Zu dem Rundungsproblem würde es eine wahrscheinlich recht simple Lösung geben, diese bedarf aber etwas mehr umbau intern. Es gibt in Deutschland 2 zugelassene Arten zu runden: auf Positionebene und auf Gesamtpreisebene. Berechne ich nun die Steuer auf Positionsebene, runde da schon und erhalte einen Gesagtpreis, so unterscheidet der sich maßgeblich (1-2cent)  von dem Preis, bei welchem man zunächst alle Werte pro Steuersatz addiert, anschließend die Steuern berechnet. 

Eine Möglichkeit wäre es nun, die Art der Berechnung wählbar zu machen. 

Ich gehe davon aus, das im Fall hier die Steuer auf Gesamtebene berechnet werden soll, Fakturama es aber auf Einzelpositionsebene durchführt. 

Wäre eine solche Änderung wünschenswert?

Grüße Boarschti

Edit: zusätzlich müsste natürlich die zwischenberechnung mit mindestens 5 Kommastellen erfolgen, um die Rundungen bei den Zwischenschritten auszugleichen.

Da kommt leider noch erschwerend ein weiterer Fakt dazu. Die Produktpreise (im Produktkatalog) können wahlweise brutto oder netto eingegeben werden, je nach Einstellung. Wenn man bspw. die Preise für die Produkte brutto eingegeben hat, seine Rechnung aber mit Nettopreisen ausweist, dann werden die Nettopreise auf der Rechnung aus den Bruttopreisen ermittelt. Aus diesen umgerechneten Werten wird dann die Gesamtsumme ermittelt. Die ganze Umrechnerei führt natürlich dann zu den unschönen Differenzen.

#borschti #rheydenr

Vllt. würde das Rundungsproblem reduziert, wenn auf Positionsebene eine Preisdarstellung und Berechnung mit X-Stellen (ich denke 5 müssten reichen) gewählt wird. Eine Rundung auf 2 Stellen sollte dann erst auf Ebene der Nettosummenbildung, USt-berechnung und Gesamtsumme erfolgen.

Hey,

Bitte bedenke, es gibt laut Finanzamt 2 Möglichkeiten zu runden: eine direkt auf positionsebene ( pos+mwst+rundung) und dann zusammenrechnen  ODER pos zusammenrechnen mwst drauf und dann erst beim gesamt runden. 

Beide Methoden haben ihre Berechtigung, eine von beiden ist derzeit bei Fakturama gewählt. Bei Bedarf können wir sicher noch ein Ticket öffnen, damit wir die Rundungsmethode im Fakturama frei bestimmen können (weiß grad nicht, obs das schon gibt @rheidenreich ?) 

Ansonsten berechnen wir das im Falturama schon mit mehr als 2 Stellen... 

Viele Grüße ausm verregneten Entwicklerstudio

Boarschti 🤣 

Moin, ein Ticket gibt's dafür noch nicht.

@rheydenr 

in meiner Naivität frage ich mal: "Gibt es eine Möglichkeit, auf Ebene Libre-Office einen Rundungparameter anzugeben?"

Nein, in LibreOffice ist das ja einfach nur Text und wird nicht als Zahl interpretiert.