Echter Warenkorb-Rabatt

Hallo. Wir nutzen SW 5.1.2 und der Warenkorbrabatt ist eigentlich ein Einzelpositionsrabatt. Das Plugin B2B - Händler MwSt Berechnung / Korrekte MwSt Rundung | Bestellprozess (Checkout) | Erweiterungen | Shopware Community Store veranschaulicht an einem Rechenbeispiel die Fehlfunktion. An welcher Stelle kann ich den Warenkorb „manipulieren“, dass es ein echten Warenkorbrabatt gibt? Danke und Gruss.

Das Plugin behebt keinen Fehler, sondern ändert die Berechnungsweise des Warenkorbes von “vertikal” auf “horizontal” - beide Rechnungsarten sind in DE vollkommen valide und auch beim Finanzamt zulässig. Hier findest du ein beispiel dafür: https://www.blitzrechner.de/mehrwertsteuer-berechnen/#berechnung-der-umsatzsteuer-bei-mehreren-posten

Der Unterschied ist einfach, dass bei einem die MwSt. pro Position errechnet udn gerundet wird und beim anderen die GesamtMwSt. 

Im eCommerce ist es gängig die Beträge auf Positionsebene zu runden, weil es das ist, was der Kunde sieht (zwei Stellen). Wenn man die Mehrwertsteuer pro Position ausgeben will, kann man auch nur die vertikale Berechnung nutzen. Es ist also kein Fehler, dass die Mehrwertsteuer pro Position gerundet wird, weil das so schon zulässig ist. 
Wenn man das ändern will, muss man tief in den Core eingreifen und vor allem auch Kompatibilitäten mit den Zahlungsplugins checken.

 

Hi [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ 

Das Finanzamt interessiert mich hierbei eigentlich nicht. Es ist nur so, dass diverse Kundengruppen “falsche” Preise angezeigt und zum Schluss auch falsch zusammengezogen  werden. Im aktuellen Fall stimmen die Rechnungspreise nicht weil 25x ein gerundeter Preis angezeigt wird, wegen 30% Rabatt fehlt dann die dritte Kommastelle. Damit kann man ja fast noch leben, aber wenn die Summe mehrerer Einzelposition real eine dritte Kommastelle haben, dann kommt da einfach eine Falsche Warenkorbsumme heraus. z.B. haben wir:

  • Endkundenwarenkorb: 212,70
  • Händlerwarenkorb mit Rabatt 30%: 148,89

Richtig wäre: 

  • 25xArtikel = 86.625
  • 3x Artikel = 62,265
  • Summe = 148,89

Falsch ist:

  • 25xArtikel = 86,63 (gerundet)
  • 3xArtikel = 62,27 (gerundet)
  • Summe = 148,90 (1Cent falsch)

Und am Falschesten ist was der Kunde angezeigt bekommt:

  • Summe = 149,03 (14 Cent falsch)

Klar, das ist hier nur 1 cent bei der richtigen Berechnung, aber das Problem ist halt bei allen Warenkörben die einen Prozentualen Rabatt haben und damit die Chance auf eine dritte oder mehr Kommastellen. Aber 14 Cent sind nicht mehr lustig. Was auch immer da berechnet wird.

Zeigst du denn im Warenkorb die 3 Nachkommastellen an?
Weil andernfalls kann ja niemand nachvollziehen, wie da gerechnet wird. Wenn der Kunde im Frontend überall 86,63 sieht, dann geht er ja erstmal davon aus, dass dies auch die Berechnungsbasis ist. Ob die Preise jetzt in der DB anders gepflegt werden, interessiert ja den Endkunden/Händler herzlich wenig. Wenn du mit mehr als zwei Nachkommastellen rechnen willst, müsstest du die ja auch anzeigen. Insofern haben wir das im Core absichtlich so gemacht, dass die Berechnung auch nachvollzogen werden kann.

Du musst mir hier mal ein konkretes Beispiel geben:

  • Wie pflegst du die Preise im Backend (netto/brutto)
    • Wie ist der Preis ohne Rabatt pro Produkt
  • Wie pflegst du den Rabatt (Preisgruppe, Kundengruppenrabatt, …)

In Shopware selbst ist der Warenkorb-Rabatt ja eine einzelposition und kein Positionsbezogener Rabatt. Der berechnet sich auf Basis des angezeigten Preises (2 Nachkommastellen). 

Die Endkundenpreise werden Brutto eingepflegt. Die Händlerpreise werden über die Kundengruppe “Händler” 30% gegeben. An der Visuellen Ausgabe ist nichts verändert, also 2 Nachkommastellen. Und leider rechnet Shopware hier mit 2 Stellen nach dem Komma. Das Ist ja bei einer Position nicht schlimm, aber wenn der Kunde mehrere Artikel in verschiedener Anzahl bestehlt ist eben der Endpreis falsch.

Beispiel: Endkundenpreis = 4,95€ brutto . Shopware errechnet daraus für den Händler 3,46€ brutto und gibt es auch so aus. Richtig ist an dieser Stelle allerdings, dass es eigentlich 3,465 € wären. Legt der Händler diesen Artikel 25x in den Warenkorb, errechnet Shopware 86,63, richtig wäre aber 86,625€. Bei der Summe mit weiteren 3-kommastellen-Produkten ergibt sich dann diese 1cent Unterschied rein rechnerisch. Was mich aber stutzig macht ist, warum der Kunde 149,03€ bezahlen soll. Es gibt keine Aufschläge für Versand (ist gratis ab 50€) und auch keine Zahlart-Aufsschläge.

Edit: Ich sehe gerade in den Kundengruppen-Einstellungen

  • Rabattmodus
  • Rabatt:30
  • Warenkorbrabatt -leer- 

Ist hier ein Unterschied in der Berechnung?

Edit2: Die Händler sollen Artikel mit dem Rabattpreis sehen und nicht erst im Warenkorb die 30% als Position bekommen

So weit ich weiß werden die Rundungen im frontend und backend unterschiedlich durchgeführt. Daher kam es bei mir damals zur selben Abweichung der Preise von Bestellbestätigung zu PDF Rechnung.

Ich musste das Plugin dann damals deinstallieren. Ich konnte dann auch erkennen, dass manche Preise, die ich prozentual erhöht hatte, im frontend um ein paar Cent anders als im backend waren.

es hängte mit den vielen Stellen hinter dem Komma zusammen.

Um mal bei deinem Beispiel zu bleiben. Shopware rechnet immer mit zwei Stellen, überall. Richtig wäre also erstmal, dass er mit 3,47 rechnet, bei 25 also bei 86,75 rauskommt (das scheint bei der Kundengruppen-Funktion generell falsch zu sein). Wichtig ist beim Warenkorb, dass man die Berechnung nachvollziehen kann, daher wird auch immer nur mit den angezeigten Preisen gerechnet. Es ist daher erstmal vollkommen beabsichtigt, dass überall mit gerundeten 2-Stelligen Werten gerechnet wird. Versteht ja kein Kunde, dass sonst 3,47*25 nicht 86,75 ergibt, sondern 8,63 weil im Hintergrund anders gerechnet wird. 

Du hast jetzt zwei Möglichkeiten:

 

1. Du gehst über Preisgruppen und legst eine für 30% an und weist die dem Artikel zu - dann wird im Frontend/Warenkorb auch korrekt 3,47 ausgewiesen.

2. Du gehst über die Pflege des Preises bei der jeweiligen Kundengruppe

Beide Dinge sollte man über SQL auch relativ einfach hinbekommen für alle Produkte.

Zu dem Thema mit den Kundengruppen hab ich ein Ticket aufgemacht, mir schleierhaft, wie er da auf 3,46 komm: Shopware Issuetracker

Im Standard bekommst du Shopware nicht dazu im Hintergrund mit merh als 2 Stellen zu rechnen und das ist auch erstmal ganz bewusst so, damit man die Rechnungen im Frontend nachvollziehen kann - ausgewiesener Stückpreis * Anzahl muss immer zusammenpassen. Das würde ja in deinem Beispiel nicht.

Es ist vorgesehen, dass man dies mal irgendwann einstellbar macht, genauso wie die Berechnungsgrundlage, solange rechnen wir im Core überall mit 2 Stellen.

 

1 „Gefällt mir“

Da sind wir doch schon auf dem richtigen Weg: :slight_smile: Ich fasse nochmal zusammen und vor allem noch ein großer Erzähl- Fehler meinerseits:

Artikel 1 wird 25x bestellt

  • EK Einzelpreis: 4,95€
  • Händler Einzelpreis 3,465€  (30% Rabatt)
  • Händler Backendbestellübersicht abgerundet 3,46€
  • Händler Frontend aufgerundet 3,47€
  • Position gesamt: EK 123,75€, H-Backend 86,63€, H-Frontend: 86,75€

Artikel 2 wird 3x bestellt

  • EK Einzelpreis:29,65€
  • Händler Einzelpreis: 20,755€ (30% Rabatt)
  • Händler Backendbestellübersicht abgerundet 20,75€
  • Händler Frontend aufgerundet 20,76€
  • Position gesamt: EK 88,95€, H-Backend 62,27€, H-Frontend: 62,28€  

Ergebnis Warenkorb (fett markiert was bezahlt wurde)

  • EK 212,70€ (richtig)
  • Händler 148,90€ aus Art.1+2 (falsch)
  • Händler 148,89€ wäre echte 30% vom EK (richtig)
  • Händler 149,03€ aus Frontend (falsch)

Im Grunde braucht doch Shopware nur mehrere Nachkommastellen für Kundengruppen (ausser der EK-Gruppe) zur Berechnung freigeben und am Ende die Rabattprozent dazu rechnen. Beim (Händler/Gruppen) Frontend wäre dann noch eine Anpassung nötig, ein Hinweis von wegen “aufgerundet/abgerundet” oder eben die Angabe mehrere Nachkommastellen.