Hallo, nach der Migration von SW5 sind alle Felder der Variantenartikel ohne Vererbung. Gibt es eine Möglichkeit, per SQL oder anders massenhaft die Vererbung für die Felder zu setzen? Ich gehe gerade alle Produkte von Hand durch und finde das wenig prickelnd. Erschwerend kommt hinzu, dass ich mehrfach speichern und kontrollieren muss, da jedes Mal beim Speichern nur ein Teil der Vererbungen geschrieben wird.
Danke
2 „Gefällt mir“
Wir stehen genau vor dem gleichen Problem. Bei einer nicht unerheblichen Anzahl an Artiklen mit jeweils mehreren hundert Varianten führt dies bei uns gegenwärtig zu einem enormen Mehraufwand. Teilweise sind wir schon dazu übergegangen ganze Artikel neu anzulegen, da alle für uns wichtigen Vererbungen dann richtig gesetzt werden. Dennoch kommen wir nicht um ein weiteres manuelles editieren herum, da wir händisch die Produktnummern zwischen dem angelegten Artikelduplikat und Original übertragen müssen. Das Plugin " Produkt Massen Aktionen" kann zwar in Teilen massenhaft Varianten bearbeiten, der Funktionsumfang reicht aber nicht aus, um die benötigten Vererbungen als Massenaktion zu setzen. Es wäre schön wenn Shopware in seiner Entwicklung diesen Punkt mit aufgreift, z.B. in Form von „Vererbungs-Templates“, oder zumindest über die Möglichkeit, in der Variantenansicht Vererbungen nicht nur pro Zeile sondern auch pro Spalte setzen zu können (d.h. ein Klick auf die Spalte „Aktiv“ und alle Vererbungen sind für das Feld Aktiv für alle Varianten gesetzt) → Kleines Feature, große Erleichterung! Auch dass man im Backend jede Änderung in der Variantenansicht einzeln abspeichern muss, wie im obigen Post beschrieben, kostet viel Zeit. Ich kann auf diesen Post also leider nur mit Anregungen an die Entwickler antworten und begrüße es sehr, wenn diese Problematik in zukünftigen Updates aufgegriffen wird.
2 „Gefällt mir“
gibt es hier bereits einen Lösungsansatz?
… Von unserer Seite bisher nicht. Wir müssen weiterhin händisch Vererbungen neu setzen oder legen den Artikel komplett neu an, wenn aufgrund der Anzahl an Varianten der Aufwand zu groß wäre. Bei unserer Suche nach Lösungsansätzen sind wir noch auf ein weiteres Plugin gestoßen, das evtl. hilfreich sein kann. Das Plugin " Mehrfachbearbeitung für Shopware 6" der Firma Nimbits bietet die Möglichkeit, massenhaft Felder über frei definierbare „Wenn-Bedingungen“ neu zu setzen. Auch Varianten sollen von diesem Plugin erfasst werden können. Getestet haben wir dieses Plugin bisher nicht und können daher auch nicht sagen, ob alle relevanten Vererbungen hiermit gesetzt werden können. Falls hier jemand bereits Erfahungen gemacht hat, bitte posten 
Was uns ebenfalls aufgefallen ist, sind automatisch gesetzte Preisregeln unter Erweiterte Preise. Ggf. ist dies ein ähnliches Problem, da wir mit Erweiterten Preisen gar nicht arbeiten. Wenn nun doch automatisch eine Preisregel gesetzt wird, kann dies zu dem Problem führen, dass diese neu gesetzte Preise im Eltern/Kinderartikel überschreibt. Wir hatten uns bereits gewundert, warum unsere Preisaktualisierungen gar nicht im Frontend sichtbar wurden, bis wir auf diese Problematik gestoßen sind. D.h. neben den fehlenden Vererbungen müssen wir zusätzlich die automatisch generierten Preisregeln händisch löschen.
Für das Problem mit den Erweiterten Preisen habe ich eine drastische Lösung parat. Hat bei mir mehrfach funktioniert, ohne Seiteneffekte
Achtung: Der SQL Befehl löscht ALLE Erweiterten Preise
ICH ÜBERNEHME KEINE VERANTWORTUNG
Erweiterte Preise löschen
TRUNCATE TABLE 'product_price'
Ein Truncate auf product_price wird das Problem nicht lösen. Grundsätzlich ist es selbstverständlich möglich, via SQL die Vererbungen zu setzen bzw. zu entfernen, wobei das entfernen der Vererbung etwas komplexer ist als das Entfernen derselben. Eien hilfreiche info wäre, um welche Felder es sich genau handelt.
@moschadr bitte lesen was ich geschrieben habe: „Für das Problem mit den Erweiterten Preisen“. Deine Antwort behindert die Problemlösung, die die Lösung sehr wohl zufriedenstellend funktioniert.
@Shrek Wie in den meisten Lebenslagen macht auch hier „der Ton die Musik“. Und Deinen halte ich, bei aller Höflichkeit, für nicht angemessen. Insbesondere da sich meine Antwort nicht ausschließlich auf Dein letztes Posting bezog, sondern den Opener und die Antworten der anderen User mit einbezog. Um das ganze aber fachlich abzuschließen … bitte wirf doch mal einen Blick auf die Spalten cheapest_price und cheapest_price_accessor in der Tabelle product. Diese werden mit einem Truncate auf product_price nicht verändert. Du entziehst dem Verweis aus der product nur die Referenz in der product_price. Nicht mehr und nicht weniger. Außerdem entfernt ein Truncate auch die Preisregeln für die Hauptprodukte und nicht nur für die Varianten. Beste (und freundliche) Grüße
Genau, der Ton macht die Musik. Das fachliche: Bei mir funktioniert es, das mit den Zombieeinträgen ist unschön, sehe ich aber nicht problematisch. Ich habe extra geschrieben, dass ALLE erweiterten Preise gelöscht werden, also selbstverständlich auch für die Produkte. Viel ärgerlicher ist, dass das aus der Migration so „ungefragt“ gekommen ist.
@Shrek: Danke für den Hinweis zur Löschung des ‚product_price‘ Eintrags!
Und sorry wenn mein zusätzlicher Hinweis auf die Erweiterten Preise diesen Thread etwas ins Offtopic geleitet haben 
Die Problematik um die Erweiterten Preise scheint aber parallel zu den fehlenden Vererberungen nach der Datenmigration aufzutreten und verursacht ähnliche Probleme. Gerade wenn Mitarbeiter ohne größere Kenntnis des Backends schnell Produktanpassungen machen wollen und diese entweder wegen einer fehlenden Vererbung oder einer ungewollten Preisregel überdeckt werden, ist das ärgerlich. Daher auch meine Intention, auf die Erweiterten Preise zu verweisen. Die Lösung von Shrek hat uns weitergeholfen, da wir ansonsten die Preisregeln, die für sämtliche Hauptprodukte im Zuge der Datenmigration automatisch gesetzt wurden, hätten entfernen müssen. Das hat uns viel Zeit und eine Fehlerquelle erspart, vielen Dank 
@moschadr: Ich fasse einmal die Varianten-Felder aus dem Backend zusammen, in denen Vererbungen gesetzt werden müssen: Artikel Preis, Aktiv-Status, Titel, Hersteller, Beschreibung, Steuersatz, Lieferzeit, Wiederauffüllzeit in Tagen, Mindestabnahme, Staffelung, Maximalabnahme, Sichtbarkeit, Kategorie, Such-Schlagwörter, Medien, sämtliche Spezifikationen, Zusatzfelder und SEO Einträge.
Kritisch für uns sind insbesondere Titel, Beschreibung, Aktiv-Status und die SEO Einträge „Meta-Titel“ und Meta-Beschreibung". Diese Felder lassen sich nicht mit unserem Massen-Aktionen-Plugin bearbeiten und wir müssen daher nach Produktanpassungen immer noch händisch die Vererbungen (wenn icht vorhanden) setzen. Bei 200 bis 300 Varianten sitzt man dann gut und gerne eine Stunde dran und es schleichen sich so auch leichter Fehler ein. Eine automatisierte Lösung wäre daher wirklich eine große Zeitersparnis 
1 „Gefällt mir“
Bitte beachte, dass sich mit der Zeit durch das alleinige leeren der Tabelle product_price „Datenleichen“ im System bilden, die u.U. irgendwann signifikate Auswirkungen auf die Performance haben können. Hinsichtlich Aktiv-Status ist der Aufwand recht klein. Jenachdem was ihr wann machen wollt reicht es in der Tabelle product die Spalte active für die betreffenden Varianten auf NULL zu setzen. Varianten erkennt man, wenn alles richtig eingespielt ist daran, dass die Spalte parent_id mit der ID des Hauptproduktes gefüllt ist. Bei Titel, Beschreibung und SEO-… wird es es etwas aufwändiger, da die Einträge hierfür in der product_translation stehen und Du erst die Varianten in der produkt ermitteln musst, um dann mit der ID in die product_translation zu gehen. Ich würde hierfür kurzerhand eine View verwenden, die ich als Refernz für das Update nehme. Entscheidend für alle Aktionen ist aber Eure Datenbasis. Weil ja irgendwann irgendjemand entscheiden muss, welches Produkt/ welche Variante geändert wird. Möglicherweise könnte man, sofern Ihr die Daten als CSV habt, diese in eine temporäre Tabelle einspielen und die dann als Referenz verwenden. Mit dem Setzen ordentlicher Indexe wäre das Anpassen von 300 Varianten in einem Bruchteil vn Sekunden Geschichte.
Zugang zu den Produkten selber bekommst Du am einfachsten über die Spalte product_number in der Tabelle product. Das Feld ist ein VARCHAR und Unique. Von dort kann man sich mitteld der ID’s durch die Folgetabellen „hangeln“
Gibt es auch die Möglichkeit per SQL die Vererbung der Kategorien in den Varianten zu aktivieren ?