updating Japanese Yen exchange rate issue

[caborela88]

Hi,

I notice that whenever i update the currency for Japanese Yen, it always round up to an integer, all decimal are zero.
how can i get the exchange rate for JPY with full decimal.

Thanks in advance!


ZC 1.5.5f

[Note: remember to include site URL, ZC version, list of plugins, PHP version, etc ... read the Posting Tips shown above for information to include in your post here. And, remove this comment before actually posting!]

[caborela88]

got it
admin/currencies.php

replace this

if ($decimal_point == '0' || in_array($code, array('JPY', 'HUF', 'TWD'))) {

to the following.

if ($decimal_point == '0' || in_array($code, array('HUF', 'TWD'))) {

then on currecny set decimal to 2 and update currency.

[DrByte]

But ... JPY doesn't have decimals, so it should always be rounded to an integer.

[mc12345678]

But ... JPY doesn't have decimals, so it should always be rounded to an integer.

True, but when/where should the currency rounding take place? Shouldn't the rounding to the nearest integer take place more at the end of the calculation of the final price rather than at the start of the potential conversion?

An example, if the currency exchange rate was 1 USD = 107.87 YEN, then the conversion rate store would be 108 when rounded. Using that stored conversion rate, a product that cost 100 USD would be 10800 Yen as compared to 10787 Yen (an additional cost to the customer of 13 Yen). In reverse if the item was priced by Yen to be 10787 and the exchange rate of 108 to 1 was used, then the store would incur a cost of 0.12 USD bringing in only 99.88 USD. This is of course without consideration of currency conversion costs that also can be factored into the process.

Of course I recognize that the difference is small, but seems that it can add up over multiple purchases and even more so with higher prices.

Caborela88, could you perhaps explain why this discrepancy is an issue for the store in question?

[caborela88]

True, but when/where should the currency rounding take place? Shouldn't the rounding to the nearest integer take place more at the end of the calculation of the final price rather than at the start of the potential conversion?

An example, if the currency exchange rate was 1 USD = 107.87 YEN, then the conversion rate store would be 108 when rounded. Using that stored conversion rate, a product that cost 100 USD would be 10800 Yen as compared to 10787 Yen (an additional cost to the customer of 13 Yen). In reverse if the item was priced by Yen to be 10787 and the exchange rate of 108 to 1 was used, then the store would incur a cost of 0.12 USD bringing in only 99.88 USD. This is of course without consideration of currency conversion costs that also can be factored into the process.

Of course I recognize that the difference is small, but seems that it can add up over multiple purchases and even more so with higher prices.

Caborela88, could you perhaps explain why this discrepancy is an issue for the store in question?

mc12345678, you just pointed out the exact issue i am having. However, if the currency is HKD to JPY, then the rounded up issue will be more significant difference.

on your example you purchase US$100, after the conversion, the price is just 0.12 USD difference.

But if i use HKD to JPY for purchasing same amount, it will be USD$ 3.6 difference.

USD 100 ~ HKD 780

HKD 1 = 13.5 JPY (but it rounded up to 14).
buying HKD 780 will be 10,920 Yen.

10,920 - 10,530 = 390 Yen (Which is USD 3.6)

[mc12345678]

To try to be sure that we're all on the same page, is the store's primary currency then either of YEN or HKD and trying to do business in those two currencies? I mean, I would think ultimately the solution should support a store being in any currency converting to any currency, but...

[caborela88]

the default currency for me is HKD. the prices i got from vendors are in JPY, then i convert the price to HKD.
Customers can only pay in HKD. The solution above can solve all i need in my case.

Dealing with JPY with decimal in price may get trouble or be denied by some payment gatway, this was my experience before. therefore, it should be round up to an integer somewhere before payment.

[David R]

I keep running into these same problems. We just updated to the latest Zen Cart version, and I'm trying to figure out where to fix it again.
We display in Japanese Yen for most customers, on a default currency of USD.
-> To fix the fact that admin won't properly store the six decimal places of conversion factor the database is set up for, I can go in with PHPMyAdmin and enter the correct six-digit value directly into the field. If I try to enter it through the Admin currencies module, all the decimal places are stripped, making the conversion highly inaccurate. But the direct entry fixes that problem.
-> To fix the fact that it doesn't calculate properly at various points in checkout is a problem I'm having to sort again. As pointed out above, it applies the final display number of decimal places (zero) to the components of the calculation which need to have six digits past the zero, resulting in inaccurate calculations.
I enter an item in the shopping cart that displays (correctly) a ¥9,995 value on the product page, and when it hits the cart, it is now ¥10,001. The error multiplies up from there.
In the past I was able to track down where the round() function was being used too early in the process, and fix that. I haven't fixed it in this version yet. If anyone reading this knows where that echoed $product['productsPriceEach'] gets calculated, that would be good information to have. :-)

[mc12345678]

By no means a direct answer to the last question above.

If you still have the code of "the previous version" (a backup) and you still have a copy of an original code set of the Zen Cart provided code of that same version, THEN take note of the differences between those two. Any changes made to the original code set to get to the code that was being used was either made out of necessity or desire. In most cases, the code is very similar though there was some relocation of some code.

My point is, if it worked before having been modified away from a provided version, then it should be able to be made workable again by relatively applying the same changes.

As to 6 decimal limitations (if I understood correctly), in most cases javascript/jQuery limits to 4 decimal places and there generally is a truncation to either 4 decimal places or the number of decimals associated with the currency in use (which as I thought I understood that the Yen didn't have a decimal place per se). At least that's what I recall of the processing the last time I was trying to step through the currency system with the various currency requirements in mind (a few years ago). Right or wrong, those are some things that may need to be reviewed, revised, or addressed.