wir haben einen Artikelstamm im ERP-System, welcher für ein Produkt verschiedene Preise abhängig von der Währung hat, jedoch unabhängig von einem statischen Wechselkurs.
D.h. kurz gesagt: Ich möchte, dass währungsspezifische Preise existieren ohne Bezug zu einem fixen Umrechnungskurs.
[B]Hat hierfür jemand einen Lösungsvorschlag?[/B]
Ich dachte bereits an einen Subshop pro Währung (wir setzen die EE-Version ein), allerdings ist der Warenkorb nicht shopübergreifend und bei einem Switch von GBP zu EUR müsste der Kunde seine Waren erneut in den Warenkorb legen.
Hi Jens,
habt Ihr eine Lösung für Euer Problem gefunden?
Ich stehe gerade vor der identischen Aufgabe.
Erweitern der Artikeltabelle um weitere Preisfelder ist ja erstmal kein Problem. Aber die Auswirkungen auf Versandkostenberechnungen, Rabattregeln usw. scheinen mir auf Anhieb extrem komplex…
Das hilft leider nicht - selbst wenn`s für die CE-Version wäre.
Das Modul arbeitet ebenfalls mit Umrechnungsraten, nur daß diese automatisch aktualisiert werden.
Jens und ich brauchen allerdings in jeder Währung komplett voneinander unabhängige Preise.
Ganz simpel: die Kunden je nach Währung in den Kundengruppen ‘Preis A, B, C’ reinpacken. GGf. dies beim Umschalten der Währung automatisieren.
Fall diese Preisgruppen (oxpricea, …) benötigt werden, kann man die Preisfelder als i18n-Felder deklarieren (Datenbank).
Am Beispiel oxarticles.oxprice
ALTER TABLE `oxarticles`
ADD `OXPRICE_1` double NOT NULL;
… und oxdelivery.oxaddsum
ALTER TABLE `oxdelivery`
ADD `OXADDSUM_1` double NOT NULL
/tmp-Ordner leeren.
Natürlich geht dass mit so ziemlich allen Datenbankfeldern (zB. oxarticles.oxpricea). Wahrscheinlich sind weitere Felder notwendig (zB. oxpayment.addsum).
Auch das Backend scheint da ohne Änderungen mitzuspielen.
Nachteile:
[ul]
[li]Errechnete Einträge (zB. oxarticles.oxvarminprice) gehen nicht.
[/li]Da dies auch nicht mit oxpricea usw. geht, sollte es auch keine weiteren Probleme machen - es sollte so die Min-Summe des Standartpreises angezeigt werden - [B]testen[/B]!!!
[li]Dies ist Sprachabhängig und nicht Währungsabhängig.
[/li]Man bräuchte also ein Modul, welches anhand von der Sprache die entsprechende Währung aktiviert oder umgekehrt.
[li]Wie die Bestellungen im Admin aussehen, habe ich mir auch nicht angeschaut - ggf. macht oxorderarticles so Probleme - hier sollte der Preis IMHO nicht i18n sein. Ggf. muss man dafür ein Modul schreiben.
[/li][/ul]
Also: testen, testen, testen (siehe oxvarminprice, Bestellungen oder das autm. Umschalten der Kundengruppen).
Hallo Markus,
interessante Idee - danke für die umfangreiche Antwort!
Eine Kopplung an die Sprache kommt bei uns allerdings nicht in Frage.
Da wir europaweit verkaufen, aber nicht alle Sprachen aller Zielländer unterstützen, muss der Kunde unbedingt nach Belieben zwischen Sprachen wechseln können.
Der Brite hat z.B. die Kombination Englisch - Britische Pfund,
der Belgier: Deutsch oder Französisch (oder eben auch Englisch) - EURO,
der Pole: Englisch - Szloty
usw.
Sprache und Währung müssen also leider zwei unabhängige Dinge bleiben.
Wie auch immer, ist nur ein Ansatz - Oxid kann man da nach Wünschen erweitern…
Denke mir , dass man zur Not ein Modul (pro Tabelle - Core-Klasse) schreiben kann, welches die Preisfelder nicht anhand der Sprache zieht, sondern anhand der Währung zieht. Dann sollten aber im Backend anpassungen notwendig sein…
Vlt. die Kundengruppen Price A usw erweitern.
[QUOTE=MBa;69167]
Denke mir , dass man zur Not ein Modul (pro Tabelle - Core-Klasse) schreiben kann, welches die Preisfelder nicht anhand der Sprache zieht, sondern anhand der Währung zieht.
[/QUOTE]
Daran werde ich mich wahrscheinlich noch in dieser Woche versuchen; scheint der Weg der Wahl zu sein.
[QUOTE=MBa;69167]
Dann sollten aber im Backend anpassungen notwendig sein…
[/QUOTE]
Stimmt. Zur Not darf das aber auch alles “unsichtbar” über die mysql-Tabelle laufen. Die Preise der Varianten kommen am Ende per Import aus der Warenwirtschaft; dann muß ohnehin niemand mehr manuell im Backend hantieren.
Hab jetzt mal testweise mit Erweiterungen für Szloty (PLN) begonnen (Standardwährung sind EUR).
Dazu zunächst in oxarticles 4 neue Spalten ergänzt:
[ul]
[li]oxprice_pln[/li][li]oxpricea_pln[/li][li]oxpriceb_pln[/li][li]oxpricec_pln[/li][/ul]
Alle natürlich wie die Originalspalte als “Double”.
Dann schnell ein Modul erstellt mit einer Kopie der Funktion getGroupPrice aus core/oxarticle.php und diese entsprechend angepasst:
protected function _getGroupPrice()
{
// set price depending on currency:
// get active currency
$oCurr = $this->getConfig()->getActShopCurrencyObject ();
$sCurr = $oCurr->name;
switch ($sCurr)
{
case "EUR":
$dPrice = $this->oxarticles__oxprice->value;
break;
case "PLN":
$dPrice = $this->oxarticles__oxprice_pln->value;
break;
}
$oUser = $this->getArticleUser();
if ( $oUser ) {
if ( $oUser->inGroup( 'oxidpricea' ) ) {
switch ($sCurr)
{
case "EUR":
$dPrice = $this->oxarticles__oxpricea->value;
break;
case "PLN":
$dPrice = $this->oxarticles__oxpricea_pln->value;
break;
}
} elseif ( $oUser->inGroup( 'oxidpriceb' ) ) {
switch ($sCurr)
{
case "EUR":
$dPrice = $this->oxarticles__oxpriceb->value;
break;
case "PLN":
$dPrice = $this->oxarticles__oxpriceb_pln->value;
break;
}
} elseif ( $oUser->inGroup( 'oxidpricec' ) ) {
switch ($sCurr)
{
case "EUR":
$dPrice = $this->oxarticles__oxpricec->value;
break;
case "PLN":
$dPrice = $this->oxarticles__oxpricec_pln->value;
break;
}
}
}
// #1437/1436C - added config option, and check for zero A,B,C price values
if ( $this->getConfig()->getConfigParam( 'blOverrideZeroABCPrices' ) && (double) $dPrice == 0 ) {
switch ($sCurr)
{
case "EUR":
$dPrice = $this->oxarticles__oxprice->value;
break;
case "PLN":
$dPrice = $this->oxarticles__oxprice_pln->value;
break;
}
}
return $dPrice;
}
Jetzt noch im Backend in den Einstellungen eventuell hinterlegte Umrechnungsraten für alle Währungen auf 1.00 setzen (damit der ausgelesene Preis nicht später noch irgendwo umgerechnet wird).
Ich befürchte, jetzt muß ich mich noch weiter durchwühlen. Z.B. basieren die Parameter für Versandkostenberechnung in oxdelivery noch alle auf einer fixen Shopwährung plus Umrechnungsraten…
[QUOTE=floko;69262] Z.B. basieren die Parameter für Versandkostenberechnung in oxdelivery noch alle auf einer fixen Shopwährung plus Umrechnungsraten…[/QUOTE]
Ganz simpel: die Kunden je nach Währung in den Kundengruppen ‘Preis A, B, C’ reinpacken. GGf. dies beim Umschalten der Währung automatisieren.
.[/QUOTE]
und wie kann ich festlegen, dass Kunden, die mit $ zahlen nur die Preise aus Gruppe A angezeigt bekommen und Kunden, die mit € zahlen den regulär eingetragenen Preis angezeigt bekommen?
ich hole mal diesen etwas angestaubten Thread wieder nach oben.
Wir stehen vor einer ähnlichen Herausforderung und zwar soll es pro Land (Sprache) individuelle Preise geben, erstmal nur EUR, später auch GBP und USD.
Ich wollte mal nachfragen, ob es in der Zwischenzeit weitere Ansätze/Lösungen gibt?
