[2.0.RC2] - Zahlungsaufschlag wird falsch berechnet

isotope / core

Core repository of Isotope eCommerce, an eCommerce extension for Contao Open Source CMS

https://isotopeecommerce.org

135 stars 107 forks source link

[2.0.RC2] - Zahlungsaufschlag wird falsch berechnet #877

Open katgirl opened 10 years ago

katgirl commented 10 years ago

Möchte ich bei PayPal-Zahlungen einen Aufschlag von 3.5% nehmen, weil dieses die Gebühren bei PayPal sind, sollten diese natürlich auch die Versandkosten berücksichtigen. Denn sonst muss ich die PayPal-Gebühren dafür selbst tragen.

aschempp commented 10 years ago

Bisher ist es leider nicht möglich, dass Zuschläge sich auf Zuschläge erheben...

zonky2 commented 10 years ago

Hallo Andreas, kannst Du mal ein Statement abgeben, wie die (geplante) Überarbeitung des Blocks "Regeln" aussehen wird und ob das in 3.x auch kommen wird...

aschempp commented 10 years ago

Aktuell gibt es noch keinen Plan, wie das aussehen wird. Der entsteht erst wenn wir uns damit beschäftigen...

e-spin commented 10 years ago

Ich meine, man wird an der Stelle nicht umhin kommen, die Reihenfolge der einzelnen Berechnungsschritte einstellen zu können.

Wenn ich mich recht erinnere, ist das z.B. in Magento der Fall

aschempp commented 10 years ago

Gibts davon (in Magento) ein Beispiel bzw. was zu sehen?

e-spin commented 10 years ago

ich suche schon...

e-spin commented 10 years ago

hier ganz gut beschrieben für die Preisregeln (denke ich) https://www.youtube.com/watch?v=2QO3fOh1_i8

beachte "Priorität der Regel" ca. bei 3:21

e-spin commented 10 years ago

oder so http://blog.muench-worms.de/eine-bessere-ubersicht-bei-magento-katalog-preisregeln/

e-spin commented 10 years ago

habe nochmal in Oxid nachgesehen: da gibt es die Reihenfolge (Priorität) nur bei den Versandkosten(-Regeln) - bei den Rabatten nicht

aschempp commented 10 years ago

Scheinbar gibt es in Magento keine "Reihenfolge der Berechnung". Das einzige was ich gesehen habe war die Option, ob der Rabatt auf Versand angewendet werden soll. Was aber in Isotope nicht so einfach ist...

zonky2 commented 10 years ago

hmmm - o.k.

dann habe ich das vllt falsch verstanden - mit Magento habe ich aktuell keinen Shop (mehr) laufen.

aber um den Kreis zu katgirl zu schließen - wenn die Berechnungsmodule für Rabatt, Versand usw. so aufgebaut sind, dass sie eine konsistente Schnittstelle haben (Input>Output), so sollte doch (theoretisch) ein individueller Berechnungsablauf möglich sein... - oder?

z.B. [Warenkorb] V [Produktgutscheine] V [Zwischensumme] V [Kundennachlass] V [Zwischensumme] V [Versandkosten] V [Kosten für Zahloptionen]

aschempp commented 10 years ago

theoretisch, ja. Es gibt dabei zwei Probleme:

wir wissen nicht welche Zuschläge vorhanden sind. Jeder Entwickler kann weitere Zuschlagsoptionen programmieren (z.B. eigene Rabatte oder ein Konfigurations-Zuschlag, haben wir auch schon gemacht).
Da wir nicht wissen welche Zuschläge es gibt, ist es auch schwer deren Position zu bestimmen.

Stell dir folgendes vor: Sollen wir irgendwann den Versand an mehrere Adressen unterstützen (kann Amazon zum Beispiel), dann würden ja mehrfache Versandkosten anfallen. Wie positionierst du die dann?

zonky2 commented 10 years ago

bisher kenne ich das bei Amazon so, dass ich eine Bestellung an eine Adresse senden kann aber nicht Position 1-5 an Adresse A und 6-8 an Adresse B

m.E. musst Du die Position nicht wissen - die kann der Admin ja einstellen

d.h. man kann auch sowas "zusammenklicken"

z.B. [Warenkorb] V [Produktgutscheine] V [Zwischensumme] V [Kosten für Zahloptionen] V [Versandkosten]

aschempp commented 10 years ago

Ich dachte Amazon kann das, es gibt aber auf jeden Fall Shops die das können (ist ein Magento Feature).

Dass das der Admin konfiguriert ist schon klar, aber jeder Gutschein kann ja wieder an einer anderen Position stehen...

zonky2 commented 10 years ago

zu 1.) Habe nochmal zu Magento gesucht: der kann das m.E. auch nur wie die meisten Shops eine bestellung an eine Adresse aber mehrere Adressen (zur Auswahl) möglich.

zu 2.) ... genau! Deshalb "muss/müsste" der Admin ggf. auch mehrere Gutscheinblocks in den Berechnungspfad einpflegen. In den Blocks müsste dann über die Regeln definiert werden, ob bei dem gerade anstehenden Kauf hier was passiert oder nicht.

Als gedanklicher Schnellschuß müssten die Module im Prinzip zwei Sachen können: a) vorhandene Preise wie Produktpreise oder Versandkosten beeinflussen (z.B. Rabatt auf Produkte bzw. Gutschein auf Versandkosten) b) neue Zuschläge erzeugen (z.B. Versandkosten) ... und wie "Legosteine" immer aufeinander passen ;-)

zonky2 commented 10 years ago

ich habe bei dem Artikel http://www.kassenzone.de/2014/02/20/das-beste-shopsystem-2014-erwartung-vs-wirklichkeit/ noch einen interessanten Screenshot zu IBM WebSphere Commerce gefunden, bei dem die Regeln offensichtlich sehr flexibel aufgebaut sind https://www-304.ibm.com/connections/files/app#/file/da3acec6-05e1-448c-b293-7344c9a56ae8 - ganz so heavy mus es ja nicht gleich sein ;-)