Tücken bei der Mehrwertsteuerberechnung (mit Firebird)

[BlueStarHH]

Hallo,

ich habe eine Tabelle mit einzelnen Postionen von Rechnungen. Dabei ist die Gesamtsumme einer Position als Bruttosumme (also inkl. MwSt, Feldname "BruttoSumme") gespeichert. Das muss so sein, da es Endkundenpreise sind, die auf den Cent genau sein müssen.

Ich möchte nun die Bruttogesamtsumme einer Rechnung ermitteln. Daraus die enthaltene MwSt. und den zugehörigen Nettobetrag. Bisher lief das so:

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)

In SQL für die MwSt:

Code:

cast(
  round(BruttoSumme, 2) - round((round(BruttoSumme, 2) / (MwStSatz / 100 + 1)), 2)
as NUMERIC(18,2)) as Mwst

Entsprechend für Netto:

Code:

cast(
  round((round(BruttoSumme, 2) / (MwStSatz / 100 + 1)), 2)
as NUMERIC(18,2)) as Netto

Ergibt mit meinen Beispieldaten diese Werte:

Code:

MwStSatz:         19,00
Brutto: 150.000.000,00
MwSt:     23.949.579,83
Netto:   126.050.420,17

Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Erklärung:

Zitat:

Die Umsatzsteuer errechnet sich durch Anwendung des jeweiligen Steuersatzes auf die sogenannte Bemessungsgrundlage. Der geleistete Bruttobetrag ist deshalb in die Bemessungsgrundlage und die Umsatzsteuer aufzuteilen. Ist bei der Leistung die Umsatzsteuer im Preis enthalten, etwa im Preis einer Eintrittskarte, muss die Umsatzsteuer aus den Einnahmen herausgerechnet werden. Dies geschieht über einen speziellen „Multiplikator für das Herausrechnen der Umsatzsteuer“. Dieser beträgt bei einem Umsatzsteuersatz von 7 Prozent 6,54... (= 7/107) und bei einem Steuersatz von 19 Prozent 15,97... (= 19/119) Prozent des Bruttoentgelts.

In SQL wäre das mit diesem Multiplikator:

Code:

cast(
  round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2)
as NUMERIC(18,2)) as Mwst,
  
cast(
  round(BruttoSumme, 2) - (round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2))
as NUMERIC(18,2)) as Netto

Wenn ich das aber so mache, fehlen signifikante Stellen (verglichen mit den Zahlen oben):

Code:

MwStSatz:         19,00
Brutto: 150.000.000,00
MwSt:     23.940.000,00
Netto:   126.060.000,00

Was mache ich falsch?
(Die Zahlen müssen so groß sein, um den Effekt zu sehen.)

Ich habe eine fertige Beispieldatenbank angehängt mit der man direkt testen kann. Alternativ die vollständige SQL-Datenbankdefinition der Testdatenbank inkl. Testdaten für mein Beispiel oben.
Das ganze teste ich direkt im IBEXPERT. Hat also nichts mit Problem in Delphi oder der DB-Komponenten zu tun.

Danke!

[peterbelow]

Meiner Meinung nach rundest Du zu oft. Versuch mal

Delphi-Quellcode:

cast(
  round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2)
as NUMERIC(18,2)) as Mwst,
 
cast(
  BruttoSumme - (round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2))
as NUMERIC(18,2)) as Netto

Kann's momentan nicht selbst testen, sorry.

[Olli73]

Geb mal anstatt +100 +100.00 ein.
Ein Ergebnis in firebird ist abhängig von den Nachkommastellen in der Berechnung.

[BlueStarHH]

Zitat:

Zitat von peterbelow (Beitrag 1538459)

Meiner Meinung nach rundest Du zu oft. Versuch mal

Delphi-Quellcode:

cast(
  round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2)
as NUMERIC(18,2)) as Mwst,
 
cast(
  BruttoSumme - (round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2))
as NUMERIC(18,2)) as Netto

Kann's momentan nicht selbst testen, sorry.

Es muss so oft gerundet werden, da sonst mit den falschen Werte gerechnet wird. BruttoSumme (das ist Positionsumme) kann bis zu 4 Nachkommastellen haben. Vor dem weiterrechnen muss die auf 2 Stellen gerundet werden, da die Gesamtsummen der Rechnung 2 Nachkommastellen haben müssen. Wenn ich das Runden zum Testen mal *komplett* entferne, stimmt MwSt aber Netto ist immer noch unverändert falsch. Edit: BruttoSumme ist hier die Summe aller einzelnen Rechnungspositionen. Die Summe wird hier gerundet. Und nicht die einzelnen Rechnungspositionen.

[BlueStarHH]

Zitat:

Zitat von Olli73 (Beitrag 1538460)

Geb mal anstatt +100 +100.00 ein.
Ein Ergebnis in firebird ist abhängig von den Nachkommastellen in der Berechnung.

Hat keine Auswirkungen. Ergebnis ist unverändert falsch.

[Gausi]

Zitat:

Zitat von BlueStarHH (Beitrag 1538458)

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)

[...]

Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Da wird doch in beiden Fällen das gleiche berechnet, wenn man mal von potentiellen Rundungsfehlern wegen Maschinengenauigkeit und Darstellung von Gleitkommazahlen absieht.

Oder ist es im Finanzwesen wie in der Musik, wo ein 2/4-Takt auch was anderes ist als ein 4/8-Takt? Wo liegt der Unterschied in den beiden Berechnungen?

[BlueStarHH]

Zitat:

Zitat von Gausi (Beitrag 1538463)

Zitat:

Zitat von BlueStarHH (Beitrag 1538458)

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)

[...]

Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Da wird doch in beiden Fällen das gleiche berechnet, wenn man mal von potentiellen Rundungsfehlern wegen Maschinengenauigkeit und Darstellung von Gleitkommazahlen absieht.

Oder ist es im Finanzwesen wie in der Musik, wo ein 2/4-Takt auch was anderes ist als ein 4/8-Takt? Wo liegt der Unterschied in den beiden Berechnungen?

Geanu, es geht um die Rundungsfehler. Und es sei vorgeschrieben, dass die zweite Formel benutzt wird. Wenn die Rundungsfehler sich aufsummieren und dann eine Diskussion mit dem FA-Prüfer stattfindet, kann man nur verlieren, wenn man nicht die richtige Formel verwendet. Aber das hier ist ein ganz anderes Thema. Thema ist: Warum fehlen in der zweiten Formel signifikante Stellen?

[Olli73]

Zitat:

Zitat von BlueStarHH (Beitrag 1538462)

Zitat:

Zitat von Olli73 (Beitrag 1538460)

Geb mal anstatt +100 +100.00 ein.
Ein Ergebnis in firebird ist abhängig von den Nachkommastellen in der Berechnung.

Hat keine Auswirkungen. Ergebnis ist unverändert falsch.

Jedenfalls hat es damit zu tun. siehe:

Code:

select
  1/3 as test1,
  1/3.00 as test2,
  1.00/3.00 as test3
from
  rdb$database

ergibt 0 0.33 0.3333

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

Da mir das cast(...) dafür immer zu lang war, habe ich mir mal UDF-Functions gecshrieben, die nichts anderes taten, als diesen cast durchzuführen, aber besser lesbar und kürzer schreibbar waren.

[Delphi.Narium]

Mit dem Kettensatz ergibt sich folgende Rechnung.

? € Mwst = 19%
119% = 150.000.000,00 € Brutto

Mwst := 19 * 150.000.000,00 / 119

Mwst := 23949579,831932773109243697478992

Mwst := Round(23949579,831932773109243697478992,2)

Mwst := 23949579,83

Mit dem Windowsrechner kommt 23.949.579,83 € als Mehrwertsteuer heraus.

Hierbei ist es egal ob 19 * Brutto / 119 gerechnet wird oder Brutto * (19 / 119). Was mathematisch ja durchaus korrekt ist.

Aber mit Firebird sieht das anders aus:

SQL-Code:

select
  Round(150000000.000 * (19.000 / 119.000),2) as A,
  Round(19.000 * 150000000.000 / 119.000,2) as B
from RDB$DATABASE;

Hier sind die Werte für A = 23949450,000000000 und für B = 23949579,829999998.
Das entspricht einem Fehler von 129,829999998 €.

Ein zweiter Versuch:

SQL-Code:

select 
Round(150000000.00 * (19.00 / 119.00),2) as a,
Round(19.00 * 150000000.00 / 119.00,2) as b
from RDB$DATABASE;

Hier sind die Werte für A = 23940000,000000 und für B = 23949579,830000.
Das entspricht einem Fehler von 9579,83 €.

Ein dritter Versuch:

SQL-Code:

select 
Round(150000000.00 * (19 / 119),2) as a,
Round(19 * 150000000.00 / 119,2) as b
from RDB$DATABASE;

Hier sind die Werte für A = 0,00 und für B = 23949579,83.
Das entspricht einem Fehler von 23949579,83 €.

Ein vierter Versuch:

SQL-Code:

select 
Round(150000000.00 * 19 / 119,2) as a,
Round(19 * 150000000.00 / 119,2) as b
from RDB$DATABASE;

Hier sind die Werte für A = 23949579,83 und für B = 23949579,83.
Das entspricht einem Fehler von 0,00 €.

Es sind hier mehrere "Besonderheiten" zu beobachten.

Die Reihenfolge der Berechnungen hat wesentliche Auswirkungen auf das Rechenergebnis.
Die Anzahl der Nachkommastellen der Eingabewerte hat wesentliche Auswirkungen auf das Rechenergebnis.
Die Klammersetzung hat wesentliche Auswirkungen auf das Rechenergebnis.

FireBird scheint zwar die Reihenfolge bei der Berechnung (zuerst die Klammerausdrücke) zu beachten, dabei aber bei einer Division von Werten ohne Nachkommastellen auch ein Ergebnis ohne Nachkommastellen zu liefern. Integer / Integer = Integer. Deshalb ergibt Fließkomma * Integer / Integer etwas anderes als Fließkomma * (Integer / Integer).

150.000.000,00 * (19 / 119) ergibt bei FireBird 150.000.000,00 * 0 und nicht 150.000.000,00 * 0,15966386554621848739495798319328.

Die Rechenergebnisse von FireBird sind abhängig von der Anzahl bzw. dem Vorhandensein der Nachkommastellen der Eingabewerten.

Mein Fazit: Rechnen mit FireBird sollte man eher unterlassen oder es muss sehr genau auf die Eigenheiten von FireBird bei der Auswertung der Datentypen und der Klammersetzung geachtet werden.

[arnof]

gerundet werden nur die Endsummen und nicht einzelne Artikel

Summe von allem:

bei Preisen ohne MwSt

Netto=Round(Netto,2)
brutto=Round(Netto*1.19,2)

MwSt=Brutto-Netto


bei Preisen incl. MwSt

brutto=Round(Brutto,2)
Netto=Round(Brutto/1.19,2)

MwSt=Brutto-Netto

[BlueStarHH]

Zitat:

Zitat von Olli73 (Beitrag 1538466)

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.

[BlueStarHH]

Zitat:

Zitat von arnof (Beitrag 1538468)

gerundet werden nur die Endsummen und nicht einzelne Artikel

Ja, das mache ich auch nur.

Zitat:

Zitat von arnof (Beitrag 1538468)

bei Preisen incl. MwSt

brutto=Round(Brutto,2)
Netto=Round(Brutto/1.19,2)

MwSt=Brutto-Netto

Genau die Formel ist falsch (nicht bezogen auf die Rundung) sagt mein StB und mehere Quellen. Ich hänge die mal an. Hast Du Quellen für Deine Formel?

Es muss ein "Multiplikator für das Herausrechnen der Umsatzsteuer" benutzt werden.

[Sherlock]

Brutto zu Netto = Brutto / 1,19
Netto zu Brutto = Netto * 1,19

Quelle und darin Herleitung sowie weiterführende Quellen und Referenzen: https://www.blitzrechner.de/mehrwert...rechnen/#falle

[BlueStarHH]

Zitat:

Zitat von Sherlock (Beitrag 1538472)

Brutto zu Netto = Brutto / 1,19
Netto zu Brutto = Netto * 1,19

Quelle und darin Herleitung sowie weiterführende Quellen und Referenzen: https://www.blitzrechner.de/mehrwert...rechnen/#falle

Glaubst Du blitzrechner.de oder eher den "Finanzämtern Baden-Württemberg":
https://finanzamt-bw.fv-bwl.de/,Lde/...uer+berechnet_
und meine andere Quelle (siehe PDF oben, ein Wirtschaftsprüfer)

Diskussion mit dem Prüfer vom Finanzamt: "Ja, aber auf blitzrechner.de stand, dass ich das so machen soll/kann."

Die Artikel von blitzrechner.de und co. werden in der Regel von Copywritern verfasst, die gut im Marketing sind und Texte über alles mögliche schreiben.

[t2000]

Die Rechnerei ist doch alles kompletter Blödsinn.
Solange man "richtig" rechnet, sind beide Verfahren identisch. (* 0,15966... zu /1,19*0,19)
Wenn aber zwischendurch gerundet wird, ist es immer unterschiedlich.
Das bedeutet, wenn mit 0,1597 gerechnet wird ist das natürlich ganz anders als bei 0,1596638...

In den "hier geposteten" Texten steht 15,97 (= 19/119). Das ist ja nicht ganz in Ordnung. Soll man mit 15,97 rechnen oder mit 19/119 ??
Im zweiten Fall sind alle Ergebniss gleich als wenn man geteilt durch 1,19 rechnen würde.

Ich hatte schon Fälle, da haben die Prüfer auf Endsummen in Rechnungen geschaut und damit gerechnet. Im Fall von 15,97 bei den Einzelpositionen hätte das vermutlich mächtig Ärger gegeben.

[BlueStarHH]

Zitat:

Zitat von t2000 (Beitrag 1538476)

Die Rechnerei ist doch alles kompletter Blödsinn.
Solange man "richtig" rechnet, sind beide Verfahren identisch. (* 0,15966... zu /1,19*0,19)

Nein, sind sie eben nicht. Ich habe beides über tausende reale Rechnungen laufen lassen und es gibt Unterschiede von +/-1 Cent. Das summiert sich auf.

Auch mein Steuerberater sagt, rechne mit dem Multiplikator, wie es in dem Dokument vom den "Finanzämtern Baden-Württemberg" steht. Fragt doch mal euren Steuerberater, was der dazu sagt. Ich denke wir als Softwareentwicker können und sollten das nicht entscheiden, welche Formel verwendet werden solle. Die Frage hier ist ja, warum kommt mit einer von zwei Formeln das falsche Ergebnis raus.

[Delphi.Narium]

Das Problem liegt nicht in den Rechenverfahren sondern in der Datenbank bzw. in FireBird:

SQL-Code:

select
  RENR,
  MWSTSATZ,
  cast(round(BruttoSumme, 2) as NUMERIC(18,2)) as Brutto,
  (MwStSatz / (MwStSatz + 100)) as mwst_1,
  round((MwStSatz / (MwStSatz + 100)),2) as mwst_2,
  BruttoSumme * (MwStSatz / (MwStSatz + 100)) as mwst_3,
  BruttoSumme * MwStSatz / (MwStSatz + 100) as mwst_4,
  round(BruttoSumme * MwStSatz / (MwStSatz + 100),2) as mwst_5,
  cast(round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2) as NUMERIC(18,2)) as Mwst,
  cast(round(round(BruttoSumme, 2) * MwStSatz / (MwStSatz + 100), 2) as NUMERIC(18,2)) as Mwst_Cast,  
  cast(round(BruttoSumme, 2) - (round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2)) as NUMERIC(18,2)) as Netto
from
(
  select
    RENR,
    MwStSatz,
    sum(BruttoSumme) as BruttoSumme
  from RePos
  group by RENR, MwStSatz
)
;

Habe mal eine der Views "erweitert" und dann die Ergebnisse verglichen.

Mathematisch sind

SQL-Code:

  cast(round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2) as NUMERIC(18,2)) as Mwst,

und

SQL-Code:

  cast(round(round(BruttoSumme, 2) * MwStSatz / (MwStSatz + 100), 2) as NUMERIC(18,2)) as Mwst_Cast,

identisch.

Die Klammerung von

SQL-Code:

(MwStSatz / (MwStSatz + 100))

ist nicht zwingend erforderlich, es würde auch

SQL-Code:

MwStSatz / (MwStSatz + 100)

ausreichen.

Das Problem dabei ist: FireBird liefert mit bzw. ohne diese Klammern unterschiedliche Ergebnisse.

Bei FireBird ist

Delphi-Quellcode:

BruttoSumme * (MwStSatz / (MwStSatz + 100))

was anderes als

Delphi-Quellcode:

BruttoSumme * MwStSatz / (MwStSatz + 100)

.

Aus für mich nicht nachvollziehbaren Gründen ist der Ergebnis der Berechnung

Delphi-Quellcode:

BruttoSumme * (MwStSatz / (MwStSatz + 100))

bei FireBird falsch.

[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:

Zitat von BlueStarHH (Beitrag 1538469)

Zitat:

Zitat von Olli73 (Beitrag 1538466)

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

Delphi-Quellcode:

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:

Zitat von Delphi.Narium (Beitrag 1538484)

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:

Zitat von Sherlock (Beitrag 1538492)

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:

Zitat von Sherlock (Beitrag 1538496)

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.

[gubbe]

Zitat:

Zitat von BlueStarHH (Beitrag 1538475)

Glaubst Du blitzrechner.de oder eher den "Finanzämtern Baden-Württemberg":
https://finanzamt-bw.fv-bwl.de/,Lde/...uer+berechnet_
und meine andere Quelle (siehe PDF oben, ein Wirtschaftsprüfer)

Diskussion mit dem Prüfer vom Finanzamt: "Ja, aber auf blitzrechner.de stand, dass ich das so machen soll/kann."

Die Artikel von blitzrechner.de und co. werden in der Regel von Copywritern verfasst, die gut im Marketing sind und Texte über alles mögliche schreiben.

Da musste ich jetzt echt lachen. :lol:

Finanzämtern und Steuerberatern glaube ich gar nichts, sondern rechne lieber selbst nach.
Und warum sollte ich jemandem glauben, der mit einem gerundeten Faktor rechnet?

Zitiert aus Deinem zweiten Dokument:

Zitat:

Beispiel für die Berechnung der Bemessungsgrundlage
Ein kleines Beispiel soll dies erläutern:
Einnahmen eines Vereins aus einer kulturellen Veranstaltung: 7.850,00 Euro (Bruttobetrag)
Umsatzsteuer (ermäßigter Umsatzsteuersatz) über Multiplikator, hier 6,54% (7.850 Euro x 6,54%) = 513,39 Euro
Nettoentgelt (Bemessungsgrundlage) = 7.850 - 513,39 = 7.336,61 Euro

7/107 ergeben gerundet (!) 6,54%. Mit diesem Faktor macht man es erst richtig falsch.
Zurückgerechnet 7.336,61 + 7% MwSt. = 7.850,17
Ohje, 17 Cent Unterschied. :(

Also das taugt wohl kaum als Begründung, warum die Berechnung mit der "Multiplikation" besser ist.

Brutto - (Brutto/1,19) und Brutto * 19/119 sind äquivalent, kannst Du ineinander umrechnen, schöne Übung, wenn die Mathekenntnisse schon länger her sind :)
Letzteres ist nur etwas einfacher zu rechnen, z.B. mit dem Taschenrechner, weil man den Bruttobetrag nur einmal eingeben muss.

Zitat:

Ich denke wir als Softwareentwicker können und sollten das nicht entscheiden, welche Formel verwendet werden solle.

Gerade wir sollten das entscheiden oder was hat uns ein Steuerberater mit seinem Halbwissen hier voraus?
Und auch wenn es mathematisch keinen Unterschied macht, kann es bei der konkreten Umsetzung bei der Softwareentwicklung durchaus Unterschiede geben, wie man auch an der Berechnung in der Datenbank gesehen hat.

[gubbe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1538482)

Die Klammerung von

SQL-Code:

(MwStSatz / (MwStSatz + 100))

ist nicht zwingend erforderlich, es würde auch

SQL-Code:

MwStSatz / (MwStSatz + 100)

ausreichen.

Das Problem dabei ist: FireBird liefert mit bzw. ohne diese Klammern unterschiedliche Ergebnisse.

Bei FireBird ist

Delphi-Quellcode:

BruttoSumme * (MwStSatz / (MwStSatz + 100))

was anderes als

Delphi-Quellcode:

BruttoSumme * MwStSatz / (MwStSatz + 100)

.

Aus für mich nicht nachvollziehbaren Gründen ist der Ergebnis der Berechnung

Delphi-Quellcode:

BruttoSumme * (MwStSatz / (MwStSatz + 100))

bei FireBird falsch.

Rein intuitiv hätte ich auch die Klammern weggelassen. Wenn ich erst dividiere rechne ich mit einem möglicherweise ungenauen Wert weiter, denn ich verliere Nachkommastellen je nach Datentyp. Die brauche ich aber bei den hohen Werten im Beispiel.
Multipliziere ich erst mit 19 und Teile dann durch 119, habe ich wenigstens im ersten Schritt einen genauen Werte und das zweite Ergebnis runde ich dann sowieso.

Also das ist letztlich genau das gleiche Problem wie in dem Beispiel des Steuerberaters, der mit einem gerundeten Faktor ungenau rechnet. Nur eben mit ein paar Nachkommastellen mehr.

[jaenicke]

Wenn man die Berechnung in Delphi mit definierten Datentypen und Rundungen an den korrekten Stellen durchführt, hat man das Problem nicht. Dann ist es auch egal, wie die verwendete Datenbank rechnet. Und da kommt dann auch das gleiche raus, egal auf welchem Weg man die genannte Berechnung durchführt.

[gubbe]

Zitat:

Zitat von jaenicke (Beitrag 1538526)

Wenn man die Berechnung in Delphi mit definierten Datentypen und Rundungen an den korrekten Stellen durchführt, hat man das Problem nicht. Dann ist es auch egal, wie die verwendete Datenbank rechnet. Und da kommt dann auch das gleiche raus, egal auf welchem Weg man die genannte Berechnung durchführt.

Ja, wenn man in Delphi mit Datentyp Double rechnet, gibt es keinen Unterschied, egal welche Formel man verwendet oder wie man klammert. Bei anderen Datentypen wie Single würde es auch Abweichungen geben.
Nur verwenden Datenbanken für die Berechnung gemäß SQL-Standard Numeric bzw. Decimal und es gibt Regeln für die Zahl der signifikanten Nachkommastellen. Das heisst nicht, dass Firebird nicht rechnen kann, sondern man muss die Regeln beachten wie auch bei anderen Datenbanken.

Bei der Division unterscheiden sich Datenbanken in der Zahl der Nachkommastellen, aber man kann es auch in MySQL nachvollziehen:

Code:

select 150000000-150000000/1.19, 150000000 * 19 / 119, 150000000 * (19 / 119);

Ergibt (zum Vergleich untereinander geschrieben)

23949579.8319
23949579.8319
23949579.7500

Der dritte Wert ist ungenauer. Es kommt also auch hier nicht auf die Formel an, sondern auf die richtige Klammersetzung. Oder man fordert mehr Präzision und gibt Nachkommastellen vor (19.00 / 119.00)

[raller09]

https://stackoverflow.com/questions/...-when-dividing

[IBExpert]

um zu verstehen, was firebird da macht, führ mal zB in ibexpert so was aus

insert into x
select
150000000.000 * 19.000 / 119.000 as A,
19.000 * 150000000.000 / 119.000 as B
from RDB$DATABASE;

auf basis von deinem select und den resultierenden Datentypen wird die tabelle
von ibexpert dynamisch erstellt

um 3 zahlen miteinander zu multiplizieren/dividiren, die jeweils 3 Nachkommastellen haben und
so wie im sql geschrieben wurde, werden zB als numeric(18,3) von firebird
interpretiert. Das resultierende Datenfeld wird also als numeric(18,9) erzeugt.

Gedankenexperiment:

wenn man nun ein mal
0.001*0.001*0.001
miteinander verlustfrei multiplizieren will, dann musst du im result
ein numeric(18,9) ermöglichen, sonst hast du ungeplant schon rundungsfehler.

Das vermeidet Firebird durch die gewählten Datentypen.

in der Tabelle x die da oben erstellt wird, sind die ergebnisfelder auch genau
dieser Datentyp, das wilde zwischendurch mal casten und rounden macht das Ergebnis
nicht besser, sondern führt ebenen ein, an denen die Abweichungen entstehen, die
hier bemängelt werden.

Und nun mal als Hinweis wo das Problem ist (bei dir an der Tastatur)

multipliziere folgende Zahlen

select
10000000000.00001*0.00001*0.00001
from RDB$DATABASE;

diese Rechnung erfordert damit nix weggerundet wird 15 nachkommastellen, ein insert
into wie oben würde dafür einen numeric(18,15) erzeugen, blöderweise sind dafür dann
aber von den 18 Stellen nur noch 3 vor dem Komma möglich, d.h. den Wert 1000 wirst
du darin schon nicht mehr speichern können.

hier ein Beispiel bei dem es knallt:

select
999900000.00111*0.11111*0.0111
from RDB$DATABASE;

Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
Integer overflow. The result of an integer operation caused the most significant bit of the result to carry.
-------------------------------------------------------------------------------------------------------------------
SQLCODE: -901
SQLSTATE: 22003
GDSCODE: 335544779

da ist keine zahl dabei, die die üblichen datentypen sprengt, aber das zwischenergebnis
kann nicht mit relevanter genauigkeit erstellt werden. Und vom dialekt 1 und dessen
gruseligkeiten reden wir da gar nicht erst, alle beispiele oben basieren auf dialekt 3.
Das Problem entsteht durch durch mehrfachoperation pro Zeile

Welche workarounds gibt es:

-Wenn das wirklich ein Problem ist, das du lösen musst, dann steig um auf fb>=4
dort gibt es numeric bis 34 statt 18, damit kommen aber nicht alle client libs
und komponenten klar

-wenn in deinem Zahlenraum >=zweistellige millionenbeträge gebraucht werden, sind für
Währungen meistens 2 Nachkommastellen ausreichend, also numeric(18,2). was dann für
Steuersätze erforderlich ist, ergibt sich durch das umfeld. Umrechnungsfaktoren
können aber auch noch ganz andere Ebenen sein, alte säcke wissen noch was mit der Zahl
1,95583 verbunden war.

-kombiniere im sql die werte immer mit nur einem operator oder nutze ab fb3 eigene
stored functions für eine sauberere berechnung, der du die werte übergibst
und die dann diese zeilenweise selber über geeignete Variablen mit ausreichender
Genauigkeit das ergebnis korrekt berechnet. SQL selber kann zwar auch direkt im
Befehl für Rechenoperationen benutzt werden, hat aber wie oben geschildert Grenzen,
die du berücksichtigen musst.

-Alternativ steht dir auch double precision in firebird als Datentyp zur verfügung, der
resultiert aber kaufmännisch betracht in anderen problemen. Eine torte für 10 € gesamtpreis
aufgeteilt in 3 stück zu je 10€/3 preislich festgelegt zeigt dann aufgrund der Endlichkeit
auf dem Preisschild 3,33€ als Stückpreis an, wenn jemand dann davon aber 3 stück kauft,
könnte es den Kunden wundern, warum deine Kasse 10€ auswirft und nicht wie im Kopf ausgrechnet
9,99€.Technisch kann nämlich im Double 3 1/3 stehen, auch wenn das im Front end nicht
komplett dargestellt wird, sind da auch unsichtbare teile in den Nachkommastellen
relevant).

-alternativ kannst du auch alle zahlen die währungsbeträge
darstellen, zB dann als int128 darstellen und damit zb jeden Betrag in ct
verwalten, auch da sollte wenig verloren gehen, ein 128 bit integer hat
ausreichend stellen (für seriennummern aller Atome in einem menschlichen
Körper würde in etwa ein int78 ausreichen, da ist also luft nach oben
selbst für so eine wenig hilfreiche seriennummernerfassung, soll aber
nur ein vorstellung geben, über welche datentypen man da redet).

numeric >=10 <=18 wird intern von fb dialekt 3 immer als int64 benutzt
numeric >=5 <=9 wird intern von fb dialekt 3 immer als int32 benutzt
numeric <=4 wird intern von fb dialekt 3 immer als int16 benutzt
das war auch schon in fb2.x so

Zusammenfassung: Firebird rechnet nichts falsch, sondern das was man dort als SQL
und basisdatentyp bzw Werte vorgibt. Und Ja, auch die reihenfolge ist wichtig, weil
auch firebird mit den verfügbaren Datentypen intern klar kommen muss, insbesondere
wenn selber noch zwischendurch castings und rundungen gemacht werden.

Wenn die Ergebnisse nicht das sind was du erwartest, musst du den Weg zum Ergebnis
anpassen. Ob dann execute block die werte mit passenden Variablen sauber zusammenstellt
oder sp oder trigger zwischenwerte ermitteln ist relativ egal, wild verschaltelte sum/cast/round
etc. sind dann aber selten eine gute strategie. Eigene Funktionen als Stored functions
bieten einen sehr zuverlässigen weg.

Für fast alle normalen Zahlenwerte ist die sql multiplikation aber einwandfrei implementiert.

Der Titel von dem Thread ist aus meiner sicht irreführend

[Redeemer]

Zitat:

Zitat von BlueStarHH (Beitrag 1538458)

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)
[...]
Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Du machst hier ein Fass auf, weil zwei Leute dir exakt dasselbe gesagt haben und du jetzt eine Änderung machen willst, bei der du nichts änderst. Laut mir, immerhin mit Master in Mathematik, ist das alles exakt dasselbe. Da braucht man keinen Master in Mathe für, es reicht locker Mathe 8. Klasse (unfassbar, dass viele daran scheitern):
MwSt = Brutto - (Brutto / 1,19)
Das erste Brutto in die Klammer ziehen:
MwSt = (Brutto * 1,19 - Brutto) / 1,19
1,19 in zwei Summanden auflösen:
MwSt = (Brutto * (1 + 0,19) - Brutto) / 1,19
Binomische Formel:
MwSt = (Brutto * 1 + Brutto * 0,19 - Brutto) / 1,19
0 entfernen:
MwSt = Brutto * 0,19 / 1,19
Mit 100 erweitern (komplett sinnfrei):
MwSt = Brutto * 19 / 119
Klammer setzen (komplett sinnfrei):
MwSt = Brutto * (19 / 119)

[gubbe]

Nicht vorsagen :)

Aber warum so umständlich?

Brutto - Brutto/1,19 // ausklammern
= Brutto * (1 - 1/1,19) // Brüche erweitern
= Brutto * (119/119-100/119) // Brüche subtrahieren
= Brutto * 19/119

[BlueStarHH]

Zitat:

Zitat von Redeemer (Beitrag 1538602)

Du machst hier ein Fass auf, weil zwei Leute dir exakt dasselbe gesagt haben und du jetzt eine Änderung machen willst, bei der du nichts änderst. Laut mir, immerhin mit Master in Mathematik, ist das alles exakt dasselbe.

Ich glaube Dir ja und den anderen. Danke nochmal an alle. Mein Steuerberater hat mich da einfach verunsichert und ganz kirre gemacht. Er ist sogar wütend geworden, als ich angefangen habe seine Aussagen zu hinterfragen. Dann hab ich's gelassen. Ich werde ihm diesen Thread mal ausdrucken oder mailen.

[arnof]

Zitat:

Zitat von BlueStarHH (Beitrag 1538470)

Zitat:

Zitat von arnof (Beitrag 1538468)

gerundet werden nur die Endsummen und nicht einzelne Artikel

Ja, das mache ich auch nur.

Zitat:

Zitat von arnof (Beitrag 1538468)

bei Preisen incl. MwSt

brutto=Round(Brutto,2)
Netto=Round(Brutto/1.19,2)

MwSt=Brutto-Netto

Genau die Formel ist falsch (nicht bezogen auf die Rundung) sagt mein StB und mehere Quellen. Ich hänge die mal an. Hast Du Quellen für Deine Formel?

Es muss ein "Multiplikator für das Herausrechnen der Umsatzsteuer" benutzt werden.

Meine Quellen sind 35 Jahre Erfahrung, es gibt namhafte Hersteller die sind schon an der mwst Berechnung kläglich gescheitert.

Das Runden ist entscheidend, schaue, das deine Datentypen nicht „Von alleine“ anfangen zu runden! Der Datentype currency ist nicht dafür geeignet. Der ist max. für Endsummen der richtige Datentype!