Tücken bei der Mehrwertsteuerberechnung (mit Firebird)

[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