Rundungsfehler (eventuell Bug 584?)

[frank@…]

in der SVN-Version vom 19.3.07 (fragt mich nicht welche Release das war -
möglicherweise r2073) gibt es einen Rundungsfehler in den Debitorenbuchungen.
Folgendes Szenario:

• Verkauf->Berichte-Rechnungen->Weiter
• es existiert eine offene Rechnung mit dem Betrag 16,07€
• klick auf Re-Nummer
• nach unten scrollen > Netto: 13,50, Ust 19%: 2,56€, Re-Summe 16,06€
• 16,06€ als Zahlungseingang buchen

-> dann ist in der Bericht "Offene Rechnungen" diese Rechnung immer noch
vorhanden mit der Differenz von 0,01€

leider konnte ich das aufgrund von #668 nicht in einer neueren Version
testen. Ich habe dieses Problem momentan mit mehreren Rechnungen...

Gut, hier gibt es zwei Probleme:

1. Es werden in der Datenbank falsche Werte bei der Rechnungssumme (ap.amount

und ar.amount) eingetragen, die sich nicht mit den im Formular angezeigten
Werten und vermutlich nicht mit dem in acc_trans decken. Das sollte relativ
leicht zu beheben sein.

2. Bereits bestehende Rechnungen müssen überprüft werden. Dazu würde ich

bitten, mal die folgenden SQL-Befehle auszuführen und das Ergebnis hier zu
posten (es werden nur IDs und Summen ausgelesen, keine sensitiven Daten):

---

create table dummy_ar (id integer, invnumber text, ar_amount numeric(15, 5),
acc_trans_amount numeric(15, 5));

insert into dummy_ar (id, invnumber, ar_amount, acc_trans_amount) select ar.id,
ar.invnumber, ar.amount, coalesce((select at.amount from acc_trans at left join
chart c on (at.chart_id = c.id) where (at.trans_id = ar.id) and ((c.link =
'AR') or (c.link like '%:AR') or (c.link like 'AR:%')) order by at.oid asc
limit 1) * -1, 0) from ar;

select * from dummy_ar where ar_amount <> acc_trans_amount;

drop table dummy_ar;

---

Und analog für Eingangsrechnungen:

---

create table dummy_ap (id integer, invnumber text, ap_amount numeric(15, 5),
acc_trans_amount numeric(15, 5));

insert into dummy_ap (id, invnumber, ap_amount, acc_trans_amount) select ap.id,
ap.invnumber, ap.amount, coalesce((select at.amount from acc_trans at left join
chart c on (at.chart_id = c.id) where (at.trans_id = ap.id) and ((c.link =
'AP') or (c.link like '%:AP') or (c.link like 'AP:%')) order by at.oid asc
limit 1), 0) from ap;

select * from dummy_ap where ap_amount <> acc_trans_amount;

drop table dummy_ap;

---

hmm - ich hab die Mail erst heute bekommen - wieso eigentlich?

hier das Ergebnis von der ersten Abfrage (Ausgangsrechnungen):

id invnumber ar_amount acc_trans_amount
20 200400566 17.26000 17.25000

1 Datensätze

bei den Eingangsrechnungen gab es keinen Datensatz - es gibt auch keine
Eingangsrechnungen - bisher

daß die Abfrage für die Ausgangsrechnungen richtig ist, möchte ich aber
vorsichtig anzweifeln, denn wie auf dem Angehängten Bild (Bildschirmfoto13)
gibts da mehrere und nicht nur einen falschen Datensatz

(Mit Bezug zu comment 1)

Gut, hier gibt es zwei Probleme:

1. Es werden in der Datenbank falsche Werte bei der Rechnungssumme (ap.amount

und ar.amount) eingetragen, die sich nicht mit den im Formular angezeigten
Werten und vermutlich nicht mit dem in acc_trans decken. Das sollte relativ
leicht zu beheben sein.

2. Bereits bestehende Rechnungen müssen überprüft werden. Dazu würde ich

bitten, mal die folgenden SQL-Befehle auszuführen und das Ergebnis hier zu
posten (es werden nur IDs und Summen ausgelesen, keine sensitiven Daten):

Hallo Moritz,

Wird hier dran noch/schon gearbeitet??? vielleicht, gehört hier auch mit dazu,
was Udo schon gangefangen hat zu fixen...
​http://www.lx-office.org/forum/board_entry.php?id=2220#p2220

Bei meiner Frau ist es so, daß immer wieder einige Rechnungen nach dem Buchen
nicht abgeschlossen sind, weil die Summen einfach nicht stimmen... mit der
aktuellen unstable betragen die Differenzen bis zu 4 Cent bei Rechnungssummen
von ca. 16€ - das darf einfach nicht sein... bei der stable sieht das aber nicht
anders aus

Nein, hieran arbeitet noch niemand.

Hallo zusammen,
mit der aktuellen unstable kann ich das Verhalten nicht feststellen.
Ferner wurde die entsprechende Zeile (Link zum Foreneintrag) in Revision 3221

r3221 | mbunkus | 2008-06-12 20:17:47 +0200 (Do, 12 Jun 2008) | 1 line

Den Preisfaktor nicht vor dem Runden des Einzelpreises einbeziehen, sonst kommen stark verfaelschte

Ergebnisse heraus. Berechnung von Zeilensumme und Rabatt in io.pl mit OE.pm abgeglichen.

Ich schliess den somit erstmal, bitte nochmal prüfen und ggf. wieder öffnen.

Danke,

Jan