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.
Hab mich ja nach „Ausprobieren“ schon korrigiert
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
Dann muss man wohl oder übel, um 23:59 Uhr, die Bestellungen ziehen und dann um 00:00 Uhr umstellen.
Also, wo ist das wirkliche Problem ?
Um was geht es dir hier? Um 0 Uhr muss die Mwst in Shop umgestellt werden. Ggf. geht man dann ein paar Stunden in den Wartungsmodus. Das ist aber nur die eine Sache.
Die andere Sache sind aber Bestellungen aus Juni, die erst im Juli ausgeführt oder gezahlt werden. Was bei einem Istversteuerer um 23:58 mit Paypal oder Kreditkarte gezahlt wird, passt. Wenn aber Überweisung gewählt wird, geht das Geld erst im Juli ein.
Beim Sollversteuerer nützt die Zahlung nichts um 23.58, wenn die Leistung im Juli erbracht wird. Oder hab ich was übersehen?
Das von Dir verlinkte wäre in etwa das, was ein Plugin letztlich auch machen würde. Greift natürlich nicht bei Preisgruppen oder abweichenden Ländereinstellungen in den Steuern. Aber im 0815-Shop sollte das so gehen.
Das zweite UPDATE würde ich dann aber gleich mit einem SET für die taxID erweitern. Den Faktor könnte ein Plugin automatisch aus den beiden Steuersätzen (also den gesetzten und den zu setzenden) errechnen. Erwarte aber nicht (auch nicht bei einer automatisierten Lösung), dass die Bruttopreise am Ende identisch sind. 4 Stellen und Rundung werden schon für leichte Abweichungen führen. Die zweite Rundung schlägt ja dann am 01.01.2021 zu Bei Schwellenwertpreisen wird wohl ggf. Nachbessern nötig sein.
ja, aber ist die Belegerstellung nicht ausschlaggebend ?
Also der Tag der Rg. Erstellung ?
Dann wird sich der Kunde doch freuen, dass er 3% weniger bezahlt
Eigentlich geht es hier eher um die technische Lösung ! Ausserdem wird sich der Kunde dann auch im Januar freuen, wenn es mit gleicher Begründung teurer wird.
Toric „erforscht“ ja nur ein Randproblem, wenn man vorhandene Steuersätze ändert und nicht alle Artikel einzeln zum 01.07.2020 auf einen anderen Steuersatz umstellen will. Man muss schon alles lesen
@NahtlosShop Es ist - wie gesagt - abhängig, wie das Unternehmen versteuert wird. Bei Istversteuerung ist es der Zeitpunkt des Geldeingangs und nicht das Datum auf der Rechnung. Bei Sollversteuerung das Leistungsdatum (das kann das Rechnungsdatum sein).
Natürlich freut es den Kunden, wenn er weniger zahlt. Aber es geht ja um das Abwicklungstechnische. Wie passt man die Belege später korrekt an. Die Beträge in der Auftragsbestätigung stimmen schon mal nicht. Entweder du überweist später ein paar Cent zurück oder schickst per Paypal eine Teilerstattung. Bei Stripe kannst du teilweise erstatten, bekommst aber die Gebühren nicht zurück. Paypal ist da noch die eleganteste Lösung. Wenn ich für eine Bankbuchung 45 Cent zahle, weil ich 25 Cent an den Kunden erstatten muss, ist es nicht mehr so toll. Beim nächsten Wechsel dann umgekehrt. Du forderst Centbeträge nach, deren Buchungskosten höher sind, als der Zahlbetrag.
Hätte da noch ein paar andere Bedenken auf Lager…
Gerade für die Übergangszeit im Juli jetzt ist der Aufwand riesig, wenn ich für alle Eventualitäten gerüstet sein muss, in der Zeit in der quasi kaum was los ist im Shop.
Werde wohl die kniffligen Zahlarten am 20.6. abschalten und mach ab 1.7. spontan Betriebsferien
Mehrfachänderung sehe ich als kritisch an. Soweit ich weiß gibt es nach wie vor noch einen Bug, der verhindert, dass die Mehrfachänderung rückgängig gemacht werden kann. Im Live-System immer schlecht, falls da was schief geht.
Nach einem langen Tag mit konstruktiven Forumsbeiträgen und Ideen zur Problemlösung, darf nun auch ein einzelner *Blubber-Beitrag* kommen:
mach ab 1.7. spontan Betriebsferien
01.07.2020 12:05 Uhr : Viva la vida - Abflug zur „schönsten Insel der Welt“ (wie man dort so trällert) - um so nerviger, dass die heisse Phase der Mwst-Umstellung für mich zwischen Kofferpacken und nach DUS fahren liegt.
Wir schreiben dafür schon ein Tutorial und stellen SQL Querries zur Verfügung. Das wird auch kurzfristig noch diese Woche oder Montag online gehen. Also da kommt natürlich was.
Das von Dir verlinkte wäre in etwa das, was ein Plugin letztlich auch machen würde. Greift natürlich nicht bei Preisgruppen oder abweichenden Ländereinstellungen in den Steuern. Aber im 0815-Shop sollte das so gehen.
Das zweite UPDATE würde ich dann aber gleich mit einem SET für die taxID erweitern. Den Faktor könnte ein Plugin automatisch aus den beiden Steuersätzen (also den gesetzten und den zu setzenden) errechnen. Erwarte aber nicht (auch nicht bei einer automatisierten Lösung), dass die Bruttopreise am Ende identisch sind. 4 Stellen und Rundung werden schon für leichte Abweichungen führen. Die zweite Rundung schlägt ja dann am 01.01.2021 zu Bei Schwellenwertpreisen wird wohl ggf. Nachbessern nötig sein.
ach verdammt, die preisgruppen/kundengruppen hatte ich völlig vergessen. *narf
ich teste das die tage durch. ich bin der hoffnung das SW selbst hier eine „simple“ Lösung zur Verfügung stellt
der eintrag im issuetracker ist ja immerhin schon „in verification“ - bei anderen tickets tut sich teilweise auch nach monaten nichts
@73k4 die Preise für “Kundengruppen” sollten jetzt nicht zum Problem werden, die stehen ja auch in der Tabelle und haben die taxID. Wie das jetzt mit Preisgruppen funktioniert: Das habe ich mir noch nie im Detail - also Datenbank - angeguckt.
“in verification” hat jedes neue Ticket zunächst…
Mist - mein “Beobachtungs-Modus” will einfach nicht funktionieren…
Preise werden ja ganz simpel nach Angebot & Nachfrage festgelegt (Was ist man bzw der Markt bereit zu zahlen?) Daran ändert eine Mehrwersteuersenkung erstmal nichts. Das wird den Markt nicht umwerfen und greift imho nur bei hochpreisigen Artikeln.
Erinnert sich jemand an die Mehrwertsteuersenkung für Tampons und Binden? Von der Senkung ist auf dem Endkundenmarkt so gut wie nichts angekommen.
Bei Schwellenwertpreisen wird wohl ggf. Nachbessern nötig sein.
