Hallo zusammen, ich wolle einmal nachfragen, ob mir jemand doppelte Artikelnummern in der Datenbank in der Tabelle s_article_deetails bestätigen kann? Soweit ich dads nachvollziehen kann passiert folgendes: - Variantenartikel angelegt (oder testweise einen vorhandenen duplizieren) - Shopware legt ja Variantenartikeln zuerst mit seiner eigenen Artiklenummer an: SW10178 z.b. - Sobald die Artikelnummer nun ein eine eigene geändert wird. Wird das auch in der DB so nachvollzogen. Allerdings bleibt die Artikelnummer SW10178 in der Datenbank in der Tabelle s_article_details stehen, obwohl es diese Artikelnummer eigentlich nicht mehr gibt. Ich habe das zu hunderten festgestellt, denn ich habe beinahe ausschließlich die “Artikel duplizieren Funktion” verwendet. Dafür gibt es sie ja auch. Nun wollte ich einmal hören, ob mir dieses Verhalten von euch bestätigt werden kann. Wie gesagt, es muss sich um Variantenartikel handeln die dupliziert wurden. Kann das bestätigt werden? Die nächste Frage wäre ja, ob ich diese Überbleibsel löschen kann, oder ob das zu Problemen führt. Oder umgekehrt. Kann ich diese Datenleichen problemlos stehen lassen? Interessant zu wissen wäre, ob das seitens Shopware überhaupt so vorgesehen ist. (Gespeichertes Variantenset z.B. was durchaus seine Berechtigung hat in der DB zu stehen) Kann das jemand bitte verifizieren?
Gibt es hier keinen der diesen Fehler auch hat? Wenn in der DB zu jedem Variantenartikel ein Eintrag stehen bleibt der da nicht hingehört, dann ist das eigentlich schon etwas schwerwiegendes und müllt ja auch die Datenbank zu. Ist es überhaupt ein Fehler? Oder bleibt die Shopwareartikelnummer wegen der Speicherung des Variantensets stehen? Es wäre gut wenn das jemand verifizieren könnte.
–Push-- Könnte vielleicht einer von euch in die DB schaun und das evtl. bestätigen? Support seitens Shopware zu erhalten ist hier echt nahezu unmöglich. Wenn man fragt, wo man ein Modul kaufen kann, dann liefert der werte Herr Schücker von Shopware auch promt eine Antwort. Sogar Sonntags. Sonst eher mau. Am Telefon erhält man auch keine Auskünfte. Wir haben für knapp 3tsd Euro Plugins gekauft, aber eine simple Auskunft erhält man nur wenn man noch einmal für einen Tausender eine Prof. Lizenz kaufen würde. Insgesamt sehr enttäuschend. Wegen einer Frage die evtl. ein Bug ist bzw. auch im Bugtracker steht, aber nicht beantwortet wird…Sehr schade…Man hilft anderen Usern, aber wenn man selber mal Hilfe braucht, dann ist es bisher schon extrem schwierig. Ich bin als User auf euch andere User angewiesen und wirklich sehr dankbar, sollte es jemand schaffen mal in die DB reinzuschaun, wie sich die Variantenartikel beim ändern der Artikelnummer verhalten. Doppel-threads können ja auch nicht die Lösung sein, scheint aber so als ob es keine andere Möglichkeit gibt. Immer wieder zu pushen kanns auch nicht sein! Danke und viele Grüße
Hallo Matt, ich mache es mal etwas ausführlicher, damit klar ist, wovon wir im Einzelnen reden. I. Artikel existiert noch nicht, Varianten sind noch nicht im Backend generiert worden wenn man einen Variantenartikel dupliziert, legt Shopware den Stammartikel ohne Konfigurator an und gibt ihm auch eine neue Varianten-Set ID in s_articles . Außerdem bekommt der neue Stammartikel eine article_ID mit der dieser Artikel in s_article_details eindeutig identifiziert wird. In s_article heißt sie noch ID in s_article_details dann article_ID. In s_article_details wird eine zweite Spalte geführt in der die ordernumber steht, die wäre die Artikelnummer in den Stammdaten im Backend. Ändert man im Backend die Artikelnummer von z.B. SW100 (=Ordernumber 100 in der Tabelle s_article_details) auf HT100, so wird die Spalte ordernumber in der Tabelle geändert, eine Kopie der Tabellenzeile mit der alten Ordernumber bleibt nicht bestehen. II. Der Artikel existiert und Varianten wurden generiert. Der Stammartikel hat die Artikelnummer (im Backend) = Ordernumber in article_details: HT100 Bei der Variantengenerierung wird für jede Variante eine neue Zeile in article_details mit eigener Ordernumber erzeugt. Dabei bleibt die Zeile mit der Ordernumber HT100 (= der Stammartikeleintrag im Backend) erhalten. Er hat aber denselben Inhalt wie die Variante HT100.1 Eigentlich hat die Artikelnummer im Stammdatenblatt im Backend jetzt keine Funktion mehr und sollte nicht mehr editierbar sein, ist sie aber. Gut, man kann wahrscheinlich einen Use-Case konstruieren bei dem dies nützlich ist. Ändert man das Stammdatenblatt so würde aus HT100 z. B. TT100, aber die Varianten blieben bei HT100.1 usw. . TT100 hätte dann denselben Inhalt wie HT100.1 Das alles für Shopware 4.1.3 Kleine Werbung in eigener Sache: Ich biete auch Beratungs-/Wartungsverträge für solche und andere Fragen und Probleme mit Shopware an. Viele Grüße H. Thomas (info@mycetome.de)
Hallo H. Thomas, vielen vielen Dank für deine Antwort. Der Support hier ist ne schwierige bis unmögliche Sache, wenn es nicht im triviale Dinge geht. Um so mehr freue ich mich, dass du das Thema aufgreifst und vor allem so ausführlich beschrieben hast. Es ist noch nicht ganz 100%ig klar. Also noch einmal zusammenfassend: 1. Ich lege einen Variantenartikel mit z.B. 3 Varianten an. Blick in die DB sollte so etwas zeigen: ID: articleID: Ordernumber: kind: additionaltext: 1116 210 SW10178 1 Gelb 1117 210 SW10178.1 2 Blau 1118 210 SW10178.2 2 Rot 2. Nun diesen artikel duplizieren (!) Blick in die DB zeigt: ID: articleID: Ordernumber: kind: additionaltext: 1119 211 SW10179 1 Gelb 1120 211 SW10179.1 2 Gelb 1121 211 SW10179.2 2 Blau 1122 211 SW10179.3 2 Rot 3. Die Artikelnummern im nächsten Schritt in meine eigenen ändern (DUP-TEST-GELB, DUP-TEST-BLAU, DUP-TEST-ROT o.ä.) Dann schauts in der s_article_details so aus: ID: articleID: Ordernumber: kind: additionaltext: 1119 211 SW10179 1 Gelb 1120 211 DUP-TEST-GELB 2 Gelb 1121 211 DUP-TEST-BLAU 2 Blau 1122 211 DUP-TEST-ROT 2 Rot D.H: Durch das duplizieren kommt die “DB Leiche” mit der shopwareinternen SKU "SW10179"zustande. Ist das nativ so gedacht? Können die shopwareinternen Artikelnummern gelöscht werden? ID: articleID: Ordernumber: kind: additionaltext: 1119 211 SW10179 1 Gelb Macht es was aus, wenn die zurückbleiben? Wenn ich deine Antwort richtig verstehe, dann kannst du bestätigen: 1. Das es eine “DB-Leiche” nachdem duplizieren gibt bzw. dass es ein Überbleibsel ist welches bei dir nachdem duplizieren auch so auftritt? Also könnte ich problemlos die “Überbleibsel” des duplizierens in der DB stehen lassen? Da es so von Shopware gewollt ist? Beste Grüße und vielen Dank für deine Mithilfe, ich war schon am verzweifeln, wie man auch dem --Push-- Beitrag entnehmen kann 
Hallo Matt! Normalerweise dupliziert Shopware nicht den Variantenkonfigurator, sondern nur den Stammartikel. In Schritt 2 sollte es nach dem Duplizieren und vor dem Variantengenerieren in s_article_details nur diesen Eintrag geben: 1119 211 SW10179 1 Gelb Im Backend sollte man eigentlich jetzt auf dem Stammdatenblatt die Artikelnummer ändern. Dann werden während der Variantengenerierung alle Variantenartikelnummern basierend auf der geänderten Artikelnummer aufgebaut. In dem Beispiel: jetzt 10179 in DUP-TEST- im Backen ändern. Alle Varianten würden dann durchnummeriert. Mann kann den einzelnen Varianten noch eigene Artikelnummern geben, aber das System ist eigentlich, diese durchzunummerieren. SW10179 oder hier DUP-Tets- bleibt immer erhalten! Das hat nichts mit dem Duplizieren zu tun, sondern ist das Shopware-Prinzip bei der Variantengenerierung. Man hätte dann so etwas in s_article_details: 1119 211 DUP-TEST- 1120 211 DUP-TEST-1 1121 211 DUP-TEST-2 1122 211 DUP-TEST-3 1119 211 SW10179 1 Gelb oder im Beispiel DUP-TEST- bleibt als Stammartikel-Eintrag immer erhalten. Das ist keine Leiche und darf auch nicht gelöscht werden! Die Namens-Verwirrung tritt eigentlich durch die manuelle Umbenennung der einzelnen Varianten-Artikelnummern auf. Viele Grüße H. Thomas
Hallo nochmal, danke für deine rasche Antwort. Da bin ich fast ein wenig überfordert und so garnicht gewohnt aus dem Forum Gut, also der Tenor ist, dass es sich um einen Stammartikeleintrag handelt und nicht gelöscht werden darf. Ich habe das allerdings testweise für mehrere hundert getan (Backup natürlich vorhanden) und keine Probleme festgestellt. Daher auch meine Frage, wenns Probleme gegeben hätte, dann wäre die Sache klar gewesen. So allerdings sah ich mich förmlich genötigt da mal nach zu haken. Da das von Shopware selbst leider nicht zu erwarten ist, bin ich dir für unsere Konversation wirklich dankbar (ich wiederhole mich). Komisch finde ich tatsächlich das es keine Probleme nach dem Löschen gab und alles wie gewohnt funktioniert hat (Checkout etc…) Gibt es hier von Shopware evtl. vielleicht eine offizielle Aussage dazu? Dokumentiert ist es ja via wiki nicht, soweit ich weiss. Ich werden alles noch einmal durchtesten und würde morgen gerne noch einmal schreiben Soweit einmal vielen Dank für deine Einschätzung und die Informationen. Beste Grüße Matt
Bsp: 1119 211 SW10179 1 Gelb 1120 211 DUP-TEST-GELB 2 Gelb 1121 211 DUP-TEST-BLAU 2 Blau 1122 211 DUP-TEST-ROT 2 Rot Wenn das hier der ein Datensatz für einen Variantenartikel in s_article_details ist und die Zeile mit der ID 1119 (1. Zeile oben) mit der Stammartikelnummer gelöscht wird, dann wird der Artikel im Backend nicht mehr aufgeführt. In der Datenbanktabelle sind die Stammdaten und die Varianten noch erhalten. Allerdings weiß ich nicht, ob die nicht irgendwann von Shopware aufgeräumt wird, um solche Leichen zu löschen.
Hallole Also ich habe das Problem mit der Leiche ebenfalls festgestellt. Wenn ich einen Artikel dupliziere, danach die Varianten neu generiere, bleibt in der s_articles_details der erste Varianteneintrag doppelt erhalten. Also der Startartikel hatte die Nummer 552266, ich habe ihn dupliziert, dieser bekommt dann manuell eingetragen die Artikelnummer 123456. Im Backend sehe ich nach dem anlegen der Varianten die Artikelnummern 123456.1 bis 123456.14. In der articles_details gibt es allerdings ebenso die Variante mit nur der Nummer 123456, was eine exakte Kopie der ersten Variante ist (der ja 123456.1 heisst), allerdings nur mit dem alten Preis aus dem Artikel 552266. Dies hat bei mir dazu gefuehrt, das ich im Frontend einen komplett falschen Preis angezeigt bekommen habe (wohl weil das der niedrigste Preis von den Variationen war), dieser so im Backend garnicht zu sehen war. Lösung: Artikel gelöscht und ueber einen CSV Import angelegt. Ich weiss jetzt nicht ob das verhalten in meinem Shop dem euren glich, aber bin schonmal froh das ich nicht alleine mit diesem Problem bin
Hallo, soweit ich mich erinnere konnten wir das Thema in einem anderen Post bereits lösen. Zumindest hat es dort daran gelegen, dass nach dem Duplizieren die Varianten nicht korrekt erzeugt wurden. Es gibt ja die Option “Zusammenführen” und “überschreiben” Das Überschreiben muss genutzt werden, wenn es keine eigene Varianten gibt - also auf beim Duplizieren. Wenn man beim neuen Artikel auf zusammenführen klickt, so kann das genannte Problem mit dem Zusatzeintrag auftreten. Das sich das so nicht automatisch abfangen lässt wollen wir hier zukünftig eine größeren Hinweis einbauen. Evtl. wurde bei dir beim Duplizieren auch nur auf Zusammenführen geklickt? Schöne Festtage Sebastian
Ja in meinem Fall kann das durchaus passiert sein. Gut zu wissen, danke!