Ein super Punkt @DP_Development
Ich habe das nochmal näher angeschaut und meinen Taschenrechner rausgeholt um die MwSt. zu rechnen. In deinem Beispiel aber @PinkybreakShop ergibt sich scheinbar doch ein Betrag von 19 % einschließlich Mehrwertsteuer und das dürftest du sehen wenn du in die .json der Bestellung gehst (einfach .json an die Order URL hinten dranhängen) → "rate": 0.19.
Addiere jede einzelne Position + Versandkosten und führe die folgende Berechnung durch:
total price of line items + shipping x .19 / 1.19 = €3.99
Die Line items sind (so wie ich das kalkuliert habe) m. E. 1.91, 0.64, und 1.44 und wenn du alle Werte addierst, mit dem 0.19 Kurs multiplizierst und dann durch 1 + 0.19 teilst, ergibt das €3,99.
Bei der Arbeit mit Steuern, die im Einzelpostenpreis enthalten sind, kann es zu einer Diskrepanz bei den Cents kommen. Das liegt daran, dass das System bei der Berechnung der in den Produktpreisen enthaltenen Steuern die Cents rundet, da die Berechnungen hauptsächlich auf Werten mit nur 2 Ziffern basieren.
Die Grundformeln zur Berechnung der im Produktpreis enthaltenen Steuern lauten also:
- tax amount = (tax rate * price) / (1 + tax rate)
- taxable amount = price taxes included - tax amount
Nehmen wir der Einfachheit halber an, du zahlst 20% Steuern auf einen Endpreis von €129,99, in dem die Steuern bereits enthalten sind:
- tax amount = (tax rate * price) / (1 + tax rate)
- taxable amount = price taxes included - tax amount
- (0.2 * 129.99) / (1 + 0.2) = 25.998 / 1.2 = 21.67
- taxable amount = €129.99 - €21.67 = €108.32
Es gibt jedoch keine Möglichkeit, die Steuern für einen 20%igen Satz auf einen Endverkaufspreis von 129,99 $ zurückzurechnen.
- €108.33 * 1.2 = €129.996 which rounds to = €130.00 (due to the 2 decimal system rule)
- €108.32 * 1.2 = €129.984 which rounds to = €129.98 (due to the 2 decimal system rule)
Das System funktioniert also folgendermaßen:
- Wir berechnen die Steuerzeilen so, als ob wir die Steuern extra auf den Endpreis des Produkts berechnen würden (inklusive Steuern).
- Dann “merkt” das System, dass wir die Steuern mit berechnen müssen, und erstellt einen Skalierungsfaktor in Floats, der anfällig für Float-Mathematik ist und daher in einigen Fällen dazu führen kann, dass Cents geändert (gerundet) werden müssen. (Ein Float ist eine Variable mit einem gebrochenen Wert. Werte in dieser Variablendeklaration haben Ziffern auf beiden Seiten eines Dezimalkommas)
Wie im obigen Beispiel erwähnt, gibt es Szenarien, in denen es keine Möglichkeit gibt, die Steuern für einen Steuersatz von X% auf einen Endverkaufspreis wie €XX,99 zurückzurechnen, da es nicht möglich ist, einen Steuersatz von X% auf einen beliebigen Preis anzuwenden, um einen Endverkaufspreis (im obigen Beispiel) von €129,99 zu erhalten, wenn man mit einer Währung mit 2 signifikanten Ziffern (Cents oder Pfennige) arbeitet.
- Sobald das System die Steuer auf den Gesamtpreis deines Artikels (einschließlich Steuern) berechnet hat, multipliziert es den steuerpflichtigen Betrag mit dem Skalierungsfaktor, um den steuerpflichtigen Betrag einschließlich Steuern zu erhalten.
- Mit diesem Wert werden dann die Steuerprozentsätze berechnet, wobei auf 2 Dezimalstellen gerundet wird. Da diese Berechnungen mit Hilfe von Gleitkommazahlen durchgeführt werden, kann es zu Rundungen kommen, um sicherzustellen, dass der steuerpflichtige Betrag + Steuerbetrag = Gesamtpreis ist.
In unserem System entscheiden wir uns also dafür, den Cent/Pfennig zugunsten des steuerpflichtigen Betrags statt des Steuerbetrags zu verschieben, um die beste Buchhaltungsposition zu erreichen.
Wir empfehlen es immer, sich bei seinem Buchhaltungsexperten zu vergewissern, ob dies mit dem lokalen Steuerrecht übereinstimmt, denn auch wenn wir uns immer bemühen, unsere internen Berechnungen so genau wie möglich den Globalen Anforderungen anzupassen (Steuerrecht → US/CA/BR/AUS/UK/ASIEN usw.), liegt es letztendlich in jeder seiner persönlichen Verantwortung, sicherzustellen, dass man seine gesetzlichen Steuerpflichten entsprechend erfüllt.
