Neu Bruttobetrag im Shop ändert sich je nach Ust.-Land. Ich will es aber nicht. Wie mache ich das?

[css-umsetzung]

Für einen Kunden, der dieses Problem mit Österreich/Deutschland hat, habe ich für Österreich eine extra Kundengruppe.
Der Shop arbeitet mit seinen 19% und wenn ein Österreicher sich zu erkennen gibt, bekommt er automatisch die Ösi Gruppe zugewiesen die dann trotz der 20%, die gleichen Preise wie die Deutschen haben.

Das läuft ganz gut, ist nur nervig da man ja ständig die Kundengruppenpreise pflegen muss.

 

[MichaelH]

So so hast du - und von wem ist das Plugin ?

 

[css-umsetzung]

Ich gebe bei Einrichtungen eines Shops fast immer ein Plugin dazu das individuelle Sachen für den Shopbesitzer regelt.

Das ist also meine Programmierung, zugeschnitten für diesen Shop.
Wenn es um mehrere verschiedene Länder geht, muss man da aucb ein mapping programmieren damit man weißwelches Land welche Gruppe bekommt aber das ist auch kein Hexenwerk.

Es ist eben nur umständlich die Gruppen zu pflegen. Eventuell sollte man da wirklich mal über eine automatische Preisanpassung via Plugin nachdenken aber für die wawi bräuchteman eh Gruppenpreise.

 

[hula1499]

Das sind alles vollständig unnötige zusätzliche Arbeitsschritte, nur weil JTL keinen Schritt weit denken kann.
Lieferschwellen gibts in der WaWi, aber im eigenen Produkt (JTL Shop) gibts dafür 0 Implementierung.
Kundengruppen gibts, in der WaWi, aber die mit unterschiedlichen STeuersätzen etc. zu versehen -> fail

a)
das Plugin/Template muss erkennen wohin es geht -> demnach dann die Steuer manipulieren
b)
in allen Produkten muss die "Kundengruppe" vom Preis her richtig verändert werden, damit der Endpreis immer stimmt.
Gilt natürlich auch für Sonderpreise, Kinderartikel etc -> alles vollkommen schwachsinniger Aufwand.
c)
manche Plugins/Zahlungsoptionen können mit der Manipulation einfach nicht umgehen und schicken dann falsche Werte (secupay, sofortüberweisung ...) in Bestellbestätigung und in die WaWi -> weiterer zusätzlicher Supportaufwand im backend

 

[Indy1]

Irgendwie finde ich diese Diskussion ein wenig unnötig...
Wenn ich in irgendein Multinationales Geschäft gehe (HuM z.B.) und mir dort was anschaue habe ich auch 3 verschiedene Preise drauf - je nachdem wo ich es kaufe und ich hab noch nie jemanden gehört der sich desshalb beschwert hätte...
Ich um es gleich vorweg zu sagen.... ich komme aus AT und ich habe die TEUREREN Preise oben stehen (wegen der MWSt) - also... bevor man da herumzickt vielleicht einfach unterschiedlich viel kosten lassen.... ?! Was ist daran jetzt sooooo ein Problem ?

 

[MichaelH]

Wenn ein Produkt mit 39,90 angepriesen wird und es kostet nach Anmeldung 41,02 dann ist es unschön und nicht gut ... so ist das, auch wenn es dir egal ist und für dich kein Problem.
Oder sind 41,02 Euro ein verkaufsfördernder Preis ?

Und nein, es geht nicht nur um Klamotten oder Schuhe oder Lampen.

 

[css-umsetzung]

Irgendwie finde ich diese Diskussion ein wenig unnötig...
Wenn ich in irgendein Multinationales Geschäft gehe (HuM z.B.) und mir dort was anschaue habe ich auch 3 verschiedene Preise drauf - je nachdem wo ich es kaufe und ich hab noch nie jemanden gehört der sich desshalb beschwert hätte...
Ich um es gleich vorweg zu sagen.... ich komme aus AT und ich habe die TEUREREN Preise oben stehen (wegen der MWSt) - also... bevor man da herumzickt vielleicht einfach unterschiedlich viel kosten lassen.... ?! Was ist daran jetzt sooooo ein Problem ?

Bei meinem Kunden um den es da z.B. ging ist es so das er noch "echte" Kataloge erstellen lässt, die er dann seinen Kunden in Deutschland und eben Österreich schickt. Er müsste also zwei verschiedene Kataloge erstellen lassen oder in den Katalogen zwei verschiedene Preise darstellen. Das ist alles nicht so der Knaller und wenn die Kalkulation stimmt und er damit leben kann das er bei Österreichern etwas Verlust macht dann ist das ein guter Weg.

 

[MichaelH]

... er macht keinen Verlust, sondern seine Marge ist geringer.

 

[css-umsetzung]

Ich bin Programmierer ich muss das nicht wissen

 

[Rico Giesler]

Wir haben zum Thema "MwSt anhand der Bruttopreise berechen" ein Ticket: https://issues.jtl-software.de/issues/WAWI-37446
Hier dürft ihr gern eine Stimme abgeben, wenn das für euch wichtig ist.

 

[zero111181]

Der Tread ist schon etwas älter, aber ich habe nun auch ein Problem, Ungarn hat 27% der Kunde hat bei uns für 600€ eingekauft das sind mal schlappe 8% Verlust gegenüber den regulären 19% MwSt. das ist nicht schön. Wir haben ca. 40€ eingebüßt ich bin am überlegen Ungarn als Lieferland auszuschließen weil mir das echt zu Fett ist. Ich würde es mir wünschen das die MwSt. anhand des Netto´s errechnet werden. Ein Hinweis am Artikel Brutto kann vom Lieferland abweichen kann man ja platzieren.

 

[MichaelH]

Hast du alles gelesen ?

Lass dich mal beraten wie das alles funktionieren könnte, sofern du es korrekt einstellst:
https://css-umsetzung.de/shop/CSS-GeoIP-MwSt-Finder

 

[Rainer S]

Welche Shopversion wird denn genutzt? Denn in der aktuellen Shopversion kann man es im Backend einstellen unter den Globalen einstellungen, in älteren Shopversionen also 5.0.x 5.1.x 5.2.x geht das per Define in der Shop Config Datei

define('CONSISTENT_GROSS_PRICES', false);

 

[Belushi]

Späte Antwort, weil ich auf der Suche nach etwas ganz anderem hier gelandet bin:

Rainer, Im Prinzip ist das die richtige Idee - bloß hat man dann leider Brutto-Preise mit x Nachkommastellen (im Debugger gut zu sehen) und entsprechende Rundungsfehler im Shop, wie z.B. 100 x 0,50€ = 50,47€.

Lässt man die Konstante auf true, treten die Rundungsfehler statt dessen in den Netto-Preisen auf. Bei uns betrifft Netto nur Händler im B2B Bereich, und die können damit besser umgehen als "Endverbraucher". Sicherheitshalber haben wir aber noch in 2 Child-Templates der "productdetails/" und des "basket/" die Netto-Ausgabe der Stückpreise auf 4 Nachkommastellen geändert, und alles andere (Zwischensummen etc.) wird 2-stellig mit dem Hinweis "gerundet" ausgegeben.
Das ist nicht gerade eine elegante Lösung, aber sie funktioniert.

Bei Brutto klappt mit 2 Nachkommastellen sowieso alles - nur hat man dann den Ärger, den zero111181 oben beschrieben hat. "CONSISTENT_GROSS_PRICES" ist also bestenfalls ein Workaround, bei dem man sich entscheiden muss, ob man sich mit dem Hammer lieber auf den linken oder rechten Daumen haut

Oder schafft es der Shop ab 5.3., sowohl Brutto als auch Netto "richtig gerundet" darzustellen, also intern immer mit 2 Nachkommastellen?

 

[OliverS]

Späte Antwort, weil ich auf der Suche nach etwas ganz anderem hier gelandet bin:

Rainer, Im Prinzip ist das die richtige Idee - bloß hat man dann leider Brutto-Preise mit x Nachkommastellen (im Debugger gut zu sehen) und entsprechende Rundungsfehler im Shop, wie z.B. 100 x 0,50€ = 50,47€.

Lässt man die Konstante auf true, treten die Rundungsfehler statt dessen in den Netto-Preisen auf. Bei uns betrifft Netto nur Händler im B2B Bereich, und die können damit besser umgehen als "Endverbraucher". Sicherheitshalber haben wir aber noch in 2 Child-Templates der "productdetails/" und des "basket/" die Netto-Ausgabe der Stückpreise auf 4 Nachkommastellen geändert, und alles andere (Zwischensummen etc.) wird 2-stellig mit dem Hinweis "gerundet" ausgegeben.
Das ist nicht gerade eine elegante Lösung, aber sie funktioniert.

Bei Brutto klappt mit 2 Nachkommastellen sowieso alles - nur hat man dann den Ärger, den zero111181 oben beschrieben hat. "CONSISTENT_GROSS_PRICES" ist also bestenfalls ein Workaround, bei dem man sich entscheiden muss, ob man sich mit dem Hammer lieber auf den linken oder rechten Daumen haut

Oder schafft es der Shop ab 5.3., sowohl Brutto als auch Netto "richtig gerundet" darzustellen, also intern immer mit 2 Nachkommastellen?

Der wirkliche "Workaround" ist eher über die Wawi. Über Kundengruppen regeln. Die Nettopreise für die Kundengruppe der Händler mit 2 Stellen, bzw. 00 als 3te und 4te Stelle, hinterlegen und die Bruttopreise für die Kundengruppe der Endkunden mit 2 Stellen hinterlegen. Beispielsweise:

29,99 als Brutto-VK und 25,2000 als Netto-VK (ist dann abgerundert von 25,2017, was die Wawi als Netto-VK angeben würde, wenn man den Brutto-VK einträgt. Zumindest bei 19% MwSt). Dann haben die Endkunden die "schönen" Bruttopreise und die Händler die "schönen" Nettopreise.

Ist aber natürlich ein bissel Arbeit. Sollte aber funktionieren. Evtl. an einem Testartikel testen ob das für euch in Frage kommt.

 

[Belushi]

Ist aber natürlich ein bissel Arbeit.

🤣😂 You made may day! 👍

Okay, das scheitert bei uns spätestens daran, dass wir Preise extern kalkulieren, und zwar ausschließlich Netto. Mit 4 Nachkommastellen.

Aber ehrlich gesagt glaube ich nicht einmal, dass der Trick funktioniert:
Die Preise werden ja Shop-intern berechnet, weil die Steuer (Tax.php) da noch reingrätscht - Stichwort OSS und so.
Und alles, das mehr als 2 Nachkommastellen hat (wohlgemerkt, im Debugger - im Shop wird immer nur 2 stellig angezeigt!) hat dann die Rundungsfehler, weil eben z.B. als Stückpreis 0,55€ angezeigt wird, man im Debugger aber sieht, dass es tatsächlich 0,54973 sind. Für die Berechnung Stückpreis x Menge wird dann intern auch die 0,54973 verwendet, nicht die angezeigten 0,55€.
Folge: Spätestens im Warenkorb steht dann 0,55€ x 100 Stk. = 54,97€ statt 55,00€. Das ist ein harmloses Beispiel, da können auch mal 50, 60 Cent Differenz vorkommen. Und mit Rabatten wird es dann richtig wild
Siehe auch Rabatte und Nettobeträge
Wie "lustig" das Kunden finden, kann sich jeder vorstellen - vor allem, wenn der Preis nicht nach unten, sondern nach oben abweicht.

Wie der Thread-Ersteller in dem verlinkten Beitrag bin ich auch der Meinung, dass alle Berechnungen intern(!) nur mit 2 Nachkommastellen gemacht werden dürfen - egal, ob Brutto oder Netto und egal ob der Shop auf fixe oder variable Bruttopreise konfiguriert ist. Alles andere führt zu irgendeinem Zeitpunkt zu Fehlern wie oben beschrieben.

Belushi

 

[OliverS]

Nun... Um Rundungsfehler bei % kommst du eigentlich nie wirklich rum.

Nettopreis: 0,5500 -> Bruttopreis 0,6545 * 100 Stück -> 65,45 €. Mit 4 Nachkommastellen gerechnet. Brutto auf 2 Nachkommastellen gerundet, wären 65,00 € gewesen. Würdest du dem Finanzamt also sagen, dein Nettopreis wär 55 Cent, dann würde dich das Finanzamt fragen, wo die restlichen 45 Cent MwSt sind.
Nettopreis: 0,5500 -> 100 Stück davon -> 55€ Netto (+ MwSt wären das dann auch -> 65,45 € Brutto. Ganz ohne mit 4 Nachkommastellen zu rechnen. 65 € Brutto wären bei dem Nettopreis also eigentlich ziemlich falsch, auch wenn ein gerundeter Bruttopreis von 0,65 € angezeigt wird)

Du hast in diesem Fall also: 55 € für die Händler ("schöner" Preis) und 65,45 € für die Endkunden.

Nettopreis: 0,5462 -> Bruttopreis 0,649978 * 100 -> 64,9978 € -> 65,00 €. Hättest du den Nettopreis hier gerundet, wären die 65 € Brutto wieder falsch. Hättest du den Bruttopreis gerundet, hätte sich nichts geändert.
Nettopreis: 0,5462 -> 100 Stück davon -> 54,62 € Netto -> 64,9978 €, was ebenfalls auf 65,00 € Brutto gerundet werden würde. Hier stimmen die 65,00 € für den Bruttopreis in Bezug auf den Nettopreis überein. Aber Händler zahlen halt nur 54,62 € bei einem angezeigten Nettopreis von 0,55 €.

In diesem Fall hast du: 54,62 € für die Händler, und 65,00 € ("schöner" Preis) für die Endkunden.

Je öfter du rundest, desto stärker weicht der Betrag ab. Bei 0,55 Netto und 19% MwSt. hast du bei einmal runden schon 45 Cent zu wenig. Daher fakturierst du in dem Fall für Brutto und nicht für Netto. Umgekehrt hast du dann, wenn du für den Bruttopreis fakturierst, einen Netto-Preis von 54,62 € bei angezeigten 0,55 €. Deswegen musst du im Händlerfall für den Netto-Preis fakturieren.

Wenn du darauf Rabatt gibst, nutzt dir das natürlich nichts mehr, weil dann wieder gerundet werden muss und entsprechend Fehler entstehen. Aber du bekommst auch keine stimmigen Brutto- und Nettopreise hin, wenn du jedes Mal auf 2 Stellen rundest.

 

[Belushi]

Hallo OliverS,

Du Beschreibst das Problem perfekt!

Dem letzten Satz muss ich aber widersprechen:

Aber du bekommst auch keine stimmigen Brutto- und Nettopreise hin, wenn du jedes Mal auf 2 Stellen rundest.

Der JTL- Shop ist unser Zweitshop für FR/BE/LU, unser Hauptshop läuft unter Shopware 6 (ja, diese frecherweise als " stable release" gekennzeichnete "ewige Beta" 😣 ). Der hat zwar massig andere Probleme, aber das mit der Rundung bekommt er hin: Zwar liegen auch dort die Preisdaten mit 4 Nachkommastellen in derShop-DB vor, gerechnet wird aber sowohl Brutto als auch Netto nur 2-stellig. Dadurch sind die Daten von der Produktseite bis zum Checkout und der Bestellung in beiden Modi zu annähernd 100% konsistent. Und das trotz Live-Umschalter Brutto/Netto und OSS-Plugin.
Das war der Hauptgrund, damals von JTL-4 auf Shopware umzusteigen, weil wir da keine Probleme bei unserem gemischten B2B / B2C Geschäft hatten. Mit dem parallel getesteten JTL-5 war das schlicht unmöglich.

Nur, damit das klar ist: Ich will hier auf gar keinen Fall Werbung für Shopware machen (siehe auch Trustpilot-Bewertungen)!!
Jedem, der sich darauf einlässt, muss klar sein, dass er oder sie massenhaft fehlende Funktionen per teurem Plugin-Abo nachrüsten muss (Willkommen in der Update-Hölle!), und selbst vorhandene Funktionen teilweise Fehler aufweisen - von der massenhaften Notwendigkeit, neue Produkte im Shop-Backend nachzubearbeiten (SEO-Url, Standard-Kategorie für Breadcrumbs u.a.) mal ganz abgesehen. Das Ding bereitet an Stellen schlaflose Nächte, die bei JTL "out of the Box" funktionieren; davon ist SW Lichtjahre entfernt.
Aber die Brutto-Netto-Geschichte war wegen des gemischten B2C/B2B Umfeldes und EU-weiter Lieferung einfach das KO-Kriterium für JTL, weswegen wir trotz aller anderen Probleme und Bauchschmerzen doch zu SW gewechselt sind. Mit fixen Brutto-Preisen im JTL-Shop funktioniert's zwar so halbwegs, aber wir müssen MwSt-Sätze von 17% (Luxemburg) bis 25% (Dänemark) abdecken - da ist das keine tragbare Option.

Wie Shopware das mit der Rundung intern macht, konnte ich übrigens nicht herausfinden, weil die Abläufe im Core dank Symfony kaum noch nachzuvollziehen sind. Aber durch Praxistests sehe ich das so:

$vkDB = Verkaufspreis/Stück in Shop-Datenbank, 4 Nachkommastellen
$vkNetto = round( $vkDB, 2)
$vkBrutto = round( $vkDB * ( (100 + $MwSt) / 100) , 2)

Der Brutto wird also auch basierend auf dem $vkDB berechnet, nicht auf Basis des zuvor ermittelten $vkNetto - andernfalls gäbe es im Live-Shop größere Rundungsfehler zwischen Brutto- und Netto-Darstellung, bzw. beim Wechsel des Lieferlandes (OSS). Es scheint also keine sukzessive Rundung zu geben, da alle weiteren Berechnungen im Warenkorb und Checkout (einschließlich Rabatten) konsistent sind. Einzig zu teilbaren Mengen kann ich nichts sagen (also z.B. 0,5 Meter), da bei uns nur Integer-Mengen vorkommen. Wird aber vermutlich auch korrekt gerundet.

Einen Haken gibt es natürlich:
Es kommt bei Bestellungen in der Wawi gelegentlich zu Differenzen zwischen dem Verkaufspreis im Shop und dem im Artikel hinterlegten Verkaufspreis. Aber es ist einfacher, das dann dort zu korrigieren, als sich mit den Kunden über offensichtliche "Rechenfehler" im Shop zu streiten.

Belushi