Das Runden ist komplexer als gedacht. Es spielen hier auch mehrere Effekte zusammen, die ich später auch noch im Detail erläutern werde.

DER zentrale Punkt ist aber folgender:
Fakturama rechnet bis zum Schluss mit den genauen, also ungerundeten Werten. Und erst am Ende kann man jeden Wert gerundet abrufen. Das führt dann dazu:

Netto: 10.004€
MwSt: 2.004€ [size=x-small](keine 19%, sondern ein fiktiver Wert)
Brutto: 12.008€

Jetzt gerundet:
Netto: 10.00€
MwSt: 2.00€
Brutto: 12.01€

Man sieht, was man sieht. Und das passiert vor allem dann, wenn krumme Teile von Cent auftreten. Und genau das passiert vor allem bei Rabatten.

Ein Lösungsansatz wäre folgender:
Man rundet in jedem Zwischenschritt:
- Nach dem Rabatt
- Nach dem Versand
- Nach der Steuer, also am Schluss

Allerdings ist es so, dass man sich jetzt entscheiden muss, ob man so rundet, dass es volle Cents beim Netto oder beim Bruttowert geben soll. Sprich: Man muss in Zukunft zwischen einem Dokument mit Netto und einem mit Bruttowerten unterscheiden. Bisher gabs das nicht. Denn man am Ende der Berechnung wurde sowohl ein gerundeter Netto, als auch Bruttobetrag bereitgestellt.

So würde das dann aussehen:

Nettodokument:
Netto: 10.004€
MwSt: 2.004€
Brutto: 12.008€

Jetzt gerundet:
Netto: 10.00€
MwSt: 2.00€
Brutto: 12.00€, weil = Netto + Steuer

Bruttodokument:
Netto: 10.004€
MwSt: 2.004€
Brutto: 12.008€

Jetzt gerundet:
MwSt: 2.00€
Brutto: 12.01€
Netto: 10.01€, weil = Brutto - Steuer

gerd

Hallo Gerd,

das mit den unterschiedlichen Formularen ist bei mir jetzt schon so. Wenn ich eine Brutto-Rechnung stellen will, benötige ich ein Rechnungsformular das mir "Inklusive MwSt" x,xx € anzeigt. Wenn ich eine Nettorechnung stelle, benötige ich im Formular "Zuzüglich MwSt".

Was mich viel mehr stört: Bei Eingabe eines Einzelpreises im Fakturama Rechnungsdokumentenfenster kann ich nicht sicher sein, diesen Preis auch im Rechnungsformular zu sehen. Hängt das denn auch mit diesem Problem hier zusammen? (Siehe http://forum.fakturama.org//read.php?1,4511)

Bei Eingabe eines Einzelpreises im ...

Das ist ein anderes Thema. Ist wahrscheinlich schon gelöst.

Aber nochmals zurück.
Das bedeutet, dass man in Zukunft nicht mehr erst beim Ausdrucken entscheiden kann, ob es eine Netto oder Bruttorechnung geben soll, sondern bereits beim Erstellen der Rechnung diese Entscheidung treffen muss.

Eine als Netto erstelle Rechnung hätte beim Ausdruck als Brutto dann wieder ab und zu die Differenz in der Summe um 1 Cent, falls die Werte ungeschickte Nachkommastellen haben,

Gerd

Hallo Gerd,

für mich persönlich hätte ich damit kein Problem. Ich habe in den Einstellungen-Dokumente bei "Preise in Artikelliste" = netto angekreuzt und habe darauf hin meine gesamte Abwicklung auf "Netto" abgestimmt. Brutto-Rechnungen kommen bei mir in der Praxis eh nicht vor.

Wäre es denn keine Möglichkeit, die Berechnung von den obigen Einstellungen abhängig zu machen? Also wer vornehmlich Bruttorechnungen erstellt, müsste dann Brutto vorwählen und seine Preise auf brutto abgestimmt eintragen, wer Nettorechnungen benötigt trägt Nettopreise ein. Wie gesagt, ich hätte damit für mich kein Problem. Mal sehen, was andere dazu sagen.

Hallo allerseits,
dieses Problem hatte ich bereits vor 20 Jahren, damals noch mit dem guten alten Basic. Wenn ich mich recht entsinne entstand der Fehler dadurch, das ich 4stellig gerechnet habe. Dadurch kommt es zu Rundungsproblemen in der Summe. Ich hatte im Programm schon bei der Berechnung auf 2 Stellen gekürzt. Danach liefen die Berechnungen ohne Probleme.

Hallo,

vielleicht auch noch ein Vorschlag:
Ich bin bei meiner Software dazu übergegangen mit Cent Beträgen in Integer Variablen zu rechnen.
Wenn ein Rechenvorgang auftritt wird dieser in einer Real Variable gemacht und dann gerundet. Die Routine für das Runden habe ich selbst geschrieben, da Lazerus (freier Delphi Klon) nur das "kaufmännische Runden" unterstützt :

Function Runden(za : Double) : Int64;
begin
If (Trunc(za*10000) mod 10000)>4998 then
Result:=Trunc(za)+1
Else
Result:=Trunc(za);
end;

Ich arbeite mit Int64 Integern, die haben einen Wertebereich von:
Int64 -9223372036854775808 .. 9223372036854775807

Das sollte vorerst reichen.
Wenn der Wertebereich nicht mehr reichen sollte, weil ich zuviel Umsatz mache, dann - glaube ich - lass ich programieren 🙂

Bei Java kann ich leider nicht weiterhelfen, davon habe ich keine Ahnung.

Gruß

Stephan

Hallo zusammen,
es gibt für Java inzwischen einen JSR 354, der sich genau dieses Themas annimmt (Money & Currency). Dieser JSR ist schon im Release Candidate-Stadium und ich plane, das auch einzusetzen. Hat den Vorteil, daß es erstens bald zum JRE gehört (also dem, was auch sowieso installiert wird) und andererseits erspare ich mir damit eine Menge Test- und Entwicklungsaufwand. Bis dahin denke ich noch mit dem Problem hier leben zu können, zumal Gerd das ja schon behoben hat.

Viele Grüße,
Ralf.

Es ist so, dass hier mehrere Dinge zusammen kommen. Und in Stephan's Beispiel sind fast alle dabei.

1.)
Fakturama benutzt "Double", um Preise zu speichern. Gleitkommazahlen werden am PC üblich im 2er Komplement gespeichert. 0.5 ist 1/2 und 0.25 ist 1/4. beides ist sehr gut darstellbar. 0.2 ist jedoch 1/5 und das kann nicht abgespeichert werden, also wird die nächst genauere Zahl verwendet. Deshalb kann es sein, dass 2.6 - 0.2 plötzlich 2.39999999999999999999 ergeben.

Wäre nicht tragisch. Aber 2.7-0.2 kann 2.4999999999999 sein. Und das wird dann nicht mehr auf, sondern abgerundet, denn die Grenze zum Runden liegt bei 2.5.

Um diese Fehler zu vermeiden wurde eine kleine Korrekturwert von 0.001 eingeführt, der daraus 2.501 macht.
Diese Korrekturwert wurde seit einer der letzten Versionen an einer Stelle im Programm nicht mehr hinzugefügt. Das ist korrigiert.

2.)
Wie muss man diesen Korrekturwert aus 1.) Wählen ? Groß genug, um einen Wert von 2.49999999999999 auf 2.5 anzuheben. Klein genug, um einen echten Wert von 2.499 nicht fälschlicherweise aufzurunden. Und genau das ist aber in einem Beispiel von Stephan der Fall gewesen. 0.001 ist also noch etwas zu hoch gewesen, denn es gibt Kombinationen aus typischen Rabattwerten und Preisen, die genau dazu führt. Der Wert wurde um einige 10er Potenzten verkleinert. Bei diesem Wert sollte es keine Möglichkeit mehr geben. (Es sei denn, man wählt Rabatte von 2.00000000001% oder ähnliche Scherze.

3.)
Werden die Zwischensummen nicht gerundet, sondern nur die gerundeten Werte dargestellt, so gibt es Fälle, wo die Summe der Zwischenwerte sich um 1Cent von der Summe der ungerundeten Werten unterscheidet. Das ist kein Java oder Fakturama-Problem, sondern Mathematik. Wenn man das verhinden will, muss man sich zuerst festlegen, ob die Summen so gerundet werden sollen, dass es für ein Dokument mit Nettowerten passt, oder so, dass es für eins mit Bruttowerten passt. Es gehrt nicht immer bei beiden.
Das wurde jetzt neu eingeführt und wird in der nächsten Version zur Verfügung stehen.

4.)
Das Runden der MwSt bei einzelnen Positionen.
Angenommen ein 7 Cent Artikel.
20 Stück zu 1,40 Euro werden verkauft. Darauf sind 27Cent (26,6Cent) MwSt.

Jetzt werden 20 einzelne und in jeweils einer andere Farbe verkauft.
7 Cent Artikel + 1Cent MwSt (1,33Cent)
Wären dann am Ende 20 Cent Steuer. (und keine 27Cent).

Fakturama geht jetzt folgenden Weg:
Die ersten 1,33 Cent werden abgerundet. Die 0,33 werden aber nicht verworfen, sondern werden "gemerkt".
Beim nächsten Runden werden die mit berücksichtigt und führen dazu, dass ein Wert von 1,4 Cent aufgerundet wird.
Dadurch geht nichts verloren, und am Ende stimmt die MwSt.
Allerdings kann es sein (um beim obigen 7Cent Artikel zu bleiben) dass dann bei einigen 7 Cent Artikel 2Cent MwSt berechnet werden. Aber am Ende stimmts.

Also 1) und 2) wurde korrigiert. 3) wurde erweitert und 4) ist schon seit 1.0 umgesetzt.

Gerd

Hallo an alle!

Ich hab Fakturama auch seit gestern im Einsatz! Finde es ist ein sehr gelungenes Programm und Hut ab für die Entwickler!

ABER Das Rundungsproblem ist leider immer noch vorhanden!
Aufgefallen ist es mir bei den Ausgangsbelegen.
Als Beispiel:

Produkt = netto10,08€
MwSt. = 19 %
Produkt = brutto 11,99€ (soweit stimmt noch alles!!!)
ABER
Gesamtbetrag = 12,00€ (hier wird aufgerundet um einen Cent!?)

Es wäre schön wenn es da in kürze ein Update dazu geben würde, da die Daten einfach stimmen MÜSSEN!

Wenn ich als netto Preis 10,078€ eingebe wird korrekt gerechnet!

Danke schonmal!

Hi

Toll. Drei Kritikpunkte:

- aktuelle .deb 64-Bit lässt sich nicht installieren, da fehlerhaft gebaut*
- aktuelle Version (.sh) schmiert mit Eclipse-Fehlern ab**
- aktuelle Version hat immer noch einen Rundungsfehler ?

Das ist für ein Programm in dem Bereich ein absolutes No-Go. Programmiere: Sechs. Setzen. Zum Glück (für den Verursacher) ist es Open-Source - sonst würde es echt eng werden mit der Haftung. Ärgerlich ist das alles trotzdem. Und nicht gerade Werbung für Open-Source.

* auch nach über vier Tagen noch nicht gefixt *facepalm*
** soll einen Fix geben - offziell habe ich nichts gefunden.

Es gibt auch Alternativen, es zwingt Dich ja keiner, das einzusetzen. Der Entwickler (ja, es gibt nur einen!) geht hauptberuflich einem Job nach, der recht anstrengend ist. Das Installationsfile wird von einem professionellem Programm gebaut. Das werde ich nochmal checken. Der Rundungsfehler sollte mit den entsprechenden Einstellungen klappen.

@Ralf

mach es aber trotzdem weiter.

Danke.

Marek

Mach ich auch. Ich lern ziemlich viel dabei... 🙂

Kann mal bitte jemand das neue 64bit-Debian-Paket checken? Die .sh-Version hab ich selber getestet (auf einem Mageia-System), die lief durch. Was kommt denn da konkret für Fehler?

Hallo Ralf,

die aktuelle .deb liesse sich zwar installieren, allerdings ist die Angabe von "Architecture: all" den Paketen vorbehalten, die tatsächlich auf allen Architekturen funktionieren würden, also Grafiken, Konfigdateien oder Binärdateien in eigenem Format etc. Bei Programmen muss die korrekte Architektur angegeben werden, sonst lassen sie sich zwar überall installieren, funktionieren dann aber nicht. Gib bitte "amd64" an, dann sollte es passen. Für die 32bit Version dann entsprechend "i386" angeben.

Mein 1.6.7 habe ich übrigens aus dem ersten verlinkten 64bit .deb herauskopiert. Einfach über die bestehende Installation drüber und alles funktioniert tadellos!

3xhossa schrieb:
-------------------------------------------------------

> Mein 1.6.7 habe ich übrigens aus dem ersten
> verlinkten 64bit .deb herauskopiert. Einfach über
> die bestehende Installation drüber und alles
> funktioniert tadellos!

Meinst Du den Fakturama_Linux_64Bit_1_6_7.deb auspacken und manuell ersetzen
Das Program Funktioniert gut und das ist wichtig dabei.
Allerdings es ist eine Notlösung keine richtige Installation und so für den täglichen gebraucht nicht zu empfehlen.

Gruß

Marek