Enterprise Software Design Blog

Multinational companies generally have operations in multiple countries and they have requirement to run transactions with multiple currencies. They need to be able to see the amounts used in transaction (Budgets, sales revenue, sales targets etc.,) in multiple currencies with current and historical exchange rates.

For example, consider a multinational company with head quarters in US having operations in Japan and Europe. The company’s sales budget is determined in centrally in US for all their subsidiaries all over the world. The CEO, based in US will allocate the budget in US dollars to these subsidiaries and the head of Europe and Japan review the sales budgets. The head of Europe and Japan are in their respective countries and will review the sales budget in EURO and Japanese Yen. On the surface, this isn’t a major issue since the software will convert the US dollar to Euro and Yen using current exchange rate. If you scratch the surface you’ll see that currency exchange rate is not constant and it fluctuates almost daily and sometimes it has wild swings. The sales head for Europe cannot be shown different sales budget every day due to currency fluctuations. Conversely there are situations where the CEO needs to see an amount always with current exchange rate. Typically while a transaction is in progress, in this case while the CEO is still planning to allocate the budget, he may want to see the EURO equivalent of the sales budget before publishing to the respective subsidiaries.

This is typical application design issues and the enterprise applications will have following terminologies introduced to address these issue.

• User Preferred Currency: This currency will be associated with every user of the software and it will generally depend on user’s native location. In the example above, CEO will have US dollars as user preferred currency and head of sales for Europe will have EURO as the user preferred currency. The application will always default all amount in user preferred currency.

• Current Exchange Rate: This is the exchange rate for any currency as of today’s date. This information will be available either thru financial institutions (thru Web Services) or application can set default exchange rate within their schema.

• Transaction Exchange Rate: This is the current exchange rate of a day when transaction was completed. The transaction completed date and current exchange rate on that day for all currencies supported will be stored in a transaction exchange rate table in schema. In the example above, when the CEO publishes the sales budget, the date when the sales budget was published and the current exchange rate of all the currencies will be stored in a table as given below

Multi currency design is explained in the process given below.

• The CEO logs in to the system to allocate sales budgets.

• The CEO will see the sales budget in user preferred currency by default, as shown. The CEO will be able to change the currency to other supported currencies and see the amount.

• Once the CEO completes a the transaction by publishing the budget, the amount will be stored in user preferred currency along with transaction date and exchange rate as show below in the transaction schema.

• The Europe sales VP will login to the application to view the budget.

• The application will identify the user preferred currency (i.e. EURO), currency code and transaction date of the sales budget from the transaction schema.

• It will look up the transaction exchange rate table to find out the transaction exchange rate for USD on the transaction date.

• If available, it will apply the transaction exchange rate to the sales budget and will display it to the user as shown below.