Hallo. Habe mich heute mal an die Eigenschaften gemacht. Dachte ursprünglich, dass man in der Verwaltung der Eigenschaften diese anlegt und beim Artiel nur noch das zutreffende ankreuzt. Dem scheint nicht so zu sein. Man vergibt wohl die “Werte” erst beim Artikel. Das wird spätestens dann zum Problem, wenn mehrere Mitarbeiter das Sortiment pflegen. Da gibt dann der eine bei “Getriebe” ein “Automatik-Getriebe”, der nächste “Automatik” und wieder einer “automatisch”. Schon ahben wir drei Filter, die dasselbe bedeuten. Gibts da eine andere Möglichkeit / einen Workaround? Müssen wir intern eine Liste “Erlaubte Eigenschaften” pflegen? Wie macht Ihr das? Bin für jede Anregung dankbar … AS
push it baby … 
Hab ich das irgendwie wieder zu umständlich formuliert? Hat denn sonst gar keiner dieses Problem? Wie handhabt Ihr denn das? Oder hab ich es einfach nicht richtig verstanden … Dann helft mir bitte mal auf die Sprünge. Danke derweil … AS
Hi, da gibt es so keine andere Möglichkeit. Es ist so, dass dort jede Eingabe zur Verfügung steht, also frei eingegeben werden kann. Hier müsste man sich als Shopbetreiber nun festlegen und darauf achten, das man in der Gruppe “Getriebe” immer nur z.B. die Filter “manuell” und “automatik” setzt/einträgt. Bei vielen Kunden wird so etwas z.B. auch automatisch mit Daten gefüllt (Warenwirtschaft o.ä.), oder über den Shopware Import erledigt. Wenn das an einer Stelle abweichend eingetragen wurde, fällt dieses ja direkt im Shop auf und kann dann angepasst werden. Ein automatisches vordefinieren von möglichen Eigenschaften ist in Shopware so also nicht möglich. Sebastian
[quote=„Sebastian Klöpper“]Hi, da gibt es so keine andere Möglichkeit. Es ist so, dass dort jede Eingabe zur Verfügung steht, also frei eingegeben werden kann. Hier müsste man sich als Shopbetreiber nun festlegen und darauf achten, das man in der Gruppe „Getriebe“ immer nur z.B. die Filter „manuell“ und „automatik“ setzt/einträgt. Bei vielen Kunden wird so etwas z.B. auch automatisch mit Daten gefüllt (Warenwirtschaft o.ä.), oder über den Shopware Import erledigt. Wenn das an einer Stelle abweichend eingetragen wurde, fällt dieses ja direkt im Shop auf und kann dann angepasst werden. Ein automatisches vordefinieren von möglichen Eigenschaften ist in Shopware so also nicht möglich. Sebastian[/quote] Sehr unpraktisch… Das gute alte xtCommerce ist hier schon viel weiter… Da gibt es shopweite Attribute, aus deren Bestand man einem Artikel dann beliebige zuordnen kann. Genau so, wie Alpine Swift sich das so vorstellt. Merkwürdigerweise macht OXID das genauso umständlich (und fehleranfällig)… Aber nicht nur, dass das sehr umständlich und fehleranfällig ist, es verletzt m.E. auch ganz gravierend das Konzept der „Normalisierung“ von relationalen Datenbanken: da wird derselbe Text dann 1.000 mal abgespeichert, wenn 1.000 Produkte dasselbe Attribut haben (eine relationale Todsünde quasi). Statt nur 1 Mal, wie das bei xtc & Co. der Fall ist (dort wird einfach eine Referenz zum shopweiten Attribut dem Artikelstammsatz mitgegeben)… Und wenn man sich dann vorstellt, dass man das Attribut dann leicht umbenennen will… 1 Mal bei xtc & Co., 1.000 Mal bei Shopware und OXID (bzw. über SQL)? Fast kann man den Eindruck gewinnen, dass bei dem ganzen OO- und Framework-Gedöns die Praktikabilität doch manchmal leider etwas auf der Strecke bleibt… Wieder was für meinen Shopware-Wunschzettel…
Schön, dass ich das nicht alleine so sehe. Nur dass das vorneweg nochmal klar ist: Ich finde die ShopWare insgesamt klasse. Aber es gibt in der Tat Bereiche, wo man sehr weit vorgreift während man bei anderen Punkten zu kurz gesprungen ist. Und leider sind das nicht selten Punkte, die so selbstverständlich sind, dass man sie eigentlich ohne vorher gross nachzufragen erwartet hätte. Zum Beispiel finde ich die Gestaltung des backend mit Desktop-Funktionalitäten ganz angenehm. Das hätte es aber nicht gebraucht. Unsere Shop-Kunden sehen davon ja ohnehin nichts. Es hat aber sicher ordentlich Programmierer-Zeit gefressen. Andersherum musste ich heute feststellen, dass ich ein Datum ab dem ein Artikel (wieder) lieferbar ist nur beim Stammartikel hinterlegen kann. Das hätte ich niemals erwartet und es stellt uns ganz schön vor Probleme. Ich habe noch keine Ahnung, wie ich das geregelt kriege. Beispiel: Wir verkaufen eine Felge. Die gibt es in rot und in blau. Wir haben beide beim Hersteller nachgeordert. Die roten kommen, die blauen nicht. Auf dem Lieferschein des Herstellers steht also eine Rückstandsposition mit dem zu erwartenden Lieferdatum. So etwas ist in jeder Handels-Unternehmung Standard. Normalerweise würde ich nun her gehen und bei den blauen im Konfigurator den Liefertermin eintragen. Dann kann der Kunde abschätzen, ob er lieber gleich die rote nimmt oder auf die blaue wartet, die er haben wollte. Geht aber nicht. Und mir fällt dazu auch kein guter Workaround ein der nicht zu mehr Kundenanfragen führte: „Habt Ihr die Felge nicht in blau? Und wann kommt die denn wieder?“ Das ist dann aber eine reine ABM für unser CRM. Nun gibt es ja wohl bald mal diese E-Mail-Benachrichtigung (http://www.shopware.de/shopware.php/sVi … tegory=277). Vielleicht wird das dann mal aufgedröselt. Aber ich habe eher die Ahnung, dass auch diese dann wieder nur für den Stamm-Artikel funktioniert. Denn allzuoft, auch da muss ich avenger beipflichten, geht es im Grunde um das DB-Layout. Je mehr ich dahinter sehe, umso mehr habe ich den Eindruck, dass dieses ziemlich … nun ja, sagen wir mal organisch entstanden ist. Ich habe heute zum Beispiel die ersten Artikel eingestellt um damit zu testen. Alle über den Konfigurator angelegt mit Option Farbe, weil es fast alle diese (11) Artikel in diversen Farben gibt. Nun habe ich in der s_articles_groups 11 Einträge die bis auf die IDs vorne vollidentisch sind. Datenbank-Normalisierung sieht wirklich anders aus. Oder habe ich an diesem Punkt einfach das Konzept nicht verstanden? Ist das ein Bediener-Fehler? Zum Stichwort OOP: Ich bin der Auffassung, dass die rote und die blaue Felge jeweils Objekte sind. Und beide können z. B. einen zu erwartenden Liefertermin haben. Unabhängig voneinander. In den Stammdaten sollten also nur die Daten liegen, welche die Varianten zwingend gemeinsam haben, z. B. den Hersteller. Alles andere gehört zu den Varianten. Bin gespannt auf Antwort … AS
Mein letzets Posting war schon lang, ja. Aber ich muss da leider noch was zu loswerden. Ich zhitiere mich mal selber : [quote]Aber es gibt in der Tat Bereiche, wo man sehr weit vorgreift während man bei anderen Punkten zu kurz gesprungen ist.[/quote] Und dafür ist diese Zitat von Sebastian leider auch wieder ein Beispiel: [quote]Bei vielen Kunden wird so etwas z.B. auch automatisch mit Daten gefüllt (Warenwirtschaft o.ä.), oder über den Shopware Import erledigt.[/quote] Auf der einen Seite baut man in die ShopWare ein Mini-ERP mit Belegerstellung, Lagerstandsreduzierung usw. ein. Sowas gehört eigentlich in die (echte) WaWi. Auf der anderen Seite erwartet man die Vorleistung von externen Systemen (siehe Zitat) bei (Normalisierungs-) Aufgaben. Das wäre aber originäre Aufgabe des Shop-Systems. AS
Sorry, aber hier kommt gleich noch einer: [quote]Nun habe ich in der s_articles_groups 11 Einträge die bis auf die IDs vorne vollidentisch sind. Datenbank-Normalisierung sieht wirklich anders aus. Oder habe ich an diesem Punkt einfach das Konzept nicht verstanden? Ist das ein Bediener-Fehler?[/quote] War aber leider kein Bediener-Fehler. Dann das mit den Templates bei den Gruppen/Optionen können wir komplett vergessen. Das funktioniert nur, wenn exakt dieselben Optionen zur Verfügung stehen sollen. Denn alles was hier eingegeben oder via Template geladen wird taucht zwingend in der Dropdown-Auswahl auf. Nun gibt es bei den Stamm-Daten eine Checkbox “Aktiv”. Wenn man dort einen Artikel ausschaltet, so taucht er im Shop nicht mehr auf. Bei den Konfigurator-Varianten gibt es unter Preisangabe dieselbe Checkbox. Das Verhalten dahinter ist aber ein völlig anderes. Es steuert nicht, ob diese Konfigurator-Variante angezeigt wird, sondern im Grunde, ob sie lieferbar ist. Denn die Option taucht in der DropDown-Auswahl auch dann auf, wenn man sie deaktiviert. Nur steht dann eben dort, wo sonst die Lieferbarkeit steht: “Diese Auswahl steht nicht zur Verfügung!” Das sind die kleinen, hässlichen Inkonsistenzen, die ich meinte … Ihr seid dran … AS
Und leider, leider noch einer: Habe eben die Artikel mit Konfigurator-Varianten exportiert. Schaue mir die CSV an und stelle fest: Es werden nur die “Stamm-Artikel” abgebildet. Keinerlei Anhaltspunkt für irgendwelche Varianten. Hab ich was falsch gemacht, oder ist das nur ein weiteres Indiz dafür, dass ShopWare Varianten eben nicht wirklich wie Artikel (Objekte) behandelt? Jetzt sind aber wirklich mal die Ste[f|ph]ans oder sonstwer dran … Bin sehr gespannt und noch immer voller Hoffnung. :wtf: AS
[quote]Und leider, leider noch einer: Habe eben die Artikel mit Konfigurator-Varianten exportiert. Schaue mir die CSV an und stelle fest: Es werden nur die “Stamm-Artikel” abgebildet. Keinerlei Anhaltspunkt für irgendwelche Varianten.[/quote] Hierzu müsstest Du mal ein neues Thema aufmachen, bitte nicht vermischen, Konfiguratorartikel können aber problemlos per CSV bzw. XML exportiert und importiert werden. Die stehen in einer Spalte kombiniert, da musst Du mal schauen, die Spalte heißt glaube ich auch sogar “konfigurator”… ZU DEN EIGENSCHAFTEN UND EIGENTLICHEN THEMA: Hier werden wir uns in Kürze einmal einen besseren Weg überlegen, um dieses Thema etwas komfortabler abzubilden. Dazu gibt es hier schon einige Überlegungen und und gutes Feedback auch hier aus dem Forum, man kann aber nicht alles immer sofort umbauen in einem Shopsystem. Solange müsste man halt damit leben, wie es aktuell ist. Die Eigenschaften haben wir aber auf jeden Fall jetzt auf der Roadmap. Stefan
Danke Stefan! [quote]Die Eigenschaften haben wir aber auf jeden Fall jetzt auf der Roadmap.[/quote] Das ist gut so und Ihr werdet wohl was draus machen … Sachdienliche Hinweise wie es sein sollte findet Ihr im Forum. Bin gespannt. [quote]Konfiguratorartikel können aber problemlos per CSV bzw. XML exportiert und importiert werden.[/quote] Danke. Schaue ich mir heute Abend gleich noch einmal an. [quote]Solange müsste man halt damit leben, wie es aktuell ist.[/quote] Um zu sehen, wie wir damit so lange umgehen können wäre es schön, wenn Du zu meinem Nachtrag hier (viewtopic.php?f=11&t=426#p2457) noch kurz was schreiben könntest. Ist eine der beiden Zwischen-Lösungen kurzfristig machbar? [quote]Eine Zwischenlösung könnte sein, wenn es bei den Filter-Optionen neben der Checkbox „Option ist filterbar“ eine Checkbox „Option ist vergleichbar“ gäbe. Dann würde man eben einstweilen für die Leistung der traktoren zwei Filter-Gruppen parallel führen. Eine zum filtern und eine zum vergleichen. Falls auch das nicht geht würde mich interessieren, ob man die Vergleichs-Funktion irgendwie generell im Shop zu deaktivieren. Geht das irgendwo in den Einstellungen? habe dazu bisher leider nichts gefunden. Denn die Filter sind für uns eigentlich wichtiger. Und dann würden wir eben zunächst auf die Vergleichs-funktion verzichten.[/quote] Danke derweil … AS
Hi zusammen, gibt es in dieser Sache schon was neues ? Grüße Stefan
Sehr schade. 2010 angesprochen und auf die „Roadmap“ - auch 2012 noch nicht umgesetzt. Bin auch gerade auf der Suche nach einer solchen Lösung. Gibt es schon Plugins oder ein Script zur Lösung? Grüße
Moin! Nein, das ganze Eigenschaften- und Filter-System wurde noch immer nicht vom Kopf auf die Füsse gestellt, leider. Man scheint sich im Moment um wichtigere Bereiche (z. B. MOSAIC) zu kümmern, ehe man sich solchen Basics zuwendet. Noch hoffe ich auf die Version 4, denn dort sollen ja die ganzen DB-Tabellen mit Artikeldaten dann auch normalisiert sein, hiess es mal … vielleicht geht man das dann auch an. Und villeicht kann auch der „Einstieg“ von bui-hinsche hier was bewirken. Die machen immer schon Plugins (bisher vor allem für xt) die sich sehr eng am tatsächlichen Nutzen für den Shopbetreiber orientieren … LG, AS