Tücken bei der Mehrwertsteuerberechnung (mit Firebird)

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

[BlueStarHH]

Zitat von arnof:

gerundet werden nur die Endsummen und nicht einzelne Artikel

Ja, das mache ich auch nur.

Zitat von arnof:

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 von 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

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 von t2000:

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

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

Die Klammerung von (MwStSatz / (MwStSatz + 100)) ist nicht zwingend erforderlich, es würde auch MwStSatz / (MwStSatz + 100) ausreichen.

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

Bei FireBird ist BruttoSumme * (MwStSatz / (MwStSatz + 100)) was anderes als BruttoSumme * MwStSatz / (MwStSatz + 100) .

Aus für mich nicht nachvollziehbaren Gründen ist der Ergebnis der Berechnung 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 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
)
;