Ja, das stimmt schon, ich wollte damit ja auch nur anregen, dass die Basis hier nicht stimmt. Aktuell wird hier sehr viel über die Templates generell diskutiert, die Basis wird hier aber nicht angesprochen. Wir sehen halt hier immer wieder, dass mit Tricks doch wieder irgendetwas gedreht wird, was bei ordentlicher Basis sicherlich einfach wäre. Wir hoffen aber auf Shopware 4.x. MfG
[quote=„Compusoft GmbH“]Ja, das stimmt schon, ich wollte damit ja auch nur anregen, dass die Basis hier nicht stimmt. Aktuell wird hier sehr viel über die Templates generell diskutiert, die Basis wird hier aber nicht angesprochen. Wir sehen halt hier immer wieder, dass mit Tricks doch wieder irgendetwas gedreht wird, was bei ordentlicher Basis sicherlich einfach wäre. Wir hoffen aber auf Shopware 4.x. MfG[/quote] Muss da leider beipflichten. Shopware ist eine wirklich sehr gute Lösung und wir sind damit bisher sehr zufrieden - vor allem mit dem Team dahinter, das wirklich Klasse arbeitet. :thumbup: Aber was die Behandlung von Varianten angeht stimmt einfach vieles im Grundsatz nicht. Also im DB-Layout. Eine Variante sollte, genau wie von Dir oben beschrieben, im Grundsatz in der DB genau so angelegt sein wie jeder Haupt-Artikel auch. In Shopware werden aber Varianten stiefmütterlich behandelt. Und dadurch sind viele Daten nicht bei der Variante ablegbar, obwohl sie dort hin gehören würden. Zum Beispiel Liefertermin / Erscheinungsdatum. Es gibt eben keinen Liefertermin für die „Jacke“, sondern einen für die „rote Jacke“, einen für die „gelbe Jacke“ und einen für die „grüne Jacke“. Ist aber in shopware so nur abbildbar wenn man den Umweg über die Zusatzfeldern nimmt und das Template anpasst. Hier geht shopware (auch mit Konfigurator-Modul) einfach an der Realität vorbei. Hoffe sehr, dass es hier fundamentale Verbesserungen geben wird. AS
Das stimmt zum Teil - sicherlich können einige Datenfelder vom Hauptartikel, in die Tabellen wandern, die die Varianten repräsentieren. Gerade bei den mehrdimensionalen Varianten, muss man aber die Performace im Hinterkopf beahlten. Bei einer Warenwirtschaft, wo es kaum Concurrent Users gibt und es nicht primär auf die Geschwindigkeit ankommt, mag das ja in Ordnung sein. Anders sieht es im Shop-Umfeld aus - wenn man hier die primären Artikel-Tabellen mit Konfigurations-Varianten “zuballert”, leidet natürlich die Performance. Dann läuft jede Query über alle Konfigurator-Varianten, obwohl deren Daten ggf. nur auf der Detailseite und im Warenkorb benötigt werden. Der Grund für die logische Trennung der Varianten-Typen liegt also hier begraben - das mag bei Shops, wo es nur um T-Shirt Variationen geht, kein Problem sein - auf der gleichen technischen Basis, müssen aber auch PC-Konfguratoren möglich sein, wo es tausende von Konfigurationsmöglichkeiten gibt. Das nur als Background-Info - zur 4.0 werden wir das Datenbank-Model auf jeden Fall optimieren, trotzdem sollte man nicht Shop und Warenwirtschaft 1 zu 1 vergleichen - da gibt es technisch schon erhebliche Unterschiede, die man bedenken muss.
Moin! Ja, Shop und Warenwirtschaft sollte man schon getrennt betrachten. Das ist sicher richtig. Aber eine gute WaWi macht ja auch nichts anderes, als die Realität abzubilden. Eben z. B., dass in der Realität Verfügbarkeit/Lieferdatum pro Variante existiert und nicht pro Stamm-Artikel. Das ist einfach gegeben. Und deshalb muss das Shopsystem diese in der Realität gegebenen Tatsachen eben auch abbilden. Da komme ich einfach nicht dran vorbei, sorry. Das heisst ja auch nicht, dass man in die Tabelle s_articles alle möglichen Daten wie Farbe, Grösse, CPU, RAM usw. rein stopfen muss und so massig Redundanzen produziert. Aber die Daten, welche einen in der Realität physisch vorhandenen Gegenstand betreffen, die sollten eben dort drin sein. Alles andere kann man ja getrost auslagern und das macht mit Blick auf die Performance auch sicher Sinn. Übrigens lassen sich die Abfragen ja relativ leicht eingrenzen. Einfach eine Spalte “parent” mit führen, oder? Wird ja an anderer Stelle auch so gemacht. AS
Hi, man könnte doch einen kurzen Workround machen und zumindest den Grundpreis - wenn Varianten vorhanden sind - ausgeben und zwar wie er beim Vaterartikel hinterlegt ist. Da wäre bestimmt einigen schon geholfen. Viele Grüße Rainer
[quote]man könnte doch einen kurzen Workround machen und zumindest den Grundpreis - wenn Varianten vorhanden sind - ausgeben und zwar wie er beim Vaterartikel hinterlegt ist[/quote] Das funktioniert aber auch nur dann, wenn die Variante nicht vom Grundpreis abweicht. Tut sie dies, hast du ganz schnell rechtliche Probleme, weil deine Grundpreisberechnung nicht mehr stimmt. An der Stelle frage ich mich, wie das Thema durch die Trusted Shops Zertifizierung gehen konnte. Abhilfe bringt an der Stelle aber Grundpreise für Varianten nutzen. Hier muss man aber an die Datenbank, was für zukünftige Updates sicherlich nicht unproblematisch ist. Unschön bzw. nicht erwartungskonform (besonders für den Kunden) ist das filtern nach Varianten. Was bringt es mir nach einer Variante in Kategorien filtern zu können, dann aber nicht auch tatsächlich diese Variante angezeigt zu bekommen, sondern nur den Master Artikel und dann auch nicht die entsprechenden (ab)-Preise der Variante(n). Ich muss AS leider vollkommen Recht geben, die Variantenumsetzung ist sehr stiefmütterlich behandelt und im Grunde nicht ohne zusätzlichen erheblichen Anpassungsaufwand verwendbar. Grüße Oliver
Hi Oliver, Hallo @all, Wie meinst du das mit filtern? Das ist ja logisch das der Vaterartikel, sonst müsste die Variante ja als einzelne Artikel angelegt werden, wenn diese einzeln angezeigt werden sollen. Das diese Artikel nach der Suche oder Filtern einzeln angezeigt werden, habe ich allerdings noch bei keinem Shopsystem gesehen. Das bei Shopware z.B. Varianten und Konfigurator Artikel unterschiedlich handelt, kann man drüber streiten - sind aber natürlich unterschiedliche Module. Bei komplexen Konfiguratoren spielt die Performance sicher eine Rolle, daher kann ich hier den Unterschied auch klar verstehen. Solche Dinge muss z.B ein Wawi in den meisten Fällen überhaupt nicht berücksichtigt werden… Auch das Thema Grundpreise Ist So eine Sache. Man muss als Shopbetreiber natürlich im Vorfeld schauen, was man mit einem Standardprodukt abdecken kann. Sich einen Shop installieren und dann im Anschluss „nörgeln“ weil man etwas vermisst, ist natürlich einfach! 
Shopware stellt hier ein Standardprodukt zur Verfügung, die CE sogar kostenlos, was ich echt beeindruckend finde. Aber es ist nun mal ein Standardprodukt! Es wird aber immer weiter entwickelt und das finde ich in einem Riesen Tempo - super! Viele Verbesserungen und Erweiterungen kommen sicher automatisch, bzw. Als Plugins oder durch due wachsende Community. Ein Produkt wächst ja mit der Zeit und daher sind sicher einige Strukturen aus Vorgängerversionen. Ich persönlich finde, dass man mit verschiedenen Behauptungen und Aussagen immer vorsichtig sein sollte. Wenn alles so einfach wäre, würde jeder sein Shopsystem selber bauen 
Entschuldigt, aber das musste ich jetzt mal schreiben
Ich gebe dir vollkommen Recht, es war auch kein Nörgeln, sondern ein Aufzeigen von Problemen bzw. Fehlern, die aktuell den Umgang mit Varianten erschweren. 
Ich bin ebenfalls schwer von der CE Version begeistert :thumbup: und freue mich auf weitere Verbesserungen und Erweiterungen. Manche Dinge werden aber eben erst nach dem installieren und „rumprobieren“ erkennbar. [quote]Das ist ja logisch das der Vaterartikel, sonst müsste die Variante ja als einzelne Artikel angelegt werden, wenn diese einzeln angezeigt werden sollen. Das diese Artikel nach der Suche oder Filtern einzeln angezeigt werden, habe ich allerdings noch bei keinem Shopsystem gesehen.[/quote] Beispiel: Artikel mit verschiedenen Inhaltsgrößen (50g, 250g, 500g, 1000g) Wenn ich eine Kategorie angezeigt bekomme und dann nach 50g filtere, erwarte ich doch die Artikel und die dazugehörigen Preise angezeigt zu bekommen. Nehme ich dann noch die 250g dazu und ein Artikel hat beide Varianten, dann erwarte ich einen ab-Preis. Der Vaterartikel (Gleichberechtigung: Mutterartikel ) ist an dieser Stelle nicht erwartungskonform. Ich bin auf die 4.0 gespannt und freue mich auf weitere Verbesserungen
Das meinte ich mit der Filterung von Varianten. Ich wüsste nicht, dass so etwas überhaupt realisierbar ist. Wenn du so etwas abbilden möchtest, würde ich einzelne Artikel vorschlagen. Durch setzen eines Filters, wirst du due Darstellung des Artikels und des Preises niemals dynamisch niemals Performanz in einem Shopsystem unterbringen koennen. Da musste so viel beachtet werden, Gerade auch bei Shopware. Da gibt es dann noch Preisgruppen, Staffelpreise, Rabattgruppen, individuelle Preuse und und und So etwas muss man natürlich immer bedenken… Nicht wahr @shopware Ich habe das geschilderte Verhalten noch bei keinem Sysrem gesehen und Stelle mir so eine Umsetzung enorm schwierig vor! Aber bin natürlich gespannt.
Ich habe ein ähnliches Problemchen: wenn ich 5 Artikel in verschiedenen Farben (Varianten) anbiete und dazu Staffelpreise (1 Artikel 2€ ab 4 1€) warum staffelt mir das dann der Warenkorb nicht? Bsp.: 1 roter Ordner (2€) dazu 5 gelbe Ordner (Staffel zeigt dann ordentlich 1€/Stck. an) Ergebnis ist aber dann Pos.1 = 2€ und Pos.2 = 5 € Da es aber ja nur Varianten sind und der Kunde auchgemischt kaufen möchte, stimmt das Ergebnis ja nicht ganz. Der erste Ordner für 2€ müsste mit in die Staffel springen- also für 1€ zu haben sein weil ja die zweite Position schon in der Staffel ist. Hoffe, ich habs verständlich erklärt :quite: Nicole // hab mch heut emal durch Preisgruppen und Eigenschaften gearbeitet, aber es hilft nix, keine Staffeln 