Currency format

[BeeSide]

I cannot set the currency format. I want comma as decimal separator.

[BeeSide]

I added the Danish language and now it works.

Only thing is I prefer to prefix the ISO code. I.e. "DKK 123,45" instead of "123,45 DKK".

[moy2010]

Hum, I'm facing this same issue after migrating from prestashop to thirtybees.

I recognize that it may be helpful to automatically set the currency format based on the customer's location as in your example of the euro zones but, sometimes this will not be the case.

Wouldn't it be better to let the user decide if this will be set automatically or manually, just as the other language/zone related parameters?

[Siteboost]

I agree with moy2010 on this one. I really miss the manual format and spacing options! Maybe you could add the option to format currencies in the country settings? This would make it possible to keep different formatting of e.g. the euro depending on user locale while still having maximum control as webshop owner/administrator.

[dynambee]

It does seem like having an easy way for ~~customers~~ site owners to determine the currency format for each country would be a nice touch. Even though a given country may have an "official standard" for currency format it's quite possible that multiple standards are used in practice and/or depending on the region of the country.

Edit: As noted. No idea what I was thinking.

[dynambee]

@mdekker said in Currency format:

The format depends on the locale (so both country + language). We thought that CLDR would be perfect for this since it has all the combos. Perhaps using that as a basis, but allowing for an override per language/country combo might be a better idea?

This sounds perfect to me.

[moy2010]

Indeed. The simpler, the better.

Most users will value the simplicity of the settings but, leaving open the option to customize it for the rest of us :).

[yaniv14]

@mdekker I have a new shop that I can't go live unless I can display the price without decimal '1050' instead of '1500.00' I've tried modifying displayPrice & commerceguys/intl but with no luck. Can you try point me to a solution? I don't mind having it as an ugly patch because this shop is only for Israel with only one country/currency/language Thanks

[Havouza]

So the setting in Preferences/General Number of dicimals will not help?

[Havouza]

Just tested in my shop and it only work in BO. Strange

[Traumflug]

@yaniv14, can you make a screenshot or two? "without decimal ‘1050’ instead of '1500.00’" sounds, uhm, odd.

Another thing to look at is Smarty/HTML code producing these numbers. I've seen rounding code in some templates. Like {$price|round} or similar.

[Havouza]

@Traumflug I think it is just a typo. 1050 instead of 1050.00 It is strange because there is two places where you can set decimals. In Preferences/General where you can set the number of decimals and in the currency itself where you can set using decimals yes or no. I can imagine there is quite a lot of currencies where decimals is not used

[Traumflug]

It is strange because there is two places where you can set decimals. In Preferences/General where you can set the number of decimals and in the currency itself where you can set using decimals yes or no.

... and inside templates.

[Havouza]

But I use the default one and change in any of those two places dont change prices in the FO. Setting decimals to 0 set the price including tax in the BO without decimals, no other change.

[Havouza]

Pity I have no PS shop up anymore so I cant compare

[dynambee]

Proper decimal place control is required for Japan, China, and Korea. Not the current main focus of 30bz perhaps but all are huge eCommerce markets.

[Occam]

@mdekker said in Currency format:

Hi BeeSide,

The currency format is now automatically adapted to the visitors locale (language + country). This, because e.g. the euro can be displayed in several ways in the euro countries.

Is there a reason why you want to change the decimal separator in your locale?

Despite the fact that this does not work properly yet, I'm afraid this is the same logical error like in PS 1.7. If the currency format does no longer depend on the currency but on language and country, every currency will be displayed the same way for the customer, as soon as he chooses a language. This causes problems. Some examples:

Language: German, Currency: Euro Currency display: 1. Austria: € 399,10 2. Germany: 399,10 € 3. Switzerland: 399.10 €

Language: German, Currency: CHF/FR Switzerland: CHF 399.10 or 399.10 FR

Language: French, Currency: FR Switzerland: FR 399.10 or 399.10 FR

Language: German, Currency: USD thirty bees: 399,10 $ PS 1.5 - 1.6: $ 399.10 (with or without blank after curreny sign depending on chosen option)

Next you should consider the thousands seperator: Switzerland: inverted comma USA, GB, Canada (English), Israel etc: comma Germany, Belgium, Denmark, Italy, Sweden etc.: dot or blank Canada (French): blank ... and so on.

And btw there is no special language for Switzerland, Austria or GB. (Try to import for example German(CH) and the customer will meet a 95% English shop language.) So it actually makes sense to restore the former behavior with options currency format and blank. A real improvement would be to replace the format options by a free input field stored in a new db table for every currency format you want to define.

[yaniv14]

In my case the format is just fine (the thousand separator, symbol location and symbol space is perfect). The only thing that I need is to get rid of the decimal points. The shop owner want to show only round numbers not floats (399 and not 399.00).

[Traumflug]

If you're going to work on this, don't forget very small amounts, which are currently almost impossible. For example, electronic resistors can cost less than half a cent, 0.0042 Euros. This results in a displayed price of 0.00, unless one raises the number of digits for all prices, even the 100-Euro ones.

A great solution would format prices as you suggested, but add a digit for each zero right of the decimal for prices < 1.

[Occam]

@mdekker Sounds good, but I really doubt how to manage this by just using the configuration table. This may be ok for a predefined currency pattern, but you would need a db field to store the different patterns. In general I'd agree not to touch the db schema, but in this case it would be helpful to redefine the format field in tb_currency from tinyint(1) to varchar(12).

[Traumflug]

In that case you would have to allow more decimals for the currency.

Works technically, but poor appearance. Having so many digits on single items means one currently has them everywhere, even in the cart: ```none 1000 Resistor 4k7 ohms € 4.2000 2000 Resistor 1k ohms € 8.4000 1 TV set € 230.0000 2 SD card 32 MB € 15.4000

Total € 253.8400 ``` ==> "OMG, this TV has a 7-digit price!"

Stores selling such stuff: about all shops selling electronic components.

[Traumflug]

But if you want more than that, you will have to alter some logic. [...] Heck, PayPal and Stripe are always limited to 2 decimals, no matter what.

Yes, absolutely. That's why I mentioned this topic: number of digits shouldn't be carved in stone and may be different for distinct items or the total price.

Similar situation with fuel prices: a liter diesel costs 1.109 Euros and these three digits to the right of the decimal are displayed at product presentation, kept during multiplication (9 liter = 9.981, not 9.90 or 9.99), still rounded on the bill (9 liter = 9.98), before payment gets processed.

[Traumflug]

Another thing to keep in mind is that some markets, e.g. Switzerland, don't round to 0.01, but to 0.05: none 1.00 => 1.00 1.01 => 1.00 1.02 => 1.00 1.03 => 1.05 1.04 => 1.05 1.05 => 1.05 1.06 => 1.05 1.07 => 1.05 1.08 => 1.10 1.09 => 1.10 1.10 => 1.10

[dynambee]

@Traumflug said in Currency format:

Another thing to keep in mind is that some markets, e.g. Switzerland, don't round to 0.01, but to 0.05:

And then there is Canada where cash payments are rounded to 0.05 but credit/debit card payments are not.

When rounding a cash payment the final total is rounded, not each item calculation.

[wakabayashi]

@mdekker said in Currency format:

@wakabayashi How do you handle the Swiss situation?

You mean the rounding with 0.05? Well we just define our prices. But when it comes to vouchers, its indeed problematic. We haven't any real solution for it. We just avoid percentage reduction as much as possible...

[Havouza]

@mdekker will it show up in 1.0.2?