The following sections list rules of the multi-currency functionality for each topic listed.
· An order defaults to base currency unless locked into a foreign currency either manually or because you added a locked-in product to the order.
· A user can manually lock an order into a currency or you can lock it by adding a product with a designated currency.
· A customer can be set up with a default currency (i.e., someone from the UK may have a default currency of GPB). Therefore, when creating orders for this customer, the default currency of the order would be GBP. However, if a product is added to the order, the product lock will override the customer default.
· If an order is locked into a specific currency, then all line items in that order are priced in that currency. If no pricing for that currency is available, then the exchange rate applied to the base currency price determines the price.
· If an order is locked into a foreign currency, that foreign currency becomes the invoice currency for the order. If no foreign currency is locked in, then the invoice currency defaults to the base currency.
· If an order is locked into a foreign currency, then calculation of transactions always starts from the invoice currency. (Receipts are an exception to this rule as explained later.) When the order is not locked into a foreign currency, the base currency is the invoice currency. This is important since the direction of conversion can lead to slightly different rounding rules and the different treatment of exchange rates in general.
· When determining whether a member fully paid his/her order, attention directs to the invoice currency balance. If the invoice currency balance reaches zero and there still remains a balance in the base currency due to rounding issues, the application automatically writes off that amount (which normally equals a penny or two if your base currency is USD).
· Once you lock the order into a foreign currency, it guarantees that price to the customer based on the exchange rate at that time as long as the customer pays in that currency. Any changes to that specific currency’s exchange rate in between locking the currency and the payment transaction are absorbed by your association.
· If the customer owes 100 Euros at the time of the order, you accept 100 Euros no matter what has happened to the exchange rate in between. If there is a difference in exchange rate, the system generates the gain/loss due to currency fluctuation transactions.
· If the order is in USD for $100 and the customer pays in Euros, the customer must pay the equivalent number of Euros to meet the $100 price given the exchange rate at the time of the payment.
· Invoices generate in the currency locked into the order; therefore, if the order is locked in Euros, the invoice displays in Euros. If your organization’s payment handler defines its base currency as US Dollars, the transactions convert to US Dollars for payment handler purposes.
· If an order has been locked in because a locked-in product exists in that order, then the user cannot manually change the currency locked into the order.
· The application maintains exchange rates at the order_detail level based on batch date or system date. If a line item is entered subsequently, that line records its own exchange rate based on the order_detail order date.
Personify uses Banker’s rounding (or Gaussian rounding) with mult-currency. Banker’s rounding is different from standard rounding. Standard rounding is when the value is rounded to the nearest number. Banker’s rounding is when the value is rounded to the nearest even number. Banker’s rounding usually simplifies the rounding process and provides more accuracy.
· When a batch is open during order entry, the exchange rate is based on the following:
· The exchange rate defined in the batch does not determine the exchange rate for the order. For example, if the user overrides the exchange rate for the batch from the default, the exchange rate of a newly created order will be different than the exchange rate for the receipt applied. If a batch is open (with an exchange rate defined) and the order is locked into a foreign currency, then the batch determines the exchange rate. If the receipt is entered in that same batch, the exchange rate on the order and the receipt would be the same.
· If you have a batch open, the batch date determines the exchange rate from the currency table by selecting one active on the date of the batch.
· If you do not have a batch open when you create an order, then the exchange rate is based on the date the order was created against the currency exchange rate tables.
· The application maintains exchange rates at the order_detail level (order line level) rather than at the master order level. That means that if you make an addition to a locked-in order subsequent to the original creation and the exchange rate changed in between this time, then the application captures the new exchange rate at the order detail level for the new line added.
· All calculations including exchange rate calculations start from the invoice currency and convert back to the base currency.
· If you place a foreign receipt against an order where the receipt currency differs from the invoice currency, then the receipt converts to the invoice currency by converting it to your base currency first.
· The exchange date rules follow the same rules as do order dates.
· If a batch is open, the batch date is used.
· When creating a batch, the batch date determines what rate defaults, but you can override the exchange rate defaulted by the system.
· the batch, then the association should use that bank exchange rate as the exchange rate of the batch itself. By doing this, your batch amounts will match the bank statement.
· For real-time transactions to a credit card, you have several possible situations:
· Your merchant ID determines the currency of the transaction regardless of the currency of the customer. The transaction will be in the base currency while the customer will see their transaction in their currency on their own statement. This situation is typical of Internet transactions where the customer is in a different country than the association.
· If your merchant ID is in a foreign currency, then the system will assume the receipt is in that currency. This can make a difference if the order is locked into 100 Euros where you expect 100 Euros in payment. A receipt transaction in base currency may lead to a different rounding or exchange rate discrepancy between the Euro amount due and the Euro amount paid because you are converting in this case from base to Euro rather than the other way around.
· The merchant ID for the credit card account determines the currency of the transaction.
· A merchant ID with a foreign currency gets treated as a foreign currency in Personify.
· A merchant ID in base currency gets treated as a base currency transaction in Personify regardless of how the member sees it on his/her statement. A member in France ordering something from the US where the US association uses a base currency merchant ID sees their transaction in their own currency even if Personify treats it as base currency.
· Credit card refunds occur in the currency of the merchant ID that originally handled the credit card.
· When applying foreign credit cards’ deferred receipts to an Inventoried product order, the exchange rate used is not dictated by the exchange rate of the batch where you created the deferred receipt. Instead, the exchange rate comes from the batch used by CCP610 when the deferred receipt converted to an actual receipt.
· If you select the Auto-Create Batch option for CCP610, then the application pulls the exchange rates from the system exchange rates defined in the Currency Setup screen.
· If you want to change the exchange rates for the conversion of deferred receipts, do not use the Auto-Create Batch option. Manually create the direct batch and modify the exchange rates to be used. Then enter that batch number in the Direct Batch parameter for CCP610.
· When defining a batch that will include foreign currency amounts, you must use a receipt type referencing that currency. This then associates, for credit cards, into the appropriate merchant ID for the different currencies.
· When creating a batch receipt mapped to a currency other than the base currency, the exchange rate defaults to the exchange rate active on the Currency Setup screen at the time of the batch date.
· The exchange rate on the batch is for the payment currency only.
· Credit card receipts refund to the same credit card through the same merchant ID and therefore must process in the currency of the original receipt.
· If the customer pays the association 100 Euros, they will only receive a full refund of 100 Euros regardless of whether or not the exchange rate changed between the time of the receipt and the time of the refund.
· Cash refunds, where no credit cards are involved, are always refunded in base currency.
· The application captures the exchange rate for a foreign currency refund at the time of the refund and creates any necessary gain/loss transactions at the same time. If the exchange rate changed between the initial transaction and the refund, the base cash refunded may differ from the base cash received.
· If the payment was not done by credit card or the credit card is no longer valid, Personify will refund in base currency. Personify can generate vouchers only in base currency and these are transferred to the AP system (assuming it is in a single currency). The assumption is that the checks will be done against a standard cash account in the base currency through the association’s AP system.
· Different rules apply if you lock the order in a currency and the refund is in that same currency versus created a refund when the payment currency and order currency differ:
· If the invoice currency and the payment currency are both in the same foreign currency, then the customer receiving a full refund will receive the same amount in the foreign currency as was the original receipt. For instance, in a Euro invoice with 100 Euros paid, the customer can receive 100 Euros regardless of any change to the exchange rate in between.
Any
difference between the exchange rate at the time of the order line and
the exchange rate at the time of the refund reflects in the order as a
currency correction.
· Whenever the receipt applied is not in the same currency as the order (receipt is unapplied), the AR/FAR_TXN amount is calculated using the exchange rate of the original receipt.
Any
difference between the exchange rate at the time of the receipt and the
exchange rate at the time of the refund reflects in the order as a currency
correction.
A receipt transfer consists of two transactions:
the From Order transaction and the To Order transaction.
For both transactions, the following rules apply:
1. The overriding rule is that the currency of a receipt remains constant through the process. For example, once a Euro at one exchange rate, always a Euro at that same exchange rate.
2. The exchange rate at the time of the original receipt follows the receipt through the transfer process rather than using a current exchange rate at the time of the transfer.
· For From Order transactions, the following rules apply:
o May be a full transfer in which case the entire gain/loss amount from the original receipt transaction reverses.
o May be a partial transfer in which only some of the gain/loss amount is reversed and, as stated before, this will be calculated based on the original exchange rate of the original payment and not based on the current exchange rate at the time of the transfer.
· For To Order transactions, the following rule applies:
o There may or may not be a gain/loss transaction on the new order depending on the configuration of that order. The receipt transferred to the new order should be treated just as a new receipt against that order would be treated.
· When reversing a receipt (i.e., NSF check), the application reverses any gain/loss transactions associated with the original receipt.
Gain or loss transactions automatically created due to changes in exchange rates occur because of the following reasons:
· A payment is made against an order where the order has its currency locked in, the invoice currency is the same as the payment currency, and the exchange rate changes between the date of the order and the date of the receipt.
· A refund is created where the current exchange rate is different from the exchange rate recorded on the order.
· When you place a flat-dollar coupon or discount against an order that is locked in a foreign currency, then the dollar amount defined for that coupon converts to the locked-in currency based on the exchange rate captured for the order.
· Like flat-dollar discounts and coupons, the application defines the shipping charges in base currency. The calculation of these orders converts them to the invoice currency from the base currency.
· Financial reports typically appear in the association’s base currency; however, some reports exist that can show the invoice currency as well.
· Personify supports the uploading of lockbox files with alternate currencies than the base currency. You need to define the currency and exchange rates contained in the file.
· When refunding an amount to a member’s credit card, the system refunds to the customer in the payment currency and a base credit is created using the exchange rate in your application at the time the refund occurs, not the exchange rate at the time the initial order occurred.
· When your merchant account collects credit card funds from a customer, the amount denominates from his/her account in the currency of the receipt type, not the base currency equivalent. In other words, if you have a credit card receipt type mapped to British Pounds, and the association collects on a 1000 GBP invoice, the customer sees 1000 GBP on his/her credit card account. The customer will always see their credit card transaction in their own currency.
· Since merchant accounts collect actual receipt currency for credit card orders, the actual receipt currency totals are checked against the batch control totals before the application posts a Deferred Posting Batch.
· When applying foreign credit cards’ deferred receipts to an Inventoried product order, the exchange rate of the batch where you created the deferred receipt does not dictate the exchange rate used in the transaction. Instead, the exchange rate comes from the batch used by CCP610 when the deferred receipt converted to an actual receipt.
The Personify application supports two options for your organization to handle multiple currencies on the Web.
· Multiple portals where each portal supports a single currency
· One portal to support multiple currencies
Different rules apply for the different scenarios available. For instructions on configuring either option, please see to Configuring Multi-Currency for e-Business.
If your organization’s website is set up to include multiple portals to accommodate multiple currencies, then the following rules apply:
· When pricing displays and/or calculates on the Web, the system uses the default currency of the website and performs the following:
· If a price exists in the currency of the website, that price is used.
· If a price does not exist in that currency, the system uses the exchange rates you set in Personify to calculate a price in that currency based on the Organization ID’s default currency price.
· If the product is locked in a different currency than the website, then the product should not display.
· Orders from a given portal automatically lock into the currency of the portal and not the currency of your organization.
· The system does not support the concept of a customer’s default currency. The currency of all orders from the e-Business site are that of the e-Business site’s Web.config file regardless of the default currency of the Organization.
If your organization’s website is set up with one portal to accomodate multiple currencies, then the following rules apply:
· If a user changes his/her preferred currency via the Web, the preferred currency associated with that user changes in the back-office as well.
· Only those Receipt Type currencies associated with the e-Commerce batch appear as options for the customer to select as his/her Preferred Currency.
· Only those Receipt Type currencies associated with the e-Commerce batch appear as options for the customer to submit payment with when finalizing an online sale.
· If a product is locked into a currency, the price will display in the preferred currency; however, customers can not purchase the product in the preferred currency. The checkout page forces them to either remove the item from the cart of pay the entire order in the locked currency.
· If you pre-define a product in multiple currencies and a customer selects one of these currencies as his/her preferred currency, the website displays the pre-defined product total rather than converting it as it will the other products.
· The Personify - ChangePreferredCurrency module does not work with the Online Membership Renewal (M01) form. If customers begin entering information on the M01 form and then try to change their preferred currency, they lose any information already entered in M01.