Bestellbestätigung und Rechnung - Abweichung vom Preis oder Rundungsfehler?

Shopware 5 Administration
1

Hallo Gemeinde,

mit ist aktuell aufgefallen, dass sich folgender Fehler zeigt:

Bei manchen Artikeln ist der Gesamtpreis auf der Bestellbestätigung richtig aber auf der Rechnung weicht er um ein paar Cent ab. Die Differenzen sind dabei zwischen 1 und 5 cent.

Ich habe hier einen Artikel, welcher 6,69 Euro kostet. Der Kunde hat davon dann 15 Stück bestellt. Macht gesamt: 100,35 Euro.

Auf der Bestellbestätigung steht auch korrekt 100,35 Euro drauf.

Wenn ich dann die Rechnung im Backend erstelle, wird die Position mit einem Gesamtpreis von 100,28 Euro angezeigt.

Das ist ziemlich häufig der Fall, aber nicht immer. Es ist auch in beiden SW 5.2.22 Shops gleich so. Es kommt immer vor, wenn mehr als 1 Stück einer Position bestellt wird.

Aber:

Vor ca. 1,5 Monaten war das noch nicht so schlimm. Wir hatten da noch Preise die fast immer mit 1,99 Euro, 4,49 Euro usw. dargestellt waren. Also mit 99 oder 49 Cent am Ende.

Ich hatte dann die Preise pauschal um 3% im Shop angehoben, wodurch dann natürlich die Preise auch ziemlich absonderlich werden. Also wie z.B. 1,63 Euro, 23,47 Euro, 45,42 Euro usw.

 

Wie kann das Zustande kommen, dass die Preise auf der Bestellbestätigung richtig Addiert werden und auf der Rechnung leicht abweichen?

Hat das auch jemand bei sich so?

Ist das evtl. Shopware bedingt normal, wegen der Rundungen oder so?

 

Viele Grüße

Matthias

 

2

So wie es aussieht rechnet Shopware dem Kunden den Warenkorbwert mit den gerundeten Preisen vor, aber für die Rechnung werden die genauen Kommawerte verwendet. Ich habe diesbezüglich den Shopwaresupport angefragt und folgende Antwort bekommen:

„Shopware rechnet die Mehrwertsteuer positionsbezogen aus und rundet hierfür auf zwei Nachkommastellen ab - einfach gesagt, er rechnet so wie es im Warenkorb angezeigt wird, damit es besser nachvollziehbar ist. Dadurch können insbesondere bei einer hohen Anzahl an Mengen/Positionen geringfügige Abweichungen auftauchen. Shopware verwendet hier die gesetzlich anerkannte horizontale Berechnung des Warenkorbs.
Eine Optimierung des Warenkorbes ist jedoch bereits geplant und kann auf unserer Roadmap verfolgt werden. Hier wird es eine umfangreichere Konfiguration der Steuersätze und des Rundungsverhalten geben. Da dies jedoch größere Brüche mit sich zieht, kann eine genauere Terminierung zum jetztigen Zeitpunkt nicht getroffen werden.“

Das bezieht sich (wenn man es genau nimmt) ja nur auf die MwSt. Also fragte ich nochmal genauer nach, ob das auch für die anderen Positionen im Warenkorb gilt. Antwort:

„In meiner vorherigen Antwort hatte ich mich auch hierzu geäußert - im Warenkorb werden die Werte verwendet, welche dem Kunden angezeigt werden. Da SW nur 2 Nachkommastellen für die Anzeige verwendet, werden auch nur zwei Nachkommastellen für die Berechnung zur Hilfe genommen. Im anderen Fall wäre dem Kunden nicht ersichtlich, wie es zu der Summe gekommen ist. Ob dies final in einer neuen SW Version so umgesetzt wird, lässt sich zum jetzigen Zeitpunkt nicht sagen.“

Du hattest gefragt: „Hat das auch jemand bei sich so?“
Ja, wir haben das Problem auch und es ist mir nicht ganz verständlich, warum man die beiden Berechnungen nicht einfach einheitlich machen kann:

a) Im Warenkorb und auf der Rechnung gerundet.
oder:
b) Im Warenkorb und auf der Rechnung mit genauen Werten.

Man könnte bei b) ja sogar die Werte im Warenkorb gerundet anzeigen und einen kleinen Hinweis einblenden im Sinne von: „Wenn sich beim Nachrechnen kleine Differenzen herausstellen, sind diese darauf zurückzuführen, dass im Hintergrund mit mehr als zwei Nachkommastellen gerechnet wird.“

Was auch ärgerlich ist: Das Problem scheint Shopware schon seit SW 4.X bekannt zu sein und trotzdem wird das immer vor sich her geschoben. Eigentlich sollte ja die Regel gelten, den Kern fehlerfrei und stabil zu machen bevor neue Features angegangen werden. Aber da scheiden sich offensichtlich die Geister.

3

das hat sich mittlerweile erledigt.

schuld daran war ein plugin im store, welches man nutzen konnte, um z.b. die Preise eines bestimmten herstellers zu erhöhen oder zu senken.

Das Plugin hat nur mit den 2 Stellen gerechnet. Also hatte ich gleich mal unsere Preise mit dem Plugin geändert. Die Folge war, dass dann die Preise im Frontend von denen im Backend abgewichen sind. Auf support anfrage beim Plugin hersteller hatte dieser dann das Plugin auf 4 Stellen nach dem Komma geändert. Aber auch das half nix, die Preise wieder in „Einklang“ zu bringen. Die Folge war: Eine Agentur musste bei 2 Shops die Preise exportieren, dann auf die Stellen Nullrunden und wieder einspielen. Also eine kostspielige Sache.

Von prozentualen Preisänderungen in der Mehrfachverarbeitung rate ich daher ab.

Eher rate ich zu Preise exportieren und dann im Excel bearbeiten, dann wieder hochladen.

 

Seit der Anpassung laufen wieder alle Preise optimal aus. Sie stimmen auf den Cent genau, auch wenn viele Artikel aus der gleichen Position gekauft werden. Auch mit Zahlartenrabatt usw. keine Probleme.

 

 

Viele Grüße

Matthias