Turning on ability to use foreign currency

We have never had to use foreign currency in our EnterpriseOne system in the 6 and 1/2 years of its use here, but now are facing a supplier who really wants us to use only Euro's for their PO's, etc.

Has anyone else turned on foreign currency(ies) after you have existing Production data based on just domestic (single) currency? I'd appreciate it if you know of any gotcha's to watch out for or special processes that must be run to switch on foreign currencies.

Thank you.

Decide what Currency Functionality is Required

· Simple (AA, CA - Account Balances (F0902) CRCX field populated)
· Detailed (AA, CA, XA,YA, ZA - F0902 CRCX field populated)
· Account Balance by Currency (AA, CA - F0902 CRCD/CRCX fields populated)

Setup Steps

Complete the multi-currency setup steps summarized below:
1) Set Up General Accounting Constants
2) Designate Currency Codes
3) Set Up Companies for Multicurrency in Company Numbers and Names
4) Designate Monetary Accounts
5) Designate Address Book Currency
6) Set Up Daily Transaction Rates
7) Review Ledger Types in User Defined Code (UDC) Tables
8) Review Ledger Type Master Table (F0025)
9) Set up Automatie Accounting Instructions (AAIs)
10) Run appropriate Load Domestic Currency Code Programs from the Multi-Currency Advanced Operations.
May also need to run the Change Display Decimals.

NOTE: All records must have a blank currency code prior to running the Load Domestic Currency code
program. It will not complete if any records are populated.

11) Run Annual Close. This updates the balance forward amount in the Account Balances (F0902) file.

It is NOT recommended to deactivate currency once it has been activated.

For Web/JAS Environments

Regenerate all objects from an environment with currency activated. This is done by logging into the environment when starting the generation program.

I think the two biggies usually turn out to be that you can't go back, and how to handle the exchange rates.

Rotsa ruck, Relroy.

Thank you very much for your quick and full response! I'll forward this onto the appropriate people for review and decision.

I can't add to JStooge's excellent task list. Regarding gotchas there are a few things to keep in mind from a technical perspective. There are no doubt more but these are a few I have noticed:

Turning on multi-currency will impact the performance of some processes. The table event rules on certain tables will have more processing to do as functions to handle currency decimals will fire. In addition many financial business functions and NERs will branch to additional logic when currency is enabled.

Some business functions will not behave as expected if you do not pass a currency code when one is provided in the datastructure for the function. I have run into at least one function which returns a number formatted with 0 decimals (when it should return 2 decimals -the default DD definition for the column) if the currency code passed on the datastructure is blank AND multi-currency is enabled.

If you eventually branch beyond Euros and start dealing with currencies that do not use 2 decimal places you need to make yourself familiar with the F0013 table and understand how direct database updates (if you make them) to currency enabled columns should be handled for currencies like Yen and some Middle Eastern currencies. Yen for instance is stored with 0 decimal places. The F0013 table is used to override the default data dictionary value for the column depending on currency.

We are stuck with extra logic to place the decimal point on currency fields until the product is enhanced to use proper numeric fields. Or until the world converts to Quatloos and we can stop worrying about all this currency processing.

Regards,