MwSt-Änderung wegen Corona

Shopware 5 Allgemein
#23

Ich habe es auf zwei Wege gemacht:

  1. Steuersatz 19% umbenannt und auf 16 geändert - Preis gesunken
  2. Steuersatz 19% eine Sonderregeleung für Kundengruppe EK von 16 hinterlegt => Preis gesunken

Jedesmal “Shopware Konfiguration”-Cache geleert!

Den Weg über “neuen Steuersatz” und dann dem Artikel zuordnen habe ich jetzt nicht gemacht, wäre mir zuviel Aufwand, alle Artikel zu ändern.

*hmm* - die Werte werden doch fest in die orders geschrieben - ändern sich da wirklich auch die Steuern bei Alt-Bestellungen? Dürfte eigentlich nicht sein - wäre ja ein grober Bug in Shopware.

Edit: *fck* Du hast Recht mit den alten Bestellungen.
Zurück auf LOS - wenn ich geahnt hätte, dass eine einfache Steueränderung bei Shopware so problematisch ist…
 

#24

Dann schau mal rein @sonic‍ dein 1) hab ich eben versucht. Wenn du alte Bestellungen öffnest, steht bei den Artikeln 16% statt 19%, bei Zahlartrabatt o.ä. bleiben die aber 19% stehen. Wenn ich auf Rechnung Vorschau klicke, steht da 19%. Nachgerechnet hab ich jetzt noch nicht, welcher Steuersatz tatsächlich berücksichtigt wurde. Gespeicherte Belege werden sich wohl nicht ändern. Aber auch das Vorgenannte wäre ungünstig und verwirrend.

Dein 2) sagt mir grad nix, das muss ich mal ansehen. Ich habe nur die zwei Steuersätze und eine Kundengruppe, da musste ich glaube ich nie Einstellungen vornehmen - außer bei einzelnen Artikeln die 7% auswählen.

#25

Jo, ich bin dann mal bei Dir - wieder mal was gelernt :wink:
Also: Habe ich “Bruttopreise” und änder im Artikel den Steuersatz, wird wohl der hinterlegte Netto-Preis neu berechnet, damit auch mit 16% der alte Bruttobetrag stimmt.
Für mich wäre das jetzt so OK, für Dich wohl eher nicht.
Damit kommt aber das nächste Problem:
In der Mehrfachänderung kann ich auf die Schnelle nicht TAX oder so finden. Und wenn doch, fällt Shopware ja immer wieder damit auf, dass Berechnungen und Aktualisierungen, die beim “Speichern” ausgeführt werden, bei der Mehrfachänderung nicht durchgeführt werden.

Ich habe jetzt aber ehrlich keine Lust, alle Artikel händisch neu zu speichern!

Also: Ändert man den vorhandenen Steuersatz, werden die Artikel billiger, alte Bestellungen haben dann aber völlig falsche Preise. Führt man einen neuen Steuersatz ein, muss man (womöglich) alle Artikel neu speichern, aber die alten Bruttopreise sind dann auch die neuen Bruttopreise.

Jetzt müsste ich gucken, wo ich lande, wenn ich zunächst die Preise im backend auf Netto umstelle, händisch alle Artikel den Steuersatz änder, und dann wieder auf Brutto stelle.

Was für ein Murks. Politischer Aktionismus trifft auf veraltete Software (wobei ich nicht glaube, dass SW6 da besser aufgestellt ist)

Will man die Preise senken, wird wohl der beste Weg sein, den Steuersatz direkt per SQL zu ändern, dann dürften die alten Netto-Preise erhalten bleiben  Sticking-out-tongue

#26

Ich hatte das bei uns im Testshop auch ausprobiert und den von Shopware angelegten Steuersatz von 19% auf 16% geändert. Und in der Tat werden alle Bruttopreise reduziert, da der Preis ja als Netto in der DB gespeichert wird und dann neu berechnet wird.

Ich habe nun auch mal in die Altbestellungen reingeschaut. Da steht dann tatsächlich auch 16 %, weil der Name des Steuersatzes sich über die taxID aus der s_core_tax geholt wird. Die tax_rate steht bei den Altebstellungen in der Datenbank aber weiterhin auf 19, d.h. die Preise bzw. der Betrag der Bestellung verändert sich nicht, nur die Bezeichnung.

 

Also der sauberste Weg wäre die Steuersätze 16 und 5 neu anzulegen und dann alle Artikel auf diese Steuersätze ab 1. Juli umzustellen (und auch die Versandkosten nicht vergessen, die stehen vermutlich auch “höchster”? Und dann an Neujahr wieder zurück?

Wird es da eine Handlungsempfehlung seitens Shopware geben?  

2 Likes
#27

@sonic schrieb:

 

Will man die Preise senken, wird wohl der beste Weg sein, den Steuersatz direkt per SQL zu ändern, dann dürften die alten Netto-Preise erhalten bleiben  Sticking-out-tongue

Genau das hatte ich weiter oben schon vorgeschlagen.

 

1 Like
#28

Vielleicht ist Shopware ja so hilfsbereit und erstellt ein FIX/Plugin, zur Verfügung.

 

Neue Probleme = neue Sorgen.

 

Warten wir mal ab.

#29

@kraeft21

 

In der DB ja, aber sind die Rg., nicht ausschlaggebend ?

 

Die ändert sich ja nicht.

Ich sehe vielmehr Probleme in der WaWi & dazugehörige Programme.

#30

Naja - die Umsatzssteuer hat sich ja schon mehr als einmal geändert. Grundsätzlich sollte man (und eine Software erst recht) damit umgehen können.
Erstaunlicher finde ich, dass der selbsternannte Innovations-Marktführer da im Shop keinen Weg für vorgesehen hat.

  1. Massenänderung aller Steuerklassen von A nach B OHNE Nettopreisneuberechnung
    2) Massenänderung aller Steuerklassen von A nach B MIT Nettopreisneuberechnung

Kann mich dunkel an Zeiten erinnern, da war die Umsatzsteuer noch bei 16%. Die letzte Erhöhung auf 19% war wohl 1998 - die Gründer und Entwickler von Shopware können also nicht geahnt haben, dass sich da mal was ändert - war ja vor deren Zeit im letzten Jahrtausend  Sticking-out-tongue

1 Like
#31

@sonic‍ ich habe getestet:
Standardsteuersatz von 19% auf 16%, führt zur Preisreduzierung beim VK-Preis.
Die frühreren Bestellungen werden unter Positionen mit dem falschen Steuersatz gezeigt. Bereits generierte Dokumente UND auch für alte Bestellungen neu generierte Dokumente enthalten den Steuersatz zum Zeitpunkt der Bestellung, Berechnung auch korrekt. Scheinbar ist nur die Anzeige im Reiter Positionen dann falsch.

D. h. ab Januar 2021 haben die Bestellungen der letzten 6 Monate in der Detailansicht einen falschen Steuersatz angezeigt, aber richtig berechnet und auf Belegen ausgewiesen.

Wenn es da keinen anderen Haken gibt, den ich noch nicht sehe, könnte ich damit leben. Die 2-3 Cent je Artikel gönn ich dann dem Kunden und er freut sich, weil er denkt, er hätte was gespart. Wie bei kostenlosem Versand und der kostenlosen Zahlart Paypal auch :wink:

Bei den neu angelegten Steuersätzen 16 und 5 habe ich das oben beschriebene Problem. Ich finde keine Möglichkeit bei der Mehrfachänderung. Ändere ich einen Artikel manuell, wird der Preis im Frontend nicht reduziert.

So gesehen hätten wir zwei Möglichkeiten - jenachdem ob der Händler den Endpreis senken will oder nicht. In den nächsten Tagen/Wochen wird sich zeigen, ob die Preissenkung im VK verpflichtend oder freiwillig ist.

@kraeft21‍
Die Versandkosten sollten den Mwst-Satz eigentlich aus der Hauptleistung ziehen. War auch bei meinem Test so (also die beiden gerade beschriebenen Varianten). Hast du in einer Rechnung versch. Steuersätze, muss das System den ansetzen mit dem höchsten Warenwert. (Vielleicht ist das auch das von dir gemeinte “höchster”)

 

 

#32

und eine Software erst recht

 

Da hängt ein Rattenschw… dahinter.

 

Und Shopware ist auch eine Software.

Wie soll man so eine jetzige Situation, vorhersehen ?

 

Ich bau doch nicht wahrscheinlichkeiten ein :wink:

#33

@Toric‍ Das “Label”-Problem betrifft aber nicht nur das Backend. In “s_order_details” wird die taxID hinterlegt (backend) aber auch für das Frontend.
Ich habe jetzt nicht die Bestellübersicht für den Kunden im Frontend - also seiner Historie - im Kopf, aber wenn dort die Steuer angezeigt wird, zieht diese das Label auch aus der Steuer direkt.
Also bekommt Kunde erst 6 Monate das falsche Label für Altbestellungen angezeigt. Ab Januar stimmen dann zwar die Alt-Bestellungen von vor 01.07. wieder - aber von 01.07 bis 31.12 sind dann dauerhaft mit 19% falsch angezeigt. Würde mich nicht wundern, wenn das dann wieder die Abmahnmaffia auf den Plan ruft.

Der sauberste Weg ist: Ändern der id in der Datenbank. Wenn man die Steuersenkung so dem Kunden weitergeben möchte, war es das schon.
Möchte man den alten Bruttopreis behalten, muss man auch noch an die s_article_prices ran. Ginge auch noch per plain SQL, wird aber unschön, weil JOIN auf s_articles und durch einmal im Juli und dann wieder im Januar “multiplizieren und runden” die Preise garantiert “anders” werden. Da könnte man dann aber die “alten” Preise in s_articles_prices_attributes zwischen speichern und im Januar zurück kopieren.

Sind ja noch knappe 4 Wochen.

Was musste ich mir heute im SPIEGEL-Forum sagen lassen: Wenn ich für das einfache Umschalten der Steuer länger brauche, als einen klick, dann bin ich kein Leistungsträger…

#34

Hi,

wir wäre es denn für die entsprechenden Länder/Regionen in der Steuereinstellung eine eigene Steuerregel bei 19 und 7% zu setzen mit den temporären Steuersätzen.

Zur Einhaltung der Bruttopreise würde ich dann auf ein Plugin wie dieses hier

nehmen und dies dann für die entsprechende Zeit mieten, wie bei Lieferschwellenländern auch. Ist doch dann eigentlich nichts anderes oder habe ich hier einen Denkfehler ?

Grüße
Stefan

 

#35

@Schnurk schrieb:

Hi,

wir wäre es denn für die entsprechenden Länder/Regionen in der Steuereinstellung eine eigene Steuerregel bei 19 und 7% zu setzen mit den temporären Steuersätzen.

Den Preis kann man damit gesondert ändern - s.o. - aber es ist eine Änderung eines bestehenden Steuersatzes.
Und da in den Steuersätzen keine “Historie” gespeichert ist, kann Shop also nicht wissen, was “früher” dort stand. Sprich: Damit wirst Du die gleichen Probleme in der “Bezeichnung” im backend/Frontend haben, wie wenn Du einfach nur den Namen und den Satz änderst. Reine Vermutung, die noch zu überprüfen wäre  Wink

#36

Die Bezeichnung im Backend ist ja eher kosmetischer Natur, diese könnte ja auch “Normaler Steuersatz” und “Verminderter Steuersatz” heißen.

Zur Darstellung auf den Dokumenten werden ja die Steuersätze benutzt und nicht die Bezeichnungen.

Die Order_details werden mit Bruttopostitionswerten befüllt und würden somit für vergangene Bestellungen nicht geändert werden.
Im Frontend selbst wird, außer im Warenkorb, ja kein direkter Steuersatz angezeigt und diese beziehen sich ja dann auf die aktuelle Zeit/Bestellung. Alte Bestellungen im Kundenkonto holen sich die Daten aus der order/order_details Tabelle.

Das würde bedeuten wenn du jetzt den Steuersatz änderst, dann ändern sich keine alten Bestellungen dadurch, auch nicht wenn du die Dokumente neu generierst. Drittplugins mal außen vor die evtl. anders arbeiten.

Alles andere würde ja zu einem katastrophalen verhalten bei einer Lieferschwellenüberschreitung führen.

ALLES THEORIE - Ausprobiert habe ich das auch noch nicht, ich kann nur die Erfahrung aus Lieferschwellenanpassung und nach wie vor korrekter alter Bestelldaten schon mal bestätigen.

 

 

1 Like
#37

Bestätige (hatte ich mir so genau noch nicht angeguckt): Im Frontend in der Historie kommt die Steuer nicht vor. Das “Problem” mit dem Backend wäre für mich (und den einen oder anderen) auch nicht so das Problem. Augen zu und durch: Einfach die vorhandenen Steuersätze zum 01.07 anpassen und umbenennen.

#38

@sonic schrieb:

@Toric‍ Das “Label”-Problem betrifft aber nicht nur das Backend. In “s_order_details” wird die taxID hinterlegt (backend) aber auch für das Frontend.
Ich habe jetzt nicht die Bestellübersicht für den Kunden im Frontend - also seiner Historie - im Kopf, aber wenn dort die Steuer angezeigt wird, zieht diese das Label auch aus der Steuer direkt.
Also bekommt Kunde erst 6 Monate das falsche Label für Altbestellungen angezeigt. Ab Januar stimmen dann zwar die Alt-Bestellungen von vor 01.07. wieder - aber von 01.07 bis 31.12 sind dann dauerhaft mit 19% falsch angezeigt. Würde mich nicht wundern, wenn das dann wieder die Abmahnmaffia auf den Plan ruft.

Der Kunde sieht bei mir im Shop keinen Steuersatz, wenn er sich seine alten Bestellungen aufruft. Da ist auch der Mehrwertsteuerbetrag nicht ausgewiesen. Nur Bruttobeträge mit * und der Zusatz am Ende * inkl. gesetzl. Mwst. …

 

#39

@drakon schrieb:

@igalvezgil‍ Euer Plugin ist für viele da sicher eine Hilfe. Aber letztlich hängt die Besteuerung vom Lieferzeitpunkt und nicht vom Zeitpunkt der Order oder der Rechnungsstellung ab. Wenn ich Bestellung aus 06/20 also erst in 07/20 versende (versenden kann), dann gilt bereits der neue Steuersatz. Da kommt noch viel Arbeit auf die Shopbetreiber zu.

Wenn jemand per Vorkasse Ende Juni bestellt und wir dann die Rechnung am Juli erstellen, wird das doch ein großes Problem. Die Auftragsbestätigung und der Endbetrag enthält doch 19% MwSt. Man kann doch bei der Rechnung nicht was anderes machen, besonders wenn man das Geld schon bekommen hat!

#40

Hab mich ja nach “Ausprobieren” schon korrigiert  Wink
Bleibt die Frage:
Was ist mit den Bestellungen, die am 30.06 oder früher reinkommen, Du pünktlich um Mitternacht am 01.07. die Steuersätze “änderst” und danach mit den Daten aus den alten Bestellungen und der unveränderten ID die Rechnungen mit dem neuen Steuersatz aus SW heraus erstellst? Kann ich jetzt echt nichts zu sagen, wir benutzen Shopware nicht zur Belegerstellungen.

An den “Übergängen” im Juni/Juli und Dezember/Januar wird genau das passieren. Da wäre es sauberer, wirklich neue Steuersätze zu definieren und diese zur Belegerstellung erst umstellen. Ist jetzt aber kein Problem, über das ich mir den Kopf zerbrechen muss - die Shops sind bei mir zu den Zeiten eh im Urlaubsmodus. Aber denkt mal drüber nach…

Ob die Wirtschaft morgen noch jubeln wird? Die Probleme dürften sich durch alle kleine und große Shops WaWis etc. ziehen. Bei den “Portal”-Betreiber werden sicherlich gerade ne Menge kluge Köpfe aus der Kurzarbeit geholt  Wink

Bin dann jetzt mal im “Beobachtung-Modus”.

#41

@10055 schrieb:

Wenn jemand per Vorkasse Ende Juni bestellt und wir dann die Rechnung am Juli erstellen, wird das doch ein großes Problem. Die Auftragsbestätigung und der Endbetrag enthält doch 19% MwSt. Man kann doch bei der Rechnung nicht was anderes machen, besonders wenn man das Geld schon bekommen hat!

Ganz einfach: Es gilt der Steuersatz, wenn Du die Rechnung stellst, bzw. Leistungsdatum.
a) Du behälst Die Bruttopreise => ändert sich in der Rechnung die ausgewiesene Steuer - Summe bleibt aber gleich.
b) Die Bruttopreise ändern sich zum Stichtag => die Rechnung wird niedriger ausfallen, Teilerstattung der Vorkasse *Punkt* Alles Andere wird für Dich teuer!

Lustig wird es - hatte ich so aber schon geschrieben - wenn die Steuer wieder von 16% auf 19% angehoben wird. Da müsste Kunde ja nachzahlen, wirst Du kaum durchgesetzt bekommen.

Gibt da nur zwei Wege: Bruttopreise dürfen sich nicht ändern (was ja nicht dem Sinn der Senkung entspricht), oder Du machst zu den Stichtagen den Shop “zu”, damit Du alle Rechnungen mit zur Bestellung passendem Steuersatz erstellen kannst.
 

#42

@sonic schrieb:

Hab mich ja nach “Ausprobieren” schon korrigiert  Wink
Bleibt die Frage:
Was ist mit den Bestellungen, die am 30.06 oder früher reinkommen, Du pünktlich um Mitternacht am 01.07. die Steuersätze “änderst” und danach mit den Daten aus den alten Bestellungen und der unveränderten ID die Rechnungen mit dem neuen Steuersatz aus SW heraus erstellst? Kann ich jetzt echt nichts zu sagen, wir benutzen Shopware nicht zur Belegerstellungen.

Das ist das, was ich eben getestet habe. Wollte gerade testen, ob man die Beträge alle manuell anpassen kann, wenn die Zahlung im anderen Steuerzeitraum eingeht. Jetzt passt gar nix mehr. Standardsatz auf 16 % geändert - wie vorher auch schon mal - im Shop bestellt zum Preis von 16% im BE wird Versand mit 16% ausgewiesen und Produkt mit 19% - Preise aber für reduzierter Steuersatz. Totales Chaos perfekt. Versuche jetzt Urzustand herzustellen und gehe mit dir in den Beobachtungsmodus :wink:

 

1 Like