Hallo zusammen, ich schlage mich jetzt schon seit Tagen mit den Variantenaufpreisen herum und schieb schon ziemlich Frust…
Ich möchte was eigentlich ganz simples: ich habe in Summe 5 aufpreispflichtige Optionen (die wiederum untereinander z.T. Abhängigkeiten haben) die ich bestimmten Artikelgruppen zuordnen will. Wegen den Abhängigkeiten untereinander kann ich das Ganze leider nicht einfach über das “Zubehör” machen… Theoretisch ist das ja mit den “normalen” Varianten durchaus möglich, in der Praxis wird das Ganze aber nicht durchführbar sein weil… #1 Aufpreise werden im Backend netto eingegeben…–> ich habe ständig Rundungsfehler (+/- 1 Cent) #2 Es lassen sich zwar Set´s speichern, dies beinhaltet aber nicht die Aufpreise selbst und auch nicht die Abhängigkeiten…heißt für mich bei 900 Artikeln —> 900x Set laden, 900x Aufpreise (jedesmal die gleichen) eingeben, 900x Abhängigkeiten (jedesmal die gleichen) konfigurieren… #3 Bei einer simplen Preisänderung muss man jedesmal in die Konfiguratorvorlage, Preis ändern, Varianten neu berechnen und dann wieder bei den verfügbaren Varianten die Vorauswahl richtig stellen…:-(…warum nimmt man hier nicht einfach den hundsgewöhnlichen Artikelpreis und rechnet die Aufpreise einfach oben drauf? #4 Wenn ich irgendwann mal den Preis einer Aufpreisoption ändern wollen würde müsste ich in jeden Artikel rein und ihn dort explizit ändern samt Neuberechnung der Varianten?!? (und das wieder 900x)… Wenn man in der Praxis nur eine handvoll Artikel hat und am Tag vll. 2 Verkäufe anstrebt mag das so alles funktionieren…für jeden nur einigermaßen laufenden Shop sehe ich “schwarz”… Wie gesagt…ich möchte eigentlich etwas ganz simples und verstehe nicht warum das in SW so umständlich gelöst ist…oder übersehe ich etwas ganz grundsätzliches bzw. habe ich da einen falschen Ansatz? Wie kann ich das von mir angestrebte (s.o.) am besten umsetzen…wäre euch für jede Hilfe dankbar!
Ich nehme mal an das ein SET eine klassische Stückliste ist. Diese gibt es dann in Varianten. Warum überläst man dieses nicht einer Wawi die ein SET als einzelnen Artikel in den Shop transferiert der mit Varianten bestückt ist. Sobald nun ein Teil sich ändern (Preis oder Menge) werden die Stücklistenpositionen neu berechnet und alle Artikel in dennen dieses Teil vorkommt dann im Shop aktualisiert. Die Wawi könnte das machen, Shopware selber tut sich da sehr schwer glaube ich, da Stücklisten so nicht möglich sind (Achtung, ich spreche NICHT von Bundles)
Ich habe die selben Probleme mit Version 4.1.0 vom 2.7.2013 Aufpreise kann man nur mit zwei Stellen hinter dem Komma eingeben. Das bringt bei Nettopreisberechnung mit abschließender Mehrwertsteueraddition immer Rundungsfehler. Warum gibt man nicht einfach zwei Nachkomma-Stellen (4 statt 2)mehr frei? Das würde die Rundungsfehler elimiminieren. In der Datenbank wird wenigstens schon mit drei Nachkommastellen gearbeitet, was aber trotzdem noch eine Stelle zu wenig ist. Ebenfalls ein No-Go ist, das keine Sets für die Aufpreise gespeichert werden können. Bei jedem Artikel sämtliche Aufpreise neu eingeben zu müssen, wenn es immer wieder die gleichen sind, ist echt übel! Ich teste gerade shopware und die Variantenlösung erscheint mir derzeit mehr als unkomfortabel und ich hätte über die tollen Features nicht vermutet, das shopware mit solchen Kleinigkeiten, wie kaufmännische Rundungsfehler, zu kämpfen hat. Ist da denn eine Änderung in Sicht?
Die Summenberechnungen von Shopware sind wirklich schlecht. Kaufmännisch wird unterschieden zwischen Privatkunden und gewerblichen Kunden. Daher müssen auch zwei verschiedene Berechnungen ausgeführt werden: - Privatkunde: Alle Einzelpreise grundsätzlich in brutto. Berechnung von Summen nur mit Bruttopreisen. Die Mehrwertsteuer (enthalten) wird dann aus der Gesamtsumme herausgerechnet. - Gewerblicher Kunde: Alle Einzelpreise grundsätzlich in netto. Berechnung von Summen nur mit Nettopreisen. Die Mehrwertsteuer (enthalten) wird dann auf die Gesamtsumme addiert. Bei shopware wird das alles irgendwie zusammengeschmissen. Die Artikelpreise werden in brutto angegeben, die Aufschläge aber in netto. Das gibt dann immer Rundungsfehler, auch wenn man die Aufschläge auf 3 Stellen anschließend direkt in der Tabelle s_article_configurator_price_surcharges ändert. Komischerweise unterscheiden sich die dort abgespeicherten Werte von den angegeben, wenn man im Backend die Preise mit 3 Nachkommastellen angibt, werden diese trotzdem nicht korrekt in der Tabelle gespeichert, manchmal werden Werte >0 als dritte Nachkommastelle abgespeichert, die aber so im Backend nicht angegeben wurden. Ich werde daraus nicht schlau und kann da auch irgendwie kein System entdecken. Als Notbehelf gegen die Rundungsfehler sollte möglich sein, Brutto und Nettopreise mit mindesten 4 oder besser 5 Nachkommastellen abzuspeichern und damit auch intern zu rechnen und nur die Ausgaben auf 2 Nachkommastellen gerundet anzuzeigen, so funktioniert es bei xt:c Andernfalls ist der shopware shop doch bestimmt stark abmahngefährdet, weil in manchen Fällen der Kunde bei der Rundung den Nachteil hat, da die Gesamtsumme teurer ist, als die einzelnen Angebote. Mir ist bekannt, das ich die Preise der Varianten manuell abändern kann, aber das Programm generiert mir für jeden Artikel mit 3Gruppen 4,4 und 6 Varianten jeweils 175 Variantenprodukte. Das macht doch keinen Sinn, das jedesmal von Hand einzugeben.
Ich habe das Problem der nicht speicherbaren Aufpreise wiefolgt mit Hilfe eines eigenen Plugins gelöst: - Das Plugin leert die Tabelle s_article_configurator_price_surcharges - Das Plugin legt für die "configurator_set_id"s von 1 bis 10000 voreingestellte Werte in die Datenbank (auf Wunsch stets dieselben) Nun wird bereits beim Erstellen jedes neuen Artikels beim Generieren der Varianten alles aus der gespeicherten Vorlage übernommen. Das klappt einwandfrei, bis Shopware speicherbare Presets für Aufpreise zur Verfügung stellt. Wenn ich diese Lösung individuell implementieren soll, einfach melden.
[quote=“RainerF”]Ich habe das Problem der nicht speicherbaren Aufpreise wiefolgt mit Hilfe eines eigenen Plugins gelöst: - Das Plugin leert die Tabelle s_article_configurator_price_surcharges - Das Plugin legt für die "configurator_set_id"s von 1 bis 10000 voreingestellte Werte in die Datenbank (auf Wunsch stets dieselben) Nun wird bereits beim Erstellen jedes neuen Artikels beim Generieren der Varianten alles aus der gespeicherten Vorlage übernommen. Das klappt einwandfrei, bis Shopware speicherbare Presets für Aufpreise zur Verfügung stellt. Wenn ich diese Lösung individuell implementieren soll, einfach melden.[/quote] Ich würde mich sehr freuen darüber, denn so macht das keinen Sinn!
[quote=„RainerF“]Ich habe das Problem der nicht speicherbaren Aufpreise wiefolgt mit Hilfe eines eigenen Plugins gelöst: - Das Plugin leert die Tabelle s_article_configurator_price_surcharges - Das Plugin legt für die "configurator_set_id"s von 1 bis 10000 voreingestellte Werte in die Datenbank (auf Wunsch stets dieselben) Nun wird bereits beim Erstellen jedes neuen Artikels beim Generieren der Varianten alles aus der gespeicherten Vorlage übernommen. Das klappt einwandfrei, bis Shopware speicherbare Presets für Aufpreise zur Verfügung stellt. Wenn ich diese Lösung individuell implementieren soll, einfach melden.[/quote] Ich würde mich sehr freuen darüber, denn so macht das keinen Sinn!