Betrifft: Bugdiskussion

Hallo Felix,

wie man unschwer im Forum erkennen kann besteht die Rundungproblematik schon mindestens 3 Jahre und wird ignoriert. Ich verstehe auch nicht warum sich nicht
mehr darüber beschwert haben. Das Ganze mit irgendwelchen Korrekturbuchungen gerade zu biegen ist doch wohl ein Witz.

Gruß
Manfred

Hallo,

ich führe gerade auch die ersten Testbuchungen durch und habe gerade auch bei den VorSteuer / Umsatzsteuerbuchungen Probleme.
Wenn ich Soll oder Haben als Eingangsrechnung oder Ausgangsrechnung buche ist alles auf den ersten Blick in Ordnung. Die 19% werden richtig berechnet und erscheinen auch auf der Umsatzsteuervoranmeldung.

Wie kann ich denn Kasse/Bank gegen 1576/1571 buchen, so dass es auch mit auf der UStVA erscheint?

Hallo,

ich habe mir mal den Sourcecode angeschaut und die Stelle in der Datei

../addons/sale/sale.py

gefunden:

def _amount_line_tax(self, cr, uid, line, context=None):
val = 0.0
for c in self.pool.get('account.tax').compute_all(cr, uid, line.tax_id, line.price_unit * (1-(line.discount or 0.0)/100.0), line.product_uom_qty, line.order_id.partner_invoice_id.id, line.product_id, line.order_id.partner_id)['taxes']:
val += c.get('amount', 0.0)
return val

Leider kenne ich Phyton überhaupt nicht. Kann eventuell jemand mal posten was wie ändern müssten? Von OpenERP werden wir ja nicht erhört. Nur so kann ich OpenERP nicht einsetzen!

-Frank

Ich habe mich ein bisschen umgeschaut und dazu die folgenden Threads gefunden.

post46147.html

http://www.mail-archive.com/openerp-exp ... 00067.html
http://www.mail-archive.com/openerp-exp ... 00082.html

was sich IMHO daraus lesen lässt ist, dass Openerp in Python in Float rechnet - und zwar mit der im Backend anzugebenen Päzision (zB 2 Nachkommastellen) .. und das aus verschiedenen Gründen die in den Threads genannt werden.
Eventuell ist diese nicht richtig gesetzt -- deswegen die Rundungsfehler.

In der Postgresql Datenbank werden die Beträge dann als Decimal gespeichert.
Für mich scheint als ob diese Anpassung mit v6 erfolgte ..
https://code.launchpad.net/~openerp-com ... price_unit
bin mir aber nicht ganz sicher

(Nachdem ich die Diskussionen gelesen habe denke ich, dass Openerp eine Implementation verwendet die in Ordnung ist -- Ich sehe, dass das Problem nur mit einem Kompromiss gelöst werden kann .. aufgrund von Datentypen Limitierungen ..
Integer*Float=Float / Decimal*Float->Exception, Decimal*Decimal->Decimal aber mit sich verschiebender Präzision -- beschrieben in den Threads weiter oben)