Crons werden nachgeholt. Aber in diesem Fall scheit Shopware vorgesorgt zu haben, dass man in der Vergangenheit nicht einplanen kann.
Dass keine Artikel mehr angezeigt werden, ist logisch: Das Tool schreibt in die MwSt Angabe der Artikel 19 statt 19%. Wähle ich in jedem Artikel händisch 19% aus, sind die Artikel danach wieder sichtbar…
Kriegen wir das bitte, bitte ganz schnell automatisiert gelöst. Ich habe bei einem Shop keinen phpmyadmin-Zugang und müsste jetzt 1000 Artikel von Hand anfassen…
SO sollte das neue Jahr irgendwie nicht anfangen… 
Ach ja: Frohes neues Jahr! 
Dass keine Artikel mehr angezeigt werden, ist logisch: Das Tool schreibt in die MwSt Angabe der Artikel 19 statt 19%. Wähle ich in jedem Artikel händisch 19% aus, sind die Artikel danach wieder sichtbar…
Kriegen wir das bitte, bitte ganz schnell automatisiert gelöst. Ich habe bei einem Shop keinen phpmyadmin-Zugang und müsste jetzt 1000 Artikel von Hand anfassen…
SO sollte das neue Jahr irgendwie nicht anfangen…
Ach ja: Frohes neues Jahr!
https://github.com/FriendsOfShopware/FroshAdminer/releases/tag/1.3.4
1 „Gefällt mir“
Weitere Möglichkeit den falschen Steuersatz per Mehrfachänderung für alle Artikel überschreiben:
Wir nutzen Shopware 5.6.9. Dort gibt es das Feld “TAX” nicht in der Mehrfachänderung. In unserem Shop wurde durch Ausführung des Plugins das Mehrwertsteuerfeld komplett geleert. Dadurch werden die Artikel im Frontend nicht mehr angezeigt. In der Artikelmaske selbst sind Preise und Pseudopreise noch vorhanden. Ich könnte also bei jedem Artikel die 19" manuell ändern, das macht bei Menge 4000-5000 aber keinen Spass. Das Plugin bietet leider nicht die Möglichkeit ein leeres Steuerfeld auszuwählen. Ich kann es also nicht mehr nutzen.
Moorleiche hat dir doch bereits den Link zum PHPMyAdmin Plugin gepostet
https://github.com/FriendsOfShopware/FroshAdminer/releases/tag/1.3.4
Dort kannst du mit einem SQL Query dein Problem lösen.
Frohes Neues!
Die zeitgesteuerte Umstellung klappte in allen Projekten einwandfrei.
Das kann nicht sein… warum sollte in der Datenbank ein % Zeichen geschrieben werden? Und das was bei dir im Backend angezeigt wird (vermutlich das was du meinst) ist nur ein Name… der spielt keine Rolle. Du kannst die Steuerklasse auch „2020 stinkt“ nennen 
relevant ist welcher Wert in der den Steuereinstellungen hinterlegt ist.
Hast du mal eine Steuerklasse mit dem Namen „19“ gelöscht? schau doch mal welche Steuer-ID bei deinen Artikeln verwendet wird und korrigiere das mit sql:
UPDATE
s_articlesSET s_articles.taxID= ‚defekteID‘ WHEREs_articles.taxID=‚neueID‘;
Viele Grüße
Mike
Dass keine Artikel mehr angezeigt werden, ist logisch: Das Tool schreibt in die MwSt Angabe der Artikel 19 statt 19%. Wähle ich in jedem Artikel händisch 19% aus, sind die Artikel danach wieder sichtbar…
Kriegen wir das bitte, bitte ganz schnell automatisiert gelöst. Ich habe bei einem Shop keinen phpmyadmin-Zugang und müsste jetzt 1000 Artikel von Hand anfassen…
SO sollte das neue Jahr irgendwie nicht anfangen…
Ach ja: Frohes neues Jahr!
1 „Gefällt mir“
Frohes Neues,
bei mir hat es nicht geklappt. Bei allen Produkten Fantasiepreise drin und alle Artikel deaktiviert.
Bei mir hat es in mehreren Shops problemlos funktioniert.
Theoretisch kann das Plugins nun entfernt werden, oder? Müssen die Steuersätze 5% bzw 16% witerhin bleiben oder können diese auch entfernt werden?
Update: Wie es ausschaut hat das die Lösung gebracht. Danke Mike!
UPDATE
s_articlesSET s_articles.taxID= ‚defekteID‘ WHEREs_articles.taxID=‚neueID‘;
kann mir das einer Idiotensicher erklären ? meine 19% steuersatz ist ID1 was schreib ich dann bei defekte ID rein ? neue ID ist ja dann ID1
Die ID der 16%
1 „Gefällt mir“
Bei uns sind noch alle MwSt Beträge mit den alten 16% und 5% berechnet. Das Plugin hat die MWSt Werte nicht automatisch umgestellt und ich habe keine Ahnung, was ich jetzt machten kann. Cron Jobs laufen.
Bei Original SW Plugins hätte ich etwas anderes erwartet. Jetzt weiss ich wenigstens, wie ich heute den Tag verbringe
Oder hat jemand eine Idee, woran es liegen kann?
OK, ich habe die MwSt jetzt manuell über das Plugin im Batch Modus zurückgestellt.
Never mind my rant …
Was wir für ein Problem hatten und wie wir es gelöst haben:
Cronjob Fehlermeldung des MwSt Plugins (XXX steht für Shopverzeichnis):
array (
‚error‘ => ‚Failed to remove directory „XXX/var/cache/production_202011060821/html/md“: rmdirXXX/var/cache/production_202011060821/html/md): Directory not empty‘,
)
In de DB hatten dadurch alle Artikel in taxID den Wert „19“ - was ich mir nicht erklären konnte, da die Umstellung im gespiegelten Testsystem über den Batchmodus ohne Probleme funktiniert hat.
Durch den unbekannten taxID Wert 19 sind aber alle Artikel im Frontend verschwunden…
Haben dann über die DB den tax ID Wert korrigiert
UPDATE s_articles SET taxID = „1“ WHERE taxID = „19“;
Und alle Artikelpreise (VK und Pseudopreis) neu importiert.
UPDATE s_articles SET s_articles.taxID = ‘defekteID’ WHERE s_articles.taxID=‘neueID’;
sicher das das funktioniert?
[**UPDATE**](http://search.mysql.com/search?site=refman-%35%31&q=UPDATE) s\_articles [**SET**](http://search.mysql.com/search?site=refman-%35%31&q=SET) taxID='1'
wenn 19% ID 1 hat. Und schon sind alle Artikel wieder sichtbar.
Übelste aufregung aber jetz läuft wieder alles … echte Katastrophe
So hab ich mir den Neujahrstag nicht vorgestellt!!!
Bei mir sind auch alle Artikel nicht mehr im Frontend sichtbar 
Also der SQL-Befehl hat zwar bewirkt, dass alle Artikel nun wieder sichtbar sind, aber freundlicherweise sind jetzt alle Preise quasi alter Bruttopreis PLUS 19% Märchensteuer.
Eigentlich müssten also jetzt alle Bruttopreise wieder durch 1,19 geteilt werden, damit die Preise wieder passen. Richtig? Hat dafür gerade mal wer einen SQL Befehl? Ich bin da leider nicht so der große Held…
Vielen Dank im Voraus! 