Business Scenarios for Enabling International Transactions
Being able to handle transactions in multiple currencies is rapidly becoming an important feature in the e-commerce marketplace. Business-to-business (B2B) transactions may involve a buying organization doing business in a number of transaction currencies, a supplier using multiple transaction currencies, and retail transactions where the buyer will only do business in a single currency, but the supplier is capable of handling multiple currency formats.
There are several types of multicurrency transactions:
- Supply chain/B2B exchange using a negotiated conversion for all currencies
- Supply chain/B2B exchange using market-based conversion for all currencies
- Supplier/B2C (business-to-consumer) using a market-based conversion for a single currency
In the following fictional scenarios, Contoso, Ltd., is based in the United States and maintains all of their financial accounts in U.S. dollars. Contoso conducts business with suppliers who trade in currencies other than U.S. dollars, and has retail users who make purchases on their Web site using a variety of currencies. Each of these types of international transactions (supplier and retail) have their own requirements. For example, retail users only make purchases using a credit card. The currency conversion rate for the user is determined when the institution that provided the credit card converts the transaction. This is an example of a "spot rate" conversion.
Conversely, the rate for Contoso suppliers in some of the scenarios is set before transactions ever take place. Contoso agrees to a conversion rate for a set period of time with each of their suppliers. When Contoso takes an order for a product supplied by a company with an alternate currency, the conversion rate that is applied to the transaction is determined by the rate agreement. This is an example of a "fixed rate" conversion.
Assumptions for All Scenarios
Supporting Multicurrency Transactions
Tracking Multicurrency Transactions
Multicurrency Transaction Issues
Assumptions for All Scenarios
The following assumptions apply to all the international transaction scenarios:
- All catalogs on the site use a single default currency (the currency that the site uses to transact with their bank).
- The user does not need to use multiple currencies on a single order. In other words, the user does not need to purchase item "A" in U.S. dollars and item "B" in Yen within the order.
.gif "Ee799533.note(en-US,CS.20).gif")
Note
- It is recommended that the Web site use a third party accounting system to handle conversions. The Order Sitelet included in the Commerce Server SDK uses a simple example method that is not recommended for production code.
Scenario 1:
- A single user makes a purchase through www.contosoretail.com using market rate currency conversion. The transaction takes place in U.S. dollars; however, the user sees an approximate price displayed in Yen as well.
This is the simplest and most common international retail or business-to-consumer transaction, where a buyer and an e-commerce site may not use the same default currency, but they want to do business together. A user visits the English language www.contosoretail.com Web site, whose default currency is U.S. dollars. The user selects Yen as the preferred currency. As the user browses through the site, all the prices will now be shown in Yen.
All Yen prices are marked "approximate" on the site because the user may be charged a slightly different amount based on the conversion rate charged by the user's bank. This rate can be approximated but will never be known exactly until the transaction is completed. When the user submits the order, the user is given an approximate total in the preferred currency and the exact value in the default currency of the site.
When www.contosoretail.com receives payment from the user's bank, they receive U.S. dollars. When the user's bank charges the user, these dollars are converted to Yen. The exact cost in Yen is not known until that moment.
Scenario 2:
- A single user makes a purchase through a single site (www.contosoretail.com) using market rate currency conversion.
- www.contosoretail.com re-sells the goods of another company or companies using a negotiated conversion.
The user's transaction with www.contosoretail.com is the same as in the first scenario; however, there is an additional transaction (or transactions) because www.contosoretail.com is now a re-seller, and must purchase goods on demand from a supplier.
The supplier of goods to www.contosoretail.com uses Swiss Francs as their default currency, and www.contosoretail.com and the supplier have agreed upon a set conversion rate. The benefit to having a set conversion rate is that www.contosoretail.com knows exactly what it will be charged for every transaction with the supplier. The bank does not own the conversion between the supplier and www.contosoretail.com, as it does between www.contosoretail.com and the user.
In this scenario, there can be more than one supplier, and each supplier may use a default currency that is different than either the re-seller or the buyer's default currency.
Scenario 3:
- A single user makes a purchase through www.contosoretail.com using a market rate currency conversion.
- www.contosoretail.com re-sells the goods of another company or companies using a market rate currency conversion.
The user's transaction with www.contosoretail.com is the same as in the first and second scenario.
This scenario differs from the second scenario in that the supplier's transaction with www.contosoretail.com is determined by the market rate at the time of the conversion. Note that this can occur at a number of points during the life of the transaction, for example, when the supplier invoices www.contosoretail.com or when www.contosoretail.com remits payment to the supplier.
The user, www.contosoretail.com, and the supplier all may use different currencies. The banks are responsible for the conversion rate. This means that www.contosoretail.com does not know what it will be charged for the transaction until after the transaction has occurred.
It is important to note that in all three of these scenarios the user does not know precisely what conversion rate will be applied to the purchase until the purchase is complete and the bank has billed the customer. Because of this, all prices displayed on the e-commerce site should be marked as "approximate."
Supporting Multicurrency Transactions
The conversion rates that are applied to a multicurrency transaction, and managing the costs associated with these transactions, are key to businesses success. Commerce Server 2002 does not address the entire lifecycle of a multicurrency transaction from a business perspective, as this would require a fulfillment and/or accounting system. Instead, intrinsic support for third party fulfillment and accounting systems is provided.
The Business Processing Pipeline System in Commerce Server 2002 addresses this through the following elements:
- The ability to specify and track the currency the user of the e-commerce site wants to use.
- The ability to track the conversion rate applied to an order.
To support this functionality, Commerce Server 2002 assumes the following:
- Catalog prices must be stored in the default currency of the e-commerce site.
- The Order Processing pipeline always runs in the default currency of the e-commerce site.
- Currency conversions happen external to Commerce Server 2002, and they will always be in the form Settlement = Default Currency * Conversion. Where Settlement is the amount paid or owed by the purchaser of goods.
- The Data Warehouse, and by extension Analysis, will always store data and report data in the default currency of the site, because all data is grouped by site.
Tracking Multicurrency Transactions
The following table shows the data the Business Processing Pipeline System tracks. The Business Processing Pipeline System tracks the data for each transaction that goes through the pipeline. This data will be stored on the order form and ultimately in the orders database.
| Field name | Placement | Description |
|---|---|---|
| billing_currency | Order Form Header | The default currency of the site. |
| supplier_currency | Line-item | The default currency of the supplier supplying the goods to www.contosoretail.com. |
| buyer_currency | Order Form Header | The preferred currency of the user. |
The following table shows the data that is not tracked natively by the Business Processing Pipeline System, but should be tracked by a third party fulfillment and/or accounting system.
| Field name | Description |
|---|---|
| Conversion rate | The multiplier used for converting the default currency for the site to the currency accepted by a member of the supply chain. |
| Conversion type | Whether the conversion was a static (contract) rate, or dynamic (bank specified) rate. |
| Conversion time | The time at which the conversion rate was locked in by the bank. In the case of a static conversion, this should always be the time at which the order was accepted for fulfillment. |
| Contract ID | The ID of the contract specifying the conversion rate, which is only used in the case of a static conversion. |
Multicurrency Transaction Issues
The following are issues related to multicurrency transactions:
- As mentioned above, it is possible that the converted line items displayed on the site do not match the total cost billed to the user.
- Discounts currently are not capable of handling multiple currencies.
- Currently, there are no credit card companies or banks that will split one transaction into different currencies, so all bookkeeping/conversions will have to be done internally on the site.
- If you want to use ads and discounts in multiple languages, you must recreate each ad/discount in the appropriate language.
See Also
International Scenario Summary
Copyright © 2005 Microsoft Corporation.
All rights reserved.