[2.0.RC2] - Zahlungsaufschlag wird falsch berechnet

[katgirl]

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]

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

[zonky2]

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]

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

[e-spin]

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]

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

[e-spin]

ich suche schon...

[e-spin]

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]

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

[e-spin]

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

[aschempp]

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]

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]

theoretisch, ja. Es gibt dabei zwei Probleme:

1. 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).
2. 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]

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]

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]

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 ;-)