MwSt 16% ab 1.7.2020

[Whiley]

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

 

 

 

[Wuschel]

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)

[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?

[Whiley]

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

[Whiley]

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

[Tecc]

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?

[rictools]

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?

[Claudiocool]

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.

[Wuschel]

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)

[Claudiocool]

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.

[rictools]

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)

[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.

[Whiley]

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

[Claudiocool]

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. 

[rictools]

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)

[Whiley]

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.

 

[RabbitZzZ]

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?

[Whiley]

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

[Claudiocool]

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)

[Whiley]

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

[Shad86]

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.

[rictools]

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 ...

[Whiley]

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

[Wuschel]

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)

[Tecc]

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.

[Claudiocool]

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

 

[chillum]

Es geht auch einfacher, bei der DE Standard 19 % einfach 19.000 durch 16.000 ersetzen.

[rictools]

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 ...

[Whiley]

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

[rictools]

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?

[Whiley]

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

 

[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.

[DRMasterChief]

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? 

[Shad86]

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)

[Whiley]

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

[DRMasterChief]

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.

[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

@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.

[Bergmann]

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...

 

[rictools]

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!

[Whiley]

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

[Jens Fessel]

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

[rictools]

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.

[codewichtel]

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?

[Jens Fessel]

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 🤔

[codewichtel]

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)

[Whiley]

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

[rictools]

Ich denke es wird eher problematisch, wenn Kunden am 31. Dezember abends noch schnell etwas zum niedrigeren MwSt.-Satz bestellen wollen ...

[Whiley]

Kulanz - heißt das Zauberwort!

Alter (niedriger) Preis aber schon die 19% MwSt, kostet halt 2,52% an Werbekosten.

 

[codewichtel]

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.

[Shad86]

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.

[rictools]

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?

[Claudiocool]

Im Normalfall gilt der Tag, an dem die Leistung erbracht wurde.

[Whiley]

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.

[Claudiocool]

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.

[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?

[Whiley]

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.

 

 

[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?

[Whiley]

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.

[Shad86]

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%.

[Wuschel]

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." 

[rictools]

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.

[codewichtel]

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%

 

[Claudiocool]

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

[rictools]

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 ...

[Claudiocool]

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.

[Wuschel]

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.

[DRMasterChief]

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* 

[DRMasterChief]

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. 

[Whiley]

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

[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....

[Tecc]

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?

[rictools]

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 ...

[Claudiocool]

Ja, aber nicht mit Tricksereien, sondern im Grunde genommen durch ein Auftragsstorno und eine Neuanlage, dann ist es korrekt und nicht zu beanstanden

 

[Tecc]

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;

 

[Whiley]

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

 

[Gurkcity]

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

[SliderFlash]

hier eine Anleitung

https://blog.ihrewebagentur.ch/prestashop-mwst-umstellen-von-19-auf-16/

[Whiley]

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

 

[Wuschel]

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)

[Gurkcity]

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

[Tecc]

21 hours ago, Gurkcity said:

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

Vielen Dank für den Hinweis, ich hatte hier in meinem Referenzshop lediglich feste Werte stehen und keine relativen Änderungen zum Standardpreis des Artikels, somit ist mir das Problem nicht aufgefallen.

Hast Du hierzu schon details wie das Update Statement in diesem Fall angepasst werden müsste?

[Whiley]

vor 1 Stunde schrieb Gurkcity:

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).

Hallo Chris,

danke, ich habe das so im ersten Post augenommen.

Grüsse
Whiley

[Casper_O]

Eine kleine Hilfe für Sie alle für Produkte mit Variantenpreis, dass Sie Produkte korrekt aktualisieren können, je nachdem, ob es 19 oder 7 MwSt. Ist

UPDATE ps_product_attribute_shop
LEFT JOIN ps_product ON ps_product.id_product = ps_product_attribute_shop.id_product
SET ps_product_attribute_shop.price = ps_product_attribute_shop.price * 1.19 / 1.16,
ps_product_attribute_shop.unit_price_impact = ps_product_attribute_shop.unit_price_impact * 1.19 / 1.16
WHERE
	ps_product.`id_tax_rules_group` = 1;

7% -> 5%

UPDATE ps_product_attribute_shop
LEFT JOIN ps_product ON ps_product.id_product = ps_product_attribute_shop.id_product
SET ps_product_attribute_shop.price = ps_product_attribute_shop.price * 1.07 / 1.05,
ps_product_attribute_shop.unit_price_impact = ps_product_attribute_shop.unit_price_impact * 1.07 / 1.05
WHERE
	ps_product.`id_tax_rules_group` = 2;

SONDERPREISE (Grundpreis verändert)

UPDATE `ps_specific_price`
LEFT JOIN ps_product ON ps_product.id_product = ps_specific_price.id_product
SET `ps_specific_price`.`price`=`ps_specific_price`.`price`*1.19/1.16
WHERE `ps_specific_price`.`price` != -1
AND ps_product.`id_tax_rules_group` = 1;

UPDATE `ps_specific_price`
LEFT JOIN ps_product ON ps_product.id_product = ps_specific_price.id_product
SET `ps_specific_price`.`price`=`ps_specific_price`.`price`*1.07/1.0.5
WHERE `ps_specific_price`.`price` != -1
AND ps_product.`id_tax_rules_group` = 2;

SONDERPREISE (Rabatt anwenden zzgl MwSt.)

UPDATE
ps_specific_price
LEFT JOIN ps_product ON ps_product.id_product = ps_specific_price.id_product
SET ps_specific_price.reduction = ps_specific_price.reduction*1.19 / 1.16
WHERE
ps_specific_price.reduction_type = "amount" AND
ps_specific_price.reduction_tax = 0 AND
ps_product.id_tax_rules_group = 1

UPDATE
ps_specific_price
LEFT JOIN ps_product ON ps_product.id_product = ps_specific_price.id_product
SET ps_specific_price.reduction = ps_specific_price.reduction*1.07 / 1.05
WHERE
ps_specific_price.reduction_type = "amount" AND
ps_specific_price.reduction_tax = 0 AND
ps_product.id_tax_rules_group = 2

Edited June 26, 2020 by Casper_O
Variantenpreis und Varianteneinheitspreis in derselben Abfrage (see edit history)

[Wuschel]

On 6/26/2020 at 12:26 PM, Gurkcity said:

• 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.

Theoretisch ja.Aber ich glaube, wir reden aneinander vorbei. Mir geht es nicht allein um den Variantenpreis, sondern um Varianten mit Grundpreisangabe.

Das Problem ist nicht der Eintrag in das Datenbankfeld "unit_price_impact", sondern das, was Prestashop ab 1.6 und auch thirty bees daraus machen: einen nicht mehr konstanten Grundpreis, der sich bei jeder Produktvariante ändert. (s. in Whileys Demoshop das Produkt demo_4 - Printed Dress) Das ändert sich auch dadurch nicht, dass das Feld mit dem geänderten MwSt-Satz per SQL-Befehl angepasst wurde. Es reicht nicht aus, nur in die Datenbank zu blicken, das Shopverhalten im Livebetrieb ist ausschlagebend.

On 6/26/2020 at 12:26 PM, Gurkcity said:

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).

Keineswegs immer, denn das wird auch bei vielen, die, wie hier schon öfter vorgeschlagen, nur bei den Varianten die Preise erfassen und das Feld Preis beim Parent auf 0 belassen,  der Nettopreis der Variante sein, auf den automatisch die MwSt gleich welchen Satzes aufgerechnet wird. Für diesen nicht gerade seltenen Fall sollte gar nichts geändert werden, es sei denn, man will erzwingen, dass die Bruttopreise gleich bleiben. 

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

[rictools]

vor 2 Stunden schrieb Wuschel:

Hier sollte deswegen gar nichts geändert werden, es sei denn, man will erzwingen, dass die Bruttopreise gleich bleiben. 

Äh, habe ich jetzt etwas falsch verstanden, sind diese ganzen Änderungen nicht nur dann erforderlich, wenn der Shopbetreiber seine Bruttopreise nicht senken will?

[Wuschel]

Das meiste ja, andere Vorschläge sind völlig überflüssig.

Im Prinzip reicht es völlig aus, wie ich schon ganz oben gesagt habe, die beiden Steuersätze im Back Office zu ändern. Prestashop legt - das habe ich mir auch erst mal klar machen müssen - daraufhin zwei neue an, lässt die alten im Back Office verschwinden, belässt aber den Status auf active, so dass sie für alle früheren Bestellungen und Rechnungen weiterhin gelten. SQL-Befehle sind nicht erforderlich.

Die Steuerregeln werden daraufhin automatisch angepasst, ohne dass es irgendeines SQL-Befehls bedürfte. Zum 31.12. ändert man die neuen Steuersätze erneut, die daraufhin wiederum automatisch durch neue (erkennbar an den IDs) ersetzt werden - und das wars.

Bei Varianten sind ebenfalls keine weiteren Änderungen erforderlich - es sei denn, man arbeitet mit einem angezeigten Grundpreis. Aber die damit verknüpften Probleme habe ich ja bereits erwähnt. 

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

[Whiley]

Am 27.6.2020 um 3:41 PM schrieb Wuschel:

Zum 31.12. ändert man die neuen Steuersätze erneut, die daraufhin wiederum automatisch durch neue (erkennbar an den IDs) ersetzt werden - und das wars.

Nur sinnvoll wenn die Daten (inkl. der tax-id) nicht exportiert werden, z.B. an eine Wawi. Wenn du den sql-Befehl so wie im ersten Post beschrieben (das ist ja auch nur ein einziger Vorgang) eingibst,  kehrst du nach dem 31.12 wieder zur ursprünglichen ID zurück.

Grüsse
Whiley

[Jörg Saxtec]

Wir haben für unsere Shops ein Modul gebaut, welches die neuen Steuern (5% und 16%) anlegt und entsprechend die Produkte ändert.

Dabei kann man auch wählen, ob der Nettobetrag oder der Bruttobetrag übernommen wird. Dementsprechend wird der Produktpreis in der Datenbank neu berechnet.

Sollte der eine oder andere Interesse an dem Modul haben, oder einen kennen, der einen kennt, der Interesse haben könnte, so freue ich mich über eine Nachricht.

Das Modul kann man hier sehen: https://www.youtube.com/watch?v=Rus8RG_SkQU 

 

Liebe Grüße und bleibt fokussiert, 

Jörg

Edited June 29, 2020 by Jörg Saxtec (see edit history)

[Gurkcity]

Vielleicht sollten wir uns in Zukunft abstimmen, 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. 😉

Ich finde es aber auch gar nicht so schlecht, wenn der Shopbetreiber die Wahl hat, per Datenbankadministration die Umstellung durchzuführen (falls die Bruttopreise beibehalten werden sollen, ansonsten ist ein direkter Datenbankeingriff gar nicht notwendig) oder ein Modul nutzt und mit wenigen Klicks die Änderungen durchführen kann. Ein Modul hat den Vorteil, es gibt Support und es ist einfach in der Bedienung.

Wir wünschen allen morgen Abend eine erfolgreiche Umstellung! 🙏

Viele Grüße

Chris

[Jörg Saxtec]

22 minutes ago, Gurkcity said:

Vielleicht sollten wir uns in Zukunft abstimmen, 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. 😉

Ich finde es aber auch gar nicht so schlecht, wenn der Shopbetreiber die Wahl hat, per Datenbankadministration die Umstellung durchzuführen (falls die Bruttopreise beibehalten werden sollen, ansonsten ist ein direkter Datenbankeingriff gar nicht notwendig) oder ein Modul nutzt und mit wenigen Klicks die Änderungen durchführen kann. Ein Modul hat den Vorteil, es gibt Support und es ist einfach in der Bedienung.

Wir wünschen allen morgen Abend eine erfolgreiche Umstellung! 🙏

Viele Grüße

Chris

Gern. Ich glaube auch in weiteren geschäftlichen Belangen wäre es für beide von Vorteil, wenn wir unsere Kompetenzen zusammenführen. Ich persönlich sehe da sehr viel Potential. 

[ShopMann]

Hallo zusammen.

Ich weiß, bin zu spät aufgewacht.

Trotzdem eine dumme Frage:

reicht es nicht, wenn ich am Mieternacht den Shop auf Wartungsmodus umschalte, dann ändere einfach bei Steuersatzeinstellungen beim Steuersatz 19% den Wert auf 16% und beim Steuersatz 7% den Wert 5%?

Wenn es nicht der Fall ist, würde mich freuen auf die Hinweise wo kann ich dementsprechende Module kaufen.

Hoffe jemand antwortet heute noch und bis dahin lese ich den Forumzweig bis zum Ende.

 

MfG

[rictools]

Ich habe jetzt - nachdem heute kein Versand mehr möglich ist - die Umstellung der MwSt. vorgenommen (und auch schon die erste Bestellung mit den reduzierten Preisen erhalten). Ich gebe die Preissenkung an meine Kunden weiter und das funktioniert offenbar sehr einfach, sodaß dafür kein Modul erforderlich ist.

Ich habe (bei 1.6) unter Lokalisierung -> Steuersätze mit "Bearbeiten" von 19 auf 16 % umgestellt, dabei hat Prestashop den vorhandenen Steuersatz mit der ID 1 gelöscht und einen neuen mit der ID 30 angelegt und offenbar die Zuordnung in der Datenbank automatisch geändert.

Anschließend wurde noch der alte Preis angezeigt, ich habe mit einem Modul alle Caches gelöscht, dann wurde nach komplettem Neuladen (beim Klick auf Aktualisieren Umschalttaste drücken) der neue Preis im Shop übernommen, auch für Produkte mit Varianten.

Jetzt mußte bei vorliegenden Bestellungen, bei denen der Kunde die Auslieferung ab dem 1.7. wünschte, noch die Umstellung erfolgen, mit dem Bearbeiten des Produkts (Menge auf 2 und dann wieder auf 1) unten auf der Seite der Bestellung im BackOffice klappte das zunächst nicht, aber zusätzlich mit Order Edit (Bestandteil der kostenlosen Prestools-Suite), hier mußte ich nur die Seite der Bestellung aufrufen und auf "Modify Order Lines" klicken (klappt aber nicht, wenn man die Prozedur mit dem Bearbeiten im BackOffice nicht vorher ausgeführt hat, vielleicht kennt jemand da eine einfachere Prozedur).

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

[Jörg Saxtec]

1 minute ago, rictools said:

Ich habe jetzt - nachdem heute kein Versand mehr möglich ist - die Umstellung der MwSt. vorgenommen (und auch schon die erste Bestellung mit den reduzierten Preisen erhalten). Ich gebe die Preissenkung an meine Kunden weiter und das funktioniert offenbar sehr einfach, sodaß dafür kein Modul erforderlich ist.

Ich habe (bei 1.6) unter Lokalisierung -> Steuersätze mit "Bearbeiten" von 19 auf 16 % umgestellt, dabei hat Prestashop den vorhandenen Steuersatz mit der ID 1 gelöscht und einen neuen mit der ID 30 angelegt und offenbar die Zuordnung in der Datenbank automatisch geändert.

Anschließend wurde noch der alte Preis angezeigt, ich habe mit einem Modul alle Caches gelöscht, dann wurde nach komplettem Neuladen (beim Klick auf Aktualisieren Umschalttaste drücken) der neue Preis im Shop übernommen, auch für Produkte mit Varianten.

Jetzt mußte bei vorliegenden Bestellungen, bei denen der Kunde die Auslieferung ab dem 1.7. wünschte, noch die Umstellung erfolgen, mit dem Bearbeiten des Produkts unten auf der Seite der Bestellung im BackOffice klappte das leider nicht, aber mit Order Edit (Bestandteil der kostenlosen Prestools-Suite), hier mußte ich nur die Seite der Bestellung aufrufen und auf "Modify Order Lines" klicken.

Das ist aus meiner Sicht nur die halbe Miete. Unser Modul legt eine zusätzliche Steuer an und setzt alle Produkte auf die neue Steuer. Das ist notwendig, da es zum festen Steuersatz in der Datenbank noch Referenzen geben kann (Warenkörbe, Bestellungen, Rechnungen, etc). Ich sage mit Absicht "kann" und nicht "muss". daher ist es ohne das Modul möglich, dass eine "alte" Rechnung auf einmal mit 16% ausgegeben wird. Das Finanzamt wird sicherlich mehr als die 19,90 EUR für das Modul an Aufwand kosten. 

Ich lasse mich gerne eines besseren belehren. Denn sonst hätte ich mir die Arbeit nie gemacht. (Und nein, der Erlös des Modules deckt in keiner Weise den Aufwand, den wir damit hatten) 

Bleibt fokussiert,

Jörg   

[ShopMann]

vor 4 Minuten schrieb rictools:

Ich habe (bei 1.6) unter Lokalisierung -> Steuersätze mit "Bearbeiten" von 19 auf 16 % umgestellt, dabei hat Prestashop den vorhandenen Steuersatz mit der ID 1 gelöscht und einen neuen mit der ID 30 angelegt und offenbar die Zuordnung in der Datenbank automatisch geändert.

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?

[ShopMann]

vor 2 Minuten schrieb Jörg Saxtec:

Das ist aus meiner Sicht nur die halbe Miete. Unser Modul legt eine zusätzliche Steuer an und setzt alle Produkte auf die neue Steuer. Das ist notwendig, da es zum festen Steuersatz in der Datenbank noch Referenzen geben kann (Warenkörbe, Bestellungen, Rechnungen, etc). Ich sage mit Absicht "kann" und nicht "muss". daher ist es ohne das Modul möglich, dass eine "alte" Rechnung auf einmal mit 16% ausgegeben wird. Das Finanzamt wird sicherlich mehr als die 19,90 EUR für das Modul an Aufwand kosten. 

Ich lasse mich gerne eines besseren belehren. Denn sonst hätte ich mir die Arbeit nie gemacht. (Und nein, der Erlös des Modules deckt in keiner Weise den Aufwand, den wir damit hatten) 

Bleibt fokussiert,

Jörg   

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?

[Jörg Saxtec]

7 minutes ago, Viaceslav said:

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?

Zumindest unser Modul nimmt Dir nur die Arbeit mit (möglicherweise tausenden) Produkten, dem neuberechnen des Bruttopreises (das war unser Hauptanliegen)  und dem Anlegen der neuen Steuer ab. Weitere Module, Versanddienste, wasauchimmer musst Du dann manuell der neu generierten Steuer zuweisen. Ich denke, das ist in jedem Shop sehr individuell und kann nicht über ein allgemeines Modul für unter 20 EUR abgebildet werden. 

[rictools]

vor 25 Minuten schrieb Jörg Saxtec:

Das ist aus meiner Sicht nur die halbe Miete. Unser Modul legt eine zusätzliche Steuer an und setzt alle Produkte auf die neue Steuer. Das ist notwendig, da es zum festen Steuersatz in der Datenbank noch Referenzen geben kann (Warenkörbe, Bestellungen, Rechnungen, etc). Ich sage mit Absicht "kann" und nicht "muss". daher ist es ohne das Modul möglich, dass eine "alte" Rechnung auf einmal mit 16% ausgegeben wird. Das Finanzamt wird sicherlich mehr als die 19,90 EUR für das Modul an Aufwand kosten. 

Ich habe meinen Post noch editiert, das Umstellen der noch zu 19 % getätigten Bestellungen auf 16 % funktionierte nicht allein mit Prestools.

Ich wollte keinesfalls eure Module kritisieren, gut dass es die gibt und es gibt ja hier auch viele, die ihre Preise nicht senken wollen, da ist die manuelle Umstellung erheblich aufwändiger. Aber für meinen Prestashop 1.6 wäre offenbar sowieso keines der Module in Betracht gekommen.

Prestashop hat ja automatisch auch eine neue Steuer mit anderer ID angelegt, ich habe gerade testweise eine Rechnung einer älteren Bestellung neu aufgerufen, sie wird korrekt mit 19 % MwSt. angezeigt.

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

[ShopMann]

vor 5 Minuten schrieb Jörg Saxtec:

Zumindest unser Modul nimmt Dir nur die Arbeit mit (möglicherweise tausenden) Produkten, dem neuberechnen des Bruttopreises (das war unser Hauptanliegen)  und dem Anlegen der neuen Steuer ab. Weitere Module, Versanddienste, wasauchimmer musst Du dann manuell der neu generierten Steuer zuweisen. Ich denke, das ist in jedem Shop sehr individuell und kann nicht über ein allgemeines Modul für unter 20 EUR abgebildet werden. 

Ich habe den Shop auch noch per FastBay-Module an Ebay eingebunden. Bin dabei auch nicht sicher ob es nicht zu Überraschungen kommt. Habe Ihres Modul gerade gekauft. Kann ich mit Ihnen bei Bedarf nur hier kommunizieren?

[Jörg Saxtec]

3 minutes ago, rictools said:

Ich habe meinen Post noch editiert, das Umstellen der noch zu 19 % getätigten Bestellungen auf 16 % funktionierte nicht allein mit Prestools.

Ich wollte keinesfalls eure Module kritisieren, gut dass es die gibt und es gibt ja hier auch viele, die ihre Preise nicht senken wollen, da ist die manuelle Umstellung erheblich aufwändiger. Aber für meinen Prestashop 1.6 wäre offenbar sowieso keines der Module in Betracht gekommen.

Prestashop hat ja automatisch auch eine neue Steuer mit anderer ID angelegt, ich habe gerade testweise eine Rechnung einer älteren Bestellung neu aufgerufen, sie wird korrekt mit 19 % MwSt. angezeigt.

Alles gut Habe es auch nicht so gemeint. 

PS: Unser Modul ist wirklich "nur" sinnvoll, wenn die netto Preise angehoben werden sollen und die Brutto Preise bleiben sollen. Das Modul für 1.6 geht gleich online und ist noch in der Testphase. 

[Jörg Saxtec]

2 minutes ago, Viaceslav said:

Ich habe den Shop auch noch per FastBay-Module an Ebay eingebunden. Bin dabei auch nicht sicher ob es nicht zu Überraschungen kommt. Habe Ihres Modul gerade gekauft. Kann ich mit Ihnen bei Bedarf nur hier kommunizieren?

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