Currency and number formatting

The display of monetary amounts varies from one country to another. Monetary values are usually accompanied by a currency symbol, which can exist in either the local currency symbols (for example,. $, , R$), or ISO 4217 international currency codes (for example, USD, EUR, BRL). Currency symbols may be placed before, within, or after the radix character of the monetary amount, and there may or may not be a space between the symbol and the amount. Although, most countries use the comma or period as the decimal separator in currency, some countries, such as Japan, do not have a currency decimal separator.

The rules for formatting numeric fields are not necessarily the same as the rules for formatting monetary amounts. Cultural formatting of numeric fields differs by country, since different countries use different positive and negative numeric representations for the same amount.

The following list shows several ways to display the same numeric values:

Negative number representation does not have a universal form. Some countries use a leading hyphen to denote negative non-monetary numbers. Some place the hyphen after the number, and some use another symbol altogether. The following list shows several ways to display the number negative fifteen:

Some countries may have more that one official language but only one currency. Canada is a prime example where there is a single currency, Canadian dollar, but two official languages, English and French. It is complex for businesses to operate in multiple currencies. Adding a language element increases this complexity and makes pricing and other currency-related tasks almost unmanageable in the WebSphere Commerce administration tools such as the WebSphere Commerce Accelerator.

A single default currency, which may be used as the basis for conversions or explicit pricing in other currencies, makes these operational tasks clearer and better matches business practices.

Linking a store's default currency to its default language has no valid business relationship and is not a valid currency defaulting method. For example, if you change the language it should not have to mean that you want the currency changed. For this reason, the selection of language and currency are two separate tasks in WebSphere Commerce as shown in the following figure:

consumer direct starter store." />

There is no way to define a one-to-one or one-to-many relationship between language and currency. Any given currency may be related to many languages, for example, Canadian dollar is related to both French and English. Any given language can be related to many currencies, for example, English is related to the US dollar, Canadian dollar, British Pound, and others.

WebSphere Commerce Currency Manager

In WebSphere Commerce, the shopping currency is the currency in which the customer sees all prices. To determine the shopping currency of a customer, the currency engine called the Currency Manager performs the following algorithm:

Note the following when the Currency Manager performs the preceding algorithm:

Currency formatting in WebSphere Commerce is dependent on the following:

This information is required to validate or format a currency. Number formatting is dependent only on the language ID.

The Currency Manager makes all of the formatting information for numbers and currency values available in the WebSphere Commerce instance database. When the WebSphere Commerce instance application server is started, this information is turned into JavaScript and becomes available for use as part of the WebSphere Commerce Tools Framework. Import the web/tools/common/NumberFormat.jsp into your JSP for these JavaScript functions. The functions perform the following tasks:

You need to include the Util.js file in your JSP when you include NumberFormat.jsp.

The following table lists some of the key JavaScript currency and formatting functions:

Task Integer Number Currency
Validate User Input (anything) isValidInteger() isValidNumber() isValidCurrency()
Save (convert to JavaScript number) strToNumber() strToNumber() currencyToNumber()
Display (format a JavaScript number for a given language) numberToStr() numberToStr() numberToCurrency()
German 10.4.98 10. April 1998 10.04.98

If you are using the notebook, wizard, or dialog UI elements, the NumberFormat is already included in the parent frame.

The following example shows a typical JavaScript currency entry form in a tools JSP: 

//requirement ::provide a user input currency entry ...
//prefilling it with the previous value ...
function initializeState(){
document.myForm.myInput.value =
parent.numberToCurrency(currAmount,fCurr,"<%=fLanguageId%>");
}
function validatePanelData(){
if (!parent.isValidCurrency(document.myForm.myInput.value),fCurr,
"<%=fLanguageId%>")){
alert("not valid");
return false;
}
return true;
}
function savePanelData(){
MyCurr=parent.currencyToNumber(document.myForm.myInput.Value,fCurr,
"<%=fLanguageId%>");
parent.put("myCurrLbl",myCurr);
}

A sample validation and format page is available in \commerce\web\tools\sample\. To execute this page launch http://hostname/commerce/tools/sample/validationTest.jsp.

It is highly recommend that you avoid using FormatNumber, FormatCurrency, and FormatInteger. These functions are included in the WebSphere Commerce Tools Framework only for backward compatibility.

FormatNumber and FormatCurrency do the validation first based on the language ID. If you get a primitive numeric format (1000.23) from the WebSphere Commerce Server, the functions return a Not a Number (NaN) value. Furthermore, FormatInteger only accepts primitive numeric integers. As a result, if you have an integer such as 1,000 in the US English language ID, it returns a NaN.

Related concepts

Supporting globalization
Cultural considerations
Localized store assets

Related tasks

Create a globalized store
Add a language or currency to a store archive
Date and time formatting
Name and address formatting

Related reference

Globalization tips
massload utility (Server environment)