Tücken bei der Mehrwertsteuerberechnung (mit Firebird)

[Uwe Raabe]

23.940.000,00/150.000.000,00 ergibt exakt 0,1596. Das ist (19/119) nach 4 Nachkommastellen abgeschnitten. Das kann natürlich kein korrektes Ergebnis liefern.

Zitat von BlueStarHH:

Zitat von Olli73:

Am besten funktioniert noch alle Zahlen in float zu casten und dann zurück in numeric.

Genau das möchte man ja nicht machen, wenn man mit Geld-Beträgen arbeitet. Deswegen ja numeric, damit keine Genauigkeit verlorgen geht, da intern mit Integern gerechnet wird.

Offenbar verwendet FireBird bei den Zwischenergebnissen gerundete oder abgeschnittene Werte. Deswegen ist der Hinweis auf den float-Cast vielleicht doch nicht so abwegig.

Die Formel Brutto*(MWStSatz/(MWStSatz + 100) muss schon ohne Rundung der Zwischenergebnisse durchgeführt werden. Wenn Zwischenergebnisse gerundet werden sollen, dann wird das in der Regel auch so beschrieben. Andernfalls muss man mit der erforderlichen Genauigkeit rechnen, zwar mit den eingegebenen Integer- bzw. Round(x,2)-Werten aber nicht gerundeten Zwischenwerten.

Ich zitiere hier mal aus dem offiziellen Programmablaufplan für die Einkommensteuerberechnung:

Zitat:

Bei der Steuerberechnung werden Gleitkommafelder verwendet.

[Delphi.Narium]

Mit

SQL-Code:

CREATE VIEW RESUMME_C(
    RENR,
    MWSTSATZ,
    BRUTTO,
    MWST,
    NETTO)
AS
select
  RENR,
  MWSTSATZ,
  cast(BruttoSumme as NUMERIC(18,2)) as Brutto,
  cast(BruttoSumme * MwStSatz / (MwStSatz + 100) as NUMERIC(18,2)) as Mwst,
  cast(BruttoSumme - BruttoSumme * MwStSatz / (MwStSatz + 100) as NUMERIC(18,2)) as Netto
from
(
  select
    RENR,
    MwStSatz,
    sum(BruttoSumme) as BruttoSumme
  from RePos
  group by RENR, MwStSatz
)
;

sollten die Ergebnisse korrekt sein.

[BlueStarHH]

Zitat von Delphi.Narium:

Mit

SQL-Code:

CREATE VIEW RESUMME_C(
    RENR,
    MWSTSATZ,
    BRUTTO,
    MWST,
    NETTO)
AS
select
  RENR,
  MWSTSATZ,
  cast(BruttoSumme as NUMERIC(18,2)) as Brutto,
  cast(BruttoSumme * MwStSatz / (MwStSatz + 100) as NUMERIC(18,2)) as Mwst,
  cast(BruttoSumme - BruttoSumme * MwStSatz / (MwStSatz + 100) as NUMERIC(18,2)) as Netto
from
(
  select
    RENR,
    MwStSatz,
    sum(BruttoSumme) as BruttoSumme
  from RePos
  group by RENR, MwStSatz
)
;

sollten die Ergebnisse korrekt sein.

Super, danke! Sieht gut aus. Nur die Rundung auf 2 Stellen fehlt noch. sum(BruttoSumme) unten ist die *Summe* aller Positionssummen. Die Positionssummen haben 4 Nachkommastellen. Also muss sum(BruttoSumme) gerundet werden, weil das die Bruttorechnungssumme ist. Das ist ja der Betrag, der bezahlt wird. Mit der gerundeten Summe werden MwSt. und Netto ausgerechnet.

SQL-Code:

CREATE VIEW RESUMME_C(
    RENR,
    MWSTSATZ,
    BRUTTO,
    MWST,
    NETTO)
AS
select
  RENR,
  MWSTSATZ,
  cast(BruttoSumme as NUMERIC(18,2)) as Brutto,
  cast(BruttoSumme * MwStSatz / (MwStSatz + 100) as NUMERIC(18,2)) as Mwst,
  cast(BruttoSumme - BruttoSumme * MwStSatz / (MwStSatz + 100) as NUMERIC(18,2)) as Netto
from
(
  select
    RENR,
    MwStSatz,
    round(sum(BruttoSumme), 2) as BruttoSumme <--- hier runden
  from RePos
  group by RENR, MwStSatz
)
;

[Sherlock]

Jemand, der mir mit "Nur Multiplikation" kommen möchte ist nicht ernstzunehmen. Egal welches Amt er vorgibt inne zu haben.

[Uwe Raabe]

Zitat von Sherlock:

Jemand, der mir mit "Nur Multiplikation" kommen möchte ist nicht ernstzunehmen.

Die Büro-Rechenmaschinen während meiner Ausbildungszeit konnten tatsächlich nur Multiplizieren. Da musste man solche Faktoren im Kopf haben (oder auf einem kleine Aufkleber an der Maschine) und das Komma im Kopf verschieben.

[Sherlock]

Nun sind wir aber im 21. Jahrhundert. Und auch als es diese Teufelsmaschinen nicht gab, hätte jeder Mathelehrer einem diese Aussage und weitere in diesem Thread um die Ohren gehauen. Mathematisch ist es irrelevant, ob ich a / b oder a * 1/b rechne. Ich finde es aber sinnvoller direkt a / b rechnen zu lassen, statt einen Zwischenschritt zu gehen.
Da es hier aber um die Unzulänglichkeit eines RDBMS geht, bin ich ohnehin raus.

[Olli73]

Ich hatte in der Vergangenheit Mal komplexere Berechnungen mit Firebird und SQL durchgeführt. Da z.B. bei einer Division "a / b" in Firebird die Anzahl der Nachkommastellen des Ergebnisses gleich der Anzahl der Nachkommastellen von "a" plus der von "b" ist (also z.B. 1.00/3.00 = 0.3333), hatte ich zunächst versucht, alles mit möglichst vielen Nachkommastellen zu berechnen, um Rundungsfehler zu vermeiden.

Dadurch bekam ich aber plötzlich Probleme mit großen Zahlen. Dann habe ich halt alles nach float konvertiert und erst am Ende wieder ein Numeric draus gemacht, wie ich bereits oben beschrieben habe. Danach war dann Ruhe.

[Lemmy]

Zitat von Sherlock:

Da es hier aber um die Unzulänglichkeit eines RDBMS geht, bin ich ohnehin raus.

das fordert eine Richtigstellung: Das sind keine Unzulänglichkeiten eines RDBMS sondern die falsche Anwendung von Typen bzw. fehlerhafte Berechnung.

Auch ich habe schon Berechnungen mit Numeric bzw. Ganzzahlen durchgeführt, weil ich das cool fand, dass ich da feste Nachkommastellen habe und war dann ganz schnell geläutert von der Vorstellung, dass hier irgend welche besseren Ergebnisse raus kommen.