Whiley Posted June 4, 2020 Share Posted June 4, 2020 Die Bundesregierung hat gestern im Zusammenhang mit dem Konjukturpaket eine Senkung der Mehrwertsteuer von 19% auf 16% für den Zeitraum vom 1.7. bis 31.12.2020 beschlossen. Das heißt für uns wir müssen den MwSt Steuersatz für alle Länder in die wir bisher mit deutscher MwSt 19% versendet haben auf einen MwSt Steuersatz von 16% abändern. Wie können wir vorgehen: 1. im Backoffice unter Lokalisierung --> Steuersätze einen neuen Steuersatz anlegen : "MwSt 16% Konjunkturpaket" mit Mwststeuersatz 16 Die ID des neuen Steuersatzes merken (z.b. 30) und die ID des 19% Steuersatzes merken (z.B. 1) Mit PHPmyAdmin die shop-Datenbank öffnen. Dann sql-Eingabe: UPDATE tabellenprefix_tax_rule SET id_tax = 'ID des 16%Steuersatzes' WHERE id_tax = 'ID des 19% Steuersatzes' also z.B.: UPDATE ps_tax_rule SET id_tax = '30' WHERE id_tax = '1' 3. am 31.12. den gleichen sql-Befehl absetzen mit umgedrehten IDs UPDATE ps_tax_rule SET id_tax = '1' WHERE id_tax = '30' Es werden dier Nettopreise beibehalten, die Bruttopreise ändern sich. Wer die ermäßigten Preise nicht an die Kunden weitergeben will muß mit den entsprechenden sql-updates die Nettopreise gleichzeitig anheben bzw. am Jahresende dann ev. wieder senken. also zum 1.7. UPDATE `ps_product` SET `price` = `price`*1.19/1.16 where `id_tax_rules_group` = 1; UPDATE `ps_product` SET `price` = `price`*1.07/1.05 where `id_tax_rules_group` = 2; UPDATE `ps_product_shop` SET `price` = `price`*1.19/1.16 where `id_tax_rules_group` = 1; UPDATE `ps_product_shop` SET `price` = `price`*1.07/1.05 where `id_tax_rules_group` = 2; Für Variantenpreise UPDATE `ps_product_attribute` SET `price` = `price`*1.19/1.16; UPDATE `ps_product_attribute_shop` SET `price` = `price`*1.19/1.16; Grundpreise: Gilt nicht für PS 1.5.X (Danke für die Info an @Wuschel) Die Grundpreisdarstellung ist automatisch richtig, außer wenn Varianten mit Preisauswirkungen verwendet werden, in diesem Fall muß folgende sql-Anweisung ausgeführt werden (Danke an @Gurkcity) UPDATE `ps_product_attribute` SET `unit_price_impact` = `unit_price_impact`*1.19/1.16; UPDATE `ps_product_attribute` SET `unit_price_impact` = `unit_price_impact`*1.19/1.16; Bei der Verwendung von Staffelpreisen muß man, sofern man den alten Brtuttopreis wieder haben will die Preise in der Tabelle ps_specific_price anpassen, @Tecc hat dazu folgende Lösung gepostet: UPDATE `ps_specific_price` SET `price`=`price`*1.19/1.16; Grüsse Whiley 2 Link to comment Share on other sites More sharing options...
Wuschel Posted June 4, 2020 Share Posted June 4, 2020 (edited) Das wäre, glaube ich, zu kompliziert, denn anschließend müsste dann noch die id_tax_rules_group in zwei Tabellen (product, product_shop) und der Texteintrag bei den europäischen Ländern geändert werden, damit die Änderungen auch für die bereits erfassten Artikel wirksam werden. Einfacher wäre es, für das halbe Jahr bei den bestehenden Einträge für 19 und 7 Prozent im Back Office nur den Inhalt in 16.000 bzw. 5.000 zu ändern. Das sind dann nur 2 Zahlen, die nach 6 Monaten rückgängig gemacht werden müssen. Edited June 5, 2020 by Wuschel (see edit history) Link to comment Share on other sites More sharing options...
Claudiocool Posted June 5, 2020 Share Posted June 5, 2020 Ich will es jetzt am Live-Shop nicht testen.... Sehe ich das richtig, dass man auf jeden Fall nicht einfach den Wert ändern kann und der Shop dann mit den geänderten Bruttopreisen weiterläuft? Link to comment Share on other sites More sharing options...
Whiley Posted June 5, 2020 Author Share Posted June 5, 2020 vor 10 Minuten schrieb Claudiocool: Ich will es jetzt am Live-Shop nicht testen.... Sehe ich das richtig, dass man auf jeden Fall nicht einfach den Wert ändern kann und der Shop dann mit den geänderten Bruttopreisen weiterläuft? Ja, falls du also die 3% nicht an den Endkunden weitergeben willst, mußt du den Preis mit den üblichen Methoden(sql-update , csv-preis-Import, webdienst) entsprechend anpassen. Grüsse Whiley Link to comment Share on other sites More sharing options...
Whiley Posted June 5, 2020 Author Share Posted June 5, 2020 vor 13 Stunden schrieb Wuschel: denn anschließend müsste dann noch die id_tax_rules_group in zwei Tabellen (product, product_shop) und der Texteintrag bei den europäischen Ländern geändert werden, damit die Änderungen auch für die bereits erfassten Artikel wirksam werden. Hallo @Wuschel das sehe ich nicht so, durch meine o.a. Änderungen wurden doch genau die Inhalte der Tax-rule für die Länder auf 16% geändert, ich habe es zur Sicherheit nochmal mit einem PS 1.6.1.24 und einem TB 1.08 durchgetestet, nach dem Cache-Löschen wird alles richtig angezeigt und richtig berechnet, alte Rechnungen werden davon nicht betroffen. Die Änderung läßt sich auch bequem "automatisch" über einen cron-job ausführen - Silvester ist also gerettet. Grüsse Whiley Link to comment Share on other sites More sharing options...
Tecc Posted June 5, 2020 Share Posted June 5, 2020 1 minute ago, Whiley said: das sehe ich nicht so, durch meine o.a. Änderungen wurden doch genau die Inhalte der Tax-rule für die Länder auf 16% geändert, ich habe es zur Sicherheit nochmal mit einem PS 1.6.1.24 und einem TB 1.08 durchgetestet, nach dem Cache-Löschen wird alles richtig angezeigt und richtig berechnet, alte Rechnungen werden davon nicht betroffen. Die Änderung läßt sich auch bequem "automatisch" über einen cron-job ausführen - Silvester ist also gerettet. Wären die SQL Statements für PS 1.7.6.* denn die gleichen, oder werden hier komplett andere Tabellen verwendet? Link to comment Share on other sites More sharing options...
rictools Posted June 5, 2020 Share Posted June 5, 2020 vor 38 Minuten schrieb Whiley: das sehe ich nicht so Mir erscheint die Änderung des bereits vorhandenen allgemeinen Steuersatzes von 19 auf 16 % auch einfacher und logischer, hätte diese Vorgehensweise denn einen Nachteil? Link to comment Share on other sites More sharing options...
Claudiocool Posted June 5, 2020 Share Posted June 5, 2020 vor einer Stunde schrieb Whiley: Hallo @Wuschel das sehe ich nicht so, durch meine o.a. Änderungen wurden doch genau die Inhalte der Tax-rule für die Länder auf 16% geändert, ich habe es zur Sicherheit nochmal mit einem PS 1.6.1.24 und einem TB 1.08 durchgetestet, nach dem Cache-Löschen wird alles richtig angezeigt und richtig berechnet, alte Rechnungen werden davon nicht betroffen. Die Änderung läßt sich auch bequem "automatisch" über einen cron-job ausführen - Silvester ist also gerettet. Grüsse Whiley Ganz so einfach wird es nicht gehen... Die Sache mit dem Cronjob ist zwar für eine zeitlich exakte Umstellung im Shop machbar, keine Frage, aber die Umstellung muss so gemacht werden, dass auch die Rechnungslegung dann dazu passt. Kommt an Silvester eine Bestellung mit 16% USt., die dann am 2. Januar bearbeitet und ausgeliefert wird, ist das Dilemma da. Dann bleibt man auf den 3% (oder wieviel auch immer, wenn die nicht auf 19 sondern einen anderen Satz wechseln) sitzen. Link to comment Share on other sites More sharing options...
Wuschel Posted June 5, 2020 Share Posted June 5, 2020 (edited) 4 hours ago, Whiley said: das sehe ich nicht so, durch meine o.a. Änderungen wurden doch genau die Inhalte der Tax-rule für die Länder auf 16% geändert, Ja, du hast recht, ich habe nochmal in die Datenbank gesehen. Es funktioniert tatsächlich auch so, wie du geschrieben hast. Nur für diejenigen, die sich an PHPMyAdmin oder auch an SQL-Befehle nicht ran trauen, scheint mir meine Lösung, lediglich die beiden numerischen Werte im Back Office zu ändern, die einfachste zu sein. Das alles gilt natürlich nur unter der Voraussetzung, dass man die MwSt-Senkung an den Kunden weitergeben will. Sonst würde es komplizierter. 4 hours ago, icemansparks said: Wären die SQL Statements für PS 1.7.6.* denn die gleichen, oder werden hier komplett andere Tabellen verwendet? Beide hier angebotenen Lösungen funktionieren auch in 1.7. In dieser Hinsicht hat sich da nichts geändert. Edited June 5, 2020 by Wuschel (see edit history) Link to comment Share on other sites More sharing options...
Claudiocool Posted June 5, 2020 Share Posted June 5, 2020 Da wird es viele Variationen der Umsetzung geben. Manche werden jetzt eben moderate Preiserhöhungen machen, um am Ende dann die 3% kompensiert zu haben. Das Auge der Kunden wird auf den Bruttopriesen vor und nach der Änderung liegen. Wir werden uns am Wochenende ansehen, welcher Aufwand die Umstellung ist, danach werden wir entscheiden, wieviel da an den Kunden durchgereicht werden kann. Link to comment Share on other sites More sharing options...
rictools Posted June 5, 2020 Share Posted June 5, 2020 (edited) vor 31 Minuten schrieb Claudiocool: Ganz so einfach wird es nicht gehen... Die Sache mit dem Cronjob ist zwar für eine zeitlich exakte Umstellung im Shop machbar, keine Frage, aber die Umstellung muss so gemacht werden, dass auch die Rechnungslegung dann dazu passt. Kommt an Silvester eine Bestellung mit 16% USt., die dann am 2. Januar bearbeitet und ausgeliefert wird, ist das Dilemma da. Dann bleibt man auf den 3% (oder wieviel auch immer, wenn die nicht auf 19 sondern einen anderen Satz wechseln) sitzen. Ich nehme an, daß für die MwSt. der Zeitpunkt der Bestellung gilt und nicht der Zeitpunkt der Rechnungsstellung, die Frage wäre, ob Prestashop das auch so verarbeitet. Edit: Ich habe gerade mal recherchiert, es gilt nicht der Zeitpunkt der Bestellung, sondern der Zeitpunkt z. B. der Versendung, d. h. wenn ein Kunde an Silvester bestellt und die Ware erst im neuen Jahr versendet werden kann, gilt die höhere MwSt. Das ist insoweit aber nicht ganz unproblematisch, weil der Kunde auf den Zeitpunkt der Versendung ja gar keinen Einfluß hat ... - - - Generell sehe ich beim Onlinehandel, der ja durch Corona meist nicht groß gelitten hat, keine Veranlassung, sich den Vorteil durch die niedrigere MwSt. ganz oder teilweise in die eigene Tasche zu stecken. Ich werde jedenfalls die Nettopreise nicht ändern sodaß die Verkaufspreise inkl. MwSt. entsprechend sinken und das im Shop auch entsprechend kommunizieren. Edited June 5, 2020 by rictools (see edit history) Link to comment Share on other sites More sharing options...
Claudiocool Posted June 5, 2020 Share Posted June 5, 2020 So sehe ich es auch. Nur hab ich heute schon 2 Kunden gehabt, die jetzt bis 1.7. warten, weil das bei denen mal eben je 150 Euro sind, die das ausmachen wird. Link to comment Share on other sites More sharing options...
Whiley Posted June 5, 2020 Author Share Posted June 5, 2020 vor 18 Minuten schrieb Claudiocool: So sehe ich es auch. Nur hab ich heute schon 2 Kunden gehabt, die jetzt bis 1.7. warten, weil das bei denen mal eben je 150 Euro sind, die das ausmachen wird. Ein ernsthaftes Problem, zumindest wenn man vorwiegend an Endverbrauer liefert. Die nächsten 3 Wochen dürfte es (auch bei unseren Shopbetreibern) Umsatzverluste geben, ev kannst du mit einer 3% Vorab-Preisaktion gegensteuern Link to comment Share on other sites More sharing options...
Claudiocool Posted June 5, 2020 Share Posted June 5, 2020 Ich gehe davon aus, dass eben dafür im nächsten Monat mehr kommt und dann im Monat vor der Rücknahme der Maßnahme nochmal. Wenn man Mainstream-Produkte hat, ist das sicher schwieriger. Link to comment Share on other sites More sharing options...
rictools Posted June 5, 2020 Share Posted June 5, 2020 (edited) Die Frage ist halt, inwieweit die Kunden mehrere Wochen warten wollen, um rund 3 Prozent zu sparen, für die kann man ja anbieten jetzt zu bestellen und erst im Juli zu liefern. Davon abgesehen kann man sich als Kunde nicht darauf verlassen, daß die Preise im Juli wirklich sinken, die erhöhte Nachfrage könnte im Gegenteil zu eher steigenden Preisen führen. Edited June 5, 2020 by rictools (see edit history) Link to comment Share on other sites More sharing options...
Whiley Posted June 6, 2020 Author Share Posted June 6, 2020 vor 20 Stunden schrieb rictools: Mir erscheint die Änderung des bereits vorhandenen allgemeinen Steuersatzes von 19 auf 16 % auch einfacher und logischer, hätte diese Vorgehensweise denn einen Nachteil? Nun, irgendwann mußt (oder solltest) du ja deine Geschäftsvorfälle buchhalterisch abbilden.Alle mir bekannten Kontenrahmen benutzen für die unterschiedlichen Steuersätze unterschiedliche Konten (z.B. DATEV SKR04 3805= 16% MWST / 3806=19% MwSt). Deshalb erscheintes mir logischer, das auch im Shop analog mit zwei verschiedenen "Steuerkonten" anzulegen., nicht zuletzt auch im Sinne der GoB. Wir haben ja einige Shops an WAWIs, Faktura- bzw Buchhaltungsprogramme angebunden und benutzen die "tax_id" direkt zur Kennzeichnung des MwSt-Satzes, dort geht es garnicht anders als mit zwei unterschiedlichen Tax-ids zu arbeiten. Aber auch wenn du deine Daten "von Hand" an deinen Steuerberater übergibst, wird der sich bestimmt über eine eineindeutige MWSt-Kennung freuen. Link to comment Share on other sites More sharing options...
RabbitZzZ Posted June 8, 2020 Share Posted June 8, 2020 On 6/5/2020 at 10:45 AM, Whiley said: Ja, falls du also die 3% nicht an den Endkunden weitergeben willst, mußt du den Preis mit den üblichen Methoden(sql-update , csv-preis-Import, webdienst) entsprechend anpassen. Was wäre denn dahingehend die sicherste und einfachste Methode? Link to comment Share on other sites More sharing options...
Whiley Posted June 8, 2020 Author Share Posted June 8, 2020 vor 11 Stunden schrieb RabbitZzZ: Was wäre denn dahingehend die sicherste und einfachste Methode? Da gibts natürlich viele Möglichkeiten (Mass-Edit oder csv-Export, Korrektur u. csv-Import), ich würde das via sql im phpmyadmin machen, das müßte etwa so gehen: UPDATE `ps_product` SET `price` = `price`*1.19/1.16; UPDATE `ps_product_shop` SET `price` = `price`*1.19/1.16; Für Variantenpreise UPDATE `ps_product_attribute` SET `price` = `price`*1.19/1.16; UPDATE `ps_product_attribute_shop` SET `price` = `price`*1.19/1.16; Grüsse Whiley Link to comment Share on other sites More sharing options...
Claudiocool Posted June 8, 2020 Share Posted June 8, 2020 (edited) Whiley, besser wäre .....price*1.19/1.16 sonst haust du den Preis durch die Decke.... Edited June 8, 2020 by Claudiocool (see edit history) Link to comment Share on other sites More sharing options...
Whiley Posted June 8, 2020 Author Share Posted June 8, 2020 vor 3 Stunden schrieb Claudiocool: Whiley, besser wäre .....price*1.19/1.16 sonst haust du den Preis durch die Decke.... Wäre aber auch nicht schlecht! Du hast selbstverständlich Recht, ich habs korrigiert! Grüsse Whiley Link to comment Share on other sites More sharing options...
Shad86 Posted June 9, 2020 Share Posted June 9, 2020 Ist schon bekannt ob es auch legal ist und als alternative gesehen werden kann, Im Warenkorb einen Rabatt von 3% zu geben? Dann könnte man generell alles so lassen, kleiner Hinweis neben dem Preis das die 3% im Warenkorb abgezogen werden und den Rabatt könnte man sogar nur bis 01.01.21 laufen lassen. Link to comment Share on other sites More sharing options...
rictools Posted June 9, 2020 Share Posted June 9, 2020 Du müßtest halt dafür sorgen, daß überall nur der Preis inkl. MwSt. und nicht der Nettopreis und auch nicht der MwSt.-Satz von 19 % angezeigt wird, sicher ein Problem wenn du die Rechnung mit Prestashop erstellst und natürlich, wenn du mehrwertsteuerfrei ins Ausland lieferst. Und die Änderung des MwSt.-Satzes dürfte weniger Arbeit machen als die Rabattregelung ... Link to comment Share on other sites More sharing options...
Whiley Posted June 9, 2020 Author Share Posted June 9, 2020 vor 3 Stunden schrieb Shad86: Ist schon bekannt ob es auch legal ist und als alternative gesehen werden kann, Im Warenkorb einen Rabatt von 3% Neben den Bedenken die Christian schon vorgebracht hat, solltest du auch bedenken, daß ein geänderter MWSt-Satz von 19% auf 16% nicht einer Warenpreisreduktion von 3% enspricht sonder einer Preisreduktion von 2,52% Grüsse Whiley Link to comment Share on other sites More sharing options...
Wuschel Posted June 10, 2020 Share Posted June 10, 2020 (edited) On 6/8/2020 at 3:16 PM, Whiley said: UPDATE `ps_product` SET `price` = `price`*1.19/1.16; UPDATE `ps_product_shop` SET `price` = `price`*1.19/1.16; Na ja, aber auch nur, wenn die Artikel nur einen MwSt-Satz haben! Denn die 7%-Preise würden mit diesem Statement zerschossen. Sicherheitshalber müsste da noch eine Bedingung angehängt werden: WHERE `id_tax_rules_group` = [entsprechende ID] Und dann wäre da noch die Frage: Wirkt sich das möglicherweise auf die Grundpreisberechnung aus? Aber ganz fatal würde sich die Verwendung beider MwSt-Sätze bei Varianten auswirken. On 6/8/2020 at 3:16 PM, Whiley said: Für Variantenpreise UPDATE `ps_product_attribute` SET `price` = `price`*1.19/1.16; UPDATE `ps_product_attribute_shop` SET `price` = `price`*1.19/1.16; Es gibt nämlich hier keine Möglichkeit, den jeweiligen MwSt-Satz abzufragen, weil dieser in der Datenbanktabelle gar nicht gespeichert ist. Ist zwar möglich, aber der SQL-Befehl wäre dann schon komplexer. Edited June 10, 2020 by Wuschel (see edit history) Link to comment Share on other sites More sharing options...
Tecc Posted June 12, 2020 Share Posted June 12, 2020 On 6/9/2020 at 6:06 PM, Whiley said: Neben den Bedenken die Christian schon vorgebracht hat, solltest du auch bedenken, daß ein geänderter MWSt-Satz von 19% auf 16% nicht einer Warenpreisreduktion von 3% enspricht sonder einer Preisreduktion von 2,52% Zusätzlich geht es ja rein rechtlich gesehen nicht darum, dass der Endkunde einen reduzierten Preis erhält, sondern darum die korrekte Steuer auszuweisen. Somit dürfte das Vergeben eines Rabatts an dieser Stelle nicht zu einem akzeptiertem Ergebnis führen. Link to comment Share on other sites More sharing options...
Claudiocool Posted June 12, 2020 Share Posted June 12, 2020 Das gaht nur darum, die Kunden jetzt in der Übergangszeit bis zur Senkung davon abzuhalten, die Käufe zurückzustellen. Dass Steuerangaben selbstredend korrekt sein müssen, ist an der Stelle sicherlich jedem klar Link to comment Share on other sites More sharing options...
chillum Posted June 13, 2020 Share Posted June 13, 2020 Es geht auch einfacher, bei der DE Standard 19 % einfach 19.000 durch 16.000 ersetzen. Link to comment Share on other sites More sharing options...
rictools Posted June 13, 2020 Share Posted June 13, 2020 vor einer Stunde schrieb chillum: Es geht auch einfacher, bei der DE Standard 19 % einfach 19.000 durch 16.000 ersetzen. Wenn du den Thread gelesen hättest, wüßtest du, dass diese Möglichkeit seit dem 2. Beitrag Teil der Diskussion ist ... Link to comment Share on other sites More sharing options...
Whiley Posted June 14, 2020 Author Share Posted June 14, 2020 vor 19 Stunden schrieb chillum: Es geht auch einfacher, bei der DE Standard 19 % einfach 19.000 durch 16.000 ersetzen. Vielleicht erklärst du kurz, wie du ohne 2 parallel benutzbare Steuersätze (16% und 19%) in den Übergangszeiten deine Bestellungen GoBD-konform abwickelst. Das war zumindest Anfang 2007 als die Umsatzsteuer von 16% auf 19% erhöht wurde, die große Herausforderung. Oder schaffst du es tatsächlich z.B. eine Bestellung die am 30.6. bei die eingeht noch am gleichen Tag beim Kunden abzuliefern? Desweiteren solltest du bei deinem Lösungsansatz überprüfen, ob bei der Weitergabe deiner Shopdaten an ein Buchhaltungssystem/Steuerberater, nicht die tax_id verwendet wird (wir verwenden die z.B.), wenn dem so wäre, wäre das Chaos vorprogrammiert. Grüsse Whiley Link to comment Share on other sites More sharing options...
rictools Posted June 14, 2020 Share Posted June 14, 2020 Abliefern muß man die Sachen ja nicht am 30.6., es reicht wenn man sie dem Versandunternehmen übergibt. Wenn ich das richtig sehe, sollte man die Umstellung nicht um Mitternacht, sondern bereits im Laufe des 30. vornehmen zu der Zeit, ab der man voraussichtlich am gleichen Tag nicht mehr versenden kann. Und maßgeblich ist doch nicht der Zeitpunkt der Bestellung des Kunden, sondern der Zeitpunkt der Rechnung oder sehe ich das falsch? Link to comment Share on other sites More sharing options...
Whiley Posted June 14, 2020 Author Share Posted June 14, 2020 Welcher MwSt-Satz verrechnet werden muß hängt vom Lieferzeitpunkt ab. Laut § 3 Abs. 1 UStG ist eine Lieferung erfolgt, sobald der Lieferant dem Empfänger die „Verfügungsmacht“ über den Gegenstand verschafft hat. Die Verfügungsmacht liegt vor, sobald das wirtschaftliche Eigentum auf den Empfänger übergegangen ist. Der Gegenstand muss dafür aber noch nicht unbedingt in den Besitz des Empfängers übergegangen sein. Bei Lieferung über Versanddienstleister ist der Übergabezeitpunkt an diesen ausschlaggebend. Bei eigener Auslieferung der Zeitpunkt der Warenübergabe an den Kunden. Bei Selbstabholung die Warenübernahne durch den Kunden. Grüsse Whiley Link to comment Share on other sites More sharing options...
Shad86 Posted June 17, 2020 Share Posted June 17, 2020 So, meiner Info nach muss im Einzelhandel nicht jedes Preisschild erneuert werden, es würde reichen an der Kasse einen dementsprechenden Rabatt zu geben. Meine Anordnung ist, genau das selbe zu machen. Also kommt eine Infobox in den Footer oder irgendwo auffälliger und im Warenkorb gibt es dann eine Warenkorbpreisregel die den Rabatt vor nimmt. Link to comment Share on other sites More sharing options...
DRMasterChief Posted June 17, 2020 Share Posted June 17, 2020 Ohne jemandem zu nahe zu treten, aber ich frage mich manchmal echt wie lasch die Onlineshopbetreiber mit ihrem Geschäft und den damit verbundenen Regeln umgehen. Warum sollte das online gehen was für den stationären Handel "ausgedacht" worden ist? Link to comment Share on other sites More sharing options...
Shad86 Posted June 18, 2020 Share Posted June 18, 2020 (edited) Guten Morgen, also in meinem Fall ist es eine Ansage vom Chef. Also selbst wenn es mir nicht gefällt, muss ich es so machen. Davon ab, es wird ja nirgends gesagt was explizit für den Onlinehandel zu tun ist. Also kann man sich ja nur an solche Aussagen halten. Sonst wär der Zusatz wichtig gewesen das dies aber ausschließlich für den Einzelhandel gilt. Warum sollte es also da okay sein und im onlinegeschäft nicht? Da müssen ebenfalls alle Preise per Hand geändert werden wenn man weiterhin 7,95 € usw. haben möchte. Edited June 18, 2020 by Shad86 (see edit history) Link to comment Share on other sites More sharing options...
Whiley Posted June 18, 2020 Author Share Posted June 18, 2020 Die von Sakia Eskens in die Diskussion geworfene Möglichkeit, daß Einzelhändler nicht unbedingt alle Preisschilder umschreiben müssen wenn sie die verminderte MwSt an den Verbraucher weitergeben wollen, sondern mit einem "Rabatt" an der Kasse arbeiten könnten, bedeutet natürlich das trotzdem alle Kassensysteme und die nachfolgende Buchhaltungskette angepasst werden müssen. In DE besteht ja Bon-Pflicht und auf dem Bon/Rechnungt muß der MwSt Betrag richtig ausgewiesen sein. Der Einzelhändler würde also auf diese Art das zweimalige Umschreiben der Preisschilder (aber nur wenn er die MwSt-Minderung weitergibt) sparen. Für den Online-Handel spielt das aber absolut keine Rolle. Im Shop kann man mit zwei Klicks (s.o.) die Anpassung der MwSt korrekt vornehmen und dabei automatisch ohne Mehraufwand alle "Preisschilder" ändern. Der Aufwand wird nur dann etwas höher wenn man den Nachlass nicht an den Endverbraucher weitergeben will (s.o.) Eine Art "Rabattierung an der Kasse" macht im Online-Handel null Sinn und bedeutet dann natürlich einen völlig unnötigen Zusatz-Aufwand die Berechnung der MwSt anzupassen, schließlich bist du nach wie vor verpflichtet den korrekten MwSt.-Betrag auf der Rechnung aufzuführen. Grüsse Whiley Link to comment Share on other sites More sharing options...
DRMasterChief Posted June 18, 2020 Share Posted June 18, 2020 So, eben! Und nur wegen dem ganzen Zirkus ist das UStG und die PAngV nicht außer Kraft gesetzt. Daher meinte ich.... ganz ehrlich - das sind Basics für jeden Chef und vor allem wenn der einen Onlineshop betreibt. Link to comment Share on other sites More sharing options...
Shad86 Posted June 18, 2020 Share Posted June 18, 2020 Mit anderen Worten sind die zu empfehlenden Lösungen folgende: (?) - Wenn keine Anbindung an eine WaWi besteht, MwSt-Satz im Backend auf 16% ändern und im Neujahr wieder zurück (oder auf was dann aktuell ist) - Bei Anbindung an WaWi, neuen MwSt. Satz anlegen und in der Datenbank die beiden Steuersatz-ID´s tauschen @DRMasterChief Das kann gut sein, das kann mir als Angestelter zum Glück egal sein und mein Chef hat dafür Personal in der Buchhaltung. Ich kann ihm Tips geben aber wenn er sagt, mach es so, dann mache ich das. Link to comment Share on other sites More sharing options...
Bergmann Posted June 18, 2020 Share Posted June 18, 2020 vor 22 Stunden schrieb Shad86: So, meiner Info nach muss im Einzelhandel nicht jedes Preisschild erneuert werden, es würde reichen an der Kasse einen dementsprechenden Rabatt zu geben. Meine Anordnung ist, genau das selbe zu machen. Also kommt eine Infobox in den Footer oder irgendwo auffälliger und im Warenkorb gibt es dann eine Warenkorbpreisregel die den Rabatt vor nimmt. Moin. Dies bzgl. habe ich mich auch mal mit unserem Rechtsfuzzi beraten. Rechtlich gesehen ist das schon denkbar, aber es wird davon abgeraten, weil häufig Berechnungsfehler oder Rundungsfehler zustande kommen können, die sich dann die beliebten Abmahner vorknöpfen... Link to comment Share on other sites More sharing options...
rictools Posted June 18, 2020 Share Posted June 18, 2020 Die Mehrwertsteuer und ein evtl. Rabatt sind doch zwei ganz unterschiedliche Dinge. Natürlich kann man 2,52 % (oder auch 2,5 oder 3 %) Rabatt geben, nur muß trotzdem die Mehrwertsteuer-Umstellung erfolgen und diese ist sowieso einfacher wenn die Inklusivpreise entsprechend gesenkt werden sollen! Link to comment Share on other sites More sharing options...
Whiley Posted June 18, 2020 Author Share Posted June 18, 2020 Am 18.6.2020 um 1:16 PM schrieb Bergmann: Am 17.6.2020 um 2:22 PM schrieb Shad86: So, meiner Info nach muss im Einzelhandel nicht jedes Preisschild erneuert werden, es würde reichen an der Kasse einen dementsprechenden Rabatt zu geben. Meine Anordnung ist, genau das selbe zu machen. Also kommt eine Infobox in den Footer oder irgendwo auffälliger und im Warenkorb gibt es dann eine Warenkorbpreisregel die den Rabatt vor nimmt. Moin. Dies bzgl. habe ich mich auch mal mit unserem Rechtsfuzzi beraten. Rechtlich gesehen ist das schon denkbar, aber es wird davon abgeraten, weil häufig Berechnungsfehler oder Rundungsfehler zustande kommen können, die sich dann die beliebten Abmahner vorknöpfen... Nein, auch rechtlich gesehen ist das so nicht denkbar ohne daß gleichzeitig der MwSt-Satz geändert wird (im stationären Handel im Kassensystem). Da im Shop also sowieso die MwSt geändert werden muß und sich dadurch automatisch unsere "Preisschilder" neu schreiben ist jeder Gedanke an eine derartige Rabattlösung verschwendete Zeit. Die SPD-Vorsitzende (und inwischen auch die Veröffentlichung der Bundesregierung zu diesem Thema) wollte mit ihrem Vorschlag wirklich nur das Neuschreiben der Preisschilder umgehen, nichts weiter. Am 18.6.2020 um 11:58 AM schrieb Shad86: Mit anderen Worten sind die zu empfehlenden Lösungen folgende: (?) - Wenn keine Anbindung an eine WaWi besteht, MwSt-Satz im Backend auf 16% ändern und im Neujahr wieder zurück (oder auf was dann aktuell ist) - Bei Anbindung an WaWi, neuen MwSt. Satz anlegen und in der Datenbank die beiden Steuersatz-ID´s tauschen Ich meine , daß nur die letztere Lösung, das Anlegen eines (oder zweier) neuer MwSt-Sätze sinnvoll ist! Grüsse Whiley Link to comment Share on other sites More sharing options...
Jens Fessel Posted June 19, 2020 Share Posted June 19, 2020 Hallo zusammen, erstmal vielen Dank für die Ausführungen zu den möglichen Umsetzungen auf technischer Seite. Das hat mir schon geholfen. Vielleicht erhellen dieser Artikel https://legal.trustedshops.com/blog/2020/06/12/mehrwertsteuersenkung-ab-1.-juli-darauf-muessen-sie-unbedingt-achten und diese Pressemitteilung https://www.bmwi.de/Redaktion/DE/Pressemitteilungen/2020/20200612-unbuerokratische-umsetzung-der-mehrwertsteuersenkung-bei-preisangaben-durch-pauschale-rabatte-moeglich.html das rechtliche Thema etwas. Viele Grüße aus Hamburg Jens Link to comment Share on other sites More sharing options...
rictools Posted June 20, 2020 Share Posted June 20, 2020 Es bringt wenig, einen Link der Onlineshops nicht betrifft (da diese keine aufwändig physisch zu ändernde Preisschilder besitzen) zu posten, das stiftet nur Verwirrung und das Thema hatten wir hier bereits abgehandelt. Link to comment Share on other sites More sharing options...
codewichtel Posted June 20, 2020 Share Posted June 20, 2020 Wir haben noch haufenweise Bestellungen welche erst nach dem 01.07 ausgeliefert werden. Die MwSt wird ja zum Bestellzeitpunkt generiert und wenn wir dann nach dem 01.07 die Rechungen machen (Rechungsdatum=Lieferdatum) wird dort ja die "alte" MwSt stehen. Hat jemand dafür ne Lösung? Link to comment Share on other sites More sharing options...
Jens Fessel Posted June 20, 2020 Share Posted June 20, 2020 Ihr müsst die MwSt. zum Termin der Rechnungsstellung ändern. Für Endkunden sollte sich der Bruttopreis nicht erhöhen, sprich gleich bleiben oder um die gesenkte MwSt. vermindern. Umsetzung in der WaWi oder im Shopsystem. Technische Ansätze sind ja oben aufgeführt. Wir werden das im Unternehmen mit verschiedenen Steuerkennzeichen für die 19er und 16er Varianten umsetzen, also mit 2 getrennten Steuersätzen arbeiten, um später eine Nachvollziehbarkeit zu gewährleisten. Automatisierung haben wir noch nicht getestet, aber zur Not muss man die betroffenen Rechnungen manuell auf das neue Steuerkennzeichen abändern. Ist eine ärgerliche, personalintensive Einmalaufgabe, aber u.U. immer noch weniger aufwendig, als sich in einer programmatischen Lösung zu verzetteln. Interessant wird noch im Test, ob wir die Daten mit geänderten Steuersätzen zwischen Shops und WaWi nachher auch fehlerfrei synchronisiert haben 🤔 Link to comment Share on other sites More sharing options...
codewichtel Posted June 20, 2020 Share Posted June 20, 2020 (edited) 2 hours ago, Jens Fessel said: Ihr müsst die MwSt. zum Termin der Rechnungsstellung ändern. Für Endkunden sollte sich der Bruttopreis nicht erhöhen, sprich gleich bleiben oder um die gesenkte MwSt. vermindern. Umsetzung in der WaWi oder im Shopsystem. Technische Ansätze sind ja oben aufgeführt. Wir werden das im Unternehmen mit verschiedenen Steuerkennzeichen für die 19er und 16er Varianten umsetzen, also mit 2 getrennten Steuersätzen arbeiten, um später eine Nachvollziehbarkeit zu gewährleisten. Automatisierung haben wir noch nicht getestet, aber zur Not muss man die betroffenen Rechnungen manuell auf das neue Steuerkennzeichen abändern. Ist eine ärgerliche, personalintensive Einmalaufgabe, aber u.U. immer noch weniger aufwendig, als sich in einer programmatischen Lösung zu verzetteln. Interessant wird noch im Test, ob wir die Daten mit geänderten Steuersätzen zwischen Shops und WaWi nachher auch fehlerfrei synchronisiert haben 🤔 Das Ändern der MwSt am Artikel selbst ist IMHO hier das geringste problem. Ich sehe das Problem tatsächlich eher am an den Werten, welche bereits bei der Bestellung generiert werden: Wenn der Artikel am 29.06 mit 19% im Warenkorb ist dann wir auch nach der MwSt Umstellung, fälschlicherweise der 19% auf der Rechnung stehen, bei der Bestellugn vom 29.06, welche nach dem 01.07 ausgeliefert wird, da die Daten wohl nicht nochmal berechnet werden. Zumindest habe ich bisher keine Möglichkeit gefunden das innerhalb von Prestashop geradezubiegen Edited June 20, 2020 by codewichtel (see edit history) Link to comment Share on other sites More sharing options...
Whiley Posted June 21, 2020 Author Share Posted June 21, 2020 Am 20.6.2020 um 5:42 PM schrieb codewichtel: Ich sehe das Problem tatsächlich eher am an den Werten, welche bereits bei der Bestellung generiert werden: Wenn der Artikel am 29.06 mit 19% im Warenkorb ist dann wir auch nach der MwSt Umstellung, fälschlicherweise der 19% auf der Rechnung stehen, bei der Bestellugn vom 29.06, welche nach dem 01.07 ausgeliefert wird, da die Daten wohl nicht nochmal berechnet werden. Zumindest habe ich bisher keine Möglichkeit gefunden das innerhalb von Prestashop geradezubiegen In aller Regel wird man wohl wissen welche Produkte ab welchem Bestelldatum(Stichtag) dann ab dem 1.7. in den Versand kommen. Diese Produkte sollte man ab dem Stichtag bereits auf die 16% MwSt umgestelt haben um spätere Korrekturen zu vermeiden. Bei einigen Shops haben wir den Umstellungs-Cronjob auf den 29.6 (Montag) gelegt, der 1.7. ist ja der dann folgende Mitwoch. Bei einem unserer Shops bei dem die Waren mit ca 7 Tagen Planungs-Vorlauf über Speditionen verschickt wreden, werden wir bereits diese Woche umstellen. Wie das Ganze marketing-positiv dargestellt werden kann ist jetzt eher das große Problem, einfacher wird es gegen Ende Dezember (kurz vor der Rückstellung auf 19%) sein, einen Kaufdruck aufzubauen. Grüsse Whiley Link to comment Share on other sites More sharing options...
rictools Posted June 21, 2020 Share Posted June 21, 2020 Ich denke es wird eher problematisch, wenn Kunden am 31. Dezember abends noch schnell etwas zum niedrigeren MwSt.-Satz bestellen wollen ... Link to comment Share on other sites More sharing options...
Whiley Posted June 21, 2020 Author Share Posted June 21, 2020 Kulanz - heißt das Zauberwort! Alter (niedriger) Preis aber schon die 19% MwSt, kostet halt 2,52% an Werbekosten. Link to comment Share on other sites More sharing options...
codewichtel Posted June 22, 2020 Share Posted June 22, 2020 16 hours ago, Whiley said: In aller Regel wird man wohl wissen welche Produkte ab welchem Bestelldatum(Stichtag) dann ab dem 1.7. in den Versand kommen. Diese Produkte sollte man ab dem Stichtag bereits auf die 16% MwSt umgestelt haben um spätere Korrekturen zu vermeiden. Ja das ist soweit auch korrekt und ok. Wenn du aber 300 Bestellungen aus dem Mai hast, welche aufgrund von Lieferverzögerungen beim Lieferanten erst mitte Juli zugestellt werden, ist das halt damit nicht getan. Link to comment Share on other sites More sharing options...
Shad86 Posted June 22, 2020 Share Posted June 22, 2020 Hi, ich habe mir das ganze zur Vorbereitung mal genauer angesehen. Habe im Testshop den Steuersatz für 16% angelegt und bin dann in die Steuerregel für 19% gegangen und habe dort die 16% verknüpft. Jetzt werden alle neuen Bestellungen und auch Preise im Shop mit 16% MwSt. angezeigt. Scheint also so zu funktionieren. Welche ID (Steuersatz oder Steuerregel) jetzt an eine WaWi weiter gegeben wird, kann ich nicht sagen. Aber so wie es aussieht, muss nichts in der Datenbank geändert werden. Hat jemand Einwände gegen dieses Vorgehen? Und da wir im Shop nicht nur versenden sondern die Artikel erst noch herstellen, ist bei uns der Tag der Bestellung, nicht des Versandes ausschlaggebend für die Steuerregel. Also im Notfall setze ich um Mitternacht per Handy die Steuerregel einmal auf 16% und damit sollte alles sauber umgesetzt sein. Link to comment Share on other sites More sharing options...
rictools Posted June 22, 2020 Share Posted June 22, 2020 vor 1 Stunde schrieb Shad86: Und da wir im Shop nicht nur versenden sondern die Artikel erst noch herstellen, ist bei uns der Tag der Bestellung, nicht des Versandes ausschlaggebend für die Steuerregel. Auf welche Quelle stützt sich diese Ansicht? Es müßte doch egal sein, ob du selbst oder ein Zulieferer die Artikel herstellt. Und bei einem Werkvertrag kommt es doch wohl auch auf die Fertigstellung an, oder? Link to comment Share on other sites More sharing options...
Claudiocool Posted June 22, 2020 Share Posted June 22, 2020 Im Normalfall gilt der Tag, an dem die Leistung erbracht wurde. Link to comment Share on other sites More sharing options...
Whiley Posted June 22, 2020 Author Share Posted June 22, 2020 vor 35 Minuten schrieb Claudiocool: Im Normalfall gilt der Tag, an dem die Leistung erbracht wurde. Die Leistung ist aber erst erbracht wenn der Lieferant dem Empfänger die „Verfügungsmacht“ über den Gegenstand verschafft hat. (§ 3 Abs. 1 UStG i) Also nicht wenn Shad86 das Plakat gedruckt hat sondern wenn er es dem Kunden übergeben hat (Ahbolung oder Lieferung) oder wenn er es dem Versanddienst übergeben hat. Link to comment Share on other sites More sharing options...
Claudiocool Posted June 22, 2020 Share Posted June 22, 2020 Und wie lange läßt er sich dann dafür Zeit? Man sollte jetzt nicht anfangen, Ameisenbeinhaare zu epillieren, sondern es einfach so machen, wie es sein muss, wer da Angst hat, setzt seinen Shop dann halt ein paar Tage auf Wartungsmodus und gut ist es. Ich kann aber auch schon vor dem 1.7. auf 16% gehen und dem Kunden mitteilen, dass die Lieferung aufgrund dieser Tatsache auch erst am 1.7 ab 0:00 Uhr in die Versandbox geht. Wie auch immer man es lösen mag, es wird viele Wege geben, gute und schlechte... Der Kunde wird kein Problem damit haben, wenn er weiß, dass seine Lieferung dann auch nur 16% Steuer bekommt, und wenn doch, ist oben rechts ein kleines Kreuzchen, dass er in dem fall anklicken darf. Vermutlich ist man rechtlich auf der sicheren Seite, wenn man den Shop in Katalogmodus setzt und eben erst ab 1.7. Bestellungen möglich macht, alles andere ist mehr oder weniger Grauzone. 1 Link to comment Share on other sites More sharing options...
rictools Posted June 22, 2020 Share Posted June 22, 2020 @Claudiocool Deinen Post kann ich nicht recht nachvollziehen, wo siehst du ein rechtliches Problem, das einen mehrtägigen Wartungs- bzw. Katalogmodus rechtfertigen würde oder daß man Kunden, die ihre Ware möglichst schnell haben möchten (und dafür gern das bißchen mehr MwSt. bezahlen) warten läßt? Link to comment Share on other sites More sharing options...
Whiley Posted June 22, 2020 Author Share Posted June 22, 2020 vor 7 Stunden schrieb Claudiocool: Vermutlich ist man rechtlich auf der sicheren Seite, wenn man den Shop in Katalogmodus setzt und eben erst ab 1.7. Bestellungen möglich macht, alles andere ist mehr oder weniger Grauzone. Das würde auf jeden Fall Umsatz kosten, das wäre sicherlich die unsinnigste Lösung. Hier gehts doch weniger um eine gravierende Rechtsfrage (es kann ja nichts weiter passieren als daß man max 3% Steuern mehr oder weniger abführen muß) als vielmehr um die Frage wie kann man nun das meiste aus der vorübergehenden Steuersenkung herauholen. vor 14 Stunden schrieb codewichtel: Wenn du aber 300 Bestellungen aus dem Mai hast, welche aufgrund von Lieferverzögerungen beim Lieferanten erst mitte Juli zugestellt werden, ist das halt damit nicht getan. Wenn die Rechnungen schon mit 19% MwSt gestellt sind passiert ja nichts weiter, du führst die 19% ans FA ab, dem Kunden der Verbraucher ist, wird es egal sein, für den gewerblichen Kunden der vorsteuerabzugsberechtigt ist spielt das auch keine Rolle, er bekommt die 19% MwSt die er bezahlt hat zurück. Link to comment Share on other sites More sharing options...
rictools Posted June 23, 2020 Share Posted June 23, 2020 Wenn der Versandzeitpunkt aus den Unterlagen hervorgeht, könnte das aber wohl doch zu Problemen führen, warum sollte man die Rechnung nicht berichtigen? Link to comment Share on other sites More sharing options...
Whiley Posted June 23, 2020 Author Share Posted June 23, 2020 vor 5 Stunden schrieb rictools: Wenn der Versandzeitpunkt aus den Unterlagen hervorgeht, könnte das aber wohl doch zu Problemen führen, warum sollte man die Rechnung nicht berichtigen? Falls sie schon ausser Haus ist, geht nichts mehr mit Berichtigen GoB). Falls sie noch nicht verschickt wurde ergäbe sich das Problem, daß du ja nicht weißt ob der Kunde Endverbraucher (Bruttopreis gleich, Nettopreis anpassen) oder gewerblicher Abnehmer (Nettopreis gleich, Bruttopreis anpassen) ist. Link to comment Share on other sites More sharing options...
Shad86 Posted June 23, 2020 Share Posted June 23, 2020 Guten Morgen, Zitat Maßgebend für die Höhe des Umsatzsteuersatzes ist demnach weder die Rechnungstellung noch der Zahlungseingang des Kunden, sondern wann die Leistung erbracht bzw. abgeschlossen wurde. Wenn beispielsweise ein Handwerker am 30.06.2020 eine Leitung repariert, dafür am 03.07.2020 eine Rechnung stellt und diese dann am 10.07.2020 vom Kunden bezahlt wird, unterliegt diese Leistung 19% Umsatzsteuer (Leistungsdatum = 30.06.2020). Quelle: https://www.germania-steuerberatung.de/aktuelle-themen/absenkung-der-mehrwertsteuer-01072020-30062021 So sehe ich es auch. Wenn wir unsere Leisung noch vor dem 01.07. erbringen, gelten 19%. Link to comment Share on other sites More sharing options...
Wuschel Posted June 23, 2020 Share Posted June 23, 2020 Aber wen interessieren schon im Onlinehandel die Handwerker? Es gilt ... .... bei Leistungen an vorsteuerabzugsberechtigte (gewerbliche) Empfänger; Es ist es egal, ob die Leistungen vor oder nach den jeweiligen Steuersatzänderungen ausgeführt werden. Es ist in diesen Fällen nur auf die korrekte Ausstellung der Rechnungen zu achten. .... bei Leistungen an nicht vorsteuerabzugsberechtigte Empfänger (Endverbraucher): Die Leistung sollte möglichst in der Zeit zwischen dem 1.7. und dem 31.12.2020 ausgeführt werden. Wann gilt eine Leistung im Onlinehandel als ausgeführt? Im B2C ist schlicht und einfach das Versendedatum ausschlaggebend für den anzuwendenden MwSt-Satz. Das gilt auch dann, wenn das Rechnungsdatum z.B. 30.6. oder 31.12. lautet. Im erläuternden Schreiben des BMF (Entwurf vom 11.6.2020) heißt es: "Lieferungen (auch Werklieferungen) gelten dann als ausgeführt, wenn der Leistungsempfänger die Verfügungsmacht an dem Gegenstand erworben hat; wird der Gegenstand befördert oder versendet, ist die Lieferung mit Beginn der Beförderung oder Versendung ausgeführt." "Maßgebend für die Anwendung dieser Umsatzsteuersätze ist stets der Zeitpunkt, in dem der jeweilige Umsatz ausgeführt wird. Auf den Zeitpunkt der vertraglichen Vereinbarung kommt es ebenso wenig an wie auf den Zeitpunkt der Entgeltsvereinnahmung oder der Rechnungserteilung (vgl. Abschnitt 12.1 Abs. 3 UStAE). Entsprechendes gilt für Teilleistungen (vgl. Rz. 2), für die die Rzn. 19 bis 25 besondere Übergangsregelungen enthalten." "Es bestehen keine Bedenken dagegen, dass in Rechnungen, die vor dem 1. Juli 2020 über die vor diesem Zeitpunkt vereinnahmten Teilentgelte für nach dem 30. Juni 2020 erbrachte steuerpflichtige Leistungen oder Teilleistungen ausgestellt werden, die Umsatzsteuer nach dem zwischen dem 1. Juli 2020 und 31. Dezember 2020 geltenden Umsatzsteuersatz von 16 Prozent bzw. 5 Prozent ausgewiesen wird." Link to comment Share on other sites More sharing options...
rictools Posted June 23, 2020 Share Posted June 23, 2020 vor 5 Stunden schrieb Whiley: Falls sie schon ausser Haus ist, geht nichts mehr mit Berichtigen GoB). Falls sie noch nicht verschickt wurde ergäbe sich das Problem, daß du ja nicht weißt ob der Kunde Endverbraucher (Bruttopreis gleich, Nettopreis anpassen) oder gewerblicher Abnehmer (Nettopreis gleich, Bruttopreis anpassen) ist. Wieso soll eine Rechnung nicht nachträglich berichtigt werden können? Ob der Kunde privater oder gewerblicher Endverbraucher oder vielleicht auch Wiederverkäufer ist wird der Betreiber eines "normalen" Onlineshops oft nicht wissen, wenn man bei allen Kunden den Bruttopreis bei Versand ab dem 1.7. entsprechend reduziert ist das auch egal. Und wenn man das nicht will und der gewerbliche Kunde bei der Bestellung nur den Bruttopreis mit dem Hinweis "inkl. gesetzliche MwSt." gesehen hat bezweifle ich daß er einen Anspruch auf Senkung des vereinbarten Bruttopreises hat. Link to comment Share on other sites More sharing options...
codewichtel Posted June 23, 2020 Share Posted June 23, 2020 13 hours ago, Whiley said: Wenn die Rechnungen schon mit 19% MwSt gestellt sind passiert ja nichts weiter, du führst die 19% ans FA ab, dem Kunden der Verbraucher ist, wird es egal sein, für den gewerblichen Kunden der vorsteuerabzugsberechtigt ist spielt das auch keine Rolle, er bekommt die 19% MwSt die er bezahlt hat zurück. Wenn die Rechnung VOR dem 01.07 datiert sind ja ... wenn ich diese aber bei einer bestellung vom 05.05 am 01.07 generiere habe ich das Rechungsdatum 01.07 mit 19% statt der 16% Link to comment Share on other sites More sharing options...
Claudiocool Posted June 23, 2020 Share Posted June 23, 2020 vor 17 Stunden schrieb rictools: @Claudiocool Deinen Post kann ich nicht recht nachvollziehen, wo siehst du ein rechtliches Problem, das einen mehrtägigen Wartungs- bzw. Katalogmodus rechtfertigen würde oder daß man Kunden, die ihre Ware möglichst schnell haben möchten (und dafür gern das bißchen mehr MwSt. bezahlen) warten läßt? Wir reden von allen Leuten, die es der Obrigkeit immer schön recht machen wollen und sich keinen Millimeter aus dem Fenster lehnen möchten... In diesem Land soll es da schon einige davon geben, ist irgendwie Mentalität hier in D Link to comment Share on other sites More sharing options...
rictools Posted June 23, 2020 Share Posted June 23, 2020 Es geht hier nicht um so etwas wie "Obrigkeitshörigkeit" sondern um Rechtssicherheit sowie das Verhältnis zu den Kunden. Und ich sehe eben überhaupt keine Veranlassung den Shop tagelang dichtzumachen und weiß nach wie vor nicht, wo du da eine "Grauzone" siehst ... Link to comment Share on other sites More sharing options...
Claudiocool Posted June 23, 2020 Share Posted June 23, 2020 Lass gut sein, ich mache, so wie ich es denke, und du machst es wie du denkst. Letztendlich ist es jedem selbst überlassen, es fiskalisch korrekt zu machen, so dass es danach keine Beanstandungen gibt. Link to comment Share on other sites More sharing options...
Wuschel Posted June 23, 2020 Share Posted June 23, 2020 Hat denn mal jemand ausprobiert, ob alle Beträge auf einer Rechnung stimmen, die vor der Umstellung generiert, aber erst nach der Umstellung ausgedruckt wird? Mag sein, dass ich mich da irre, aber ich vermute mal, dass es hier zu Inkonsistenzen kommen könnte, da einige der informationen, auf die Prestashop hier zurückgreift, schon vor der MwSt-Umstellung berechnet wurden, andere erst danach. Denn für die Rechnungslegung werden m.W. verschiedene DB-Tabellen herangezogen. Link to comment Share on other sites More sharing options...
DRMasterChief Posted June 24, 2020 Share Posted June 24, 2020 Hallo, mir grad egal ob manche das hören mögen: Ich bleibe grade bei meinem obigen Post, das Halbwissen von Geschäftstreibenden sehe ich als größeres Problem an als die USt.-Senkung Zur Frage ob jemand schon dies&das.... im thirtybees-Forum gibts nen Beitrag dazu und dort wurde es auch probiert, da investieren manche Leute mehr in Produktives als ins Foren-schreiben *ups* Link to comment Share on other sites More sharing options...
DRMasterChief Posted June 24, 2020 Share Posted June 24, 2020 ahso und, wem das im einem Shopsystem zu komisch ist der sollte halt überlegen eine Wawi zu verwenden. Shop bleibt Shop und Wawi bleibt Wawi, sozusagen. Das gibt viel mehr Möglichkeiten und machts einfacher, von GOBD usw. ganz zu schweigen. Link to comment Share on other sites More sharing options...
Whiley Posted June 24, 2020 Author Share Posted June 24, 2020 vor 22 Stunden schrieb codewichtel: Wenn die Rechnung VOR dem 01.07 datiert sind ja ... wenn ich diese aber bei einer bestellung vom 05.05 am 01.07 generiere habe ich das Rechungsdatum 01.07 mit 19% statt der 16% Ja, das wäre in deinem Fall ungeschickt, du kannst dir da aber mit einem kleinen Trick behelfen Du gehst im BO auf die Bestellung und änderst eine Kleinigkeit ab, z.B die Menge oder den Preis, aktualisierst und änderst dann wieder zurück und aktualisierst erneut. Es wird dabei der neue Steuersatz eingelesen und gespeichert, die Rechnung stimmt dann. Grüsse Whiley Link to comment Share on other sites More sharing options...
Claudiocool Posted June 24, 2020 Share Posted June 24, 2020 Und dann stimmt es nicht mehr mit der Auftragsbestätigung überein, die der Kunde bei der Bestellung bekommen hat.... so ganz ohne ist der "Trick" nicht, wenn du nicht weißt, ob ein Fan des Finanzamts der Kunde ist.... Link to comment Share on other sites More sharing options...
Tecc Posted June 24, 2020 Share Posted June 24, 2020 Ich habe jetzt mal die SQL Statements von oben im Testshop ausprobiert und anschließend den Haupt Steuersatz von 19% auf 16% geändert. Die Preise sehen soweit alle korrekt aus was normale Produkte und Varianten betrifft. Bei Staffelpreisen habe ich noch Probleme, wo finde denn diese zum aktualisieren in der Datenbank? Link to comment Share on other sites More sharing options...
rictools Posted June 24, 2020 Share Posted June 24, 2020 vor 3 Stunden schrieb Claudiocool: Und dann stimmt es nicht mehr mit der Auftragsbestätigung überein, die der Kunde bei der Bestellung bekommen hat.... so ganz ohne ist der "Trick" nicht, wenn du nicht weißt, ob ein Fan des Finanzamts der Kunde ist.... Ich kann nach wie vor nicht nachvollziehen, wo du das rechtliche Problem siehst. Wenn ein Kunde vor der Umstellung bestellt und der Versand erst danach erfolgt bist du doch dazu verpflichtet, den MwSt.-Satz zu ändern ... Link to comment Share on other sites More sharing options...
Claudiocool Posted June 24, 2020 Share Posted June 24, 2020 Ja, aber nicht mit Tricksereien, sondern im Grunde genommen durch ein Auftragsstorno und eine Neuanlage, dann ist es korrekt und nicht zu beanstanden Link to comment Share on other sites More sharing options...
Tecc Posted June 24, 2020 Share Posted June 24, 2020 29 minutes ago, Tecc said: Ich habe jetzt mal die SQL Statements von oben im Testshop ausprobiert und anschließend den Haupt Steuersatz von 19% auf 16% geändert. Die Preise sehen soweit alle korrekt aus was normale Produkte und Varianten betrifft. Bei Staffelpreisen habe ich noch Probleme, wo finde denn diese zum aktualisieren in der Datenbank? Kann meine eigene Frage beantworten. Falls noch jemand sucht, die Staffelpreise / reduzierten Preise stehen in der Tabelle: ps_specific_price Das SQL Statement sollte dann dem Beispiel der vorangegangenen folgend so aussehen: UPDATE `ps_specific_price` SET `price`=`price`*1.19/1.16; 1 Link to comment Share on other sites More sharing options...
Whiley Posted June 25, 2020 Author Share Posted June 25, 2020 Hallo Tecc, ich habe deine Ergänzung in den Post#1 dieses Thread übernommen. Jetzt müßte sich nur noch jemand um die Grundpreise kümmern. Grüsse Whiley Link to comment Share on other sites More sharing options...
Gurkcity Posted June 25, 2020 Share Posted June 25, 2020 Hallo Whiley, danke für die Ausführungen und das Zusammentragen der Infos. Wir haben uns das mit den specific_prices Tabellen näher angesehen. Das ist nicht ganz so einfach und sollte unterscheiden werden. Für den Fall, dass hier Produkte mit hinterlegten id_product stehen, kann das richtig sein. In der Regel steht aber im Feld 'price' ein -1.000000 Wert und erst dann wird abhängig von reduction_tax und reduction_type der Wert im Feld reduction berücksichtigt. Anderenfalls ist der Wert > 0 und wird als Fixwert behandelt. Betrifft übrigens Sonderpreise von Produkten, wie auch die Katalog-Preisregeln. Sehe ich es richtig, dass die Grundpreise gar nicht berücksichtigt werden müssen, da in der product Tabelle nur das unit_price_ratio gespeichert wird? Vielleicht habe ich auch einen Denkfehler...Ich werde das bis zum Wochenende mal testen und hier nochmal Feedback geben. Viele Grüße Chris Link to comment Share on other sites More sharing options...
SliderFlash Posted June 25, 2020 Share Posted June 25, 2020 hier eine Anleitung https://blog.ihrewebagentur.ch/prestashop-mwst-umstellen-von-19-auf-16/ Link to comment Share on other sites More sharing options...
Whiley Posted June 25, 2020 Author Share Posted June 25, 2020 vor 2 Stunden schrieb Gurkcity: Sehe ich es richtig, dass die Grundpreise gar nicht berücksichtigt werden müssen, da in der product Tabelle nur das unit_price_ratio gespeichert wird? Hallo Chris, das sehe ich genauso! Ich habe die Frage lediglich nochmal erwähnt, weil sie bereits in einem anderen Post schon mal in den Raum geworfen war. Grüsse Whiley Link to comment Share on other sites More sharing options...
Wuschel Posted June 26, 2020 Share Posted June 26, 2020 (edited) 17 hours ago, Whiley said: 20 hours ago, Gurkcity said: Sehe ich es richtig, dass die Grundpreise gar nicht berücksichtigt werden müssen, da in der product Tabelle nur das unit_price_ratio gespeichert wird? Hallo Chris, das sehe ich genauso! Das sehe ich aber gar nicht so! Denn um überhaupt einen Grundpreis speichern zu können, ist zwingend eine Eingabe im Feld Verkaufspreis brutto des Artikels erforderlich. So weit, so gut. Hat man aber Varianten, so muss eine unit_price_ratio erzeugt werden, indem man bei den Varianten eine Erhöhung oder Ermäßigung des Preises um einen bestimmten Betrag erfasst, da man den Preis selber nicht erfassen kann. Bleibt der Variantenpreis immer gleich, gilt das auch für den Grundpreis. Er wird korrekt ausgegeben. Falls nicht, hat man ein Problem, denn da das Entwicklerteam eigentlich nie so recht verstanden zu haben scheint, dass es einen Unterschied zwischen Stückpreis und Grundpreis gibt (im Englischen heißt beides unit price), wandert der Grundpreis dann mit. In 1.5 war es noch relativ einfach. Hatte man den den Variantenpreis vermindert oder erhöht, so reichte es aus, im Feld Auswirkung auf den Stückpreis (müsste eigentlich Grundpreis heißen!) umgekehrt den Bruttobetrag als Erhöhung bzw. Verminderung einzugeben, um den Grundpreis konstant ausgeben zu lassen. Ab 1.6 geht das aber leider nicht mehr. Die Resultate sind zwar numerisch abweichend, aber auf den korrekten Grundpreis kommt man trotzdem nie, außer mit einigen wirklich um die Ecke gedachten Überlegungen. Denn hier wurden in der Berechnung gleich mehrere Fehler eingebaut. Also ganz so einfach scheint die Sache doch nicht zu sein. Das gleiche Fehlverhalten beim Grundpreis findet man übrigens auch bei thirty bees, obwohl sich einer der Entwickler noch Dienstag im dortigen Forum über diesen Topic hier mokiert hat: https://forum.thirtybees.com/topic/4197-mehrwertsteuer-umstellung/?do=findComment&comment=36241 Vielleicht sollte sich @Traumflug mal besser auf die Fehlersuche begeben ... On 6/24/2020 at 11:03 PM, Tecc said: Kann meine eigene Frage beantworten. Falls noch jemand sucht, die Staffelpreise / reduzierten Preise stehen in der Tabelle: ps_specific_price Das SQL Statement sollte dann dem Beispiel der vorangegangenen folgend so aussehen: UPDATE `ps_specific_price` SET `price`=`price`*1.19/1.16; Dazu hat @Gurkcity ja schon die richtigen Einwände vorgebracht. Das Ganze würde in einem Fiasko enden, weil hier gar kein Preis gespeichert ist. Edited June 26, 2020 by Wuschel (see edit history) Link to comment Share on other sites More sharing options...
Gurkcity Posted June 26, 2020 Share Posted June 26, 2020 Wie angekündigt, haben wir nochmal die Steuer-Änderungsthematik zu den Grundpreisen recherchiert: Grundpreise für einfache Einzelprodukte sind unproblematisch, da hier das Verhältnis (unit_price_ratio) gespeichert ist. Das ist das Verhältnis des NettoProduktpreis zum Netto-Grundpreis. Also einfach nur ein Faktor, der durch die Mehrwertsteuerumstellung nicht betroffen ist. Bei Artikel mit Varianten, die Einfluss auf den Grundpreis haben verhält es sich ein wenig anders, da hier das Feld "Auswirkung auf den Preis pro Einheit" als absoluter Wert in der Datenbank steht. Das Feld "unit_price_impact" muss also auch mit dem Faktor der Umstellung multipliziert werden (am 01.07. => *1.19/1.16). Es ist also kein Raten notwendig, um die korrekten Preise zu bekommen. Und ehrlich gesagt, finde ich diese Berechnung viel charmanter und einfacher, als es noch bei 1.5 war. Es gibt hierbei noch weitere Felder zu beachten, z.B. in der product_attribute(_shop) Tabelle das Feld "price". Das ist die Nettopreis-Auswirkung auf den Produktpreis des Hauptproduktes. Auch dieser muss mit dem Faktor der Umstellung multipliziert werden (am 01.07. => *1.19/1.16). Viele Grüße Chris Link to comment Share on other sites More sharing options...
Recommended Posts