Liebe Shopbetreiber, es gibt nochmal ein Thema, bei dem wir nicht wollen, dass jemand unnötig unvorbereitet auf die Klappe fällt und über das wir deshalb nochmal eigens reden wollen: Mit dem Sprung auf GX4.5 tut sich einiges bei Variantenartikeln. Dieser Prozess macht viele neue Sachen möglich, aber einige ehemals vorhandene entfallen im Kleinen auch. Für Nutzer, der bisher in Shops bis GX4.4 vorhandenen Artikel-Attribute, kann das etwas ausmachen. Es entfallen die in den Attributen bisher vorhandenen Felder für EAN und Grundpreisangaben. Nicht in Stammartikeln, nicht in Eigenschaften oder neu Varianten, aber in Attributen oder neu Zusatzoptionen Wenn man diese Felder nicht nutzt sollte es kein Problem geben, alle die diese Felder bislang nutzen sollten hier einmal weiterlesen. Kommen wir zunächst einmal zum großen warum wir die Felder entfernen... Denken wir uns 2 Beispielartikel, dann kann man sehen was geht und was nicht geht. Nehmen wir eine Murmelbahn, und die konnte man bislang mit 1m oder 3m Schienen kaufen. Die Schienenlänge wurde als Attribut angelegt und dem Artikel zugewiesen, je nach Schienenlänge hat der Artikel eine unterschiedliche EAN. Das ließ sich so einfach machen und wäre auch jetzt eigentlich unproblematisch... Nehmen wir aber einen weiteren Beispielartikel, jetzt ein T-Shirt. Das gibt es in 3 Größen (S, M, L) und 3 Farben (rot, grün, blau). Wenn man einem Artikel nun in der Vergangenheit die Attribute Farbe und Größe mit ihren jeweiligen Werten zuwies, konnte man für rot, grün und blau je eine EAN hinterlegen, außerdem je eine EAN für jede Größe. Das Problem ist dann, dass Attribute in keiner Verbindung zueinander stehen, und das macht den Artikel logisch kaputt. Nehmen wir an ein kleines rotes Shirt hat eine eigene EAN, ein großes, grünes hat dazu eine weitere EAN, das konnte man dann nicht ausdrücken bzw. korrekt anlegen. Wenn zum Beispiel bei den Farben je eine EAN hinterlegt wurde, hatte die Auswahl der Größe keinen Einfluss darauf welche der Shop ausgeben sollte, denn ein EAN Feld griff immer nur für eine der beiden Auswahlen. Bei der Größe konnte man das auch nicht machen, dann hätte die Farbe keinen Einfluss gehabt, die Umkehrung geht auch nicht. Die beiden Auswahlen kamen nie zusammen. Und kein Stück besser: Wenn für die Farbe Rot die EAN 12345 hinterlegt worden wäre und für die Größe L die EAN ABCDE, und ein Kunde wählt die Attribute genau so aus, welche EAN wäre dann die richtige, die zu verwenden wäre? Man kann das drehen und wenden wie man will, sobald ein Artikel mehrere Attribute hatte, führte das zu keiner sinnvollen logischen Möglichkeit. Nur bei der Verwendung eines einzigen Attributs pro Artikel und nur genau dort Eingaben der Werte machte das Ganze überhaupt einen Sinn. Es wurde aber niemand davor geschützt das fehlzubedienen, das gabs öfter und sehr viele Leute haben das Prinzip auch nie verstanden. Wir haben darum entschieden, mit GX4.5 aus dem Attribute-Nachfolger Optionen das EAN Feld zu entfernen, dass ist in GX4.5 und höher nicht mehr vorhanden. EAN können weiterhin über den Artikeleigenschaften und dessen Nachfahren Varianten angelegt und verwaltet werden, aber dazu muss man dann eben auch Eigenschaften/Varianten benutzen. Es gibt keine automatische Migration von fraglichen Artikeln ins neue Format, das wäre logisch hochschwierig ohne Kleinholz zu erzeugen. Das bedeutet die Artikel müssen im Zweifel selbst durchgepflegt werden. Unserer Kenntnis nach sind das nicht viele betroffene Händler, aber das müssen diese Leute definitiv wissen. Genau dasselbe Thema ergibt sich bei über Artikelattribute-gepflegten Grundpreisen, also zum Beispiel für alle Leute mit Lebensmitteln und dort mit Mengenauswahlen in den Artikeln über Attribute. Auch dort passiert großer Quatsch, wenn man in mehreren Attributen Grundpreisfaktoren eingibt, auch hier sind wir der Meinung, dass es keinen rechten Sinn macht die Felder in die Zukunft zu retten. Allerdings machen wir hier einen Unterschied: Die Grundpreis Felder in den neuen Attributen, den Optionen, erhalten eine Gnadenfrist. Wir wollen vermeiden, dass die Menge der Shops die das bisher nutzte und das erst nach einem Update mitbekommt durch das Update rechtsbrüchig oder abmahnbar wird. Wir haben eine neue Option, die steuert ob die Eingabefelder in den Optionen noch vorhanden sind, die per Default aus ist, aber in 4.5/4.6 durch den Shopbetreiber aktiviert werden kann. Stand heute wollen wir die Option und die Felder mit GX4.7 dann entfernen, ab dann werden die nicht mehr da sein und die Daten beim Update auf GX4.7 und höher auch verloren gehen. Wir sind wie immer offen für euer Feedback. Sollten wir einen wichtigen Fall übersehen haben, könnt ihr das hier gerne darlegen, das wird dann geprüft und durchdacht. Sollte jedoch nichts an plausiblen Einwänden zu uns kommen, würden wir den Plan so wie gedacht umsetzen wollen. Auch Fragen werden gerne beantwortet, fühlt euch also frei diese genau hier zu stellen.
Es braucht Variationen zum konfigurieren und Anpassen von Grundartikeln. Dabei gibt es dann 2 Wege 1. Eigenschaften-Kombinationen die die Auswahl in Abhängigkeit voneinander kombiniert, wie für z.B. Textilien zwingend notwendig, da nur aus der Kombi von 2 oder mehr Auswahlfelder ein Artikel entsteht und es ohne Auwahl eigentlich nicht mal den Grundartikel gibt. 2. Optionen / Atribute die den vorhandenen Grundartikel ergänzen und erweitern wie z.B. Extras die dazugepackt werden, Optionale Erweiterungen die am ende aber keinen eigenständigen fertigen Artikel ergeben. z.B. Ersatzteile, Zusatzgarantien, usw. Alles was nicht abhängig von der vorherigen Auswahl ist. Man benötigt unabhängige Auswahlfelder und welche die von der vorauswahl abhängig sind. Ohne abänigkeiten kann man z.b. nicht festlegen wieviele roten-XL Shirts man lagernd hat oder das es das gelbe gar nicht in XXL größe gibt und somit die Auswahl XXL bei wahl der Farbe Gelb nicht angezeigt wird. Bei den alten Atributen konnte man ja einen konfigurierten Artikel gar keine konkrete EAN geben. Man konnte nur den eines Grundartikels oder einer der verwendeten Atribute angeben aber nicht wenn man 2 kombinierte. Wegfallen lassen würde ich die aber nicht, da man z.B. für eine Garantie Option oder Ersatzteil Option die EAN der Teile durchaus benötigt, parallel zum Hauptartikel - was wieder eher richtung Bunlde geht, statt zu einem Artikel der durch die Option / Atribut konfiguriert wurde. Hier sollte man vorab mal sammeln welche Anwendungsfälle überhaupt aktuell genutzt werden oder benötigt werden. Das vermisse ich in letzten Monaten etwas. Es wird zwar viel Feedback im Hintergrund gesammelt aber aktiv danach gefragt wurde seltener als früher. Es wird immer öfters einfach gesagt: Wir finden das es so für die meisten am Besten ist, daher machen wir das so. Das ist etwas schade.
Mich würde interessieren, was sich Datenbank-seitig konkret bei Eigenschaften (neuerdings Varianten?) ändert? Neue Tabellen oder alte Tabellen mit teilweise modifizierten Strukturen oder alte Tabellen mit Erweiterungen, oder alles so wie es war?
Falsche Frage. Auf Datenbanklevel garantieren wir Endnutzern für so ziemlich genau gar nichts und dokumentieren auch nicht alle Entscheidungen und Änderungen. Die Nachricht ist der Shop ist auf Datenbankebene nicht modellstabil, er ist das Gegenteil. Wir wollen da reformieren. Jetzt ist noch relativ viel gleich zu vorher, die Warnungen sind aber nicht neu und die Pläne gehen weiter und Ausführungen rücken immer näher. Wer Prozesse auf direkter Datenbankmanipulation aufbaut, wird also - versprochen - Schmerzen bekommen, das ist der falsche Weg für einen längeren Erfolg. Der Weg um an Daten zu kommen sind intern die PHP Serviceklassen und extern die REST-API, da liegen die Garantien. Wer das trotzdem anders als strikt empfohlen machen will, trägt selbst alle verbundenen Risiken. Das machen aber halt Leute... und es macht uns das Leben auch schwer. Es geht recht wenig um den Willen von Shopbetreibern aus Gefühlssicht. Entweder etwas macht Sinn zu erhalten, weil es ein Werkzeug mit validem Usecase ist, oder es kann weg. Es gibt viele logische Gründe die genannten Sachen wegzutun: das Zeug bremst, macht die Logik schwieriger zu pflegen und zu handhaben, kompliziert Datenaufbereitung für Feeds und SEO, es kostet uns also Geld und Fortschritt und macht Händlern dazu auch Ärger. Es wurde bislang aus Historismus noch toleriert, aber war nicht ohne EInschläge. Die Frage ist ob wir logische Gründe übersehen das zu behalten, geschildert an zum Beispiel praktischem Szenario oder Gedankenmodell, das hätte gute Chancen zu verfangen. Wir entscheiden am Ende wirtschaftlich und auf Sinnebene. Und wenn die Gründe gut sind, würden wir vermutlich die Zeit nehmen und das Feature sauberer neumodellieren, das bauen, dann das alte kippen, im Rahmen einer Migration. Wir sehen einen solchen Einsatz nur bislang als nicht begründet an, und wenn das so ist dann passiert nix, dann machen wir andere Sachen. Das muss sich klären. Alte Zeit. Wir haben extra Eigenschaften und Attribute gleichzeitig auf Artikeln als Usecase im Sinn und haben darauf zugearbeitet. Das ging früher nicht. Das wird auch bei Optionen so bleiben wenn wir den Weg gehen. Für Kombinatorisches musst man Kombinationen, sprich EIgenschaften/Varianten. Das Kommen oder Nichtkommen einer Bundlefunktion hängt davon nicht ab, das würden wir wenn logisch wohl anders aufziehen. Grobes Modell: Das hinzufügen eines Stammartikel oder eines Stammartikel mit spezifischer Variante oder das Auswählen einer Option an einem Artikel bewegt als Randprozess einen anderen vollständigen Nebenleistungsartikel mit in den Warenkorb. Der hätte dann aber eigenen Bestand, eigene EAN, lokalisiert an dem jeweiligen Nebenartikel. Das ist aber kein 4.5 Stoff, ich wollte nur zeigen, dass das eine andere Baustelle ist.
Ich merke gerade dazu hatte ich nix gesagt, ist aber bemerkt. Japp, verstanden. Das heisst ihr hängt da ansich nicht dran wenn es anders geht, aber ihr bräuchtet nach Möglichkeit eine Lösung für den Weg ans andere Ufer. Für eine Person könnten wir das nicht sinnvoll programmieren, aber mal schauen ob noch weitere Kandidaten aufschlagen. Sicherheitshalber: Wir schaffen nicht die Möglichkeit ab EAN zu hinterlegen. Wir treiben das EAN Feld nur an einer Stelle von mehreren ab. Ich habe die sehr starke Vermutung, dass eure Artikel auch in einer neuen Welt abbildbar sind, die ist nur eben etwas anders aufgehängt.
Ich weiß. Aber es liegen äußere Sachzwänge vor, so dass wir die Schmerzen in Kauf nehmen müssen. Magst du mir die Frage daher trotzdem beantworten?
Also ich würde mich auch über eine Migration von Attributen zu "Neu Varianten" freuen. Ich habe Attribute gewählt, weil bei der Menge von Auswahlmöglichkeiten bei unseren Produkten die Eigenschaften keinen Sinn machten.
Hallo Hartwig, Ich bin mir bei deinen Artikeln gar nicht sicher, ob du wechseln musst. Haben deine fertigen Artikel denn eine eigene EAN?
@barbara Ich denke habe das Ganze nicht so richtig verstanden. Ich dachte die Attribute gehen weg. Naja ....
Die bekommen nur einen neuen Namen Was weg fällt ist bei den Attributen das EAN-Feld. Aber ich gebe Dir recht, dass das ganze mit den neuen Namen und so schon verwirren kann.
Das ist eine absolutes No Go, dass "IHR" mal eben so das Ende der Attribute beschließt ohne eine automatisierte Migration zu den Eigenschaften anzubieten.
... die Attribute fallen nicht weg. Nur das Feld für die EAN bei den Attributen, wie Barbara schon geschrieben hat.
Hat das wegfallen der EAN irgendwelche Auswirkungen auf den Google Shopping Datenfeed? Grundpreise funktionieren ja seit dem Update auf 4.4.0.3 im Google Datenfeed auch nicht mehr.
Dafür bleiben die Varianten. Ich habe vor langer Zeit schon angefangen alles auf die Eigenschaften umzuwuchten, auch wenn es viel Arbeit ist. So weit ich mich erinnern kann, standen die Attribute schon vor vielen Jahren im Gespräch nicht die optionale Lösung zu sein. Bei den Eigenschaften finde ich es auch zum Vorteil das der Kunde nicht einfach etwas in den Warenkorb legen kann, sondern erst auswählen muss.
Liebe Leute, Ein Webshop ist weder Lagerverwaltung noch Artikelverwaltung! Um eine saubere Lagerverwaltung zu haben, bedarf es einer ordentlichen WaWi !. Glaubt mir, ich habe darin 25 Jahre Erfahrung. Der richtige Weg, und nur so ist eine saubere Verwaltung möglich, geht über die Artikelanlage in der WaWi und dann Überleitung in den Shop. Bereits in der WaWi werden die ganzen Attribute zum Artikel hinterlegt. Wie Größe, Farbe, Produktgruppe, etc. Die WaWi erzeugt auch den EAN-Code. Ihr wollt ja aussagekräftige Auswertungen machen. Das ganze Wischiwaschi bringt nichts. Ist nur umständlich. Daten-Import/Export ist bei Gambio derzeit noch sehr umständlich, weil viele in einer Wurscht gehalten ist, z.b. Preise, und besonders die Beschreibung mit den Zusatzfeldern. Bitte zerlegt diese in einzelne Spalten. Danke. Franz aus Graz
Tiefes seufzen. Das ist ganz schön pauschal und auch Unfug. Mit genau solchen Sätzen hätte niemand eine Chance uns mit einer Message zu erreichen, weder du noch andere, da fehlt das sachliche Futter. Es geht nicht um "Stammtischparolen", die interessieren uns generell nie. Nie nie nie. Es geht um sachliche, belegte Diskussion von Features und Usecases oder zumindest Angabe von Gedankenmodellen. Das könnte man sachlich kurz als die "Warum-Frage" definieren, bei uns gibts immer ein Warum und ein Darum. Deins hat nur ein Deswegen, das tut nicht. Was ist also das Warum und das Darum bei dir? Auch so ein Pauschalismus, und falsch. Wawi Leute vertreten sicher gerne mal so einen Humbug, aber so schwarz/weiss pauschal ist das schlicht auch nicht richtig. Wawis haben ihre Haben-Punkte, aber da zu sagen das sei der Universal Zauberstab ist Unfug. Das fängt dabei an, dass nicht jede Wawi das gleiche kann und es da gute und schlechte gibt. Dann gibts es verschiedene Usecases. Und dann gibts Shops, die Sachen können, die Wawis nicht können. Die Antwort ist also: Das richtige Set an Werkzeugen für die Erreichung des Ziels ist die Lösung. Das ist mal eine Wawi, mal eine Wawi mit Shop, mal ein Shop ohne Wawi. Für jeden der Cases kann man plausible und valide Muster zeigen.
Ganz ehrlich Wilken: nicht auf dem Niveau. Wir sind weder unmündige Kinder noch Bittsteller. Und ich kann mir nicht vorstellen, daß du nicht weißt wo das Problem liegt. Falls dem nicht so sein sollte, erkläre ich es gerne: wir verkaufen Modeschmuck und Accessoires. Also z.B. Ringe, Armbänder oder Gürtel. Die Größen werden über Attribute abgebildet. Ein Ring hat z.B. fünf Größen: 17,18, 19, 20 und 21. Der Hersteller vergibt für jede dieser Größen eine GTIN (früher EAN). Die GTIN ist der verbindende Link zu Amazon. Ein Mischzustand aus Eigenschaften und Attributen ist per Magnalister nicht mit Amazon synchronisierbar. Aufgrund der großen Anzahl der Produkte und aufgrund der genannten Magnalister Einschränkung ist für uns nur ein automatisierte Umstellung von Attributen zu Eigenschaften möglich. Solange es keinen automatisierte Umstellung gibt, bitten wir dringend darum, das Feld EAN in den Attributen zu erhalten. Es ist ja auch logisch gar nicht nachzuvollziehen, warum ihr das EAN Feld aus den Attributen entfernen wollt, die Attribute aber weiterhin erhalten bleiben sollen.
Das Problem mit den EANs bei Attributen entsteht dann, wenn man mehr als ein Attribut hat (ich bleibe hier gerade mal bei den alten Bezeichnungen). Wenn du ein Attribut „Größe“ mit den Werten „S“, „M“ und „L“ hast und ein Attribut „Farbe“ mit den Werten „rot“, „grün“ und „blau“, dann kannst du z. B. „S“ die EAN 12345678 zuweisen und „grün“ die 40771701. Und welche EAN hat jetzt ein grüner Artikel in Größe S? Die Datenstrukturen für die Attributen waren immer schon etwas … suboptimal. Sie erzeugen in solchen Situationen unauflösbare Uneindeutigkeiten. Merkregel, seit jeher: Wenn du unterschiedliche Fächer in deinem Lagerregal bezeichnen willst, sind das Eigenschaften. Wenn du nur ein Fach für den Artikel hast und die Variante nur bestimmt, was du mit dem Artikel noch tust oder was du ihm hinzufügst, dann ist das ein Fall für Attribute.