Hallo, wir haben Eigenschaften mit Aufpreisen im Einsatz, und hierauf Sonderangebote zu geben ist sehr aufwändig, siehe mein satirisches Tutorial: (Link nur für registrierte Nutzer sichtbar.) Da ein neues Eigenschaften-System im Gespräch, aber in weiter Ferne liegt: Wäre es nicht eine einfache und gute Möglichkeit, einfach in der products_properties_combis Tabelle eine Zusatzspalte für einen Sonderangebots-Aufpreis zu hinterlegen, bei dem ein prozentual eingegebener Rabatt des Vaterartikels automatisch auch in selber Höhe für die Eigenschaftsartikel-Aufpreise angewendet wird? Vorteile: Man kann eine sehr schlanke Möglichkeit schaffen (ggf. über einen Kippschalter aktivierbar: "Prozentuale Sonderpreise auch auf Eigenschaften berechnen"), um doch noch ohne aufwändige Berechnungen einen prozentualen Sonderpreis durchgängig auf alle Variationen anzubieten Man kann auch mit rabattierten Eigenschafts-Aufpreisen die Preisangabenverordnung einhalten und reduziert das Risiko von Abmahnungen: man hat die Möglichkeit, in den Sonderangebots-Ribbinnens einen korrekten Preis zu hinterlegen man kann die Streichpreise (UVP-Preise) korrekt darstellen - bisher ist es ja so, dass der UVP aus Hauptartikelpreis mit Rabatt zzgl. einem Kindartikelpreis der nicht der Listen-Aufpreis sein muss berechnet wird. Das führt immer zu falschen Streichpreisen, wenn der Eigenschafts-Aufpreis größer oder kleiner als der UVP-Aufpreis ist.
Das kann man wohl derzeit für Eigenschaften und Attribute nur über die Kundengruppen steuern. Für Sonderangebote gibts da keine shopseitige Möglichkeit. Ich hatte mir für Attribute mal was anpassen lassen, damit die Attribute mit denselben x% rabattiert werden, wie der Hauptartikel. Im Standard wird ja nur der Hauptartikel mit x% rabattiert und die Eigenschaften und Attribute werden zum normalen Preis aufgeschlagen. Da gab es damals lange Diskussionen ... und man wollte es nicht der Realität anpassen. Gambio Mitarbeiter sind die Einzigen Kunden, die beim Autokauf nur einen Rabatt auf das Basismodell haben wollen und alles hinzukonfigurierbare (Navi, Alu, Winterräder, Lack, Leder etc. zum Ladenpreis - unrabattiert - kaufen. Lustig wirds, wenn dadurch die (beworbenen) 10% Nachlass im roten Ribbon durch dazukaufen von Eigenschaften/Attributen auf nur 7% zuammenschmelzen ... ein werbetechnisches / wettbewerbsrechtliches Desaster.
Und wieder ein Beitrag von dir den ich lese, den ich aber nicht ernst nehme. Dafür geht mir der Stil zu sehr auf den Senkel. Ich meine damit: Die "Realität", aha. Der Shop ist begrenzt flexibel an der Stelle, aber Realität? Ehrlich das war ja nun kein Treffer. Man hätte jetzt ja über die Sache reden können, aber Irgendwie kriegt man bestimmt auch in einen Nebensatz, dass wir alle im Team doof sind. Gut, dein Punkt. Wettbewerbsrechtliches Desaster! Sorry, Weltverschwörung oder was? Du verspielst so bei mir und allen anderen laufend Credits, ich hab gar keine Lust mehr dir auf die Sache zu antworten. Dabei ist auch egal ob du einen Punkt triffst oder nicht, du schwächst dauernd und immer deine eigene Sachargumente weil du eine Bildzeitungsreife Story drumrumbaust. Ewiges rumgestänker, grosse Fehlleistung von dir finde ich. Du bist jetzt bei der Form der Datenspeicherung, das ist aber die kleinste Hürde bei dem ganzen. Ich würde da nie einen Prozentsatz speichern wollen, sondern immer Beträge. Im Eigenschaftenkontext, wo wir immer Aufpreise speichern wäre das dann vermutlich ein Alternativaufpreis. Die eigentliche Hürde ist aber die Preisberechnung auf der einen Seite, das ist extrem heikel, Die Pflege und die Darstellung an alle relevanten Stellen die andere. Da lässt sich kurzfristig nichts in Aussicht stellen.
Mal sehen ob das Customizing mir ein Angebot für eine Lösung machen kann (auch wenn die meine letzten Anfragen für Sonderanpassungen aus Kapazitätsgründen abgelehnt haben)
Klar, so meinte ich das auch, dass die Aufpreise absolut gespeichert werden. Das geht aber ja nur bei prozentualer Eingabe und muss in absolut umgerechnet werden, weil sonst ja kein Sonderpreis-Aufpreis berechnet werden kann. Das mit der Darstellung der relevantesten Stellen der Preisberechnung finde ich seltsam. Ich dachte, schon XTCommerce war damals so weit objektorientiert, dass man einfach nur auf eine Preisberechnngs-Class zurückgegriffen hat statt die Preisberechnung und -Darstellung an jedem Ort einzeln vorzunehmen? Ist das nicht alles in der xtcPrice drin? Dann wäre das doch sehr einfach zu überladen, oder nicht? Siehst du so große technische Hürden, dass auch Kai Stejuhn das nicht sauber hinbekommt und das Gambio Customizing Team auch nicht?
Alles ist in der xtcPrice ist genau das Problem. Die wird von überall aufgerufen und muss für alles funktionieren. Wenn du da irgendwo was drin änderst, wunderst du dich dann regelmässig auch was wo anders im weiteren Altcode dann passiert. Du hast da soviele Sachen untereinander und ineinander gestapelt, undokumentiert, dass das vor langem allerschwieriegst wartbar geworden ist. Es gibt auch bei uns in der Firma nur 2-3 Cracks, die sich noch an das Ding herantrauen und bis zum Ende einigermassen gut wissen, was welche Dinge darin wo tun. Wenn man sich Code und Historie bis zurück zu xtc3 ansieht, sieht man manchmal noch den Frankenstein vor dem inneren Auge der Entwickler tanzen die eine Zeile hinzugefügt haben und dann "ES LEBT!" jubeln. Je eher wir das Ding loswerden können, desto besser. Bis dahin gilt bei uns: möglichst nicht anfassen müssen.
Ich glaube was @Wilken (Gambio) damit sagen möchte ist, man müsste zunächst alle Stellen wo der Preis an xtcPrice übergeben und ggfl. durch xtcPrice "manipuliert" wird, ggfl. im Frontend und Backend ausfindig machen und diese um deinen Wunsch anpassen. xtcPrice macht viel, vielleicht auch zu viel, aber auch hier müsste man an vielen Stellen (Discount, VPE, Staffelung. etc.) herumschrauben, damit der korrekte Preis angezeigt wird. Hinzu kommen noch diverse Stellen hinzu, wie z.B. Ribbon, wo nur der Artikelpreise zur Berechnung herangezogen wird. Kurz: Es ist eine große Baustelle und vielleicht verliert der Eine oder Andere einfach auch den Überblick oder der Aufwand dahinter ist demjenigen einfach zu groß. Edit: Wilken war schneller
Nonsens. Niemand behauptet, dass irgend jemand "doof" wäre. Leider ist das damals lang und breit diskutierte Anliegen nicht auf fruchtbaren Boden gefallen, sodass selbstverständlich der Eindruck entstanden ist, dass es für Gambio "normal" ist, dass sich der Rabatt nur auf den Basispreis bezieht, Attribute aber zu 100% aufgeschlagen werden. (Link nur für registrierte Nutzer sichtbar.) (Link nur für registrierte Nutzer sichtbar.) Ich denke doch ... denn komischerweise war die Flexibilität plötzlich da, als es programmiert wurde. Das (Link nur für registrierte Nutzer sichtbar.) existiert ja auch schon seit August 2016. (Link nur für registrierte Nutzer sichtbar.) Man kann Bedenken auch ins Lächerliche ziehen. Ob das der Sache zuträglich ist, lasse ich mal dahingestellt ... Wenn man mit 30% Rabatt wirbt und der Kunde sich dann den Artikel mit Attributen bestellt .. da werden aus 30% auf einmal nur noch 12%. Somit stimmt die werbende Aussage (30%) nicht mehr. In eurem Testshop wird ein PC mit 30% Rabatt beworben. Hier ist von den 30% nichts mehr zu sehen, es sind dann nur noch 12%. Traurig ist es auch, dass es zwar für die Eigenschaften die Möglichkeit der Sortierung gibt, diese für Attribute aber noch immer nicht vorhanden ist. Das Beste dabei: Für beide Sachen (Einbeziehung der Attribute in die Rabattierung und Möglichkeit der Sortierung der Attribute) liegt der Code bei euch rum. Auch die Darstellung im Ribbon (% oder €) könnte angepasst werden. Sicherlich sehen für den Kunden 10% von 25 EUR im Ribbon besser aus als 2 €. Bei einem höheren Preis von zB 1999 EUR sehen allerdings 199 EUR besser aus als 10%. Eine größere Zahl macht eben mehr her.
Du hast bei Attributen keinerlei Erweiterungen der Funktionalität mehr zu erwarten. Du kannst im Gegenteil davon ausgehen, dass Attribute früher oder später gänzlich verschwinden werden. Wie gesagt: Wir bauen bei Attributen nicht mehr am Code herum, es sei denn es läge ein dringendes Problem vor, selbst wenn der Code korrekt wäre. Totaler Quark. Erstens werden in dem Artikel Eigenschaften verwendet, das sind kein Attribute. Zweitens sind die 30% durchaus erreichbar, ich hatte kein Problem solch eine Kombination im Demoshop auszuwählen, überprüf das gerne selbst. Solange der Preis zu erreichen ist, und das ist er nunmal, ist dein Argument der vorgeblichen Irreführung von Kunden ziemlich dünn aufgestellt.
Da steht aber nicht "AB 30 %" sondern "30 %". Deswegen haben wir die Ribbons deaktiviert. Nicht rechtssicher, ebenso wie die falschen Streichpreise, wenn die Eigenschaften-Aufpreise Rabatte bekommen.
Wir auditieren den Shop regelmässig durch Rechtspartner. Bisher hat noch keiner da etwas moniert, das müsste ich wissen. Ich bin mir auch relativ sicher, dass ein "ab" falsch wäre. Wenn man ein Rechtsproblem feststellen würde, würde man vermutlich eine Änderung machen ala "-6-30%". Ich würde das aber auch nicht machen wollen bevor wir müssen: Da kann relativ viel Rechenarbeit bei jedem Kategorie und Startseitenaufruf bei herauskommen, immerhin muss man sich alle Kombinationen für jeden Artikel ansehen, und das multipliziert sich schnell aus. Und dann wird aus sowas schnell ein performancerelevanter Miesepeter.
By the way: Das sich ein Artikelrabatt auch auf Eigenschaften und Attributartikel inklusive der jeweiligen Varianten anwenden lässt wisst ihr oder?
Und was sagst du zur Angabe der UVP? Wenn der Aufpreis rabattiert wird, ist die UVP zu niedrig. Je höher der Aufpreis, desto geringer der berechnete % Rabatt, auch wenn er gemessen an dem richtigen UVP (nicht den vom Shop berechneten falschen )konstant ist.
Wenn der Aufpreis rabattiert wird, ist die UVP zu niedrig. Weil UVP = normaler Vaterpreis zzgl. Rabattierter Aufpreis der Eigenschaft. Je niedriger der Aufpreis, desto geringer die errechnete UVP und der berechnete Ribbon-Rabatt
Jetzt verstehe ich das glaube ich, dafür mangelts mir jetzt adhoc an Wissen. Müsste ich mal unseren Variantengurus vorlegen, bitte ein Ticket.
Ich habe bei mir statt UVP ein "bisher" stehen, sollte aber doch egal sein und bei mir werden vom bisherigen Preis und allen Attributen der Rabatt abgezogen und egal was da ausgewählt wird, der genannte Rabattsatz bleibt immer gleich und richtig. Beispiel: (Link nur für registrierte Nutzer sichtbar.) oder verstehe ich da mal wieder was falsch?
Wie machst du das? Hast du da irgendeine Anpassung für Eigenschaften-Sonderpreise? Das ist doch sonst ein Zirkelbezug der niemals aufgeht: Kamin Grundausstattung alter Preis: 1000,- EUR Sonderpreis 880,- EUR: 12 % Rabatt Aufpreis für Luxusausstattung: 500 EUR Dann würde im Shop angezeigt: Alter Preis 1000+500 = 1500 EUR Sonderpreis bleibt bei 880,- EUR, weil Sonderpreise nur auf den Vaterartikel eingerichtet werden können, also 880,- + 500,- EUR Luxusausstattung= 1380,- EUR. Das sind dann aber nur noch 8 %. Wenn du jetzt den Eigenschaftsaufpreis für die Luxusausstattung auch um 12 % reduzierst auf 440,- EUR, müsste es so sein: Alter Preis: 1000+440 EUR = 1.440 EUR Neuer Preis = 800,- EUR Sonderpreis + 440 EUR reduzierter Eigenschaftspreis = 1.240 EUR Rabatt: 13,9 % statt 12 %. Das Problem ist doch, dass der alte Preis immer schon die reduzierten Eigenschaftsaufpreise enthält und damit der Rabatt nie passen kann, außer wenn eine Eigenschaft 0,- EUR Aufpreis hat. Frage daher: Wie bekommst du das hin, für alle Eigenschaftskombinationen immer 12 % Rabatt anzubieten? Habe bei dir nachgerechnet, scheint zu passen.
der alte Preis ist bei mir immer der Preis ohne optionale Aufpreise. Und ich habe angehakt, dass der Artikel-Rabatt auch bei Attributen genommen wird; also trage ich bei Attributen den Standardpreis ein und der Shop macht was er machen soll