Please note: This page was retired in June 2007.

You can find current information from the links below

If you need to buy a license for this specific version, please contact us for availability and pricing.

Other information on this page is shown for historical reference only and may have changed considerably since.

The Currency Exchange Utility offers a variety of features that enhance the component functionality and versatility. Some of the features included are:

• Stores, retrieves, and converts simple and complex currency information
• Allows for manual or automatic approval of currency use
• Handles dynamic or static rates and add on adjustment factors
• Provides rounding and formatting methods
• Supplies batch procedures for currency input and self-sustaining maintenance

The Currency Exchange Utility is also delivered with an end-user application. The main menu additionally embeds a test harness option that allows developers to review some public operations offered by the component and allows for complete verification of the operation's pre- and post- conditions.

Most large businesses are no longer localized to a single area or region, but span geographically across many countries if not worldwide. The computer applications that support businesses must take into account the handling of currency/exchange rates. Because currencies may be dynamic over time, the complexity of currency conversion must be facilitated within the applications. Described below are some basic concepts that are helpful in understanding the Currency Exchange Utility and the approaches it uses.

The base currency is the baseline that other currencies are measured against. It is the set of ratios for all other currency/exchange rates. It may be thought of as the price of money for other currencies. Like all other currencies, the base currency is represented by a name or code value with national or geographical distinction.

The local currency is the standard used for normal business transactions for a particular geographic area/country or because of a particular business practice. Usually, amounts input on a transaction screen are in local currency and are converted to other currencies when needed. Generally, all transactions within a business application consolidate and/or report upward to a single currency, usually the base currency.

Every business transaction involving currency can be reduced to single operations converting an amount from one currency to another, suggesting two currencies. When the base and local currencies are identical, it is conceptually easy to see how the conversion takes place. However, if the "from" and "to" currencies are different than the base currency, the application developer must decide how to determine the conversion factor between the "from" and "to" currencies. One method is to simply apply the single conversion factor between the "from" and "to" currencies (assuming it's available). The second method is to derive the conversion factor from the ratio of the "from" / base and base / "to" rates. Although the first method seems simpler, the second is actually more stable since the relationship of the "from" and "to" currencies and the base currency is usually set over the same time frame and circumstances. Conversely, the conversion directly between the "from" and "to" may tend to vary depending upon the frame of reference. It is this second method that the Currency Exchange Utility implements in its conversions, giving it the broadest possible usage, and as previously mentioned, it is this method in using base currency that provides a uniform set of ratios over the same time frame and circumstances.

Within the functions of the Currency Exchange Utility, the base currency may be "implied" if all transactions within the application system use the same base. The base may also be specifically designated, but is always used in the conversion process. The conversion can be programmatically achieved via one or two operations, depending on the needs of the programmer, but whether the base is implied or explicit, both methods are supported.

As an example of a currency conversion, let us assume that a company in the U.S. takes orders for its products in many different countries. It receives them electronically into its computer ordering system residing in the U.S. It also assumes that the base currency will be U.S. and probably most, in not all, of its reporting will be converted to U.S. currency for management to view. If it receives an order from England to be billed in Italy, it will probably enter the order for the English customer in pounds, then convert the bill-to amount (whatever is shipped) to lira. The conversion from pounds to lira will be based on the U.S. "price" of money, since the ratios of English pounds to US dollars and US dollars to Italian lira is used. If the company has a subsidiary in Germany, and takes an order using the same world-wide ordering system, the conversion from pounds to lira may have a slightly different conversion rate if German marks was its base currency. As long as base currencies are not mixed, conversions can be well defined and consistent.

In many international businesses, multiple currency bases are used. As in the above example, it may be that the regional headquarters is in Germany so that German marks is the base and reporting currency for all of the European operations. Consolidating a report between the US operations (in US dollars) and that of the European headquarters, means an adjustment may need to be made averaging the ratio difference of US dollars to German marks over the time of the reporting period. Conceptually this is not difficult, but implies a higher degree of complexity to build such a function into the reporting process.

It is a business decision as to whether multiple base currencies should be used, and this procedure should be outlined in the currency policy of the company and in the architectural design.

For most application systems the currencies are transferred or downloaded from a government agency, a bureau, a business, or a bank on a regular basis. In some instances, multiple feeds are used to supply different data or different currency rates. The currency source indicates where the currency data came from or how it was derived. The Currency Exchange Utility supports multiple sources of rates/exchange and even allows for the designation of "test" rates.

For most applications a single source of currency rates is enough. For more complex environments, there may be statutory or customer requirements in using a particular source for the currency rates. The application architect must again be careful to keep the application system consistent across sources, similar to the base as previously mentioned. For example, a particular application may get its currency rate information from the Wall Street Journal, though when dealing with the Federal government, it must use the US Treasury Department. Though each may have its base as US dollars, the set of rates from the Wall Street Journal and the US Treasury Department may vary slightly. Hence, the US dollar to Japanese yen rate of exchange may be different (though probably not much) and must be dealt with at the transaction level when different sources are required. Again, the currency policy should outline such requirements at a detail level when using multiple sources. It is important to remember the currency source and base work together in allowing uniqueness and uniformity in conversions.

Currencies and other factors may vary over time. Currencies are "applied" to business objects that may have a life cycle of their own. For example, if we use "order" as our business object, it may have a life cycle of the following indicated by its status.

The business rule of the application may permit the currency/exchange rate of the order to vary its price to that of the base currency. This may be due to wide fluctuations in the local currency, or because the product sold contains an exchange rate for precious metals whose cost changes rapidly in the marketplace. Then the total value of the order when it was drafted/quoted, may not be the same amount as when an acknowledgment of the order is sent to the customer, or when it is finally billed. Depending upon the application need, there may be staging points along the order's life cycle where either the currency used or some other specific data (such as date) must be "stored" to access the currency at that point in the cycle. If the order is partially shipped, the billed portion may "store" the actual currency (its rate or identifier), while the backlogged portion may need only a code and date to compute the backlog value of the order into other currencies. In this case, one or more currencies are involved with a single object and must be associated to the appropriate life cycle state.

NOTE: Unless there are particular reasons to store the currency rates within the business object, it is recommended to use the Currency Exchange Utility to store and retrieve historical rates. The control and batch maintenance portions of the Currency Exchange Utility facilitate the management of currencies over time.

If the business rule is to always bill the amount that was quoted or entered, then a single currency can be used during the whole life cycle of the order. Depending on how you wish to report the amount, you might associate/store the currency (identifier) or relevant data for future or historical access with the business object. Overall, the business rules of the system will determine what and how currencies are used and should include currency rules for the development of all business objects.

When discussing the conversion of any amount, there are two distinct concepts that, though they have little difference in the implementation of the Currency Exchange Utility, have an important difference in the way the conversions are applied in the application. Indeed, a standard must be followed strictly with the architecture of the application to ensure uniform conversions.

A currency rate is the multiplier in converting an amount from one geographical currency to another. An example would be the currency rate of converting US dollars to English pounds. Currency rates are usually determined by overall market conditions. For multi-national corporations, the sale of goods and services is often designated by country (i.e., a local currency rate is established), then rolled upward and converted to a single currency for corporate reporting.

A conversion or exchange rate is often more localized and static to its circumstances. It is usually a one-time event. For example, a business traveler reports his trip expenses to his company and includes the exchange rate he received in converting US dollars to English pounds at a bank. This might be different than the exchange rate at an airport. The rate can be stored with the expense statement since it affects only that transaction at that point in time. Typically, exchange rates will have their information stored with the business object (e.g., the bank exchange rate stored with the expense statement), and do not span across multiple transactions of business objects.

Currency rates and exchange rates are often used interchangeably in discussion. The distinction in this document is to convey conceptual differences in order to recognize them in the applications and handle them appropriately based on application standards. Currency rates of sales orders will probably be handled much differently than exchange rates of expense statements. In other cases there may be little difference in their handling. Both can be used in the Currency Exchange Utility.