Nachtrag: Ich hatte nun einige Artikel aus unserem produktiven Shop (3.5.6) importiert. Natürlich werden dann die ordernumbers schön übernommen: Hauptartikel bzw. erste Variante: XY102030.1000 Weitere Varianten: XY102030.1001 XY102030.1002 XY102030.1003 usw. Wenn ich nun aber z. B. eine neue Farbe hinzunehme oder sonst mehr Varianten anlege bekommen diese die folgenden ordernumbers: XY102030.1000.1 XY102030.1000.2 XY102030.1000.3 usw. Ist ja klar, weil sich SW4 die ordernumber der ersten Variante greift und diese als Grundlage nimmt, dann wieder einen neuen Punkt dran hängt und wieder hoch nummeriert. Das würde aber bedeuten, dass man alle ordernumbers der importierten Artikel aus 3.5er Shops korrigieren müsste. Spätestens wenn neue Varianten dazu kommen. Einfach weil der Hauptartikel als solcher von SW3.5.x auf SW4.x.y abgeschafft wurde. Denn die ordernumber der ersten Variante kann scheinbar schlechthin nicht dieselbe Länge & Struktur haben wie die ordernumbers aller anderen Varianten, richtig? Nun ist das ja keine kleine Veränderung und ich nehme an, dass das swag-Team bei so gravierenden Anpassungen mögliche Kollateralschäden wie diesen antizipiert hat. Und da habt Ihr Euch doch sicher dann auch eine Lösung zu überlegt, hoffe ich …? Denn ich bin da im Moment wirklich ziemlich ratlos. :wtf: Bei uns wäre das sonst ziemlich fatal, weil z. B. dann die Bestände in der WaWi ja überhaupt nicht mehr stimmen usw. … das zieht sich ja durch. LG, AS
Hallo, der Effekt, dass komplett neue Nummern generiert werden, kann ja nur auftreten, wenn du alles wirklich neu erstellst! Wenn du nur eine Option hinzufügst und die Varianten „zusammengeführt“ werden können, werden nur neue Varianten hinzugefügt und alle anderen Varianten und Artikelnummern bleiben vollständig bestehen. Wenn du eine Gruppe hinzufügst muss natürlich alles neu erstellt werden, da sich die gesamte Konstellation/Matrix ändert. Mit den Artikelnummern ist der Aufbau noch wie in 3.5.6 Also die Artikelnummern können ja gar nicht immer gleich lang sein. Beispiel: SW1000.1000 SW1000.10010 Sobald die Nummer zweistellig wird wurde diese auch in der 3.5er länger. Das ist also auch Jet noch der Fall. Siehe - Genau das Schema kann jetzt auch so genutzt werden. 
Hallo Sebastian Danke Dir, dass Du das so spät am Abend noch angeschaut hast. [quote]Mit den Artikelnummern ist der Aufbau noch wie in 3.5.6[/quote] Das ist aber so definitiv nicht richtig. Es gibt beim Aufbau der Artikelnummern zwischen der 3.5.6 mit altem Artikelkonfigurator und der 4.0.3 mit neuem Artikelkonfigurator (gravierende) Unterschiede. Zur Struktur der Artikelnummern: In der 3.5.6 gibt es einen Sichtreiter “Stammdaten”. Dort gibt es ein Feld “Artikelnummer”. Die Artikelnummer die man hier einträgt dient [color=red]lediglich[/color] als Basis für die Erstellung der Artikelnummern bei den Varianten. Ein bestellbarer Artikel mit dieser Artikelnummer existiert nicht. Es handelt sich also hier um echte “Stammdaten”. In der 4.0.3 gibt es einen Sichtreiter “Stammdaten”. Dort gibt es ein Feld “Artikelnummer”. Die Artikelnummer die man hier einträgt dient [color=red]einmal[/color] als Basis für die Erstellung der Artikelnummern bei den Varianten. Sie ist aber [color=red]zugleich[/color] die Artikelnummer der ersten Variante und damit eines bestellbaren Artikels. Es handelt sich also hier eigentlich nicht um “Stammdaten”. Das hört sich spitzfindig an. Aber es hat eben deutliche Auswirkungen. Denn wenn ich bei der Anlage der Varianten auf dieselbe Weise vorgehe, so bekomme ich in der 4.0.3 ein völlig anderes Resultat als in der 3.5.6: Wir legen in der 3.5.6 einen Artikel an. In das Feld “Artikelnummer” unter “Stammdaten” tragen wir ein: SW1000 Wir legen nun Varianten an. Es werden folgende Artikelnummern vergeben: Variante 1: SW1000.1 Variante 2: SW1000.2 Variante 3: SW1000.3 usw. Wir legen in der 4.0.3 einen Artikel an. In das Feld “Artikelnummer” unter “Stammdaten” tragen wir ein: SW1000 Wir legen nun Varianten an. Es werden folgende Artikelnummern vergeben: Variante 1: SW1000 Variante 2: SW1000.1 Variante 3: SW1000.2 usw. Während also in der 3.5.6 die Artikelnummern aller Varianten grundsätzlich dieselbe Struktur aufweisen ist dies in der 4.0.3 nicht der Fall. Dies lässt sich vorübergehend korrigieren, indem man nach Anlage der Varianten in der 4.0.3 die Artikelnummer der ersten Variante entsprechend anpasst: SW1000.0 Nun weisen auch hier die Artikelnummern aller Varianten grundsätzlich dieselbe Struktur auf. Aber nur bis man irgendetwas an der Zusammensetzung der Varianten ändert. Nimmt man nämlich z. B. eine neue Farbe hinzu, so müssen natürlich für die neu entstehenden Varianten auch wieder Artikelnummern generiert werden. Und die sehen dann so aus: Variante 1: SW1000.0 Variante 2: SW1000.0.1 Variante 3: SW1000.0.2 usw. Denn mit der Änderung der Artikelnummer einer (nämlich der ersten) Variante hat man zugleich die Stammdaten verändert und damit die Basis für neu zu generierende Artikelnummern. Und spätestens an diesem Punkt, wenn die Editierung von Daten bei einer Variante zugleich auch die Stammdaten verändert, wird man doch ziemlich nachdenklich … Zur Länge der Artikelnummern: Natürlich wird das Suffix (und damit die Artikelnummer insgesamt) mit jedem Dezimalsprung um eine Stelle länger. Aber das lässt sich eben in der 3.5.6 ganz leicht vermeiden. Man fängt einfach bei SW1000.1000 an und hat für die nächsten 8999 Varianten immer dieselbe Länge der Artikelnummern. Zudem lässt sich damit sehr elegant eine korrekte Sortierung nach Artikelnummern im backend erreichen. Denn wenn erst einmal eine Variante mit der Artikelnummer SW1000.1000 existiert, so vergibt die 3.5.6 als nächstes automatisch die SW1000.1001 usw. In der 4.0.3 ist das leider nicht der Fall. Ich hoffe, dass ich das Problem jetzt vielleicht besser herausarbeiten konnte. Für jeden Hinweis, wie man das lösen könnte bin ich sehr dankbar. Wenn man es so wie es war nicht mehr hin bekommt, dann hilft mir der Hinweis darauf auch schon weiter. Nur muss ich dann eben ziemlich vieles ziemlich neu denken … LG, AS
Ich habe damit weiter getestet und mir ist ein neues Problem aufgefallen. Wenn man die erste Variante löscht, weil z. B. die Farbe oder Grösse nicht mehr existiert, so ersetzt SW4 die Artikelnummer in den Stammdaten natürlich durch die Artikelnummer der nächsten ersten Variante.Somit hat dann die Artikelnummer in den Stammdaten, die als Basis für die Anlage neuer Artikelnummern dient, bereits ein Suffix aus „.“ und einer Nummer. Legt man nun neue Varianten an, so haben diese dann natürlich plötzlich zwei Punkte und zwei Nummern als Suffix, logisch. Lösungsvorschlag Das ganze wäre eigentlich ziemlich einfach zu lösen. Einfach für das swag-Team, nicht für mich … 
SW4 müsste bei der Neugenerierung von Artikelnummern wie folgt vorgehen: 1.) Suche die zuletzt angelegte Variante zu diesem Artikel anhand s_articles_details.id und s_articles_details.articleID. 2.) Nimm aus diesem Datensatz den Wert in s_articles_details.ordernumber. Suche darin von rechts kommend nach dem ersten Punkt (".") den Du finden kannst. 3.) Alles links vom Punkt = $basis 4.) Die Zahl rechts vom Punkt + 1 = $neues_suffix 5.) $neue_ordernumber = $basis.".".$neues_suffix Damit wäre das Verhalten aus 3.5.6 original wieder hergestellt. Ich mache dazu jetzt mal ein Ticket. Würde mich sehr über eine Rückmeldung freuen. LG, AS EDIT: Ticket ist SW-4279
Moin! Nachdem das oben bezeichnete Ticket auf „4.0.5“ gesetzt wurde (Danke dafür!) dachte ich: OK, bis dahin können wir damit leben. Dann legen wir eben erst einmal keine neuen Artikel und Varianten an. Wir müssen ja ohnehin erst einmal die bestehenden Artikel aus der 3.5.6 exportieren und in die 4.0.4 (RC) importieren. Ich exportiere also erst einmal alle Artikel aus der 3.5.6, schneide den größten Teil ab und importiere mal 21 Artikel samt Varianten (wir haben in der 3.5.6 ausschließlich Konfigurator-Artikel) in die 4.0.4 (RC). Das läuft auch glatt durch und sieht ganz prima aus. Dann exportiere ich alle Bilder aus der 3.5.6, schneide mir den relevanten Teil für die 21 Artikel raus und importiere das in die 4.0.4 (RC). Ergebnis: Nur 10% der Bilder werden importiert. Ich lese fleißig in Forum & Wiki, eliminiere alle möglichen potentiellen Fehlerquellen und teste und teste und teste alles Mögliche… Dann schaue ich mir die CSV-Datei mit dem Bild-Export noch einmal an und denke plötzlich: Komisch. In der Spalte „ordernumber“ stehen ja unsere alten Artikelnummern aus den damals noch „echten“ Stammdaten. Die gibt es doch in der SW4 gar nicht mehr. Wie konnten da überhaupt irgendwelche Bilder (besagte 10%) zugeordnet werden? Eigentlich hätte das doch so insgesamt gar nicht funktionieren dürfen. Also schaue ich mir die importierten Artikel noch einmal genauer an und stelle fest, dass sich SW4 beim Import von Artikeln mit Konfigurator-Varianten offensichtlich nicht konsistent verhält was die Vergabe der Artikelnummern angeht. Man würde ja erwarten, dass die alte Artikelnummer aus den Stammdaten der 3.5.6 einfach verworfen wird und bei dem importierten Artikel stattdessen unter „Stammdaten“ die Artikelnummer der ersten Variante erscheint. In 90% der Fälle ist dies auch der Fall – und das sind genau die 90% bei denen dann auch der Bildimport konsequenterweise nicht funktionierte. Einfach, weil zu dem Wert in der Spalte „ordernumber“ kein Artikel gefunden werden konnte. Wirklich seltsam ist aber, dass in einigen Fällen beim importierten Artikel unter Stammdaten im Feld Artikelnummer unsere alte Stammdaten-Artikelnummer steht. Diese taucht aber dann bei den Varianten gar nicht auf!? Das sind dann natürlich genau die Artikel, bei denen (wohl fälschlicherweise) der Bildimport funktionierte. Leider zieht sich das Problem mit den Artikelnummern also doch in ganz andere Bereiche weiter und ist nicht nur optischer Natur. Wir wären daher wirklich sehr dankbar, wenn vielleicht doch eine (noch) raschere Lösung möglich wäre. Denn im Moment sind wir natürlich (unverhofft kommt oft) doch wieder völlig blockiert … Die exports aus der 3.5.6 bzw. Zugang zum backend Stelle ich Euch natürlich gerne zur Verfügung. LG, AS Ticket ist angelegt: http://jira2.shopware.de/Widgets/Jira/?ticket=SW-4283