This chapter contains information on preparing for base currency conversion using the PeopleSoft Currency Conversion Utility and discusses:
Conversion of effective-dated tables.
Impact of the conversion "As of Date" on effective-dated tables.
Synchronization of effective-dated related language tables.
Exchange rate conversions.
Note. Because the Currency Conversion Utility conversion processes are very complex and deal with the conversion of extremely important financial data throughout your system, PeopleSoft strongly recommends that you contact PeopleSoft Global Services (PGS) for assistance in using the Currency Conversion Utility.
Before you run any currency conversion processes, we recommend that you complete a thorough analysis of your base currency conversion requirements and understand exactly what Currency Conversion Utility processes convert. Once you have determined your organization's currency conversion requirements, you can determine how to meet your base currency conversion requirements.
Each base currency conversion project has unique requirements, but this document presents some general guidelines for setting up your system for base currency conversion. These guidelines include information on product line and application conversion approaches, conversion setup requirements, and pre- and post-conversion considerations and tasks.
We assume that anyone who converts base currency using the Currency Conversion Utility has a solid understanding of the following:
PeopleSoft databases and products.
PeopleSoft record structures and relationships.
PeopleSoft Application Designer.
PeopleSoft Application Engine.
Structured Query Language (SQL) and how to build and use SQL queries.
How PeopleSoft applications handle currencies.
How PeopleSoft applications use base currencies.
Also before you run any Currency Conversion Utility conversion processes, you should thoroughly understand how the utility performs certain conversion tasks. Understanding how the Currency Conversion Utility determines which data to convert can help you determine some of your basic conversion criteria, such as your conversion As Of Date and how much historical data to include in your conversion.
Because the Currency Conversion Utility's conversion processes are based on rules developed by each PeopleSoft application that is affected by the base currency conversion, the conversion approaches used by each application vary.
The amount of historical data converted by the Currency Conversion Utility depends on the product line and the applications installed on your system.
For some process groups, you can specify any As Of Date (past, present, or future). For these process groups, this gives you the flexibility to convert not only current and future-dated rows of data, but also historical data residing in your system.
Converting the base operating currency in a PeopleSoft application generally involves the following phases:
Analysis.
Conversion.
The following sections describe some basic guidelines for the phases, tasks, and steps involved in a base currency conversion.
Note. The steps outlined here are intended to be general guidelines only and are not intended to represent a comprehensive base currency conversion project plan. Every site has a unique implementation.
The initial phase in currency conversion usually involves a thorough analysis of conversion requirements to determine which business units, currencies, and PeopleSoft products need to be converted. This phase usually involves answering the following questions:
How extensively have the installed products been customized?
What pre-conversion tasks will need to be performed?
When will the actual currency conversion take place?
What other business decisions or regulatory requirements may need to be accounted for that may affect the conversion?
At a high level, the analysis phase involves completing the following steps:
If required, define the new base currency.
If your new base currency is not yet defined as a currency in your system, add the new currency definitions. If you have set up the new currency, ensure that the proper exchange rates have been established prior to conversion.
Determine which PeopleSoft applications are installed.
This information determines the Currency Conversion Utility conversion processes you need to review, as well as required pre- and post-conversion steps.
Select a conversion As Of Date.
Carefully review your conversion requirements to determine a conversion As Of Date that is appropriate for your organization. This date is particularly important for effective-dated records.
Review all conversion tasks.
Review your conversion tasks for both the Currency Conversion Utility and the affected installed applications. Include a baseline test prior to conversion.
Note. For more information about application-specific conversion tasks, please contact PeopleSoft Global Services (PGS).
Determine database sizing requirements for the conversion, particularly as they relate to the space required for the temporary work records and the audit detail records.
Thoroughly analyze your system and conversion requirements to determine how much of your system resources can be allocated for conversion. This analysis involves a number of factors, including how many applications will be converted, how many open items or transactions will be converted, what database platform you are using, whether to store detailed audit trails for converted data, and so forth.
Analyze customizations and conversion readiness.
Prior to conversion, analyze any system customizations to determine how they might affect PeopleSoft Currency Conversion Utility processing. Depending on the number of system customizations, you may need to modify the PeopleSoft Currency Conversion Utility or associated processing to accommodate these changes.
Determine reporting customization requirements to accommodate the new currency.
Determine if you need to modify any reports to accommodate the post-conversion data.
The second phase of base currency conversion normally involves determining the steps required to perform the actual conversion of the base operating currency. Because this conversion phase may take place at a different time from the analysis phase, you may need to revalidate some of the analysis steps before the actual conversion takes place.
At a high level, the conversion phase involves completing the following steps:
Perform setup tasks pending from the analysis phase.
This step involves procedures such as setting up the new base currency, backing up your production database, creating a copy of the production database for conversion testing, and so forth.
Revalidate customization analysis and determine that the conversion readiness steps have been completed.
Identify any changes made to your system since the analysis phase, and ensure that all the pre-conversion requirements are satisfied. This step could also include another baseline test.
Review any customizations to Currency Conversion Utility process groups, conversion rules, and exception processes.
Review any additions, deletions, or modifications to the conversion processes associated with the PeopleSoft Currency Conversion Utility to ensure that no additional modifications are required.
Test Currency Conversion Utility conversion processes on affected applications.
Perform pre-conversion tests on each of the affected applications to determine if the Currency Conversion Utility conversion processes, whether run as delivered or customized, convert your system data as expected.
Make modifications based on the results of testing, if necessary.
Make any additional adjustments to the conversion processes and retest.
Test reporting.
Confirm that the appropriate reports continue to run properly after conversion.
Do a system backup.
Perform a complete system backup just prior to conversion.
Run the Currency Conversion Utility conversion processes.
Use a step-by-step conversion checklist for running all the appropriate Currency Conversion Utility process groups.
Perform post-conversion processes.
Use a checklist of the post-conversion tasks for appropriate applications.
Perform additional post-conversion functional testing. (Optional.)
This step includes any additional post-conversion functional testing.
In general, the conversion rules and exception processes for effective-dated tables cause the Currency Conversion Utility to insert new rows during conversion rather than update existing rows. This means that the Currency Conversion Utility conversion processes for effective-dated tables preserve the maximum amount of historical data in your tables after conversion because they won't overwrite historical data. For some conversion records, however, it's more appropriate for the Currency Conversion Utility to update (convert) the current effective-dated row instead of inserting a new current row during conversion.
Most conversion processes are designed to convert records on or after the As Of Date you specify on the Currency Conversion Utility run control.
Each process group definition includes a Dates Allowed field that specifies what conversion As Of Date you can select at run time. This will vary by process group. Some process groups restrict you to selecting only the current date as the conversion As Of Date at run time. Others allow you to specify any date.
Selecting an As Of Date requires a careful analysis of your business requirements, particularly if you want to specify a historical As Of Date, where the conversion date is less than the current system date. While you may want to convert historical data, you should be aware of the implications of converting historical effective-dated data.
The following scenarios demonstrate the ways in which the As Of Date affects how the Currency Conversion Utility converts data in effective-dated tables. In general, if you want to retain the maximum amount of current, effective-dated data in your system after conversion, use an As Of Date that is in the future, but which is close to the system date at the time you convert the data.
Warning! If you use a current or past date as your conversion As Of Date for effective-dated tables, some of the current rows in those tables may be updated. If the current row has an effective date that is the same date as the conversion As Of Date, and no effective sequencing is defined for that conversion record, then the Currency Conversion Utility updates that row instead of inserting a new row.
For all these examples, assume that there is an effective-dated table with the following combination of past, present, and future rows:
January 1, 2001
January 1, 2003
July 1, 2003
October 1, 2003
January 1, 2004
In the following example, the German deutsche mark (DEM) and the French franc (FRF) are the From Currencies (the original base currencies for the business units being converted). The European Union euro (EUR) is the To Currency (the new base currency for both business units).
In addition, the following example uses an As Of Date that is less than the current date.
System Date (current date) |
April 1, 2003. The current system row is January 1, 2003, meaning the record's current effective date is set at January 1, 2003.. |
As Of Date |
December 31, 2002 (a historical As Of Date). |
Conversion Process |
The Currency Conversion Utility uses January 1, 2001 as the conversion current row and inserts a new converted row with an effective date of December 31, 2002. Future-dated rows (January 1, 2003 and beyond) are updated (converted). |
Impact |
Historical data converts, but current information is lost. |
The following shows how the table looks after conversion when using this As Of Date scenario. Values inserted or modified by the Currency Conversion Utility are in italics.
Pre-Conversion Date |
Pre-Conversion Amount |
Pre-Conversion Currency |
Post-Conversion Date |
Post-Conversion Amount |
Post-Conversion Currency |
Jan. 1, 2001 |
500 |
DEM |
Jan. 1, 2001 |
500 |
DEM |
Newly inserted row |
Dec. 31, 2002 |
250 |
EUR |
||
Jan. 1, 2003 |
2000 |
FRF |
Jan. 1, 2003 |
500 |
EUR |
July 1, 2003 |
2200 |
FRF |
July 1, 2003 |
550 |
EUR |
Oct. 1, 2003 |
2400 |
FRF |
Oct. 1, 2003 |
600 |
EUR |
Jan. 1, 2004 |
2600 |
FRF |
Jan. 1, 2004 |
650 |
EUR |
In this scenario, the table no longer contains the original currency code and amounts for rows after the conversion As Of Date (Jan. 1, 2003 and beyond). This may be an issue for historical and statutory reporting purposes.
In the following example, the German deutsche mark (DEM) and the French franc (FRF) are the From Currencies (the original base currencies for the business units being converted). The European Union euro (EUR) is the To Currency (the new base currency for both business units). We provide example conversion rows for FRF.
In addition, the following example uses an As Of Date equal to the current date.
System Date (current date) |
April 1, 2003. The current system row is January 1, 2003, , meaning the record's current effective date is set at January 1, 2003. |
As Of Date |
April 1, 2003 (current date) |
Conversion Process |
The Currency Conversion Utility uses January 1, 2003 as the conversion current row and inserts a new converted row with an effective date of April 1, 2003. Future-dated rows (July 1, 2003 and beyond) are updated (converted). |
Impact |
No historical data is converted. |
The following shows how the table looks after conversion using this As Of Date scenario. Values inserted or modified by the Currency Conversion Utility are in italics.
Pre-Conversion Date |
Pre-Conversion Amount |
Pre-Conversion Currency |
Post-Conversion Date |
Post-Conversion Amount |
Post-Conversion Currency |
Jan. 1, 2001 |
500 |
DEM |
Jan. 1, 2001 |
500 |
DEM |
Jan. 1, 2003 |
2000 |
FRF |
Jan. 1, 2003 |
2000 |
FRF |
Newly inserted row |
April 1, 2003 |
500 |
EUR |
||
July 1, 2003 |
2200 |
FRF |
July 1, 2003 |
550 |
EUR |
Oct. 1, 2003 |
2400 |
FRF |
Oct. 1, 2003 |
600 |
EUR |
Jan. 1, 2004 |
2600 |
FRF |
Jan. 1, 2004 |
650 |
EUR |
In the following example, the German deutsche mark (DEM) and the French franc (FRF) are the From Currencies (the original base currencies for the business units being converted). The European Union euro (EUR) is the To Currency (the new base currency for both business units). We provide example conversion rows for FRF.
In addition, the following example uses an As Of Date that is greater than the current date.
System Date (current date) |
April 1, 2003. The current system row is January 1, 2003, meaning the record's current effective date is set at January 1, 2003.) |
As Of Date |
December 31, 2003 (future date) |
Conversion Process |
The Currency Conversion Utility uses October 1, 2003 as the conversion current row and inserts an additional row for that row with an effective date of December 31, 2003. Future-dated rows (January 1, 2004 and beyond) are updated (converted). |
Impact |
The Currency Conversion Utility doesn't convert historical or current data. |
The following shows how the table looks after conversion using this As Of Date scenario. Values inserted or modified by the Currency Conversion Utility are in italics.
Pre-Conversion Date |
Pre-Conversion Amount |
Pre-Conversion Currency |
Post-Conversion Date |
Post-Conversion Amount |
Post-Conversion Currency |
Jan. 1, 2001 |
500 |
DEM |
Jan. 1, 2001 |
500 |
DEM |
Jan. 1, 2003 |
2000 |
FRF |
Jan. 1, 2003 |
2000 |
FRF |
July 1, 2003 |
2200 |
FRF |
July 1, 2003 |
220 |
FRF |
Oct. 1, 2003 |
2400 |
FRF |
Oct. 1, 2003 |
2400 |
FRF |
Newly inserted row |
Dec. 31, 2003 |
600 |
EUR |
||
Jan. 1, 2004 |
2600 |
FRF |
Jan. 1, 2004 |
650 |
EUR |
Note. Scenarios 2 and 3 are similar. Specifying a future As Of Date of June 30, 2003, or any date before July 1, 2003, in Scenario 3 would have the same net result as the current operation of Scenario 2.
Because many effective-dated tables have different current rows, there are other considerations for selecting a conversion As Of Date. If you select a past As Of Date for a process group, some of the affected tables may fall into both Scenario 1 (where the conversion date is earlier than the As Of Date) and Scenario 2 (where the conversion date is equal to the As Of Date).
Because of this possibility, we recommend that, prior to conversion, you research the effective dates of the current rows on the tables to be converted. This helps you to determine an As Of Date that preserves the level of historical detail to comply with internal auditing needs and any external regulatory reporting requirements.
The Currency Conversion Utility conversion As Of Date may have a significant impact on PeopleSoft reports used for regulatory or internal reporting, particularly if you are converting historical data. We recommend thoroughly evaluating your reporting requirements before converting historical data.
When the Currency Conversion Utility inserts a new row with a new effective date into an effective-dated table that has an associated related language table, the two tables may become unsynchronized. To keep the original table and the related language table synchronized, the Currency Conversion Utility calls an exception process after converting the record to insert a new row into the related language table with the correct effective date. This ensures that the original table and the related language table remain synchronized.
When creating new rules, be sure to call the related language synchronization exception process after any conversion rule that inserts new rows into an effective-dated table that also has a related language table.
If you are using an exception process instead of a rule to insert a new row into an effective-dated table that also has a related language table, be sure to do a direct call to the related language synchronization exception process after the initial exception process runs.
The following sections demonstrate how this type of exception processing works.
The JOBCODE_TBL table:
SETID |
JOBCODE |
EFFDT |
SURVEY_SAL |
CURRENCY_CD |
ADM |
1500 |
1/1/1999 |
400 |
CAN |
ADM |
1550 |
1/1/1999 |
300 |
DEM |
The JOBCODE_LANG table:
SETID |
JOBCODE |
EFFDT |
LANG_CODE |
ADM |
1500 |
1/1/1999 |
INE |
ADM |
1550 |
1/1/1999 |
GER |
The Currency Conversion Utility inserts a new row for the selected conversion row (DEM) with the new effective date, converted amount, and currency code (EUR).
Rows inserted by the Currency Conversion Utility are in bold. Old (pre-conversion) current rows are in italics.
The JOBCODE_TBL table:
SETID |
JOBCODE |
EFFDT |
SURVEY_SAL |
CURRENCY_CD |
ADM |
1500 |
1/1/1999 |
400 |
CAN |
ADM |
1550 |
1/1/1999 |
300 |
DEM |
ADM |
1550 |
1/1/2004 |
900 |
EUR |
The JOBCODE_LANG table:
SETID |
JOBCODE |
EFFDT |
LANG_CODE |
ADM |
1500 |
1/1/1999 |
INE |
ADM |
1550 |
1/1/1999 |
GER |
The first exception process synchronizes the exception date of the unconverted row in the JOBCODE_TBL.
Rows inserted by exception process 1 are in bold. Old (pre-conversion) current rows are in italics.
The JOBCODE_TBL table:
SETID |
JOBCODE |
EFFDT |
SURVEY_SAL |
CURRENCY_CD |
ADM |
1500 |
1/1/1999 |
400 |
CAN |
ADM |
1500 |
1/1/2004 |
400 |
CAN |
ADM |
1550 |
1/1/1999 |
300 |
DEM |
ADM |
1550 |
1/1/2004 |
900 |
EUR |
The JOBCODE_LANG table:
SETID |
JOBCODE |
EFFDT |
LANG_CODE |
ADM |
1500 |
1/1/1999 |
INE |
ADM |
1550 |
1/1/1999 |
GER |
The second exception process inserts new rows into the JOBCODE_LANG related language table with the correct effective date for both the converted row and unconverted rows on the JOBCODE_TBL.
Rows inserted by exception process 2 are in bold. Old (pre-conversion) current rows are in italics.
The JOBCODE_TBL table:
SETID |
JOBCODE |
EFFDT |
SURVEY_SAL |
CURRENCY_CD |
ADM |
1500 |
1/1/1999 |
400 |
CAN |
ADM |
1500 |
1/1/2004 |
400 |
CAN |
ADM |
1550 |
1/1/1999 |
300 |
DEM |
ADM |
1550 |
1/1/2004 |
900 |
EUR |
The JOBCODE_LANG table:
SETID |
JOBCODE |
EFFDT |
LANG_CODE |
ADM |
1500 |
1/1/1999 |
INE |
ADM |
1500 |
1/1/2004 |
INE |
ADM |
1550 |
1/1/1999 |
GER |
ADM |
1550 |
1/1/2004 |
GER |
After the conversion rules and exception process, the tables are synchronized and all rows (converted and unconverted) have the same effective date. Rows inserted by the exception processes are in bold. Old (pre-conversion) current rows are in italics.
The JOBCODE_TBL table:
SETID |
JOBCODE |
EFFDT |
SURVEY_SAL |
CURRENCY_CD |
ADM |
1500 |
1/1/1999 |
400 |
CAN |
ADM |
1500 |
1/1/2004 |
400 |
CAN |
ADM |
1550 |
1/1/1999 |
300 |
DEM |
ADM |
1550 |
1/1/2004 |
900 |
EUR |
The JOBCODE_LANG table:
SETID |
JOBCODE |
EFFDT |
LANG_CODE |
ADM |
1500 |
1/1/1999 |
INE |
ADM |
1500 |
1/1/2004 |
INE |
ADM |
1550 |
1/1/1999 |
GER |
ADM |
1550 |
1/1/2004 |
GER |
The following SQL statement is an example of a query that could be used to determine if you have any records that may require an exception process to synchronize effective-dated related language tables with conversion records.
SELECT RD.RECNAME, RD.RELLANGRECNAME FROM PSRECDEFN RD WHERE RD.RELLANGRECNAME <> '' AND RD.RECNAME IN (SELECT DISTINCT R.RECNAME FROM PS_EO_CURRCNV_RULE R WHERE (EFFDT_PROC_CD = '3' OR EFFDT_PROC_CD = '4')) AND 'EFFDT' IN (SELECT RF.FIELDNAME FROM PSRECFIELD RF WHERE RF.RECNAME = RD.RECNAME)
The PeopleSoft Currency Conversion Utility uses rate multiplier and rate divisor values to convert currency amounts. When the Currency Conversion Utility converts a taxation currency to a base currency, the utility must not only convert the taxation amount to the base amount, it must also convert the old rate multiplier and rate divisor values to the new rate multiplier and rate divisor values used to convert the new combination of currencies.
The following examples of rate multiplier and rate divisor conversions are based on the following assumptions and conversion formulas:
Run control exchange rate |
This value is calculated when you enter From Currency, To Currency, rate type, and effective date values on the Currency Criteria run control page. This Exchange Rate field value dictates the converted rate multiplier and converted rate divisor values. |
Converted rate multiplier |
The formula for the new rate multiplier varies based on whether the From Currency or the To Currency is being converted. This is the formula used to derive the converted rate multiplier when converting the From Currency.
This is the formula used to derive the converted rate multiplier when converting the To Currency
|
Converted rate divisor |
1. This value is usually 1 because the exchange rate is in the rate multiplier, or numerator. |
Converted amount |
|
Conversion Run Control Parameters |
|
Before conversion:
Taxation Currency |
Taxation Amount |
Base Currency |
Base Amount |
Rate Multiplier |
Rate Divisor |
USD |
100 |
FRF |
500 |
5 |
1 |
After conversion:
Changes are in bold.
Taxation Currency |
Taxation Amount |
Base Currency |
Base Amount |
Rate Multiplier |
Rate Divisor |
USD |
100 |
EUR |
83.33... |
0.83333... |
1 |
The following formulas are used to perform the conversion:
Converted Base Amount |
|
Converted Rate Multiplier |
|
Converted Rate Divisor |
|
Old Exchange Rate |
|
Converted Exchange Rate |
|
Converted Rate Multiplier |
|
Before conversion:
Taxation Currency |
Taxation Amount |
Base Currency |
Base Amount |
Rate Multiplier |
Rate Divisor |
FRF |
500 |
USD |
100 |
0.2 |
1 |
After conversion:
Changes are in bold.
Taxation Currency |
Taxation Amount |
Base Currency |
Base Amount |
Rate Multiplier |
Rate Divisor |
EUR |
83.33 |
USD |
100 |
1.2 |
1 |
Conversion formula:
Converted Taxation Amount |
|
Converted Rate Multiplier |
|
Converted Rate Divisor |
|
The rate multiplier and rate divisor represent the rate used to convert the taxation currency (FROM currency) to the base currency (TO currency).
To convert the taxation currency from FRF to EUR, the rate multiplier and rate divisor must also be converted. In this case, rate multiplier and rate divisor are associated with the FROM amount/currency; that is, rate multiplier and rate divisor are converted because the FROM amount and taxation currency are converted.