Hallo Shopwaregemeinde, wir setzen aktuell einen B2B shop auf. Uns ist aufgefallen das Shopware sich bei der berechnung der MwSt verrechnet. Die Shoppreise sind als netto hinterlegt.
Hier wird als mwst 25.21 ausgespielt. Eine simple Rechnung von 132,64 * 0,19 ergibt bei mir jedoch 25,2016 was auf 2 stellen kaufmännisch gerundet 25,20 ergeben müsste… Wieso wird hier so vorgegangen? auf die 25.21 für die mwst komme ich nur wenn ich für jeden artikel die mwst auf zeilenebene errehne und dort auf die ersten beiden nachkommastellen runde. 16,99 -> 19% = 3,1863 29,40 -> 19% = 5,586 83,19 -> 19% = 15,8061 3,28 -> 19% = 0,6232 3,19 + 5,59 + 15,81 + 0,62 = 25,21 Kann mir jemand erklären wieso dies so ist? Die Abweicung die hier aktuell nur 1 cent beträgt würde somit ja bei berechnung der mwst auf artikelzeilenebene rapide ansteigen… sodas auch abweichungen von mehreen cent bzw euro denkbar wären… was natürlich blöd ist.
[quote=„weflorian“]Hallo Shopwaregemeinde, wir setzen aktuell einen B2B shop auf. Uns ist aufgefallen das Shopware sich bei der berechnung der MwSt verrechnet. Die Shoppreise sind als netto hinterlegt.
Hier wird als mwst 25.21 ausgespielt. Eine simple Rechnung von 132,64 * 0,19 ergibt bei mir jedoch 25,2016 was auf 2 stellen kaufmännisch gerundet 25,20 ergeben müsste… Wieso wird hier so vorgegangen? auf die 25.21 für die mwst komme ich nur wenn ich für jeden artikel die mwst auf zeilenebene errehne und dort auf die ersten beiden nachkommastellen runde. 16,99 -> 19% = 3,1863 29,40 -> 19% = 5,586 83,19 -> 19% = 15,8061 3,28 -> 19% = 0,6232 3,19 + 5,59 + 15,81 + 0,62 = 25,21 Kann mir jemand erklären wieso dies so ist? Die Abweicung die hier aktuell nur 1 cent beträgt würde somit ja bei berechnung der mwst auf artikelzeilenebene rapide ansteigen… sodas auch abweichungen von mehreen cent bzw euro denkbar wären… was natürlich blöd ist.[/quote] Ein beispiel für eine grobe verrechnung bei mehreren Artikeln wenn wir die mwst auf artikelebene berechnen und addieren wäre folgendes Szenario ein Artikel für 16,99 netto wird 201 mal gekauft das würde folgende mwst ergeben mittels der rechnung die shopware aktuell durchführt 16,99*201 = 3414,99 3414,99 * 0,19 = 648,8481 ~ 648,85 mwst des artikels haben wir aber nun 201 verschiedene artikel die je auch 16,99 kosten würde folgende gesamte mwst heraus kommen 16,99 * 0,19 = 3,2281 ~ 3,23 3,23 * 201 = 649,23 (201 - weil wie für jeden artiukel die mwst extra errechnen wie es shopware macht) Es liegt also somit eine differenz vor! 649,23 -648,85 -------- 0,38 cent… das kann doch nicht sein… habt ihr ähnliche Probleme?!Hallo weflorian, Shopware rundet an der Stelle kaufmännisch auf zwei Stellen hinter dem Komma und zwar immer für die einzelne Position. Nicht für die Gesamtsumme. Dies ist aktuell bewusst so implementiert. Gruß Patrick
[quote=„Patrick Schücker“]Hallo weflorian, Shopware rundet an der Stelle kaufmännisch auf zwei Stellen hinter dem Komma und zwar immer für die einzelne Position. Nicht für die Gesamtsumme. Dies ist aktuell bewusst so implementiert. Gruß Patrick[/quote] Wenn pro Zeile kaufmännischgerundet auf 2 Stellen nach dem Komma gerundet wird anstatt bei den Einzelpositionen nicht zu runden, ergibt sich in der Summierung der einzelnen MwSt. Beträge eine Abweichung zur errechneten MwSt der Gesamtsumme. Sprich die Zusammenfassung des Warenkorb beinhaltet Differenzen in der berechneten MwSt. Was bei 2-3 Artikeln evtl 1 cent aus macht aber bei vielen Artikeln ~ 300 dann schnell mal 50 cent … x euro sein können. Was ja so nicht sein darf. Zusammenfassend darf die Zeilenweise berechnung nicht pro zeile gerundet werden und erst am schluss in der Summierung dieser erechneten Mwst beträge auf 2 stellen nach dem Komma gerundet werden. Könnten Sie uns dazu nochmal eine abschließende Rückmeldung geben. Für das Betreiben eines B2B Shops mit netto würde dies dann ja keinen sinn ergeben. Gruß Florian
Hallo, aktuell ist das Verfahren so wie beschrieben. Shopware rundet kaufmännisch auf zwei Stellen hinter dem Komma. Für jede Position einzeln. Es ist möglich, dass das Verfahren auf Dauer geändert wird. Dies ist aber keine kleine Änderung in Shopware, sondern eine grundlegende die nicht einfach zu durchgeführt werden kann. Wann genau das Verfahren geändert wird kann aktuell noch nicht gesagt werden. Bis dahin ist es so wie es ist. Dieses Verfahren wurde so in der Form auch schon bei Shopware 3.5 verwendet. Es wird also in sehr vielen Shops so gehandhabt. Gruß Patrick Schücker
[quote=“Patrick Schücker”]Hallo, aktuell ist das Verfahren so wie beschrieben. Shopware rundet kaufmännisch auf zwei Stellen hinter dem Komma. Für jede Position einzeln. Es ist möglich, dass das Verfahren auf Dauer geändert wird. Dies ist aber keine kleine Änderung in Shopware, sondern eine grundlegende die nicht einfach zu durchgeführt werden kann. Wann genau das Verfahren geändert wird kann aktuell noch nicht gesagt werden. Bis dahin ist es so wie es ist. Dieses Verfahren wurde so in der Form auch schon bei Shopware 3.5 verwendet. Es wird also in sehr vielen Shops so gehandhabt. Gruß Patrick Schücker[/quote] Okay dann müssen wir das wohl so hin nehmen. Sprich im B2C bereich wo Preise im Brutto behandelt werden ist alles okay und im B2B Berreich hat Shopware eine seltsame bzw. fehlerhafte Art und Weise zu rechnen…
Hab hier auch und immer noch ein Problem bei der Endsumme. Bruttopreise eingegeben, Nettopreise im Frontend. Summe 27,74 €* = Richtig Versandkosten 3,78 €* = Richtig Gesamtsumme 37,52 € [color=red]= Falsch[/color] Gesamtsumme ohne MwSt.: 31,52 € = Richtig zzgl. 19.00 % MwSt.: 6,00 € [color=red]= Falsch[/color] Hier rechnet er die Mwst falsch! Diese wäre nach Adam Riese 5,98€ und nicht 6,00€. Korrekter Endpreis wäre 37,50 €!!! Somit zahlt der Kunde 0,02 Cent zuviel. Als seriöser Händler steht man ganz schön blöd da. [quote=“Patrick Schücker”]Hallo, aktuell ist das Verfahren so wie beschrieben. Shopware rundet kaufmännisch auf zwei Stellen hinter dem Komma. Für jede Position einzeln. Es ist möglich, dass das Verfahren auf Dauer geändert wird. Dies ist aber keine kleine Änderung in Shopware, sondern eine grundlegende die nicht einfach zu durchgeführt werden kann. Wann genau das Verfahren geändert wird kann aktuell noch nicht gesagt werden. Bis dahin ist es so wie es ist. Dieses Verfahren wurde so in der Form auch schon bei Shopware 3.5 verwendet. Es wird also in sehr vielen Shops so gehandhabt. Gruß Patrick Schücker[/quote] Und wenn eine Software auch für Händler ausgelegt ist, dann sollte das richtig funktionieren. Wäre schön, wenn es hier endlich mal eine Lösung gäbe. Schlagen uns seit SW 3.0 schon damit rum und dachte mit 4 wäre das endlich behoben!!! In der basket.php habe ich das schon versucht, die Nachkommastellen zu ändern, aber das bringt auch nichts, da kommen dann ganz andere Summen heraus. Bitte Shopware tut endlich etwas. So kann man doch nicht arbeiten.
Hallo, Das Problem scheint immer noch vorhanden zu sein. Wir haben diesen Effekt ebenfalls in einem unserer Kunden-Shops für den B2B Bereich. Gibt es hier bereits Abhilfe? Beste Grüße
Würde mich auch interessieren, leider noch immer brandaktuell…
Ich habe auch immer noch das Problem. Die Netto- und Bruttosummen werden jetzt richtig berechnet nach kleinen Änderungen, aber die Anzeige der Mwst ist immer noch falsch. Mal 1 Cent zu viel, mal 1 Cent zu wenig. Ist schon merkwürdig.
Hallo,
wir sind nun auch auf den Fehler aufmerksam geworden da die payone API immer wieder einen Fehler wegen abweichender Preise auswarf.
Folge = Ablehnungen bei Rechnungskäufen, Ratenkäufen etc.
Grund: die vertikale Berechnung der MwSt.
Hat irgendjemand eine Lösung gefunden dies umzustellen?
Shopware hat die sleider noch immer im Shop!!! Warum auch immer…
Beste Grüße
Sebastian
Auch im Jahr 2018 gibt es das Problem wohl noch immer. Also die Grundvorraussetzung für ein Shopsystem ist für mich, dass die Berechnungen richtig sind.
http://de.wikipedia.org/wiki/Rundung
Summenerhaltendes Runden:
Beim summenerhaltenden Runden werden die Summanden so gerundet, dass deren Summe gleich der gerundeten Summe der Summanden ist. Dabei kann es erforderlich sein, manchen Summanden vom nächstgelegenen gerundeten Wert weg auf den gegenüber gelegenen Wert zu runden.
Dieser Ansatz ist beispielsweise notwendig, wenn auf einer Rechnung die gesamte Mehrwertsteuer auf die einzelnen Posten verteilt, aber jede Spalte korrekt summiert werden soll.
-
Wenn alle Summanden positiv sind, kann man leicht die Summe der Beträge der Rundungsfehler minimieren. Der bei Abrundung wegfallende Anteil eines Summanden sei kurz Rest genannt: Summand minus abgerundeter Summand. Summanden mit großem Rest werden aufgerundet, solche mit kleinem Rest abgerundet, und zwar so, dass kein abgerundeter Summand einen größeren Rest hat als ein aufgerundeter und die Summe weiterhin stimmt. Ein Beispiel ist das Hare-Niemeyer-Verfahren.
-
Das folgende Verfahren wirkt auch bei Summanden mit beiderlei Vorzeichen: Man rundet einen Summanden nach dem anderen (kaufmännisch oder mathematisch) und führt den kumulierten Rundungsfehler mit. Beim Runden der ersten Zahl entsteht ein Rundungsfehler (Summand minus auf- oder abgerundeter Summand). Dieser Rundungsfehler (positiv, negativ oder null) wird vor dem Runden des zweiten Summanden zu diesem addiert. Der neue (kumulierte) Rundungsfehler ist dann die Differenz dieser Summe zum gerundeten Wert des zweiten Summanden. Dieses Verfahren setzt man fort bis zum letzten Summanden.
- Der Betrag des kumulierten Fehlers ist dabei immer höchstens gleich der Hälfte des kleinstmöglichen Abstands zwischen zwei gerundeten Zahlen (beim Runden auf ganze Zahlen also höchstens 1/2).
- Die Rundung kann von der Reihenfolge der Bearbeitung abhängen: Aus 2,3 + 3,4 = 5,7 wird 2+4=6; aus 3,4 + 2,3 = 5,7 wird 3+3=6.
- Man kann diese Abhängigkeit nutzen, um gewünschte Eigenschaften zu erzielen, etwa die Summe der Beträge der Rundungsfehler zu minimieren. Alle Permutationen zu probieren und die beste zu nehmen geht immer; ein weniger unwirtschaftlicher Algorithmus ist nicht bekannt.
Warum stolpern da nicht noch mehr drüber? Nutzen das System so wenige als B2B System? Ich kauf doch kein Plugin für 300 Euro damit das Shopsystem richtig rechnet. :-))
Ich verstehe nicht auf was du hinaus möchtest.
Shopware setzt zur Errechnung der enthaltenen Mehrwertsteuer das vertikale Verfahren ein. Es wird auf positionsbasis die Mehrwertsteuer errechnet und gerundet und abschließend zur Gesamtsumme zuusammenaddiert. Das ist rechtlich so einwandfrei.
Es gibt in Deutschland auch die Möglichkeit die Mehrwertsteuer horizontal zu errechnen, dabei wird der Nettogesamtbetrag einfach umgerechnet. Hier gibt es im Netz Beispiele dazu: https://www.blitzrechner.de/mehrwertsteuer-berechnen/#horizontale-berechnung-der-umsatzsteuer
Das hat beides seine Vor- und Nachteile. Bei der vertikalen Berechnung ist es möglich pro Position die enthaltene Mehrwertsteuer auszugeben, was bei der horizontalen so nicht möglich ist. Dafür kann man bei der horizontalen Berechnung besser nachvollziehen wie sich die enthaltene Mehrwertsteuer (Gesamtbetrag) errechnet.
Es macht hier durchaus Sinn, dass du einen neuen Thread mit einem konkreten Berechnungsbeispiel (inkl. Informationen wie der Preis in welcher Nachkommazahl gepflegt wird) aufmachst. Anhand deiner Schilderung kann man das so nicht nachvollziehen. Der Thread hier ist über 3 Jahre alt und es gibt hier hunderte Optimierungen seitdem 