MwSt 16% ab 1.7.2020

[ShopMann]

vor 1 Minute schrieb Jörg Saxtec:

Du darfst mich gern anrufen, anmailen, anskypen und auch persönlich auf eine Tasse Kaffee vorbeikommen

Klasse 😁 Und wo finde ich all die Kontaktdaten? 🙄

[rictools]

vor 42 Minuten schrieb Viaceslav:

Haben Sie auch den Namen den Steuersätzen geändert oder nur die Werte? Ich vermute, wenn Sie nur die Werte ändern aber nicht die Steuersatznamen, dann werden keine neue Steuersatz-ID erzeugt und trotzdem alle Brutto-Warenpreise erneuern sich. Oder?

Ich habe den Namen (in dem sich die 19 findet) unverändert gelassen und nur den Wert von 19 auf 16 geändert (Produkte mit reduziertem MwSt.-Satz habe ich nicht), Prestashop hat automatisch (so wie ich ja auch geschrieben habe) einen neuen Steuersatz mit der ID 30 angelegt, der mit der ID 1 wird nicht mehr in der Liste angezeigt. Alle Preise inkl. MwSt. sind jetzt entsprechend niedriger.

vor 33 Minuten schrieb Viaceslav:

Wahrscheinlich noch eine dumme Frage von mir, trotzdem, werden mit dem Modul auch die MwSt für den Versand korrigiert? Und was ist mit den Import-Modulen? Wir importieren oder aktualisieren regelmäßig mehrere tausende Waren über ein Import-Module. Berücksichtigt das alles Ihres Modul?

Die Versandkosten werden auch entsprechend reduziert im Shop angezeigt, ohne dass ich da etwas bearbeiten mußte.

Beim Import kommt es wohl darauf an, ob dieser die Netto- oder Bruttopreise übermittelt, der jeweils andere Preis wird ja von Prestashop automatisch errechnet. Möglicherweise muss in der Importdatei die MwSt.-ID oder der -Satz geändert werden, wenn mehrere MwSt.-Sätze verwendet werden und es deshalb ein entsprechendes Feld gibt.

Edited June 30, 2020 by rictools
Ihr schreibt so schnell, da hat man gar keine Zeit mehr den Text noch mal zu checken vor dem Absenden ... (see edit history)

[Jörg Saxtec]

2 minutes ago, Viaceslav said:

Klasse 😁 Und wo finde ich all die Kontaktdaten? 🙄

Im Impressum, in unserer Rechnung, auf unserer Webseite

 

[ShopMann]

vor 47 Minuten schrieb Jörg Saxtec:

Weitere Module, Versanddienste, was auch immer musst Du dann manuell der neu generierten Steuer zuweisen. 

Ich habe mich gerade bei den Versandeinstellungen umgesehen. Da gibt es keine Möglichkeit den MwSt. auf den Versand zu steuern. Die Aufgabe übernimmt das Rechtsicherheitsmodul. Und bei Einstellungen von Rechtssicherheitsmodul gibt es auch keine Möglichkeit den MwSt zu steuern. Es ist mir jetzt unklar wie soll dabei die Umstellung von MwSt. auf den Versand funktionieren.

[Gurkcity]

Das Rechtssicherheitsmodul setzt voraus, dass die Bruttopreise bei den Versanddienstleistern angegeben werden. Wer also das Modul "Rechtssicherheit" im Einsatz hat, sollte nach der Umstellung keine Probleme haben. Aus dem Bruttobetrag wird für die Bestellung/ Rechnung der Steuerbetrag errechnet. Egal ob mit Anhebung der Nettopreise (bei Beibehaltung der Bruttopreise) oder anders herum.

Wer also auch hier bei den Versandkosten den Steuervorteil an den Endverbraucher weiter geben möchte, kann das bei den Versanddienstleistern im Nachgang der Steuerumstellung machen.

Viele Grüße

Chris

Edited July 1, 2020 by Gurkcity
Falschaussage (see edit history)

[ShopMann]

Am 29.06.2020 um 4:28 PM schrieb Gurkcity:

denn wir haben letzte Woche auch ein neues Modul entwickelt und in unserem Shop veröffentlicht, mit dem sich die Steuersätze auf Knopfdruck ändern lassen. 😉

 

https://www.onlineshop-module.de/mehrwertsteuer-aenderung-ps17.html

da in der Kompatibilitätsliste fehlt unser Prestashop der Version 1.7.2.4.
Ist der Modul nicht kompatibel mit dem Prestashop 1.7.2.4?

[Jörg Saxtec]

16 minutes ago, Viaceslav said:

https://www.onlineshop-module.de/mehrwertsteuer-aenderung-ps17.html

da in der Kompatibilitätsliste fehlt unser Prestashop der Version 1.7.2.4.
Ist der Modul nicht kompatibel mit dem Prestashop 1.7.2.4?

Das sind unsere: 

https://tinyurl.com/yb68w73t - für PrestaShop 1.6

https://tinyurl.com/yabx5acg - für PrestaShop 1.7

[rictools]

vor einer Stunde schrieb Gurkcity:

Das Rechtssicherheitsmodul setzt voraus, dass die Bruttopreise bei den Versanddienstleistern angegeben werden. Wer also das Modul "Rechtssicherheit" im Einsatz hat, sollte nach der Umstellung keine Probleme haben. Aus dem Bruttobetrag wird für die Bestellung/ Rechnung der Steuerbetrag errechnet.

Also bei mir (1.6) wurden mit der Steuerumstellung auch die Versandkosten reduziert, ich habe jetzt übrigens auch eine Bestellung mit PayPal-Zahlung erhalten, auch da alles OK.

[Gurkcity]

1 hour ago, Viaceslav said:

https://www.onlineshop-module.de/mehrwertsteuer-aenderung-ps17.html

da in der Kompatibilitätsliste fehlt unser Prestashop der Version 1.7.2.4.
Ist der Modul nicht kompatibel mit dem Prestashop 1.7.2.4?

Die neueste Version 1.1.0 ist auch kompatibel mit 1.7.2.4. Habe es eben selbst nochmal getestet.

Jörg hat sogar eine Version, die mit 1.6 kompatibel ist.

[Gurkcity]

44 minutes ago, rictools said:

Also bei mir (1.6) wurden mit der Steuerumstellung auch die Versandkosten reduziert, ich habe jetzt übrigens auch eine Bestellung mit PayPal-Zahlung erhalten, auch da alles OK.

Vollkommen korrekt, da habe ich mich geirrt. Habe das eben getestet (in einiger 1.7er Versionen von 1.7.2.4 bis 1.7.6.5). Die Versandkosten werden als Netto bei den Versanddienstleistern in die Eingabemasken eingetragen. Diese werden mit der Steuerumstellung auch reduziert. Wer also den gleichen Versandkostenbetrag beibehalten möchte, muss hier nochmal eingreifen und den Wert um den Steuermultiplikator (1,19/1,16) erhöhen.

[Wuschel]

1 hour ago, Gurkcity said:

Vollkommen korrekt, da habe ich mich geirrt. Habe das eben getestet (in einiger 1.7er Versionen von 1.7.2.4 bis 1.7.6.5). Die Versandkosten werden als Netto bei den Versanddienstleistern in die Eingabemasken eingetragen. Diese werden mit der Steuerumstellung auch reduziert. Wer also den gleichen Versandkostenbetrag beibehalten möchte, muss hier nochmal eingreifen und den Wert um den Steuermultiplikator (1,19/1,16) erhöhen.

Soweit ich weiß, war EU Legal (bis 1.6.1.2) das letzte Rechtssicherheits-Modul, mit dem man die Versandkosten brutto erfassen konnte. AEUC ließ immer nur Nettowerte zu. Von daher war es klar, dass sich durch die MwSt-Senkung auch die VersandKosten verbilligen würden, was natürlich keiner will.

Edited June 30, 2020 by Wuschel (see edit history)

[ShopMann]

vor 3 Stunden schrieb Jörg Saxtec:

Das sind unsere: 

https://tinyurl.com/yb68w73t - für PrestaShop 1.6

https://tinyurl.com/yabx5acg - für PrestaShop 1.7

Ich habe gerade das Modul installiert und sofort kommt die erste Frage:

Modul fragt an welcher Steuerregel die 16% Zuordnung muss angewandt werden. Ok, bei uns sind die untere zwei aktuell sind.
Aber warum fragt das Modul nur nach 16% Zuordnung? Und was ist mit 5%?
In Youtube Video der Feld gar nicht zu sehen.

Jetzt sitze ich und hoffe, daß du noch wach bist und ich bekomme eine Antwort )

Edited June 30, 2020 by Viaceslav (see edit history)

[Gurkcity]

Schau doch mal bei einem Produkt, das mit 19% erfasst wurde, wie die Steuerregel heißt. Diese wählst Du dann in dem Modul aus (so vermute ich es zumindest, ohne das Modul zu kennen).

Viele Grüße

Chris

[ShopMann]

vor 1 Minute schrieb Gurkcity:

Schau doch mal bei einem Produkt, das mit 19% erfasst wurde, wie die Steuerregel heißt. Diese wählst Du dann in dem Modul aus (so vermute ich es zumindest, ohne das Modul zu kennen).

Viele Grüße

Chris

Ich weiß genau welche Regeln zur Zeit angewandt sind: die zwei untere - DE VAT 19% und DE VAT 7%.

Aber im Modul gibt es eine Auswahl nur für eine einzige Regel und zwar Zuordnung für 16% - sieht man in der Bildschirmabbildung oben.

Und wie soll die 5% Zuordnung bestimmt werden?

Oder nach dem ersten Durchlauf kommt die Möglichkeit?

Im YouTube Video und sonst nirgendwo  gibt es keine Erklärung, kein Hinweis.

Mehr noch. Ich habe bereits die MwSt.-Aktualisierung mit dem Modul gestartet und nach ein Paar Sekunden kam eine Überraschung: HTTP ERROR 500.

Jetzt sitze ich im ....

 

[ShopMann]

Also ich habe jetzt doch die Steuersatzwerte einfach geändert so, wie es von Wuschel beschrieben wurde. 
Ich habe danach auch den Cache per Erweiterte Einstellungen -> Leistung -> gelöscht und den Browser-Cache per STRG+F5 geleert.

Trotzdem die Preise haben sich gar nicht geändert.

Edited July 1, 2020 by Viaceslav (see edit history)

[Gurkcity]

Poste doch mal Deine SQL-Statements. Vielleicht hast Du etwas vergessen. Hast Du vielleicht Caching Module im Einsatz?

zum 500er Fehler: schau mal in die Error-Logs des Servers. Ansonsten schalte mal den Debug Modus im Shop an (Erw Einstellungen > Leistung) und schicke den Request nochmal ab.

 

[Whiley]

Viaceslav,  erklär doch erstmal was du vorhast. Willst du die MwSt-Senkung an deine Kunden weitergeben oder nicht?

Sollen also, nach der MwSt-Änderung die Bruttopreise gleich sein wie vorher oder sollen sie niedriger sein?

[ShopMann]

vor 15 Minuten schrieb Whiley:

Viaceslav,  erklär doch erstmal was du vorhast. Willst du die MwSt-Senkung an deine Kunden weitergeben oder nicht?

Ja, ich will die Senkung an Kunden weitergeben.

Ich habe gerade entdeckt, daß nach der Änderung der beiden Steuersätzen die Steuerregel für Deutschland blieben bei 19% stecken und 7% wurden doch auf 5% gesenkt.

Aus welchem Grund kann ich nicht nachvollziehen.

Das ist warscheinlich die Ursache dafür, daß wie ich sehe die Bücherpreise sind gesenkt (MwSt jetzt bei denen 5%), die andere Waren aber bleiben mit MwSt 19%.

Komischerweise aber der Versandpreis hat sich gar nicht gesenkt.

 

Edited July 1, 2020 by Viaceslav (see edit history)

[ShopMann]

So, ich habe jetzt auch die Steuerregel für Deutschland DE VAT 19 manuell auf 16% umgestellt und jetzt alle Waren haben die richtige Preise und MwSt.

Aber der Versandpreis blieb unverändert - 4,80 Euro für Deutschland.

Wieso?

[ShopMann]

Das nächste Problem fand ich bei Rechnungen, die in unserem Shop via Module m4pdf generiert werden.

Die MwSt-Werte sind hier schon die richtige aber die Steuersatzbezeichnungen werden so wie sie sind übernommen )

Spricht etwas dagegen, daß ich nicht nur die Werte von Steuersätzen und Steuerregeln ändere, sondern auch die Bezeichnungen?

 

[Gurkcity]

Ja, wenn das so benutzt wird, würde ich sinnigerweise auch die Bezeichnungen abändern.

Wir haben das bei den Shopbetreibern, die wir manuell umgestellt haben, direkt in der Datenbank Tabelle ps_tax_lang geändert

[rictools]

Zumindest bei 1.6 wird normalerweise in der Spalte Steuersatz nicht die Bezeichnung der Steuer, sondern nur der Prozentsatz angegeben so wie das auch üblich ist. Es sollte aber auch kein Problem sein, die Bezeichnung zu ändern.

[Wuschel]

14 minutes ago, Viaceslav said:

Rechnungen, die in unserem Shop via Module m4pdf generiert werden.

Die MwSt-Werte sind hier schon die richtige aber die Steuersatzbezeichnungen werden so wie sie sind übernommen )

M4PDF arbeitet, glaube ich, mit eigenen Datenbanktabellen. Möglicherweise muss da auch etwas geändert werden. Aber da bin ich mir nicht sicher.

[ShopMann]

vor 7 Minuten schrieb Gurkcity:

Ja, wenn das so benutzt wird, würde ich sinnigerweise auch die Bezeichnungen abändern.

Wir haben das bei den Shopbetreibern, die wir manuell umgestellt haben, direkt in der Datenbank Tabelle ps_tax_lang geändert

So, ich habe zuerst nur die Steuersatzbezeichnungen in Deutsch korrigiert.

Jetzt die Rechnung sieht gut aus.

Bleibt noch zu prüfen wie sieht es aus bei Warenimport durch Importmodule Product Catalog (CSV, Excel) Import

und mit der Synchronisierung mit Ebay durch das Modul FastBay.

 

[ShopMann]

Komisch ist nur, daß der Brutto-Versandpreis unverändert blieb und stattdessen der Nettopreis wurde angepasst.

So komisch funktioniert das Rechtssicherheitmodul?

[ShopMann]

So, es scheint alles in Ordnung zu sein. Auch mit dem Import, auch mit Ebay.
Jetzt kann ich wohl endlich schlafen gehen )

[Markus Nowakowski]

Ich habe das Tool PrestaShop Tax Switcher 2020 auch installiert. Die Preise haben alle funktioniert. Jedoch musste ich das DB Backup selber machen, da das Script sonst rumspinnt. Muss man die Versandkosten nun auch anpassen?

 

 

Edited July 1, 2020 by Markus Nowakowski (see edit history)

[Bergmann]

Guten Morgen.

Das Wetter draußen verleitet hoffentlich genug Kunden zum Einkauf... 

Fazit der Anpassung der MwSt.: Läuft. Danke an Saxtec für das aus dem Boden gestampften Modul. Im ersten Durchlauf wollte es nicht, aber danach habe ich das DB-Backup ausgeschaltet und das (sowieso...) von Hand gezogen. Danach alles gut.

Versandkosten geprüft und angepasst.
Einzige Herausforderung die sich heute morgen ergeben hat, war die Buchpreisbindung, die wir beachten mussten. Da wir wegen Laden und Shop parallel-betrieb die Bruttopreise beibehalten haben, hat sich das aber auch geregelt. Einzig die Verwirrung, welcher Satz denn jetzt gilt. Nach aktuellem Wissensstand gilt (natürlich...) der Satz von 5%, aber der Brutopreis muss dem aus der Preisbindung entsprechen.

Da hat jemand wieder ganz ausführlich über Sinn und Zweck der ganzen Sache für die Einzelhändler nachgedacht....

Wünsche angenehmen Tag und gute Geschäfte.

Bergmann

[Wuschel]

1 hour ago, Markus Nowakowski said:

Ich habe das Tool PrestaShop Tax Switcher 2020 auch installiert. Die Preise haben alle funktioniert. Jedoch musste ich das DB Backup selber machen, da das Script sonst rumspinnt. Muss man die Versandkosten nun auch anpassen?

Ich glaube, da musst du noch ein bisschen mehr anpassen. Vielleicht fehlt mir da die nötige Phantasie, aber mir erschließt sich wirklich nicht, wie diese MwSt-Beträge errechnet wurden, denn die scheinen mir nicht zu stimmen, ganz egal ob es jetzt 19 oder nur 16% wären. Auch die Versandkosten scheinen bei diir steuerfrei zu, denn sonst wäre die Differenz wohl noch größer.

(Und an den Übersetzungen würde ich auch noch arbeiten ....)

[Wuschel]

1 hour ago, Bergmann said:

die Buchpreisbindung, die wir beachten mussten.

Darüber haben wir uns heute morgen auch unterhalten. Daran scheint wirklich niemand gedacht zu haben.

[Wuschel]

7 hours ago, Viaceslav said:

Komisch ist nur, daß der Brutto-Versandpreis unverändert blieb und stattdessen der Nettopreis wurde angepasst.

So komisch funktioniert das Rechtssicherheitmodul?

Wenn es so funktioniert, ist es völlig richtig. Scheint aber nicht bei allen so zu sein. Welche Prestashop-Version und welches Rechtssicherheitsmodul hast du denn?

[Netprofit]

Kudne will gleiche Brutto-Preise, daher reicht Änderung der Steuersätze nicht.

SQL Befehle funktionieren, SQL rundet jedoch so stark, so dass es am Ende nicht mehr stimmt. Statt 11,37 Euro ergibt das dann 11,67 Euro und wieder einen

Kann man da was machen?

[Tobias]

Bekomme beim Modul-Upload (gc_taxtoggle_1.1.0) einen "500 Internal Server Error". Hatte ich bisher bei keinem anderen Modul und weiß dementsprechend gerade nicht so wirklich weiter. Habe es jetzt mehrmals versucht, irgendwann ging dann zwar die Installation durch, aber ich kam mit demselben Fehler nicht in die Einstellungen und eine Deinstallation war auch nicht möglich. Scheint also nicht korrekt zu installieren und ich musste dann ein Backup von letzter Nacht aufspielen, um das Modul wieder loszuwerden. 

Hat jemand eine Idee, woran es liegen könnte?

Edited July 1, 2020 by Tobias (see edit history)

[rictools]

vor 3 Stunden schrieb Markus Nowakowski:

Ich habe das Tool PrestaShop Tax Switcher 2020 auch installiert. Die Preise haben alle funktioniert. Jedoch musste ich das DB Backup selber machen, da das Script sonst rumspinnt. Muss man die Versandkosten nun auch anpassen?

Da wir nicht wissen, ob deine 4,78 € Versandkosten nun inkl. 19 % oder 16 % oder ganz ohne MwSt. sind können wir diese Frage schwer beantworten ...

Mit dem Pfeil auf dem Screenshot zeigst du nicht auf die Versandkosten, sondern auf die Zeile mit der MwSt., da muß offenbar der Text in den Übersetzungen geändert werden.

vor 1 Stunde schrieb Netprofit:

SQL Befehle funktionieren, SQL rundet jedoch so stark, so dass es am Ende nicht mehr stimmt. Statt 11,37 Euro ergibt das dann 11,67 Euro

Das kann nichts mit der Rundung zu tun haben, vielleicht wurden Punkt und Komma verwechselt?

vor einer Stunde schrieb Tobias:

Bekomme beim Modul-Upload (gc_taxtoggle_1.1.0) einen "500 Internal Server Error". Hatte ich bisher bei keinem anderen Modul und weiß dementsprechend gerade nicht so wirklich weiter. Habe es jetzt mehrmals versucht, irgendwann ging dann zwar die Installation durch, aber ich kam mit demselben Fehler nicht in die Einstellungen und eine Deinstallation war auch nicht möglich. Scheint also nicht korrekt zu installieren und ich musste dann ein Backup von letzter Nacht aufspielen, um das Modul wieder loszuwerden.

Da müßtest du wenigstens mal deine Prestashop-Version verraten, hast du die dafür richtige Modulversion verwendet? Vielleicht auch deine PHP-Version. Was den Error 500 angeht, aktiviere Error Reporting für eine (hoffentlich) aussagekräftige Fehlermeldung.

[Whiley]

vor 1 Stunde schrieb Netprofit:

SQL Befehle funktionieren, SQL rundet jedoch so stark, so dass es am Ende nicht mehr stimmt. Statt 11,37 Euro ergibt das dann 11,67 Euro und wieder einen

Wir haben die Umstellung in zig Shops gemacht, in keinem Fall kam es zu Rundungsabweichungen (bei ganz ganz  wenigen lag die Differenz bei 1 Cent).

Poste mal die Datenbankinhalte für diesen Fall vor und nach Ausführung der sql Anweisung mit allen Nachkommastellen.

[Gurkcity]

20 minutes ago, rictools said:

1 hour ago, Tobias said:

Bekomme beim Modul-Upload (gc_taxtoggle_1.1.0) einen "500 Internal Server Error". Hatte ich bisher bei keinem anderen Modul und weiß dementsprechend gerade nicht so wirklich weiter. Habe es jetzt mehrmals versucht, irgendwann ging dann zwar die Installation durch, aber ich kam mit demselben Fehler nicht in die Einstellungen und eine Deinstallation war auch nicht möglich. Scheint also nicht korrekt zu installieren und ich musste dann ein Backup von letzter Nacht aufspielen, um das Modul wieder loszuwerden.

Da müßtest du wenigstens mal deine Prestashop-Version verraten, hast du die dafür richtige Modulversion verwendet? Vielleicht auch deine PHP-Version. Was den Error 500 angeht, aktiviere Error Reporting für eine (hoffentlich) aussagekräftige Fehlermeldung.

Ich habe mit dem Kunden direkt Kontakt aufgenommen. Danke Whiley, für den schnellen Support 😉

[ShopMann]

vor 5 Stunden schrieb Bergmann:

Einzige Herausforderung die sich heute morgen ergeben hat, war die Buchpreisbindung, die wir beachten mussten.

Und wenn der Verlag sich außerhalb von Deutschland oder sogar außerhalb von EU befindet aber die Bücher werden im Online-Shop auch für Kunden in Deutschland und anderen EU-Staaten verkauft?

[ShopMann]

vor 3 Stunden schrieb Wuschel:

Wenn es so funktioniert, ist es völlig richtig. Scheint aber nicht bei allen so zu sein. Welche Prestashop-Version und welches Rechtssicherheitsmodul hast du denn?

Prestashop 1.7.2.4. Modul Rechtssicherheit 2.0.4.

Und bei welchen Versionen funktioniert das anders?

[rictools]

vor 24 Minuten schrieb Viaceslav:

Und wenn der Verlag sich außerhalb von Deutschland oder sogar außerhalb von EU befindet aber die Bücher werden im Online-Shop auch für Kunden in Deutschland und anderen EU-Staaten verkauft?

Das ist ein sehr spezielles Rechtsthema, das mit Prestashop und insbesondere auch dem Thema dieses Threads nichts zu tun hat.

[rictools]

vor 22 Minuten schrieb Viaceslav:

Prestashop 1.7.2.4.

Das ist ja schon eine fast historisch zu nennende Version der 1.7-Reihe, wenn möglich, solltest du auf eine aktuelle Version updaten (gilt generell für 1.7 wegen der zahlreichen Bugs vor allem am Anfang, dazu kommt noch ein gravierendes Sicherheitsproblem).

[Bergmann]

vor 4 Minuten schrieb rictools:

Das ist ein sehr spezielles Rechtsthema, das mit Prestashop und insbesondere auch dem Thema dieses Threads nichts zu tun hat.

Jap. Da stimme ich voll zu. Wende Dich dafür an deinen Steuerberater bzw. die Rechtsberatung....

LG

[Tobias]

Kurze Ergänzung zu meiner Problematik mit dem 500er Server-Fehler: Es lag an einer "veralteten" PHP-Version. Habe nun auf PHP 7.2.31 aktualisiert und das Modul funktioniert reibungslos. Nur, falls jemand dasselbe Problem hat. Danke an Gurkcity für die schnelle Hilfe.

[rictools]

- - -

Edited July 2, 2020 by rictools (see edit history)

[Claudiocool]

Kleiner Fauxpas für mich....

Ich habe die Steuer geändert, alles sah sehr gut aus, nur hatte gestern jede 2. bestellung mit PayPal einen Rundungsfehler drin. Also mussten wir gestern alle Bruttopreise nachziehen. Ein Artikel, der jetzt 5,31 kostet, wurde bei einer Menge ab 4 Stück um einen Cent falsch gerundet, der Shop hatte dann einen Cent mehr verlangt, als PayPal bezahlt hat. da ich jetzt nicht im Modul pfuschen wollte, um PayPal abzugewöhnen, unsere Bestellung selbst nochmal zu kalkulieren, habe ich jetzt alle Preise nochmal mit ein paar Nullen (also 5,310000 EUR) nachgezogen. Ebenso auch bei den Varianten.

Eventuell hätte man es auch anders lösen können, aber so ging es am Schnellsten und ohne Risiko, dass dann an anderer Stelle Kalkulationsfehler entstehen, wenn man da an den Datenstrukturen rumbastelt. Mit der Prestoolsuite war das in einer Stunde (bei 1000 Artikeln und ca. 250 davon mit Varianten, die auch Aufpreise kosten) erledigt.

Also, falls auch jemand plötzlich vermehrt Fehler bei der Bezahlung bekommt, weil da ein Rundungsfehler drin ist, das wäre ein Ansatz.

[ShopMann]

vor 18 Stunden schrieb Tobias:

Kurze Ergänzung zu meiner Problematik mit dem 500er Server-Fehler: Es lag an einer "veralteten" PHP-Version. Habe nun auf PHP 7.2.31 aktualisiert und das Modul funktioniert reibungslos. Nur, falls jemand dasselbe Problem hat. Danke an Gurkcity für die schnelle Hilfe.

Nicht unbedingt. Bei mir läuft php 7.2 und trotzdem 500 Fehler. Aber heute gab es eine Email mit neuer Version. Eventuell wurde da das Problem behoben. Obwohl stellte ich schließlich alle Steuersenkungen manuell ohne Modul erfolgreich um.

Edited July 2, 2020 by Viaceslav (see edit history)

[Shad86]

vor 2 Stunden schrieb Claudiocool:

Also, falls auch jemand plötzlich vermehrt Fehler bei der Bezahlung bekommt, weil da ein Rundungsfehler drin ist, das wäre ein Ansatz.

Die Erfahrung mit Paypal habe ich auch gemacht. Wir haben jetzt im Backend alle Preise dreistellig nach dem Komma eingegeben. Scheint soweit zu funktionieren. Bisher auch nach der MwSt. Umstellung, noch keine Probleme. Wird aber weiter beobachtet.

[Claudiocool]

Dreistellig dürfte für Stückzahlen im Zweistelligen Bereich reichen. Ich habe es gestern nach den fehlermeldungen durchexerziert, und daher habe ich 4 Stellen nach dem Komma gesetzt, geht mit Prestool-Suite recht schnell, eventuell kann man da auch versuchen, ein SQL-Script zu basteln, bzw, es mit einem PHP-Script geradeziehen. Aber nachdem das in einer Stunde ereldigt war und ich im Umkehrschluss nicht jeden Artikel prüfen musste, ob es da irgendwelche preise verbogen hat, hielt sich dieser Aufwand in Grenzen.

Bei einem Script könnte man versuchen, den Preis durch z.B. 10000 zu teilen, wenn der Betrag 6 Stellen nach dem Komma hat und dann eben wieder mit 10000 zu multiplizieren, mit etwas Glück vergisst er dabei dann alles, was nach der 2. Stelle hinterm Komma stand., allerdings darf man das dann nur beim Bruttopreis machen und muss den dann wieder zurück in die Datenbank schreiben, so dass der Nettopreis neu gerechnet wird.

Also Preis auslesen, Rechenoperation drüberjagen und zuletzt zurückschreiben. So in etwa könnte das dann funktionieren.

Edited July 2, 2020 by Claudiocool (see edit history)

[rictools]

Drei- oder vierstellig? Sorry, das ist doch völlig egal, die Preise, die überwiegend im Shop ausgewiesen werden (ohne oder inkl. MwSt.) sollten nur 2 Nachkommastellen (und danach von mir aus noch ein, zwei oder auch mehr Nullen ...) haben, einer von beiden Preisen ist aber immer krumm. Und bei einer Änderung des MwSt.-Satzes ergeben sich logischerweise krumme Bruttopreise, der einzige Weg ist dann tatsächlich, diese auf zwei Nachkommastellen zu runden wenn man Bruttopreise im Shop ausweist (nur ob sich dieser Aufwand für die paar Monate lohnt wenn man die MwSt.-Senkung an die Kunden weitergibt ...).

[Pete78]

Hi, sowas in der Art wäre doch auch denkbar, damit man nicht ganz so viele Probleme bei den Rundungen hat (gerade ältere PayPal Modul Versionen verschlucken sich ja gerne)

Beziehe mich mal auf den ersten Post

UPDATE `ps_product` SET `price` = ROUND(1.16*`price`*1.19/1.16,2)/1.16 where `id_tax_rules_group` = 1;
UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`*1.19/1.16,2)/1.16 where `id_tax_rules_group` = 1;
 

Muss man dann noch für Attribute und unit prices und 5/7% Produkte  anpassen bzw. erweitern..

[steffran]

On 7/2/2020 at 10:46 AM, Claudiocool said:

Kleiner Fauxpas für mich....

Ich habe die Steuer geändert, alles sah sehr gut aus, nur hatte gestern jede 2. bestellung mit PayPal einen Rundungsfehler drin. Also mussten wir gestern alle Bruttopreise nachziehen. Ein Artikel, der jetzt 5,31 kostet, wurde bei einer Menge ab 4 Stück um einen Cent falsch gerundet, der Shop hatte dann einen Cent mehr verlangt, als PayPal bezahlt hat. da ich jetzt nicht im Modul pfuschen wollte, um PayPal abzugewöhnen, unsere Bestellung selbst nochmal zu kalkulieren, habe ich jetzt alle Preise nochmal mit ein paar Nullen (also 5,310000 EUR) nachgezogen. Ebenso auch bei den Varianten.

Eventuell hätte man es auch anders lösen können, aber so ging es am Schnellsten und ohne Risiko, dass dann an anderer Stelle Kalkulationsfehler entstehen, wenn man da an den Datenstrukturen rumbastelt. Mit der Prestoolsuite war das in einer Stunde (bei 1000 Artikeln und ca. 250 davon mit Varianten, die auch Aufpreise kosten) erledigt.

Also, falls auch jemand plötzlich vermehrt Fehler bei der Bezahlung bekommt, weil da ein Rundungsfehler drin ist, das wäre ein Ansatz.

Genau das Problem habe ich auch. Bei Bestellungen - die in höherer Stückzahl den gleichen Artikel beinhalten - kommt es zu Abweichungen zwischen 1 bis 3 Cent. Habe ich das richtig verstanden, dass ich den Bruttopreis um auf 4 nachkommastellen anpassen muss? Also 7,99 auf 7,9900 Euro?

Hatte erst gehofft, dass man das ganze mit den Rundungseinstellungen irdenwie fixen kann.

Viele Grüße

Stefan

[Pete78]

1 minute ago, steffran said:

Genau das Problem habe ich auch. Bei Bestellungen - die in höherer Stückzahl den gleichen Artikel beinhalten - kommt es zu Abweichungen zwischen 1 bis 3 Cent. Habe ich das richtig verstanden, dass ich den Bruttopreis um auf 4 nachkommastellen anpassen muss? Also 7,99 auf 7,9900 Euro?

Hatte erst gehofft, dass man das ganze mit den Rundungseinstellungen irdenwie fixen kann.

Viele Grüße

Stefan

Wurde die Umstellung von 19 auf 16 bereits gemacht, kann man im nachhinein noch runden...

ohne gewähr, bitte Backup machen oder ggf. mit einem Produkt testen

UPDATE `ps_product` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;
UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;

[Jörg Saxtec]

4 minutes ago, Pete78 said:

Wurde die Umstellung von 19 auf 16 bereits gemacht, kann man im nachhinein noch runden...

ohne gewähr, bitte Backup machen oder ggf. mit einem Produkt testen

UPDATE `ps_product` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;
UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;

Da wäre aber ganz vorsichtig, solche Tipps zu geben. In der Datenbank sollte man nicht ohne grundlegende Kenntnisse der PrestaShop Core und Modulprogrammierung herumpfuschen. Im schlimmsten Fall ist die Datenbank und damit der Shop völlig hinüber. Wenn man weiß, was man tut, ist das obengenannte ein guter Anfang. Kann aber, wiegesagt, böse in die Hose gehen.

 

habt ein schönes Wochenende,

Jörg

[Claudiocool]

Ich habs mit Prestool gemacht, da hst man die Kontrolle über sein Tun.

[Whiley]

vor 2 Stunden schrieb Jörg Saxtec:

Da wäre aber ganz vorsichtig, solche Tipps zu geben. In der Datenbank sollte man nicht ohne grundlegende Kenntnisse der PrestaShop Core und Modulprogrammierung herumpfuschen. Im schlimmsten Fall ist die Datenbank und damit der Shop völlig hinüber. Wenn man weiß, was man tut, ist das obengenannte ein guter Anfang. Kann aber, wiegesagt, böse in die Hose gehen.

Vielleicht hast du schon bemerkt, daß wir uns hier in einem "OPEN SOURCE Forum" befinden, solche Tipps sind natürlich immer willkommen,  mehr jedenfalls als die Posts, die hier als Werbung für die eigenen Module dienen.

[Gurkcity]

23 hours ago, Pete78 said:

Wurde die Umstellung von 19 auf 16 bereits gemacht, kann man im nachhinein noch runden...

ohne gewähr, bitte Backup machen oder ggf. mit einem Produkt testen

UPDATE `ps_product` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;
UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;

Danke für den Vorschlag. Einer unserer Kunden ist ebenfalls in dieses Dilemma gekommen, da durch die MwSt. Umstellung die Bruttopreise nicht mehr "glatt" waren, was diese aber für einen B2C Shop mit Bruttopreisen sein sollten. Wir haben das noch auf die Varianten und den ermäßigten Steuersatz erweitert. Und wer weitere ermäßigte Steuersätze oder mit anderen IDs oder Tabellenpräfixen arbeitet, muss das entsprechend noch anpassen.

-- Rundungsdifferenzen nachträglich korrigieren

-- Regelsteuer (16%)
-- Produkte
UPDATE `ps_product` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;
UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1;

-- Produktvarianten
UPDATE `ps_product_attribute` AS pa
INNER JOIN `ps_product` AS p ON (p.`id_product` = pa.`id_product`)
SET pa.`price` = ROUND(1.16*pa.`price`,2)/1.16
WHERE p.`id_tax_rules_group` IN (1);

UPDATE `ps_product_attribute_shop` AS pa
INNER JOIN `ps_product_shop` AS ps ON (ps.`id_product` = pa.`id_product` AND ps.`id_shop` = pa.`id_shop`)
SET pa.`price` = ROUND(1.16*pa.`price`,2)/1.16
WHERE ps.`id_tax_rules_group` IN (1);

-- Sonderpreise
UPDATE `ps_specific_price` AS sp
INNER JOIN `p_product_shop` AS ps ON (ps.`id_product` = sp.`id_product` AND ps.`id_shop` = sp.`id_shop`)
SET sp.`reduction` = ROUND(1.16*sp.`reduction`,2)/1.16
WHERE ps.`id_tax_rules_group` IN (1)
AND sp.`reduction_type` = 'amount'
AND sp.`reduction` > 0
AND sp.`reduction_tax` = 0;


-- Foodstuff / Reduced Rate o.ä. (5%)
-- Produkte
UPDATE `ps_product` SET `price` = ROUND(1.05*`price`,2)/1.05 where `id_tax_rules_group` = 2;
UPDATE `ps_product_shop` SET `price` = ROUND(1.05*`price`,2)/1.05 where `id_tax_rules_group` = 2;

-- Produktvarianten
UPDATE `ps_product_attribute` AS pa
INNER JOIN `ps_product` AS p ON (p.`id_product` = pa.`id_product`)
SET pa.`price` = ROUND(1.05*pa.`price`,2)/1.05
WHERE p.`id_tax_rules_group` IN (2);

UPDATE `ps_product_attribute_shop` AS pa
INNER JOIN `ps_product_shop` AS ps ON (ps.`id_product` = pa.`id_product` AND ps.`id_shop` = pa.`id_shop`)
SET pa.`price` = ROUND(1.05*pa.`price`,2)/1.05
WHERE ps.`id_tax_rules_group` IN (2);

-- Sonderpreise
UPDATE `ps_specific_price` AS sp
INNER JOIN `p_product_shop` AS ps ON (ps.`id_product` = sp.`id_product` AND ps.`id_shop` = sp.`id_shop`)
SET sp.`reduction` = ROUND(1.05*sp.`reduction`,2)/1.05
WHERE ps.`id_tax_rules_group` IN (2)
AND sp.`reduction_type` = 'amount'
AND sp.`reduction` > 0
AND sp.`reduction_tax` = 0;

Bin gerne offen für Verbesserungsvorschläge 😉

[Wuschel]

@Gurkcity Der Sinn dieser SQL-Statements erschließt  sich mir leider nicht. Mal ein Beispiel:

Sonderpreis 8,04 € brutto, gespeichert als Nettopreis (16%) 6.931034

(1.16 x 6.931034) = 8.04 (gerundet auf 2 Stellen)

8.04 / 1.16 = 6.931034

Womit wir wieder beim Ausgangspunkt wären ... 

 

[Claudiocool]

Beide können ja kaum, bzw. in nur sehr wenigen Fällen gerade sein, da sie ja mittels Faktor 1,16 in einer direkten Relation zueinander sind. Wenn ich B2C mache, sollte ich die Bruttopriese so runden, dass sie hinterm Komma keine weiteren versteckten Werte haben, bei B2B entsprechend die Sache bei d3en Nettopreisen hinbiegen.

Edited July 4, 2020 by Claudiocool (see edit history)

[Wuschel]

Genau! Ganz davon abgesehen, dass das von @Gurkcity vorgeschlagene Vorgehen so richtig unsinnig dann in der Tabelle ps_specific_price wird. Denn da der Inhalt des Feldes reduction ja auch ein Prozentwert sein kann (und dies häufig auch ist), wären solche Fälle ausgeschlossen. Aber weil die Bedingung reduction_tax = 0 normalerweise sowieso nie erfüllt wird, richtet das SQL-Statement wenigstens keinen Schaden an. 

Edited July 4, 2020 by Wuschel (see edit history)

[rictools]

vor 48 Minuten schrieb Wuschel:

@Gurkcity Der Sinn dieser SQL-Statements erschließt  sich mir leider nicht. Mal ein Beispiel:

Sonderpreis 8,04 € brutto, gespeichert als Nettopreis (16%) 6.931034

Das Problem ist ja eben, dass z. B. der Preis bei 19 % MwSt. auf glatte 8,25 € festgelegt wurde (= 6,932773 netto) und sich bei der Änderung des MwSt.-Satzes auf 16 % dann 8,042017 ergeben, dieser krumme Preis wird mit der Formel dann auf 8,04 € gerundet. Wer in seinem Shop ganz oder überwiegend mit Nettopreisen arbeitet (B2B, Export) braucht das natürlich nur, wenn er die MwSt.-Senkung nicht weitergeben will was aber gerade dann kaum Sinn macht.

[rictools]

vor 52 Minuten schrieb Wuschel:

Genau! Ganz davon abgesehen, dass das von @Gurkcity vorgeschlagene Vorgehen so richtig unsinnig dann in der Tabelle ps_specific_price wird. Denn dader Inhalt des Feldes reduction ja auch ein Prozentwert sein (und dies häufig auch ist), wären solche Fälle ausgeschlossen. Aber weil die Bedingung reduction_tax = 0 normalerweise sowieso nie erfüllt wird, richtet das SQL-Statement wenigstens keinen Schaden an. 

Wenn ich das richtig verstehe, wird der Befehl nur ausgeführt, wenn der reduction_type "amount" (Betrag) ist, also nicht "percentage" (Prozentsatz).

Zumindest in 1.6 kann ich bei Preisreduzierungen einstellen, ob es sich um den Inkl.- oder Exkl.-Preis handelt, d. h. wenn reduction_tax = 1 habe ich die Reduktionen inkl. MwSt. eingegeben und es handelt sich somit auch um runde Beträge, zumindest bei der MwSt.-Änderung im BackOffice wird dieser Betrag nicht geändert (der Kunde profitiert also von einem relativ etwas höheren Preisnachlass, möchte man das nicht muß man hier noch eine Änderung vornehmen). reduction_tax = 0 dürfte bei B2C-Shops tatsächlich kaum vorkommen. 

[Gurkcity]

1 hour ago, Wuschel said:

@Gurkcity Der Sinn dieser SQL-Statements erschließt  sich mir leider nicht. Mal ein Beispiel:

Sonderpreis 8,04 € brutto, gespeichert als Nettopreis (16%) 6.931034

(1.16 x 6.931034) = 8.04 (gerundet auf 2 Stellen)

8.04 / 1.16 = 6.931034

Womit wir wieder beim Ausgangspunkt wären ... 

 

Du gehst von einer falschen Ausgangslage aus. Richtig wäre

VK 8,25€ mit inkl. 19% MwSt.

macht Nettopreis in Presta DB 6,932773

Dann am 01.07. Steuersenkung von 19 auf 16%, wir gehen davon aus, dass die Steuersenkung an den Endverbraucher weiter gegeben wird.

Daraus ergibt sich ein VK von 8,04€ inkl. 16% MwSt.

Dies aber gerundet, denn von diesem Nettopreis kommen wir auf 8,0420168 € als Brutto inkl. 6 Nachkommastellen, also ziemlich unrund aus B2C Sicht. Natürlich sieht der Endverbraucher nur die 2 Stellen hinter dem Komma.

Jetzt kommen die obigen Formeln ins Spiel. Die Steuerumstellung ist passé, die Preise sind mehr oder weniger ungerade. PayPal macht Probleme, da das Modul alles nochmal versucht selbst zusammenzuwursteln und mit dem Presta Warenkorb vergleicht.

Die obigen Formeln rechnen den Nettopreis um in den Bruttopreis, rechnen mit 16% Steueraufschlag, runden auf 2 Stellen und schreiben daraus den neuen Nettopreis in die DB. Das ist gebau das gleiche, wie wenn Du im BO den Bruttopreis mit zwei Stellen gerundet ins Feld eintippst, im Hintergrund wird Netto mit 6 Nachkommastellen errechnet und in die DB geschrieben.

Aus 8,04€ Brutto inkl. 16% MwSt. wird dann 6,931034 in die DB geschrieben.

Ich habe es getestet und es passt für uns auch soweit.

[Wuschel]

21 minutes ago, rictools said:

Zumindest in 1.6 kann ich bei Preisreduzierungen einstellen, ob es sich um den Inkl.- oder Exkl.-Preis handelt, d. h. wenn reduction_tax = 1 habe ich die Reduktionen inkl. MwSt. eingegeben

Das war auch vor 1.6 schon so und hat sich auch in 1.7 nicht geändert.

[Gurkcity]

24 minutes ago, rictools said:

Wenn ich das richtig verstehe, wird der Befehl nur ausgeführt, wenn der reduction_type "amount" (Betrag) ist, also nicht "percentage" (Prozentsatz).

Zumindest in 1.6 kann ich bei Preisreduzierungen einstellen, ob es sich um den Inkl.- oder Exkl.-Preis handelt, d. h. wenn reduction_tax = 1 habe ich die Reduktionen inkl. MwSt. eingegeben und es handelt sich somit auch um runde Beträge, zumindest bei der MwSt.-Änderung im BackOffice wird dieser Betrag nicht geändert (der Kunde profitiert also von einem relativ etwas höheren Preisnachlass, möchte man das nicht muß man hier noch eine Änderung vornehmen). reduction_tax = 0 dürfte bei B2C-Shops tatsächlich kaum vorkommen. 

korrekt, der reduction_type muss auf 'amount' stehen. Bei percentage macht das natürlich keinen Sinn.

[Wuschel]

2 minutes ago, Gurkcity said:

Du gehst von einer falschen Ausgangslage aus. Richtig wäre

VK 8,25€ mit inkl. 19% MwSt.

Mag sein, aber nicht in deinem SQL-Statement.

[Gurkcity]

Ich habe Pete78 zitiert und da steht das bereits. Bitte mal genau lesen. Meine SQL-Statements gehen davon aus, dass die Mwst bereits umgestellt wurde und die Bruttopreise nicht beibehalten wurden.

[Wuschel]

Ja eben, daher mein Beispiel, um zu zeigen, dass du dich so im Kreis drehst.

[Gurkcity]

2 hours ago, Wuschel said:

@Gurkcity Der Sinn dieser SQL-Statements erschließt  sich mir leider nicht. Mal ein Beispiel:

Sonderpreis 8,04 € brutto, gespeichert als Nettopreis (16%) 6.931034

(1.16 x 6.931034) = 8.04 (gerundet auf 2 Stellen)

8.04 / 1.16 = 6.931034

Womit wir wieder beim Ausgangspunkt wären ... 

 

Irgendwie reden wir aneinander vorbei. Du gehst davon aus, dass 6.931034 in der DB stehen. Tut es aber nicht, es steht 6.932773 nach der Umstellung, genauso wie vor der Umstellung in der DB. An den Nettopreisen hat sich ja nichts geändert. Die sind lediglich "krumm", da der Bruttopreis "gerade" eingegeben wurde. Und durch die Umstellung sind jetzt beide Preise "krumm". Und Endkunde und PayPal möchten "gerade" Preise. Also korrigiere ich 16% VK wieder "gerade" wodurch neuer Nettopreis anders "krumm" wird (6.931034 neu).

[Wuschel]

Das war doch nur eine Beispielrechnung! Was weiß ich, welche Zahlen in deiner DB stehen. 

Willst du wirklich anzweifeln, dass 6,931034 (netto) dem Bruttopreis von 8,04 bei 16%MwSt. entsprechen? Ich rede doch nicht davon, was vorher in der DB stand, sondern versuche dir klarzumachen,  dass deine SQL-Statements nicht das leisten, was sie leisten sollen. 

Sonderpreis 8,25 € brutto, gespeichert als Nettopreis (16%) 6.932773

(1.16 x 6.932773) = 8.25 (gerundet auf 2 Stellen)

8.25 / 1.16 = 6.932773

Du korrigierst auf diese Weise gar nichts, sondern alles bleibt, wie es ist.

 

Edited July 4, 2020 by Wuschel (see edit history)

[rictools]

Wuschel, lies doch Gurkcitys und meine Beiträge noch einmal genau durch, wir haben ja offenbar unabhängig voneinander am gleichen Beispiel versucht, dir die Sache zu erklären. Noch einmal, NACH der Umstellung von 19 auf 16 % MwSt. ist es sehr unwahrscheinlich, daß dabei ein Bruttopreis mit nur 2 Nachkommastellen rauskommt und es geht darum, das, was du als Anfangswert nennst (8,25) erst zu erreichen!

[Wuschel]

😁 sei mir nicht böse, aber kann es sein, dass du vielleicht auch nicht verstehst, warum es mit Gurkcitys SQL-Statements nicht klappen kann, das, was er will, zu realisieren?

Bei Prestashop kommt am Ende immer ein Bruttopreis mit 2 Nachkommastellen raus, da im Core entsprechend gekürzt wird. 

[rictools]

Im Shop (und wie ich eben erst festgestellt habe auch im BO) wird der Bruttopreis gekürzt angezeigt, aber hinterlegt ist er ungekürzt (ändere den Bruttopreis im BO und stelle ihn dann wieder zurück, der Nettowert ist jetzt ein anderer). Wenn du eine gewisse Stückzahl eines unmodifizierten Artikels in den Warenkorb legst, ergibt sich ein um ein oder mehrere Cents abweichender Gesamtpreis.

- - -

Ich habe bei mir diese Änderung noch nicht durchgeführt, in einem halben Jahr komme ich ja nicht unbedingt wieder auf den genauen Ursprungspreis zurück. Mich würde interessieren, ob es dadurch zu Problemen mit der PayPal-Zahlung kommen kann oder ob der Zahlbetrag allenfalls leicht abweicht.

[Wuschel]

Nein, so ist das nicht in Presta. Der Bruttopreis ist an dieser Stelle überhaupt nicht hinterlegt. Der Shop speichert den Nettopreis mit 6 Stellen hinterm Komma, und ein Javaskript sorgt im Back Office für diese Umrechnung on the spot. Zugleich wird sichergestellt, dass der errechnete oder eingegebene Bruttopreis nach dem Speichern mit nur maximal 2 Nachkommastellen dargestellt wird, ganz egal, wieviel du eingibst.

Solche Javaskripte gibt es an vielen Stellen im Back Office. (Eines davon ist beispielsweise für den seit etlichen Jahren bestehenden Fehler verantwortlich, dass eine unit_price_ratio für die Grundpreisberechnung nie als 1.000000 abspeichert wird, sondern einen Wert kleiner Null bekommt, wodurch es immer mal wieder zu Differenzen um einen Cent beim Brutto-Grundpreis kommt.) 

Was Paypal anbelangt, so hängt das eher vom eingesetzten Modul ab, ob es zu Rundungsdifferenzen kommt oder nicht, und weniger vom Steuersatz. Zumindest, wenn man bei der Umstellung alles richtig gemacht und keine überflüssigen Datenbankoperationen durchgeführt hat. 

 

[Claudiocool]

Also, ihr führt eine sehr interessante Dskussion....

Es ist wie Wuschel sagt, der Nettopreis kann hier variieren, während der Bruttopreis aufgrund der nur 2 sichtbaren Stellen eben konstant erscheint. Bei Einzelprodukten wäre das auch nicht weiter tragisch, erst bei mehr Produkten kann dann die Rundung den Betrag "verwässern". Einerseits unschön, andererseits provoziert es bei PayPal Fehler, weil die den Preis mit 2 Stellen übernehmen und dann einfach multiplizieren. Die Zahlung kommt zwar aufgrund der PayPal-Kalkulation, nebenbei natürlich auch diejenige, die der Kunde intuitiv erwartet, denn 10 Teile zu je 7,50 kosten nunmal 75 EUR und nicht 75,04 EUR.

Das Script muss also jetzt den VK nehmen, auf 2 Stellen runden und zurückschreiben, das sollte der ROUND-Befehl hinbekommen, es geht jetzt lediglich darum, dass dann dabei der Nettopreis neu gerechnet wird und der Bruttobetrag dann gleich bleibt. Also muss der Nettopreis dann hier korrekt mit (100+Tax_rate)/100 zurückgeschrieben werden, dann ist der Bruttopreis, wie ihn das System dann auf der Basis des Nettopreises errechnet auch mit höheren Stückzahlen korrekt. Ich denke, das ROUND mit 2 Nachkommastellen sollte genau das leisten, allerdings muss dabei dann auch der Nettopreis auf dieser Basis zurückgeschrieben werden, sonst verpufft die Aktion. Hier sollte bei einem MWST-Satzänderung genau diese Aktion ablaufen, eventuell mit einer Abfrage, welche Preisstrategie (B2C-B2B) gewollt ist.

[Whiley]

vor 19 Stunden schrieb Gurkcity:

Bin gerne offen für Verbesserungsvorschläge 😉

Hallo Chris,
perfekt, wir haben im Grunde die identischen Umrechnungen durchgeführt, allerdings direkt während der Umstellung von 19 auf 16% (was aber zum gleichen Ergebnis führt), zusätzlich haben wir noch die in Frage kommenden Tabellen mit dem alten Inhalt und dem neu berechneten Inhalt dubliziert (es gibt jetzt z.B. nebem der ps_product noch eine  ps_product19 und ene ps_product16--Tabelle) um ggfs. am Jahresende, nach Überprüfung daß es keine Preisänderung gab, exakt wieder auf den Ursprungspreis zurückgehen können.

@Wuschel, wenn du in deinem Shop einen Artikel hattest der 8,25 brutto bei 19% MwSt kostete stand in der DB ein Nettowert von 6.932773

bei 19% 8,25 brutto  - Nettowert in der DB: 6.932773

wenn du nun einfach hergegangen bist und hast den Steuerwert von 19% auf 16 % geändert ergibt sich

bei 16% 8,04 brutto  - Nettowert in der DB: 6.932773 (gleich wie vorher)

wenn du nun einmal im auf 16% umgestellten Shop einen neuen Artkel eingibst mit einem Bruttopreis von 8,04 "rundet" das java script mit dem Ergebnis:

bei 16% 8,04 brutto  -  Nettowert in der DB: 6.931034

Der Unterschied  von netto 6.932773 zu netto 6.931034 ist aber genau das Problem, deshalb ist es sinnvoll die Rundungsfunktion des java-scripts nachzubilden .

Grüsse
Whiley

[Wuschel]

2 minutes ago, Whiley said:

deshalb ist es sinnvoll die Rundungsfunktion des java-scripts nachzubilden

Allmählich übersteigt das dann aber die Fähigkeiten des durchschnittlichen Anwenders, @Whiley.Das Problem sind auch nicht die neu eingestellten Artikel - da kann man den Bruttopreis ja von vornherein harmonisieren, sondern die bereits zuvor mit 19 oder 7 Prozent erfassten. Allein um die geht es, und da hat @Claudiocool schon den richtigen Weg aufgezeigt: 

47 minutes ago, Claudiocool said:

es geht jetzt lediglich darum, dass dann dabei der Nettopreis neu gerechnet wird und der Bruttobetrag dann gleich bleibt. Also muss der Nettopreis dann hier korrekt mit (100+Tax_rate)/100 zurückgeschrieben werden, dann ist der Bruttopreis, wie ihn das System dann auf der Basis des Nettopreises errechnet auch mit höheren Stückzahlen korrekt. Ich denke, das ROUND mit 2 Nachkommastellen sollte genau das leisten, allerdings muss dabei dann auch der Nettopreis auf dieser Basis zurückgeschrieben werden, sonst verpufft die Aktion.

 

[Gurkcity]

Hallo Whiley,

vollkommen korrekt. Danke nochmal für das Aufgreifen des Beispiels und die Idee mit den zusätzlichen Tabellen. Ich habe einfach ein Backup lokal von allen Shops vom 30.06.2020 vorliegen. Damit lässt sich das am 01.01.2021 nochmal abgleichen.

Mal eine andere Frage, vielleicht hat das der eine oder andere bereits untersucht: die Schwierigkeiten tauchen insbesondere bei PayPal auf. @Wuschel hat das bereits angedeutet, dass das vom eingesetzten Modul abhängt. Das klassische PayPal Modul (z.B. bei einem älteren Shop die Version 3.11.1, technischer Name 'paypal') berechnet den Warenkorb neu. Ich denke, dass das auch bei den neueren Modulen so ist.

Hat das Problem dadurch auch etwas mit den im Shop eingestellten Rundungsregeln zu tun?

Viele Grüße

Chris

[Whiley]

vor 32 Minuten schrieb Gurkcity:

Das klassische PayPal Modul (z.B. bei einem älteren Shop die Version 3.11.1, technischer Name 'paypal') berechnet den Warenkorb neu. Ich denke, dass das auch bei den neueren Modulen so ist.

Das Problem an sich ist ja nicht neu, es tritt auch dann auf, wenn mann Nettopreise direkt in die Datenbank einspielt ohne z.B. über die csv-importroutine zu gehen. Aufgefallen ist mir der Fehler schon bei "PayPal v3.14.2", "PayPal v5.4.3 - von thirty bees" und bei einer älteren mollie-Version.

 

vor 59 Minuten schrieb Wuschel:

.Das Problem sind auch nicht die neu eingestellten Artikel - da kann man den Bruttopreis ja von vornherein harmonisieren, sondern die bereits zuvor mit 19 oder 7 Prozent erfassten.

Genau!

Exakt dieses habe ich oben aufgezeigt.

Es geht hier aber nicht um das manuelle harmonisieren des Bruttopreises, sondern einfach um die Eingabe desselben, alles andere regelt das Prestashop-java-script intern!

[Claudiocool]

Gut, dann wäre es aber sinnvoll, in einem B2B-Shop eine Änderung der Mwst. über eine Rundungsfunktion der Bruttopreise laufen zu lassen, damit genau das aufgetretene Problem erst gar nicht entsteht. Wer parallel im Laden verkauft, wäre dann eventuell sogar über eine entsprechende Funktion, die eine 0/5-Abstufung der zweiten Ziffer erlaubt oder die beliebte 9 am Ende.

[Wuschel]

Rundungsfehler sind aber trotzdem bei solchen Datenbankoperationen nicht auszuschließen, denn der SQL-Befehl ROUND() beherrscht nur das mathematische Runden, während die Prestashop-Funktion ps_round wenigstens versucht, das kaufmännische Runden nachzubilden. Deckungsgleich sind beide Verfahren jedenfalls nicht.

Wer sowieso nicht centgenau rechnen will, sondern lieber den Betrag in ganzen Euros ausweist, dem hilft

CEIL(tabname.`price`)

 

Edited July 5, 2020 by Wuschel (see edit history)

[Whiley]

vor 26 Minuten schrieb Claudiocool:

Gut, dann wäre es aber sinnvoll, ... eine Änderung der Mwst. über eine Rundungsfunktion der Bruttopreise laufen zu lassen, damit genau das aufgetretene Problem erst gar nicht entsteht.

Wenn du das Script von Chris Gurk mit dem im ersten Post genannten Script verknüpfst ist genau das auch das Ergebnis. So haben wir im Prinzip unsere Shops umgestellt.

Das mit der 5 oder 9 am Ende wäre natürlich auch sehr leicht zu realisieren, unsere Shopbetreiber machen aber teilweise MwSt-Werbung "wir geben die Mehrwertsteuersenkung weiter etc...", da sehen die ungewohnt endenden Preise realistischer aus.😉

[Whiley]

vor 3 Stunden schrieb Wuschel:

, denn der SQL-Befehl ROUND() beherrscht nur das mathematische Runden,

@Wuschel, von welcher SQL Variante sprichst du?

Bei allen mir bekannten SQL-Dialekten rundet round () kaufmännisch  (DIN 1333)!

Ist die ersts abgeschnittene Ziffer eine 1,2,3 oder4 wird abgeschnitten, ansonsten aufgerundet.

Grüsse
Whiley

[runimo]

On 7/5/2020 at 11:07 AM, Claudiocool said:

Also, ihr führt eine sehr interessante Dskussion....

Es ist wie Wuschel sagt, der Nettopreis kann hier variieren, während der Bruttopreis aufgrund der nur 2 sichtbaren Stellen eben konstant erscheint. Bei Einzelprodukten wäre das auch nicht weiter tragisch, erst bei mehr Produkten kann dann die Rundung den Betrag "verwässern". Einerseits unschön, andererseits provoziert es bei PayPal Fehler, weil die den Preis mit 2 Stellen übernehmen und dann einfach multiplizieren. Die Zahlung kommt zwar aufgrund der PayPal-Kalkulation, nebenbei natürlich auch diejenige, die der Kunde intuitiv erwartet, denn 10 Teile zu je 7,50 kosten nunmal 75 EUR und nicht 75,04 EUR. Das Script muss also jetzt den VK nehmen, auf 2 Stellen runden und zurückschreiben, das sollte der ROUND-Befehl hinbekommen, es geht jetzt lediglich darum, dass dann dabei der Nettopreis neu gerechnet wird und der Bruttobetrag dann gleich bleibt. Also muss der Nettopreis dann Korrekt mit (100+Tax_rate)/100 zurückgeschrieben werden. Über die MwSt Änderung kann man hier auch was interessantes lesen. , dann ist der Bruttopreis, wie ihn das System dann auf der Basis des Nettopreises errechnet auch mit höheren Stückzahlen korrekt. Ich denke, das ROUND mit 2 Nachkommastellen sollte genau das leisten, allerdings muss dabei dann auch der Nettopreis auf dieser Basis zurückgeschrieben werden, sonst verpufft die Aktion. Hier sollte bei einem MWST-Satzänderung genau diese Aktion ablaufen, eventuell mit einer Abfrage, welche Preisstrategie (B2C-B2B) gewollt ist.

Von welchem Script ist denn hier die Rede? Ich habe auch das Problem mit den Rundungsfehlern und suche schon nach längerer Zeit nach einer Lösung. Vielleicht kann mich jemand in die richtige Richtung lenken 🙂

Edited September 14, 2020 by runimo (see edit history)

[Gurkcity]

On 9/14/2020 at 8:58 AM, runimo said:

Von welchem Script ist denn hier die Rede? Ich habe auch das Problem mit den Rundungsfehlern und suche schon nach längerer Zeit nach einer Lösung. Vielleicht kann mich jemand in die richtige Richtung lenken 🙂

Guten Morgen runimo,

einen guten Ansatzpunkt findest Du direkt in Deiner Datenbank, da dort die Nettopreise Deiner Produkte "ungerundet" stehen. Wenn Du ausgehend hiervon mal ein paar Beispiel-Bruttopreise mit dem aktuell gültigen Steuersatz berechnest, wirst Du vermutlich erkennen, dass diese nicht glatt mit 2 Dezimalstellen sind, sondern auch hier "ungerundet" vom PrestaShop "erzeugt" werden. Damit diese wieder "geglättet" werden, könnten Dir diese SQL-Statements helfen:

Ich hoffe, es hilft Dir weiter. Viel Erfolg beim Hin- und Herrunden 😀