Habe heute Shopware auf 5.7.7 upgedatet, in der Hoffnung dass der MwSt. Bug gelöst ist.
Leider treten immer noch Rundungsfehler auf und das ist echt bescheuert, auch wenn es nur Cent Beträge sind.
Hier das Beispiel aus Shopware und als Zweites aus Excel. Wie kann der Fehler korrigiert werden ???.
Shopware Rechnung
Excel Rechnung
Die Einstellung aus den Grundeinstellungen > Storefront > Warenkorb / Artikeldetails > Nettobestellungen auf 2 Stellen runden greift irgendwie nicht.
SW verwendet das vertikale Verfahren, viele ERP Systeme wie SAP oder Lexware (und auch deine Excel-Berechnung) das horizontale.
Das betrifft auch B2B Netto-Rechnungen, da auch hier die MwSt zunächst auf Positionsebene berechnet und gerundet wird, und erst dann die einzelnen Werte addiert werden.
Beide Verfahren sind gesetzlich zulässig, aber wenn man Vorsteuer ziehen will, darf man hier natürlich nur den vom Lieferanten tatsächlich ausgewiesenen Steuerbetrag ansetzen, da dieser ja auch ans FA abgeführt wurde.
Dem kann ich nicht zustimmen, meine Excel Kalkulation mit der vertikalen Berechnung kommt auf das gleiche Ergebnis wie der horizontalen, siehe mein Screenshot.
Bei Shopware werden 2 Cent draufgeschlagen, es kommt als Ergebnis 1.298,89 EUR
Woher kommen die 2 Cent ???
Rechts die Spalte „Preis mit MwSt.“ als vertikale „Shopware“ Kalkulation!!!
Erstens gewöhn dir einen anderen Ton an. Die Leute die hier nach Lösungen suchen, machen es für Spaß.
Wenn du eine Lösung brauchst, buche den Support bei Shopware, lass es umprogrammieren oder falls es ein Bug ist, erstelle ein Ticket bei Shopware: https://issues.shopware.com/
Zweitens, wie sieht im Detail der gleiche Beleg / die Bestellung in Shopware aus?
Die „Fehler“ kommen meistens daher, dass die gesetzlichen Vorgaben zur Steuerberechnung in der Excel-Tabelle nicht korrekt beachtet werden. Bitte die einschlägigen Gesetze lesen.
Es sind nach jedem Rechenschritt die Dezimalstellen ab der 3. Stelle zu verwerfen, der Rest ist kaufmännisch zu runden.
Das gilt sowohl bei vertikaler als auch bei horizontaler Berechnung.
Der Fehler ist, dass in Excel meist durchweg mit der vollen Dezimalstellenzahl gerechnet wird und erst zum Schluss gerundet wird. Das führt aber vor allem bei größeren Stückzahlen zu falschen Ergebnissen.
Guter Punkt von @drakon. Was ist wenn du die gerundeten Zeilensummen mit dem Taschenrechner zusammenrechnest? Excel zeigt in deinem Beispiel die Zahlen 2 Stellig an. Rechnet aber mit der vollen Genauigkeit.
Rein aus Langeweile: Summiert man die „zweistelligen“ Mwst.-Beträge aus der Tabelle auf, kommen 207,4EUR raus, und nicht 207,38EUR - also nur gerundete darstellung in Excel Da sind sie wieder, die 2 Cent
Das betrifft doch nicht nur mich, sondern alle. Und es kann doch nicht wirklich schwer sein, die MWST. richtig zu berechnen, wenn der Nettobetrag bis dahin stimmt.
Man nehme den Nettobetrag * 0,19 und addiere alles zusammen, gerne auf 4 Stellen, wie das übrigens auch von vielen gewünscht, seit mehreren Jahren versprochen, aber weder in Shopware 5 noch in Shopware 6 umgestellt wurde.
Wenn man sich als die Shop Lösung vermarktet, dann haben auch einfache Dinge zu funktionieren.
Also korrekte MwSt + 4 Stellen nach dem Komma, das ist doch keine Bachelor oder Masterarbeit.
Wenn ich wüsste, wo sich die Kalkulation im Code befindet - dazu wird auch nichts gepostet - dann kann ich mir das auch selber ansehen.fett gedruckter Text
In der ersten Tabelle „oben“ stehen sie zweistellig. Und die ergeben aufsummiert 207,40 - einfach mal mal selber rechnen. Da wird was gerundet angezeigt aber ungerundet gerechnet. Nachträglich was anderes nachschieben mit 4 Stellen? Bin raus aus dem Thema.
Wenn du das Forum durchstöberst, dann findest du auch andere User, die das gleiche Problem haben… und das nicht erst seit gestern… sondern seit der Version 3.5.
Excel ist dein Freund, wenn du nicht magst, dann nimm LibreOffice.
Letzter Versuch: Excel rechnet intern immer mit voller Genauigkeit und rundet nur die Anzeige - außer Du erzwingst das über eine Formel wie RUNDEN() oder VRUNDEN(). Wie @drakon bereits richtig anmerkte: für das kaufmännische Runden gilt nach DIN 1333 folgende Regel: Beim Runden wird die letzte Stelle, die nach dem Runden noch bei der Zahl verbleibt, Rundestelle genannt. Steht hinter der Rundestelle eine der Ziffern 0 bis 4, so wird abgerundet, steht hinter der Rundestelle eine der Ziffern 5 bis 9, so wird aufgerundet. Die weiteren ggf. noch nachfolgenden Ziffern sind dabei unerheblich.
2,1949 ergibt also beim Runden nach DIN 1333 also nicht 2,20, sondern 2,19 (Ziffer nach Rundestelle = 4, also abrunden). Beim normalen Runden würde man hingegen von hinten nach vorne durchrunden, also 2,1949 => 2,195 => 2,20.
Hallo, wir haben es auch mit vertikaler Berechnung versucht (Berechnung der Steuer anhand des Gesamtbetrags netto laut Shopware) – jetzt sind die Differenzen noch höher und wir können die Steuerberechnung gar nicht mehr nachvollziehen. Beispiel:
Kunde kauft für 367,54 € netto – zzgl. 19 % Steuern => 437,3726 € => kaufm. gerundet: 437,37 € , so auch bei uns in der WaWi – bei Shopware jedoch 437,36 € – Das ergibt für uns nun überhaupt keinen Sinn mehr.
Das Problem kann wie folgt gelöst werden, wobei wichtig ist, aus Sicht eines auf zwei Nachkommastellen gerundeten Bruttobetrags zu denken. In deinem Beispiel Artikel XYZ soll exakt 437,37 € Brutto kosten. In der Tabelle s_articles_prices muss ein ungerundeter Nettobetrag stehen 437,37 / 1.19 = 367,53781512605042016806722689076 .
Preisupdates werden in unserem Shop direkt in der Datenbank durchgeführt (kein Backend, keine API). Ob Preisupdates, die im Backend oder über die API durchgeführt werden, den Nettopreis runden kann ich daher nicht sagen.
Vielen Dank, durch deine Antwort konnte ich den Fehler finden. Wir haben in Shopware tatsächlich Brutto-Preise auf Produktebene mit drei bis vier Dezimalen hinterlegt. Obwohl wir in unserem EPR-System ausschließlich Netto-Preise mit max. 2 Dezimalen hinterlegt haben.
Wo der Fehler genau liegt werde ich untersuchen. Ich vermute in der Schnittstelle von unserem ERP-System büro+, welche leider keine Option zur Anpassung der Preise vor Übertragung bietet.