Falsche Berechnung bei Bestellbearbeitung für Kundengruppen mit "UST in Rechnung ausweisen = Nein"

[Torsten Riemer]

Kauft ein Kunden einer Kundengruppe, die die Einstellung "UST in Rechnung ausweisen = Nein" gesetzt hat im Shop ein, so rechnet der Shop erst einmal korrekt. Bearbeitet man die Bestellung nachträglich und klickt bei "Bestellungsbearbeitung beenden und Bestellung neu berechnen" auf "Speichern", so addiert der Shop die MwSt. zusätzlich auf die Summe.

Vorher:

Zwischensumme, netto: 109,24 €
Deutsche Post (Versand nach DE: (1 x 3 kg)): 6,90 €
Summe, netto: 116,14 €

Nachher:

Zwischensumme, netto: 109,24 €
Deutsche Post (Versand nach DE: (1 x 3 kg)): 6,90 €
Summe, netto: 138,20 €

Problem ist hier offensichtlich, dass es für das Modul "Versandkosten (ot_shipping)" keine Unterscheidung gibt, ob die Kundengruppe netto oder brutto eingestellt ist.

Das Feld "Steuerklasse" im Modul "Versandkosten (ot_shipping)" sehe ich daher als überflüssig an. Die Steuerklasse muss aus den Versandmodulen gezogen werden und auch bei Bearbeitung einer Bestellung muss die Steuerklasse unter Berücksichtigung der Kundengruppen-Einstellung (brutto, netto) verarbeitet werden.

[Ronald Parcinski]

Kundengruppe wurde nicht verändert?

Ich bin mir ziemlich sicher das dieser Fehler bei der 1.06 nicht auftritt.

Ich habe das mal im 1.06 Demoshop nachgestellt

84.03 €
Zwischensumme: 84,03 €
Deutsche Post (Versand nach DE: (1 x 3 kg)): 6,90 EUR
Nachnahmegebühr: 4,00 EUR
Summe: 94,93 €

Was mich wundert ist die Bezeichnung "Summe,netto"

ot_subtotal_no_tax sollte bei dieser Kundengruppeneinstellung gar nicht aktiv sein

Auch im 2.00 Demo bekomme ich keinen Fehler

Artikel Artikel-Nr. Preis (exkl.) Total (exkl.)
1 x Testprodukt3 003 42.02 € 42.02 €
Zwischensumme: 42,02 €
Tabellarische Versandkosten (Bester Weg): 8,50 EUR
Summe: 50,52 €

[Torsten Riemer]

Dann hast du im Modul "ot_shipping" für die Bestellbearbeitung nicht die Steuerklasse "Standardsatz" ausgewählt. Somit rechnet er das bei dir korrekt, da du ja eine Bestellung einer Netto-Kundengruppe bearbeitest.

Ich habe eben mal eine Brutto-Kundengruppen-Bestellung bearbeitet mit Testartikel 43 & Versandart "dp" (Steuerklasse "Standardsatz").

Vor der Bearbeitung:

Zwischensumme: 129,99 €
Deutsche Post (Versand nach DE: (1 x 3 kg)): 8,21 €
inkl. MwSt. 19%: 22,06 €
Summe: 138,20 €

Nach der Bearbeitung:

Zwischensumme: 129,99 €
Deutsche Post (Versand nach DE: (1 x 3 kg)): 8,21 €
inkl. MwSt. 19%: 22,07 €
Summe: 138,20 €

Auf einmal differiert die MwSt. um einen Cent.

[Ronald Parcinski]

1 ct Rundungsdifferenzen sind normal und rechtlich ok.

Ich habe im 2.00 Demoshop die Best.Nr 5 auf Händler EU umgeschaltet und neu berechnen lassen

• mit und ohne Standardsatz bei ot_shipping - kein Unterschied

Artikel Artikel-Nr. Preis (exkl.) Total (exkl.)
1 x Testprodukt3 003 42.02 € 42.02 €
Zwischensumme: 42,02 €
Tabellarische Versandkosten (Bester Weg): 8,50 EUR
Summe: 50,52 €

Alles korrekt

[Ronald Parcinski]

Das wird nur richtig berechnet weil es in den Demoshops FALSCHE Einstellungen bei den Versandmodulen gibt, bei allen steht der Steuersatz auf -keine-. Das sollte mal korrigiert werden.

Stellt man dort einen Steuersatz ein kommt es zu einer Falschberechnung der Gesamtsumme.

[Torsten Riemer]

Also kannst du den Fehler nun nachvollziehen?

Ich habe nun in der Demoshop 2.00 Datenbank bei den Modulen "dp.php", "zones.php", "ot_shipping.php" die Steuerklasse "Standardsatz" zugeordnet.

[Torsten Riemer]

Also der Fehler ist nur reproduzierbar, wenn:

1.) Man falsche Kundengruppeneinstellungen vornimmt:
Preise inkl. MwSt. = Nein
UST in Rechnung ausweisen = Nein

2.) Bei den Versandarten keine Steuerklasse angeben ist

3.) Im Modul "ot_shipping" die Steuerklasse "Standardsatz" für die Bestellbearbeitung ausgewählt ist.

Besonders Punkt 1 sollten wir abfangen. Wenn man eh immer nur eines der beiden auf "Ja" stellen darf, dann macht es an dieser Stelle keinen Sinn zwei Dropdowns dafür zu benutzen, sondern wir sollten es zusammenfassen in einem Dropdown oder per Radio-Button, so dass auf jeden Fall keine falschen Kundengruppen-Einstellungen vorgenommen werden können.

[Torsten Riemer]

Der Fehler ist in der aktuellen Version nicht mehr reproduzierbar.