Decimal price field sometimes comma / sometimes dot

[Mark Roethof]

Hi there,

We are experiencing inconsistent behavior in how the decimal sign is shown for price fields (for example price field on the Catalog Items, both on list as on form). Sometimes the decimal is a dot (.), sometimes this is a comma (,). Inconsistent as in that this can occur for one user, which has the same Language set, same User preference Language set, same browser, etc..

I also opened a Hi case to investigate this. Though I thought, maybe someone on the community already encountered a situation like this?!

It is reproducible on our Madrid company instance, though also on my Personal Developer Instance which is on New York.

Key is: You have to have an additional Language pack installed 🙂 In our case Dutch.

Steps to reproduce:
If the decimal sign is a dot
- sys_user record, change Country code into Germany, save
- sys_user record, change Language into Dutch, save
- sys_user reocrd, change Country code back into System + change Language back into System, save

If the decimal sign is a comma
- sys_user record, change Country code into Germany + change Language into Dutch, save
- sys_user record, change Language back into System, save
- sys_user record, change Country code back into System, save

Curious if someone already encountered this and how they handled this.

Kind regards,
Mark

---

LinkedIn

[scott barnard1]

Hi the system uses the Locale to determine what decimal separators to use

The biggest influence on locale in the platform is user language on the sys_user record then the country.

So if the system thinks your locale is dutch you will see the dutch separator

In a single language system it only shows 1 separator type based on the default system language.

Then you have the price values in the based sc_cat_item table that are based around the language the developer was using when they created the item. 

You also have issues with locale with some browsers that have multiple languages and their order is not what is needed.

For example my system language is US-EN and I have both EN-GB and EN-US as languages in my browser. It will pick up a locale of en-gb from my user language record but my browser is telling it that En-us has a higher preference so I'll see dollars not £'s

Then you have people modify their language in the general preferences section. This may need a refresh before it displays the language translations however unless the browser believes your locale is the same it will show the currency and separators of the locale.

Regards

[scott barnard1]

http://www.localeplanet.com/support/browser.html

Is a useful site to start your locale query

[Mark Roethof]

Thanks for the info.

Does sound oke, though somehow... even if all settings look the same, sys_user record XML is identical, user preferences are the same, using the same laptop/browser, etc., you could still end up with different decimal notation. Also switching browser or using incognito doesn't make a difference. So it's not something with caching of the browser or something. Really weird.
So what are we missing? Is there still somewhere something else stored in ServiceNow or on database level?

I've also opened a Hi case for this, though no luck so far. We are able to reproduce, also on New York.

Kind regards,
Mark

[Mark Roethof · Accepted solution]

Got an update from HI:

"Solution proposed is :

Hello Mark,

We are placing this issue in Solution Proposed.

Issue:
Decimal price field sometimes comma / sometimes dot

Most Probable Cause:
This issue is documented in PRB1326824 and this is a known error.

Solution Proposed:
According to PRB1326824, the available workaround is:
==================================================================================================================================================================================================
***THIS DOES NOT APPLY TO READ-ONLY FIELDS: SEE PRB1334313 IF HAVING AN ISSUE WITH A READ-ONLY CURRENCY FIELD***

For READ-ONLY CURRENCY FIELD, check KB0751474:
https://hi.service-now.com/kb_view.do?sysparm_article=KB0751474

This problem is under review and targeted to be fixed in a future release. To receive notifications when more information becomes available, subscribe to this Known Error article (KB0751474) by clicking the Subscribe button at the top right of this form.

The workaround consists in creating a Global UI Script ("SNC Workaround for PRB1326824") as listed below. This should be set in a dev instance and activated on a prod instance only after testing.

NOTE: THIS WORKAROUND OVERRIDES AN INTERNAL API AND NEEDS TO BE REMOVED WHEN UPGRADING TO A VERSION THAT ALREADY HAS THE FIX.

***THIS DOES NOT APPLY TO READ-ONLY FIELDS:***

addTopRenderEvent(function() {
if (typeof CurrencyElement !== "undefined") {
CurrencyElement.prototype._extractCurrency = function(currency) {
var currencyParts = currency.split(';');
var localeCode = window.NOW.locale.code.replace(/_/g, '-');
var currencyCode = currencyParts[0];
var value = currencyParts[1].replace(/[^\d-^.]/g,'');
var negPrefix = value.startsWith('-') ? '-' : '';
value = negPrefix + value.replace(/[^\d\.]/g, '');
var amount = Number(value).toLocaleString(localeCode, {
style: 'currency',
currency: currencyCode,
minimumFractionDigits: 2,
maximumFractionDigits: 4,
currencyDisplay: 'code'
});
var replaceChars = "(" + currencyCode + "|\u200F|\u00A0)+";
var replaceRegEx = new RegExp("^" + replaceChars + "|" + replaceChars + "$", "g");
amount = amount.replace(replaceRegEx, '');
return {
amount: amount,
type: currencyCode
};
};
}
});
====================================================================================================================================================================================================

Next Steps:
Please check the given information and test workaround in sub-production first.
To close this case, please click on the Accept Solution button.

Best regards,"