Naja. Solange man Bettdecken aus der Weltraumforschung verkaufen kann… 
Ich kann das nicht mehr beurteilen.
Mein Kauferhalten hat sich geändert.
Ich schaue nicht mehr auf den Cent. Ich will Qualität !
Aber man kann sich das ja vor Augen halten:
4,50 € oder 4,39 €
Wo kaufe ich jetzt ?
Um die alten Brutto-Preise beizubehalten, würde ich die Preise aller Artikel exportieren, dann die Steuersätze umstellen, danach dann die alten Bruttopreise wieder importieren, das sollte je nach Artikelanzahl nicht übermäßig lang dauern und müßte so funktionieren (ungetestet).
Also ich habe das genauso auf meinem Staging-System getestet. Das funktioniert einwandfrei und ist eine Sache von 5 Minuten. Es werden die Preise aller Kundengruppen berücksichtigt und die Preise sind nach der Aktion so wie vorher.
Im Shop möchte man die Brutto-Preise so behalten, da es auch Flyer oder ähnliches gibt und die Kunden aus meiner Sicht dadurch verunsichert sind. Aber das heißt nicht, dass der Shopbetreiber nicht bereit wäre einen Rabatt zu spielen. Das kann man ja unabhängig davon machen und ich finde das eine gute Idee, da der Shopbesucher den „Rabatt“ auch als „Rabatt“ wahrnimmt. (Auch wenn 3% ja rein rechnerisch zuviel Rabatt ist *g*)
@sonic Wie machst du das, wenn du in Urlaub gehst mit dem Shop? Setzt du ihn in den Wartungsmodus oder gibt es eine andere Möglichkeit, Bestellungen nicht zuzulassen bei der die Kunden sich trotzdem im Shop umschauen können?
Generell brauche ich eine einfache Lösung für die Mwst-Umstellung ohne Export von Datenbank usw. Abgesehen davon, dass ich mir nicht zutraue, das fehlerfrei umzusetzen, habe ich noch einen speziellen Aufpreis einprogrammieren lassen, was zusätzliche Probleme verursachen wird. Mir ist es egal, ob der Endpreis für die Kunden sinkt und krumm ist oder gleichbleibt. Ich nehme die am einfachsten umzusetzende Variante.
EDIT
Nachdem ich nochmal alles durchprobiert habe, sehe ich die zwei Möglichkeiten (ohne Plugin):
a) Vorhandene Steuersätze im BE um Mitternacht überschreiben. 2 Minuten Aufwand. Es ändert sich dann der VK-Preis im Shop. In der Bestelldetailansicht unter “Positionen” wird bei alten Bestellungen der falsche Steuersatz angezeigt (nur bei Rabatt und Versandkosten steht der tatsächliche Steuersatz der Bestellung), die Belege und Beträge sind aber weiterhin korrekt.
b) Zwei neue Steuersätze anlegen und in der Tabelle s_core_tax die IDs raussuchen. Dann in der s_articles (Spalte taxID) mit suchen/ersetzen die ID austauschen. Dann ist die Ansicht im BE auch immer richtig. Da hier der VK im Shop nicht geändert wird, kann man wenn gewünscht einen Rabatt im Warenkorb anbieten (2,53% oder 1,87% wenns exakt sein soll). Wer zwei Steuersätze im Shop hat, muss sich halt für einen Rabatt entscheiden.
An suchen/ersetzen bin ich bei meinem Test noch gescheitert. Da werden nicht alles Spalten zur Auswahl angezeigt ?! Muss aber doch irgendwie machbar sein.
Bei Bestellungen im Übergangszeitraum kann/muss man ggf. die Bestellungen manuell anpassen, machbar ist es auf jeden Fall. Erstattungen/Nachforderungen könnte man ggf. minimieren, indem man Variante b) nutzt und den Rabatt zweitversetzt aktiviert bzw. vor Jahresende deaktiviert.
@Toric mit einer Themeanpassung blende ich mir bei Bedarf einen Textbaustein auf allen Seiten ein. Darin weise ich auf den Urlaub hin. Dann werden Gastbestellungen und die Schnellbesteller-Zahlungsplugins wie PayPal Express deaktiviert. Zuletzt setze ich noch den Mindestbestellwert auf 1Mio Euro. Früher hatte ich mal ein kleines Plugin, welches mir die Checkout Actions umleitete, aber das wollte ich für 2x im Jahr nicht weiter pflegen. Irgendwo im Theme hatte ich auch mal eine Checkbox, mit der ich in der Buybox im theme den InDenWarenkorb-Button ausgeblendet habe.
@sonic oh je
Wartungsmodus ist auch keine gute Idee.
Schmeisst Dich bei Google & Co., gleich 5 Seiten nach hinten.
@ Toric
Shopware wird doch diesbezüglich ein Plugin erstellen.
Einfach mal ein paar Tage abwarten.
Ein erstes Tutorial zu dem Thema findet ihr absofort in der Dokumentation:
Ein erstes Tutorial zu dem Thema findet ihr absofort in der Dokumentation:
Vielen Dank. Im Prinzip sind hier Variante 1 und 2 das, was ich hier in meinem letzten ausführlichen Beitrag beschrieben habe mit a und b. Nur einen wesentlicher Unterschied habe ich im Ergebnis. Bei der Anlage und Zuordnung von neuen Steuersätzen (Variante 2) ändert sich der Preis im Shop nicht.
NACHTRAG:
So müsste ich die IDs bei den Steuersätzen doch auch austauschen können (suche 1, ersetze durch 6):
UPDATE s_articles SET taxID = REPLACE(taxID, „1“, „6“)
Ein erstes Tutorial zu dem Thema findet ihr absofort in der Dokumentation:
Danke soweit. Was mir in diesem Tutorial unklar bleibt, ist wie mitder Kundengruppe „Händler“ (H) umgegangen wird, für die der Nettopreis gleich bleiben soll, während für die Kundengruppe „Shopkunden“ (EK) der Bruttopreis gleich bleiben soll. Also mein Ziel ist, dass für alle Kunden der sichtbare Preis der gleiche bleibt, so wie sie ihn gewöhnt sind.
Ein erstes Tutorial zu dem Thema findet ihr absofort in der Dokumentation:
Vielen Dank. Im Prinzip sind hier Variante 1 und 2 das, was ich hier in meinem letzten ausführlichen Beitrag beschrieben habe mit a und b. Nur einen wesentlicher Unterschied habe ich im Ergebnis. Bei der Anlage und Zuordnung von neuen Steuersätzen (Variante 2) ändert sich der Preis im Shop nicht.
NACHTRAG:
So müsste ich die IDs bei den Steuersätzen doch auch austauschen können (suche 1, ersetze durch 6):
UPDATE s_articles SET taxID = REPLACE(taxID, „1“, „6“)
Hey,
wichtig ist, dass du den Cache leerst weil direkte Änderungen an der Datenbank keine Cache-Invalidierung auslösen.
@dewib, dein Feedback leite ich mal weiter. Der Artikel wird natürlich noch weiter ergänzt.
Ein erstes Tutorial zu dem Thema findet ihr absofort in der Dokumentation:
Danke soweit. Was mir in diesem Tutorial unklar bleibt, ist wie mitder Kundengruppe „Händler“ (H) umgegangen wird, für die der Nettopreis gleich bleiben soll, während für die Kundengruppe „Shopkunden“ (EK) der Bruttopreis gleich bleiben soll. Also mein Ziel ist, dass für alle Kunden der sichtbare Preis der gleiche bleibt, so wie sie ihn gewöhnt sind.
Der Beitrag wird noch erweitert. Es wird auch ein Plugin geben, für diejenigen die es eben nicht per SQL lösen wollen.
Steht auch in kürze im Beitrag :D
@AndreHerking
Der Cache ist übers Backend gelöscht (während der Test der letzten Tage sogar mehrfach), Theme kompiliert und nun hab ich auch noch den productionordner manuell gelöscht. Bei Variante 2 ändert sich der Bruttopreis definitiv nicht. Ich kann die Bestellung mit diesem Preis ausführen und die Mehrwertsteuer wird mit 16% ausgewiesen und korrekt berechnet.
Ich habe den Haken bei „Bruttopreise eingeben“ - falls das eine Rolle spielt.
@AndreHerking: Werden die Pseudopreise nicht auch Netto gespeichert und müssen im selben Query mit angepasst werden?
Also eher so: UPDATE s_articles_prices SET price = price/1.16*1.19, pseusdoprice = pseusdoprice/1.16*1.19
Eventuell auch der Baseprice?
@AndreHerking: Werden die Pseudopreise nicht auch Netto gespeichert und müssen im selben Query mit angepasst werden?
Also eher so: UPDATE s_articles_prices SET price = price/1.16*1.19, pseusdoprice = pseusdoprice/1.16*1.19
Eventuell auch der Baseprice?
Baseprice ist immer netto und wird auch nicht brutto ausgegeben. Bzgl. Pseudo-Preis gebe ich dir recht, aber wie Moritz sagt entwickeln wir hier gerade eine „saubere“ Lösung in Form eines Plugins.
@AndreHerking im verlinkten Tutorial wird die Version ab 5.5.0 genannt. Wie sieht es denn mit älteren Versionen aus wie bspw 5.4.5? Bzw. das Plugin wird doch hoffentlich auch für ältere Versionen kompatibel sein oder?
@AndreHerking im verlinkten Tutorial wird die Version ab 5.5.0 genannt. Wie sieht es denn mit älteren Versionen aus wie bspw 5.4.5? Bzw. das Plugin wird doch hoffentlich auch für ältere Versionen kompatibel sein oder?
Es wird vorr. ab 5.2.0 kompatibel sein.
Hallo,
hat schon jemand eine Lösung für das Problem mit Bestellungen aus Juni, die erst nach dem 01.Juli ausgeliefert werden? Selbst wenn man den Standard Steuersatz von 19% auf 16% senkt, werden bei den alten Bestellungen, wenn man die Rechnung erstellt, die 19% MwSt ausgegeben. Reines Chaos
Spätestens jetzt zeigt sich, warum es sinnvoll ist, eine Shopsoftware nicht mir einer Warenwirtschaft/Finanzbuchhaltung zu verwechseln.
Hallo,
hat schon jemand eine Lösung für das Problem mit Bestellungen aus Juni, die erst nach dem 01.Juli ausgeliefert werden? Selbst wenn man den Standard Steuersatz von 19% auf 16% senkt, werden bei den alten Bestellungen, wenn man die Rechnung erstellt, die 19% MwSt ausgegeben. Reines Chaos
Welcher MwSt.-Satz steht denn bei der Bestellung im Reiter Positionen beim Artikel nach der globalen Änderung von 19 auf 16?
@simplybecause je nach Zeitpunkt der falsche.
Wenn du z.B. am 1.7. Steuersatz mit ID1 jetzt 19% auf 16% änderst, werden die Bestellungen am 1.7. mit 16% ausgewiesen und berechnet - in den Belegen, egal, wann du die Belege generierst. Also auch in 2021 werden Bestellungen aus 2.HJ 2020 mit 16% ausgegeben, auch wenn du inzwischen wieder auf 19% überschrieben hast.
Allerdings wird im Reiter Position bei den Produkten immer das Label des derzeitigen Steuersatzes ID1 angezeigt. Ggf. halt ein anderes, als tatsächlich berechnet. Versandkosten und Rabatt zeigen allerdings des Steuersatz zum Zeitpunkt der Bestellung an.
@pram16359 in meinen Tests hatte ich alte Bestellungen mit geändertem Steuersatz überschrieben. Das ging. Ich bin mir nur gerade nicht mehr sicher, auf welche Weise.
Ich habe bei den 16% + 5% als weitere Steuersätze angelegt, weil ich noch unentschlossen bin, welche der Varianten die ich auf Seite 3 hier beschrieben habe, nutzen werde. Wahrscheinlich hatte ich da dann den jeweils anderen ausgewählt. Bei Versandkosten musst du den Steuersatz im anderen Reiter der Bestellung anpassen.