Hallo,

ich teste gerade den Umstieg von Financial LexWare Pro auf OpenERP. Soweit habe ich die Installation unter Unbuntu hinbekommen aber leider komme ich beim Verkaufsauftrag nicht weiter.

Ich habe einen Verkaufsauftrag mit 5 Positionen

241,50
69,00
66,00
20,88
16,52
= 413,94 Netto
+ 19% Umsatzsteuer
= 492,5886 Brutto (gerundet 492,59)

Aber OpenERP rechnet 413,94 + 78,66 Steuer = 492,60 Brutto. Also 0,01 mehr !!!

Für mich sieht es so aus als wenn die Steuer pro Position berechnet wird und dann als Summe ausgegeben wird.

Kann ich das Verhalten ändern oder habe ich einen Denkfehler ?

Gruß

Frank

Hallo Frank,

Sie sollten schon mit den richtigen Summen rechnen.

241,50
69,00
66,00
20,88
16,52
= 413,90 Netto und nicht 413,94(kann man auch im Kopf rechnen)
+ 19% Umsatzsteuer
= 492,541 Brutto (gerundet 492,54)

OpenERP rechnet 413,90 + 78,64 Steuer = 492,54 Brutto. Also keinen Cent mehr.

Gruß

Manfred

_________________
OpenERP 6 RC2 auf Fedora14-Server mit Postgresql 9.0
Clients: Win XP und Linux GNOME Desktop

Hallo Manfred,

leider hat sich ein Tippfehler eingeschlichen: nicht 16,52 sondern 16,56

241,50
69,00
66,00
20,88
16,56
= 413,94 Netto
+ 19% Umsatzsteuer
= 492,5886 Brutto (gerundet 492,59)

Aber OpenERP rechnet 413,94 + 78,66 Steuer = 492,60 Brutto. Also 0,01 mehr !!!

Gruß

Frank

Hallo Frank,

ich habe mal Ihre Zahlen eingegeben.

241,50
69,00
66,00
20,88
16,56
= 413,94 Netto
+ 19% Umsatzsteuer
= 492,5886 Brutto (gerundet 492,59)

OpenERP rechnet 413,94 + 78,6486 (gerundet 78,65) Steuer(19%) = 492,59 Brutto. Also keinen Cent mehr.


Alles OK!!!

Eine Rundung der Summen der Einzelpositionen wäre nicht gut und würde größere Abweichungen bringen.

Gruß

Manfred

_________________
OpenERP 6 RC2 auf Fedora14-Server mit Postgresql 9.0
Clients: Win XP und Linux GNOME Desktop

Hallo Manfred,

genau das gleiche Ergebniss will ich auch! Aber ich bekomme:

Copy aus dem WebClient:
Nettobetrag ? : 413,94 Umsatzsteuer ? : 78,66 Bruttobetrag ? : 492,60 Marge ?

Also genau einen Cent mehr und jeder Kunde würde diese Rechnung zurückweisen. Nur woran kann das liegen? Ich habe die neuste Version und es sieht bei mir so aus als wen OpenERP die Steuer aus den Einzelposten summiert.

Gruß

Frank

Hallo Frank,

ich habe dasselbe mit dem Web-Client probiert.
Diesen Fehler kann ich auch mit viel guten Willen nicht nachvollziehen.
Alles OK!!!

Testinstallation: Verkauf mit Demodaten

Gruß

Manfred

_________________
OpenERP 6 RC2 auf Fedora14-Server mit Postgresql 9.0
Clients: Win XP und Linux GNOME Desktop

Hallo,

leider bin ich mit meinen Problem immer noch nicht weiter gekommen.

Ich habe immer noch das Problem das bei einem Verkaufsauftrag mit fünf Positionen(241,50 / 69 / 66 / 20,88 und 16,56) 1 Cent Umsatzsteuer zu viel berechnet wird. Also bei einem Nettobetrag von 413,94 wird 78,66 anstatt 78,65 Umsatzsteuer berechnet. Wenn ich nur eine Position mit einem Nettobetrag von 413,94 nehme, wird die richtige Umsatzsteuer von 78,65 berechnet. Web- oder GTK Client ist egal.

Mittlerweile kann Manfred (59590) den Fehler auch bestätigen. Er hat eine Datenkopie von mir auf seinem System eingespielt, den falschen Umsatzsteuer-Wert von 78,65 gesehen, berechnen geklickt und bei ihm wird dann die richtige Umsatzsteuer berechnet.

Heute habe ich mir auch mal von openbig.org die neue VM runter geladen und auf zwei unterschiedlichen Systemen und VMWare-Versionen installiert, aber mit dem gleiche falschen Ergebnis!

Was kann ich noch tun?


Gruß

Frank

und vielen Dank an Manfred

Hallo Frank,

ich habe festgestellt, das durch Patchen eigentlich keine Korrekturen in einer bestehenden Datenbank durchgeführt werden. Nachdem ich manuell die Stamm- und Bewegegungsdaten in eine neu erzeugte Datenbank überführt habe waren meine Probleme beseitigt.

MfG

Felix Schubert

------------------------------------
OpenERP V6 - stable auf Ubuntu 10.04 LTS
Clients: WEB-ONLY

Hallo Felix,

ich habe eine komplett frische Version 6.0.1 installiert und den Vertriebsauftrag per Hand neu angelegt. Auch eine die virtuelle Maschine von http://www.openbig.org/open-erp-virtuelle-maschine.html zeigt das gleiche Problem.

Gruß

Frank

Habe hier das gleiche Problem, hat das schon jemand als Bug reported?

Wurde gerade reportet (von einem von euch?)
https://bugs.launchpad.net/openobject-a ... bug/707923

Ich zitier mal aus dem Link, den ich dort gepostet habe:

Es existieren Zwei Methoden zur Berechnung der Mehrwertsteuer:
Die spaltenweise (vertikale) Berechnung und die zeilenweise (horizontale) Berechnung der MwSt, die Lexware büro easy [und OpenERP] verwendet.

Es ergibt sich also je nach Berechnungsmethode eine Rundungsdifferenz von 0,01 EUR.
Beide Verfahren sind zulässig, führen jedoch eventuell zu Rundungsdifferenzen, wenn Beträge mit Nachkommastellen verwendet werden.

Ich habe mir mal anhand dieses Beispiels die Steuerberechnung im Sourcecode(Vorteil Opensource) angesehen
In OpenERP ist es so, dass die Mehrwertsteuern positionsweise berechnet und die gerundeten Werte aufsummiert werden.Dabei können sich natürlich durch die Rundungsdifferenzen höhere Werte ergeben. Richtig wäre die Nettowerte der einzelnen Steuerklassen zu addieren und dann die Steuer auf den Endbetrag zu berechnen. So haben wir es in unseren eigenen Programmen gehalten und sind damit weitgehend ohne Reklamationen geblieben. Es gibt Zahlenkombinationen bei denen Rundungsfehler unvermeidbar sind.

Zusätzlich scheint die Rundungsfunktion von Python nicht die Werte zu liefern, die mathematisch korrekt sind.

Beispiel:
round(45.885,2) ergibt 45.88 richtig wäre 45.89
round(0.885,2) ergibt 0.89 ist korrekt
round(45.886,2) ergibt 45.89 korrekt

Vielleicht weiß da jemand eine Erklärung.

Gruß
Manfred
_________________
OpenERP 6 RC2 auf Fedora14-Server mit Postgresql 9.0
Clients: Win XP und Linux GNOME Desktop

Bezüglich der round() Funktion in Python weisst die Python Funktion explizit darauf hin, das es sich nicht um einen Bug handelt, sondern um eine nicht mögliche Abbildung von Brüchen im Typ float.

Damit werden wir also leben müssen - für weitere Informationen s. die Python Dokumentation http://docs.python.org/tutorial/floatingpoint.html#tut-fp-issues

Was ich nicht nachvollziehen kann ist, warum OpenERP die gerundeten Werte addiert und nicht die vollen Float Werte und nur die Ausgabe gerundet anzeigt.

Gruß
Felix

hallo Felix,

https://bugs.launchpad.net/openobject-a ... bug/707923
bei diesem Bug haben die Fachleute von Openerp auch schon gemerkt, das das Runden bei Zwischenergebnissen nicht der richtige Weg ist.

Es war nur nicht nachvollziehbar warum ich nicht die selben Ergebnisse wie Frank auf meiner Fedorainstallation bekommen habe. Mein Rechner hat scheinbar richtig gerechnet, aber mit falschen Rundungszwischenergebnissen.

Eine Rechnung auf einer Ubuntu 10.10 und Centos 5 Install.
Python 2.6.6 Centos Python 2.4
round(45.885.2) ergibt 46,890000000000001 damit wie auf Franks Rechner +1 Cent
Fedora 14 mit Python 2.7
round(45.885,2) = 45.88

Diese Unterschiede erklärt auch das Python Tutorial nicht

Aber leben müsste man damit trotzdem nicht. Wenn man die zu rundenden Zahlen
mit folgender einfacher Funktion bearbeitet.

def runden(zahl,stellen):
zahl = zahl*10**(stellen+1)
zahl = round(zahl,-1)
zahl = zahl*1/10**(stellen+1)

runden(45.885,2) => 45.89

Gruß
Manfred

Es sollte aber doch hoffentlich eine Lösung geben, die auf alle Maschinen ohne Frickelei funktioniert?
Es handelt sich hier immerhin um eine absolute Grundfunktionalität jeder kaufmännischen Software.