Problems with points and commas in numbers

[30knees]

Some numbers in the store are displayed with a comma and some with a point, eg 20,20 or 20.20. 

When I enter a number, for example for a refund, I often don't know which is correct: the comma or the point. I go with what I see. So if the Stripe module shows me that the total was 70,00, I'll use a comma to enter the refund amount.

When this is wrong and I should have used a point instead of a comma, like it's the case with Stripe, the number gets truncated and my refund of 5,55 becomes 5.00.

Where does this mix of commas and points come from and is there anyway to fix this? 

[e-com]

Numbers in database are stored only with a point.
If any number is a currency amount, it is displayed on backend and frontend according to our settings for that currency.
If we type any number into an input, we always use a point.

[datakick]

Controllers can (and often do) use helper function like Tools::parseNumber to process input values. This allows merchant to enter formatted strings that includes spaces and different separators, for example "$1 012,10".

In core and native modules we try to use these helper methods everywhere user can input values. But of course, there are places we missed. You can file issues for those.  

[e-com]

Tools::displayPrice method displays amounts according to currency format, Tools::displayNumber method can also format for currency.
If we have several currencies in store, e.g. USD and EUR, then once the amounts are with a point and once with a comma.
And there is a bit of confusion with this. We have to report to UN so they unify numbers around the World 😄

[the.rampage.rado]

Then report to USA so they could finally come to the 'normal' world with dates, time and measures. 😄

[30knees]

OK, then the takeaway is that typically I should use a point and if it's related to the core or a native module I can file an issue.

Thanks, all!

One thing that is problematic with this setting below is that different languages have different standards. For example, this is the same number:

EN: 12,000.59

DE: 12.000,59

But the setting below ignores language settings.

4 hours ago, e-com said:

 

[e-com]

25 minutes ago, 30knees said:

But the setting below ignores language settings.

If number is a currency amount, the format from currency is taken. If number is a standard number such as quantity, the setting for language is taken.

[e-com]

55 minutes ago, the.rampage.rado said:

Then report to USA so they could finally come to the 'normal' world with dates, time and measures. 😄

I think President Clinton wanted to implement metric system in US, but met powerful resistance from conservatives.

[30knees]

6 hours ago, e-com said:

If number is a currency amount, the format from currency is taken. If number is a standard number such as quantity, the setting for language is taken.

Yep, but that's wrong because it should not depend on the currency but on the language. 

EN: 12.59 €

DE: 12,59 €

[e-com]

13 hours ago, 30knees said:

Yep, but that's wrong because it should not depend on the currency but on the language. 

EN: 12.59 €

DE: 12,59 €

I found the cause.
Module "Auto Currency Formatter" so messes up the display of numbers for currencies.
- for English US:
€45.59
- for Polish:
45,59 €

I don't use this kind of modules introducing such chaos to the backend interface and I couldn't figure out the reason why to you it displays amounts for currencies like this.

[30knees]

46 minutes ago, e-com said:

I found the cause.
Module "Auto Currency Formatter" so messes up the display of numbers for currencies.
- for English US:
€45.59
- for Polish:
45,59 €

I don't use this kind of modules introducing such chaos to the backend interface and I couldn't figure out the reason why to you it displays amounts for currencies like this.

Interesting, good that you discovered that it causes problems ... but we don't use the module. 🙂