Prawidłowe przeliczanie pola currency

praski

Witam

Mam problem z polem currency.
Dokładnie z przeliczaniem kwot w różnych walutach.
O ile jest jedna waluta - nie zauważyłem problemu.
Gorzej jak jest ich kilka, i każdy z nich ma inny znak części dziesiętnej. Tu obserwuję dziwne (niezrozumiałe przeze mnie) działania.

Problem: Potrzebuję określić z ceny wartość, czyli zrobić przykładowo

list($kwota,$cur_id) = Utils_RecordBrowserCommon::get_value('jakis_recordset',1,'cena'); - standardowe pole currency w rekordsecie. (tutaj przykładowo załóżmy, że $kwota = 88.24 z dokładnością do reprezentacji separatora dziesiętnego, który jest różnie zapisywany)
$ilosc = 1;
$wartosc=$kwota*$ilosc;

I teraz niuanse, które mnie dobijają:
Jeśli jest tylko kwota podstawowa w systemie, to przelicza ok, pomimo tego, że separatorem dziesiętnym dla tej kwoty jest przecinek. (w bazie automatem dla domyślnej waluty zapisywana jest kropka, wiec traktowane jest jako float nawet jeśli jest dopisek __1 w stringu currency)
print_r($wartosc) daje 88.24

Jeśli jest to inna waluta (np drua zdefiniowana w syetemie - przykładowo eu), która ma przecinek jako separator i nie jest domyślna to się zaczynają problemy.
W bazie zapisywana jest domyślnie jako string 88,24__2 (dlaczego nie jako 88.24__2???)

Jeśli teraz wykonamy powyższe, to oczywiście
$wartosc = 88
No bo tak być musi.
Nie było by tego problemu, gdyby baza zapisywała w polu currency tylko prawidłowy separator dziesiętny dla float. Ale tak nie robi, bo RB z jakiegoś powodu podaje przecinek (przy new record).

Nasuwa się pytanie - jak prawidłowo pracować z polem currency aby zawsze móc wykonać działanie $kwota*$ilosc i poprawnie zapisywało się w bazie dla innych walut niż domyślna (moim zdaniem separator dziesiętny powinien być zawsze tak samo zapisywany - czyli ".", a nie ze zmiennym znakiem separatora dziesiętnego)

Miotam się z tym tematem.
Mogę napisać funkcję, która poprawia przecinek na kropkę przy zapisie, ale wolałbym zrozumieć logikę przyjętą dla pola currency i sposobu wykonywania przeliczeń dla różnie zdefiniowanych walut, bo być może z założenia błędnie pracuję z tym polem.

Testuję to na epesi 1.5.5, ale nie widziałem w release notesach do 1.5.6 i 1.6.0 jakichś wzmianek o zmianach w działaniu pola currency.

Wyjaśnicie mi?
Może jakaś mała dokumentacja na WIKI do pola currency?

Pozdrawiam
Praski

ajb

Ok... rozumiem problem i wiem w czym może być problem.

W bazie danych zawsze powinno być zapisane z kropką. Jeśli nie jest to znaczy, że coś jest nie tak. Patrz *** dalej.

Dodałem właśnie złotówki z przecinkiem i w bazie jest zawsze kropka. Jedyne co wg mnie nie działa dobrze to to, że w polu edycji trzeba zawsze używać kropki. Ale gdyby było inaczej, to zmieniając walutę trzeba by zmieniać znak dynamicznie.

Zmianą, która była zrobiona w 2012 roku było to, że przy niektórych lokalach (zmiana języka w EPESI) mapowanie wartości float na string dawało przecinek zamiast kropki. Zostało to naprawione i takie mapowanie powinno dawać zawsze kropkę. Można to sprawdzić w prosty sposób np takim warunkiem

("" . 45.45) === "45.45"

*** Kolejna sprawa to magiczna funkcja \Utils_CurrencyFieldCommon::format_default, która nie wiem dlaczego... ale robi coś złego, bo formatuje walutę nie z kropką, tylko ze znakiem separatora dziesiętnego... To jest sprawa, którą muszę obgadać. Jest ona używana właściwie tylko w modułach premium, m.in. w magazynie, tam mogą pojawić się wartości z przecinkiem.

Najprawdopodobniej zrobię zmiany takie, żeby Ci to działało - tylko muszę jeszcze o nich porozmawiać w zespole.

W wersji 1.6.0 pojawiła się klasa Utils_CurrencyField_Value, której najlepiej używać.
Przykład

$r = Utils_RecordBrowserCommon::get_record( ... );

$raw_value = $r['some_currency_field']; // 123.45__1  ($)

$raw_value_2 = $r['some_currency_field2']; // 45.45__2

$raw_value_3 = $r['some_currency_field3']; // 45.45__1

$val = Utils_CurrencyField_Value::from_string($raw_value);

$val2 = Utils_CurrencyField_Value::from_string($raw_value_2);

$val3 = Utils_CurrencyField_Value::from_string($raw_value_3);

$val->add($val2); // currency mismatch - throws exception

$val->add($val2, false); // do not report error - does nothing

$val->add($val3); // adds values, because currencies match -> 123.45 + 45.45

$val->add_amount(100); // adds amount

$val->format(); // $ 168.90 // in fact: $&nbsp;168.90 // 123.45 + 45.45

$val->to_string(); // 168.90__1

$val->set_amount($val->get_amount() * 10); // 10x more

No to tyle... to zobacze co z tymi błędami i dam znać. Tymczasowo zamieniaj przecinek na kropkę.

Dzięki za zwrócenie uwagi na problem

Pozdrawiam,
Adam

praski

No nie mogłem czekać ;-)

Funkcja Utils_CurrencyFieldCommon::format_default jest rzeczywiście błędna.

Jest zamieniona kolejność w str_replace oraz kolejność kroków przeliczania $v

Jest:

public static function format_default($v, $c=null) {

	if ($c===null) {

		$c = explode('__',$v);

		if (!isset($c[1])) {

			$c = 1;

		} else {

			$v = $c[0];

			$c = $c[1];

		}

	}

	$v = round($v,self::get_precission($c)); //Tu błąd powinno być pod linią poniżej

	$v = str_replace('.', self::get_decimal_point($c), $v); //Tu błąd w kolejności parametrów

	return $v.'__'.$c;

}

Powinna być (moim zdaniem - aczkolwiek błądzić jest rzeczą ludzką)

public static function format_default($v, $c=null) {

	if ($c===null) {

		$c = explode('__',$v);

		if (!isset($c[1])) {

			$c = 1;

		} else {

			$v = $c[0];

			$c = $c[1];

		}

	}

	$v = str_replace(self::get_decimal_point($c), '.', $v);

	$v = round($v,self::get_precission($c));

	return $v.'__'.$c;

}

Pozdrawiam
Praski.

ajb

Wczoraj analizowałem tę funkcję i też wydawała mi się podejrzana.
Zmieniłem ją w podobny sposób jednak trochę inaczej.
Kod na githubie 🙂 Plus jeszcze zmiana jedna, żeby to co ma już przecinek też dobrze było obsłużone przez metodę get_values.

Epesi ENS | Epesi Academy | epesi.cloud PaaS | GitHub

Help Me! | Download from SourceForge