Erstellt vor 5 Jahren

Geschlossen vor 5 Jahren

#1328 closed Fehler (duplicate)

ap.amount und acc_trans.amount sind verschieden

Erstellt von: information@… Verantwortlicher: m.bunkus@…
Priorität: normal Meilenstein:
Komponente: kivitendo ERP Version: 2.6.2 unstable
Schweregrad: normal Stichworte: Einkauf
Beobachter:

Beschreibung

select ap.amount, ac.amount from ap left join acc_trans ac on (ac.trans_id = ap.id) where ac.chart_id=51;

48.19000 | -48.20000

S.a. Screenshots.

Interessant, oder?

Anhänge (2)

rechnungs-details.png (42.5 KB) - hinzugefügt von information@… vor 5 Jahren.
Detailansicht der Rechnung
rechnungsübersicht.png (26.3 KB) - hinzugefügt von information@… vor 5 Jahren.
Übersicht der Rechnung (ap.amount)

Alle Anhänge herunterladen als: .zip

Änderungshistorie (10)

Geändert vor 5 Jahren durch information@…

Detailansicht der Rechnung

Geändert vor 5 Jahren durch information@…

Übersicht der Rechnung (ap.amount)

comment:1 Geändert vor 5 Jahren durch information@…

Die Mehrwertsteuer wird nicht korrekt gerundet: 7.69 statt 7.70

in IR.pm 526

comment:2 Geändert vor 5 Jahren durch information@…

Beim Erfassen von Einkaufsrechnungen wird nicht korrekt kaufmännisch gerundet:

40,50 * 0,19 = 7,965

An welcher Stelle soll man das verbessern?

comment:3 Geändert vor 5 Jahren durch information@…

In Ergänzung zu oben, es wird doch korrekt gerundet, dass Problem besteht beim unterschiedlichen Aufruf.

$form->{amount}{ $form->{id} }{$item} =-7.695;

-7.69 == $form->round_amount($form->{amount}{ $form->{id} }{$item},2));

-7.7 == $form->round_amount(-7.695,2));

An der Stelle steige ich erstmal aus ...

comment:4 Geändert vor 5 Jahren durch information@…

Ok.
Es ist reproduzierbar und kein direkter Rundungsfehler.

Der Fehler tritt in Einkaufsrechnungen, sowie in Verkaufsrechnungen auf.

In Tabelle ap/ar wird der Brutto-Betrag um einen Cent nach unten abweichend gespeichert.

Das Problem gibt es in SAP auch und muss jeweils für den Mandanten je nach Gusto konfiguriert werden:

MWSt-Berechnung Fall A:

Alle Positionen werden netto addiert und danach wird die MWSt berechnet.

(x + y + ... + n) * 1,19 = brutto

MWSt-Berechnung Fall B:

Für jede Position wird die MWSt berechnet und separat addiert:

(x * 1,19) + (y * 1,19) + ... + (n * 1,19) = brutto

Dieses Tatsache verknüpft mit der Frage "Wann wird round_amount ausgeführt?" führt zu folgenden Ergebnis

Unser Beispiel:

Position x = 35,90
Position y = 4,60

In der acc_trans wird gespeichert:
(35,90 + 4,60) * 1,19 = 48,195
nach round_amount = 48,20

In Tabelle ar/ap

(35,90 * 1,19) = 42,721 round_amount 42,72

+ (4,60 * 1,19) = 5,474 round_amount 5,47

48,195 round_amount 48,19

comment:5 Geändert vor 5 Jahren durch information@…

Nach Diskussion mit Moritz gestern, liegt der Fehler darin, dass in io.pl -> display_row der Rundungsfehler für die einzelnen Positionen nicht mitgenommen wird.

Ggf. könnte man die Berechnungsroutine bündeln und mit einem entsprechend Testfall auch entsprechend gesichert freigeben.

comment:6 Geändert vor 5 Jahren durch m.bunkus@…

  • Status von new nach assigned geändert
  • Verantwortlicher von p.reetz@… nach m.bunkus@… geändert

comment:7 Geändert vor 5 Jahren durch m.bunkus@…

  • Schweregrad von Wichtig nach Normal geändert

comment:8 Geändert vor 5 Jahren durch m.bunkus@…

  • Lösung auf duplicate gesetzt
  • Status von assigned nach closed geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.