FUNCTIONAL DESIGN - Oracle



Implementation Toolkit

FINANCIAL CLOSE MANAGEMENT

CONFIGURING ERPI FOR ARM

Author: Heather Lynds

Creation Date: Feb 21, 2012

Last Updated: Apr 17, 2012

Document Version: 1.0

Status: DRAFT

Table of Contents

1. Overview 4

1.1 Purpose of this Document 4

2. Data Integration Options 5

2.1 ERP Sources 5

2.2 Open Interface Method 5

2.3 File-Based Data Loads 5

2.3.1 File Naming Convention 5

2.3.2 File Columns 6

2.3.3 Importing Balances Associated with Different Currency Buckets 6

3. Data Load Process 8

4. Planning the ERPI Configuration 9

4.1 Planning Locations 9

4.1.1 One for each Unique Chart of Accounts within a Single Source System 9

4.1.2 Multiple Reconciliation Processes 10

4.1.3 Same Source System Account reconciled in 2 different Profiles in a Single Process 10

5. Configuring ERPI for ARM 11

5.1 Configure System Settings 11

5.2 Register Target Application 12

5.2.1 Configure the Target Application Summary 12

5.2.2 Configure the Dimension Details 12

5.3 Period Mapping 14

5.3.1 Global Mapping 15

5.3.2 Application Mapping 16

5.3.3 Source Mapping 16

5.4 Category Mapping 16

5.4.1 Review ARM Currency Configuration 16

5.4.2 Single Currency Category Mapping 17

5.4.3 Multi-Currency Category Mapping 17

5.5 Register Source Systems 18

5.6 Register Source Adapter 18

5.7 Select Source Accounting Entities 19

5.7.1 Configure Accounting Entities 20

5.7.2 Configure Entity Groups 20

5.8 Configure Import Formats 21

5.8.1 Configure Details 21

5.8.2 Configure Mappings 22

5.9 Configure Locations 26

5.10 Configure Data Load Rules 27

5.10.1 Configuring Data Load Rules for ERP Sources 27

5.10.2 Configuring Data Load Rules for File-Based Data Loads 29

5.11 Configure Data Load Mapping 30

5.11.1 Rules Assigning ARM Profile ID’s 31

5.11.2 Rules Assigning ARM Balance Source Types 33

5.11.3 Import Data Load Mappings 34

6. Appendix 1: Supported Currency Codes 39

7. Appendix 2: Troubleshooting 42

7.1 ODI Studio Error Message 42

8. Index 43

Overview

Integration of account balances is core to the effective functioning of an account reconciliation solution. FCM’s Account Reconciliation Manager (“ARM”) uses Oracle Hyperion Financial Data Quality Management ERP Integration Adapter for Oracle Applications (“ERPi”) to load balances from source systems and map the balances to reconciliations.

1 Purpose of this Document

ERPi is used by many different Oracle applications. The purpose of this document is to facilitate planning for an ARM implementation and to explain how a typical ARM customer would configure ERPi for ARM. This document is intended to supplement the instructions contained in the Oracle Hyperion Financial Data Quality Management ERP Integration Adapter for Oracle Applications Administrator’s Guide.

Data Integration Options

ERPi provides three options for importing balances into ARM.

1 ERP Sources

ERPi has native support for importing general ledger balances from the following ERP source systems:

• Oracle E-Business Suite 11i, 12

• Oracle Fusion Financials

• PeopleSoft Enterprise Financial Management 9.0, 9.1

• SAP ERP Financial 4.7c, ECC 6.0 enhancement pack 4.0+

• JD Edwards Enterprise version 9.0

Once connections to these source systems have been configured in ERPi, balances are retrieved from the source system directly upon initiation of a data load (no manual extract from the source system is required).

2 Open Interface Method

ERPi provides an Open Interface Adapter which enables customers to populate data from any source system into an open interface table in ERPi, where the data is then accessible for import into ARM. This option is useful for importing general ledger balances from ERP’s for which adapters have not been produced, from subledger systems from any ERP platform, from HFM, or from any other system containing balances to be reconciled.

In addition to configuring the Open Interface Adapter in ERPi, customers must also populate the open interface table each month, using a data extraction tool of the customer’s choice. ODI can be used for this purpose, so long as the customer obtains a license to ODI.

3 File-Based Data Loads

File-based data loads enable customers to import balances from delimited or fixed-width text files. In addition to configuring the file import, customers must also publish the files to be imported to the proper location each period. The location is configurable based on the ERPi application root directory (see Configure System Settings).

1 File Naming Convention

ERPi supports two naming conventions for data load files: Static File Name, or Static File Name plus a Period Suffix. The convention used is based on the Data Load Rule configured for the file.

1 Static File Name

The name of the file remains the same from period to period. This option is only appropriate for customers who plan to load balances for one period at a time (since the file name is the same for all periods, the directory can only store one copy of the file at a time).

For example, if the Static File Name is set to “EBS_Balances”, then when balances are imported for a selected period, ERPi will look for a file titled “EBS_Balances” and will import those balances into the selected period.

2 Static File Name plus a Period Suffix

The file name consists of two parts: a static part that remains the same from period to period, and a suffix that identifies the period. This option is appropriate for customers who may load balances for multiple periods (for example, importing both January and February balances throughout the month of February).

When choosing the Period Suffix, two options are available: Period Key or Period Name. Both values are configured in the Global Mapping section of the ERPi Period Mapping dialog. The Period Suffix must exactly match the values configured, or the import will fail.

For example, if the Static File Name is set to “EBS_Balances_.txt”, Period Name is used as the suffix, and the Period Name is “January 2012”, then when balances are imported for January, ERPi will look for a file titled “EBS_Balances_January 2012.txt” and will import those balances into the selected period. If the file matching the expected name does not exist, then no balances will be imported.

2 File Columns

Files must include the following columns:

• Account Segments: The source system account segments associated with the balance (one segment per column)

• Balance: The period-end balance

In addition, if the file contains balances in more than one currency, then an additional column must exist in the file containing the 3 digit ISO currency code associated with each balance. Refer to Appendix 1 for a list of supported currency codes. If the balances pertain to a single currency, then currency code may be omitted from the file and configured at the Location level.

Files do not require a header row. If a header row is included, it must be configured to be ignored in the Import Format definition.

1 Determining which Source System Segments to Include in the File

There are two factors to consider when determining which source system segments to include in the file:

1. Segments used in balance mappings: Any source system segments that are used to map balances from the source system to Profiles in ARM must exist within the file.

a. For example, if your source system contains segments for Company, Account, Profit Center, Plant, and Intercompany code, yet reconciliations are only ever performed at the Company-Account level, then the file only needs to contain values for the Company and Account segments. The values in these two segments will be used to map balances to the Profile in ARM.

b. If, however, some reconciliations are performed at the Company-Account level, while others are performed at the Company-Account-Plant level, then the file will need to store values from all three segments, so that the mapping rules can be configured properly. Mapping rules for accounts reconciled the Company-Account level will ignore the Plant segment values, while rules for accounts reconciled at the Company-Account-Plant level will use all three.

2. Segments that need to be visible during drill-back to aid in discovery: When viewers of reconciliations view balances in ARM, they are presented in summary, at the level at which reconciliation is performed. ARM supports drill-back to ERPi for the balance detail. The information displayed on the drill-back landing page is obtained from the values in the file. Therefore, all information that should be visible during drill-back must exist in the file, so that the information will be present during drill-back.

3 Importing Balances Associated with Different Currency Buckets

ARM supports reconciliation of balances in up to 3 currency buckets. The names of buckets are configurable within ARM, but are generally classified like the following:

• Entered: The currency in which the transaction occurred

• Functional: The currency of the entity that owns the ledger

• Reporting: An enterprise-wide reporting currency (typically the consolidation currency)

If the reconciliation process requires reconciliation of balances in more than one currency bucket, then balances must be imported for each bucket and a separate file is required for each set of balances. In this case, the static file name should include the currency bucket name to enable proper configuration of the import files.

Data Load Process

The ARM data load process encompasses three phases:

[pic]

• Staging (managed by ERPi) – The staging phase extracts balances from the source system, assigns an ARM Profile ID and balance Source Type (source system or sub-system), and stores the balances in the ERPi staging table (TDataseg) by Location and Period. Within the staging table, there is a one-to-one relationship to balances in the source system (no summarization has occurred). The staging table maintains only the latest data load for each Location/Period combination. When balances are imported multiple times for the same Location/Period (for example, when importing multiple sets of preliminary balances for a period), only the latest data load is maintained, ensuring data volumes are managed appropriately.

• Load (managed by ARM) – The load phase summarizes the balances by Period, Location, Profile ID, balance Source Type, currency bucket, and currency code and loads the balances into ARM. These balances are permanently stored in ARM but are subject to updating if changed balances are imported in the future.

• Post-Processing (managed by ARM) – the post-processing phase performs the following actions:

o Changes the status of reconciliations “Open with Reviewer” or “Closed” to “Open with Preparer” if the reconciliation balances changed

o Runs the auto reconciliation routines

o Flags reconciliations containing normal balance violations (cases where the balance is expected to be a debit and a credit balance exists, or vice versa)

While configuration of data loads has to occur within ERPi, it’s important to note that data loads should be initiated from within ARM. Although ERPi enables data loads to be initiated from within ERPi, doing so will limit execution to the first phase (Staging). The Load and Post-Processing phases will not occur. To execute a complete data load (encompassing all three phases), data loads must be initiated within ARM by an Administrator from the Manage Periods dialog.

Planning the ERPI Configuration

The main components of an ERPI data load are Locations, Import Formats, Data Load Rules, and Data Load Mapping.

[pic]

Location is the level at which a data load is executed in ARM. A Location is associated with one source system, but can import data from multiple ledgers from that system. Each Location is assigned an Import Format, one or more Data Load Rules, and a Data Load Mapping.

The Import Format determines which fields (columns) are extracted from the source system and how the data is stored in the ERPi staging table.

The Data Load Rules determine which records (rows) are extracted from the source system, including which balance types are selected (Entered/Functional), whether zero balances are included, and whether currency rates are imported along with the balances (for ERP sources only).

The Data Load Mapping determines which ARM Profile ID and balance Source Type is assigned to each balance imported. Source Type refers to the classification of a balance as either a source system balance or a subsystem balance.

1 Planning Locations

Location is a key component and requires consideration and planning.

One Location is needed for each general ledger and subledger from which balances are imported. For example, if general ledger balances are required to be imported from Oracle EBS, PeopleSoft, and SAP, and subledger balances are imported from the Accounts Payable and Accounts Receivable subledger from each of the 3 source systems, then 9 Locations are required:

|Source System |Repository |Interface Method |

|Oracle EBS |General Ledger |EBS Adapter |

|Oracle EBS |Accounts Payable Subledger |Open Interface or File-Based Data Load |

|Oracle EBS |Accounts Receivable Subledger |Open Interface or File-Based Data Load |

|PeopleSoft |General Ledger |PeopleSoft Adapter |

|PeopleSoft |Accounts Payable Subledger |Open Interface or File-Based Data Load |

|PeopleSoft |Accounts Receivable Subledger |Open Interface or File-Based Data Load |

|SAP |General Ledger |SAP Adapter |

|SAP |Accounts Payable Subledger |Open Interface or File-Based Data Load |

|SAP |Accounts Receivable Subledger |Open Interface or File-Based Data Load |

If balances are imported from multiple ledgers within a single source system and the ledgers contain different charts of accounts or period configurations, then a separate Location is required for each configuration.

1 Multiple Reconciliation Processes

Balances within a single Location can only be assigned to a single Profile ID in ARM. Therefore, if the same source system accounts need to be reconciled as part of two different reconciliation processes (for example, as part of the Balance Sheet Reconciliation Process and the Consolidation System Reconciliation Process), then a separate Location must exist for each Process (because in this case, two Profile ID’s will exist in ARM: one for each process).

When performing multiple reconciliation processes for the same source system balances, we recommend naming the Locations with a combination of the source system name and the process name. For example:

• BSProcess_EBS_GL (Oracle EBS general ledger balances for the Balance Sheet Reconciliation Process)

• BSProcess_EBS_AP (Oracle EBS Accounts Payable subledger balances for the Balance Sheet Reconciliation Process)

• ConsolProcess_ EBS_GL (Oracle EBS general ledger balances for the Consolidation System Reconciliation Process)

2 Same Source System Account reconciled in 2 different Profiles in a Single Process

On rare occasions, the same source system account may be included in two different reconciliations as part of the same reconciliation process in ARM. Within a single Location in ERPi, a source system balance can only be assigned to a single Profile ID in ARM. Therefore, to accommodate a second assignment, a second Location must be created for the same source system. Only those accounts subject to a second Profile ID assignment are mapped in this Location. The rest of the accounts are ignored.

Configuring ERPI for ARM

Login to Workspace and launch ERPi:

[pic]

1 Configure System Settings

1. Click the System Settings link located within the Preferences section on the Tasks navigator.

2. Provide the following values for the system settings options, and then press the Save button:

|Option |Value |

|ODI Agent URL |The host and port should be the same as was configured during ODI installation. For example: |

| | |

|ODI User Name |SUPERVISOR |

|ODI Password |SUNOPSIS |

|ODI Execution Repository |WORKREP |

|ODI Master Repository Driver |WORKREP |

|ODI Master Repository URL |Must match the Master Repository schema created during ODI installation |

|ODI Master Repository User |Must match the Master Repository schema created during ODI installation |

|ODI Master Repository Password |Must match the Master Repository schema created during ODI installation |

|Application Root Directory |This is the folder into which import files will be placed when data is imported from file-based sources. This folder|

| |must be located on the ODI server, and sharing should be configured so that it is accessible by the server upon |

| |which ERPi is installed and from computers responsible for placing files into the folder. The |

| |Open_Interface_Adapter.xml file should also be placed into this folder. This xml file can be obtained from: |

| |“\products\FinancialDataQuality\odi\11.1.2.2.00\adapters” folder |

|File Archive Directory |This is the folder into which import files are archived. The folder must be created under the Application Root |

| |Directory. |

2 Register Target Application

In order for ERPi to retrieve data for ARM, ARM must be registered as a Target Application in ERPi.

1 Configure the Target Application Summary

3. Click the Target Application link located within the Setup section on the Tasks navigator.

[pic]

4. Click the Add button.

[pic]

5. Select Account Reconciliation Manager from the Select Application dialog and click the OK button.

2 Configure the Dimension Details

[pic]

Configuration of the Target Application Dimension Details enables users to specify how columns in the staging table will be used for storing values from source systems. Only those source system values configured as Dimensions will exist in the staging table.

The staging table contains a fixed definition, including a series of standard fields of pre-determined use by ERPi, and a series of 20 user defined fields (UD1-UD20) that can be used by Target Applications for application-specific purposes. In ARM’s case, UD1 is reserved for storing the balance Source Type (the setting that classifies balances in ARM as either source system or subsystem balances). UD2-UD20 can be used to store other information required to be imported from the source systems.

1 Pre-Defined Dimensions

After registering the Target Application, the Dimension Details section will contain the following four rows. These rows are not editable:

• Period: maps the source system period to the Period column in the staging table

• Profile: maps the ARM Profile ID to the Account column in the staging table

• Currency Bucket: maps the ARM currency bucket to the Scenario column in the staging table

• Source Type: maps the ARM balance type (source system or subsystem) to the UD1 column in the staging table

2 LOOKUP Dimensions

In addition to the four pre-defined dimensions, additional dimensions (“LOOKUP Dimensions”) need to be added for additional data required to be imported from the source systems and stored in the staging table. There are two reasons why additional values would need to exist in the staging table:

3. Segments used in balance mappings: Any source system segments that are used to map balances from the source system to Profiles in ARM must exist within the staging table.

a. For example, if your source system contains segments for Company, Account, Profit Center, Plant, and Intercompany code, yet reconciliations are only ever performed at the Company-Account level, then the staging table only needs to contain values for the Company and Account segments. The values in these two segments will be used to map balances to the Profile in ARM.

b. If, however, some reconciliations are performed at the Company-Account level, while others are performed at the Company-Account-Plant level, then the staging table will need to store values from all three segments, so that the mapping rules can be configured properly. Mapping rules for accounts reconciled the Company-Account level will ignore the Plant segment values, while rules for accounts reconciled at the Company-Account-Plant level will use all three.

4. Segments that need to be visible during drill-back to aid in discovery: When viewers of reconciliations view balances in ARM, they are presented in summary, at the level at which reconciliation is performed. ARM supports drill-back to ERPi for the balance detail. The information displayed on the drill-back landing page is obtained from the staging table. Therefore, all information that should be visible during drill-back must exist either as pre-defined or LOOKUP Dimensions, so that the information will be present in the staging table.

3 Configure LOOKUP Dimensions

Perform the following actions to configure LOOKUP Dimensions:

1. Click Add/Edit Lookup Dimension

[pic]

2. Click the Add icon

[pic]

3. Assign a Dimension Name and select from the list of User Defined columns in the staging table to store the value in

[pic]

The purpose for assigning a name to the column is to make it easier to remember what data is being stored in the column when the Dimension is used in subsequent configuration steps. For example, when configuring balance mapping rules, it would be a lot easier to refer to columns titled “Company” and “Account” instead of “UD2” and “UD3”.

Since the same staging table is used to store balances from all source systems, names may need to be assigned more generically if the source systems have very unique charts of accounts. For example, if the staging table will be configured to store 3 segment values, and segment 3 is called “Profit Center” in one source system and Department in another, then the name assigned to the Dimension may need to be generic in order to accommodate both. In cases like this, “Segment 3” may be an appropriate Dimension name. In addition, best practices would dictate using the same segment names in ARM.

It is important to note that LOOKUP Dimension names are only used in ERPi during configuration. They are not visible to users of ARM viewing imported data through drill-back to ERPi. Rather, when drilling back from ARM to ERPi, these users will see labels that are specific to each data source imported.

3 Period Mapping

Periods exist in ARM, source systems, and ERPi. In order for ERPi to successfully retrieve source system balances and export those balances to the proper period in ARM, rules must be defined that document the relationship between these three sets of periods. This is accomplished using the Period Mapping feature in ERPi.

To map Periods:

1. Click the Period Mapping link located within the Setup section on the Tasks navigator.

[pic]

2. Configure both the Global Mapping and Application Mapping according to the instructions below.

1 Global Mapping

Global Mapping is where ERPi periods are created and where default mappings are established between:

• ERPi and Target Applications like ARM

• ERPi and source systems

If ERPi is used for importing balances to other EPM applications, then values may be present on the Global Mapping tab that are tailored to a different application. This is OK. ARM uses the values on the Application Mapping tab (not the Global Mapping tab). However, Application Mappings can only be created for periods existing on the Global Mappings tab. Hence, both are required.

Begin by ensuring that the list of periods required by ARM exists on the Global Mapping tab. To add periods:

1. Click on the Global Mapping tab.

2. Click the Add icon to add a row to the Global Mapping table.

3. For each period added, provide the following values:

a. Period Key: Period Key is the unique identifier for the period and must be a date value. Period End Date would be a good value to use as the Period Key.

b. Prior Period Key: The Period Key associated with the preceding period. The Period Key does not have to exist in ERPi in order to be used in the Prior Period Key column.

c. Period Name: Period Name is a secondary identifier for the period. The value must also be unique, but may include alpha-numeric characters.

d. Target Period Month: Provide the name of the period exactly as it exists in ARM.

a. Year Target: Year is a required value, but it does not affect processing for ARM. Provide the year associated with the corresponding ARM period.

b. Click the Save button to save the mapping. Repeat steps 2 & 3 until all periods have been added.

Note that the Target Period Quarter, Target Period year, and Target Period Day columns should be left blank. A sample Global Mapping is provided below:

[pic]

2 Application Mapping

Application Mapping is required for ARM. To configure:

1. Click on the Application Mapping tab.

2. Select “Account Reconciliation Manager” from the Target Application selection box.

4. Click the Add icon to add a row to the Global Mapping table.

5. For each period, provide the following values:

a. Period Name: Select the Period Name from the list provided (obtained from the Global Mapping tab).

b. Period Key: Defaults based on the Global Mapping configuration.

c. Target Period Month: This value must match exactly match ARM’s associated period name. This is how we associate the ERPi period with the ARM period.

c. Year Target: Year is a required value, but it does not affect processing for ARM. Provide the year associated with the corresponding ARM period.

d. Click the Save button to save the mapping. Repeat steps 3 & 4 until all periods have been added.

Note that the Target Period Quarter, Target Period year, and Target Period Day columns should be left blank.

3 Source Mapping

Source Mappings define the relationship between ERPi periods and source system periods. Select the “Explicit” option if mappings must be configured at the GL Calendar level to support ledgers that use different period calendars.

For additional instructions on configuring Source Mappings, refer to the ERPi Administrator guide, as procedures are specific to each source system.

4 Category Mapping

Category Mappings enable users to associate source system balances with ARM currency buckets. The instructions for configuring Category Mappings in ERPi depend on how ARM has been configured.

1 Review ARM Currency Configuration

Before configuring Category Mappings, review the ARM currency configuration:

1. Login to ARM as an Administrator and open the System Setup dialog (Manage ( System Setup)

3. Click on the Currency link to review the Currency Configuration

4. On the Currency Buckets tab, determine whether ARM has been configured for a single currency or multi-currency environment.

a. If the “Balances and Transactions are in a single currency” option is selected, follow the instructions for Single Currency Category Mapping

b. If the “Balances and Transactions are in multiple currencies” option is selected

i. Make note of which currency buckets are enabled in ARM

ii. Note the names of each enabled currency bucket

iii. Follow the instructions for Multi-Currency Category Mapping

To configure Categories:

1. Click the Category Mapping link located within the Setup section on the Tasks navigator.

[pic]

5. Configure both Global Mappings and Application Mappings, using either the Single Currency or Multi-Currency Category Mapping instructions below.

2 Single Currency Category Mapping

If ARM has been configured as a single currency environment, then create a single Category on both the Global Mapping and Application Mapping tabs with the following values:

[pic]

When configuring the Application Mapping values, select Account Reconciliation Manager as the Target Application.

3 Multi-Currency Category Mapping

If ARM has been configured as a multi-currency environment, then for each enabled currency bucket in ARM, add a corresponding Category in ERPi on both the Global Mapping and Application Mapping tabs. When configuring the Application Mapping values, select Account Reconciliation Manager as the Target Application.

Note that the Target Category value must exactly match the bucket name in ARM.

[pic]

5 Register Source Systems

Source systems must be registered for each source system containing balance data to be loaded into ARM. “Source System” in this case refers to:

• Supported general ledger platforms: Add a source system for each general ledger from which balances will be imported.

• Files containing balances imported using File-Based Data Loads: If balances will be imported from files, then define a source system of type “File”. Only one should be required, even if files from multiple systems are being imported (they can all use the same Source System of type “File”).

• Balances imported using the Open Interface method: Balances imported using the Open Interface method require a Source System Type of “Other”.

To configure Source Systems:

1. Click the Source System link located within the Setup section on the Tasks navigator.

[pic]

6. Refer to the ERPi Administrator Guide for instructions on configuring each type of source system, as instructions are type-specific. If detailed logging is desired, set the Log Level to 5.

6 Register Source Adapter

Registration of the Source Adapter is required when data is to be loaded from file-based sources.

To register the Source Adapter:

1. Click the Source Adapter link located within the Setup section on the Tasks navigator.

7. Click the Import button

[pic]

8. On the Import dialog, select Open_Interface_Adapter.xml and click the OK button.

[pic]

9. On the Source Adapter page, click the Save button.

[pic]

7 Select Source Accounting Entities

After Source Systems have defined, then Source Accounting Entities must configured by selecting the ledgers from which balances should be imported from each source. (This step does not apply to source systems of type “File” or “Other”).

To configure Source Accounting Entities:

1. Click the Source Accounting Entities link located within the Setup section on the Tasks navigator.

[pic]

2. Select the Source System Type from the list of types provided.

[pic]

10. Select the associated Source System from the list provided, which are derived from Source System configuration.

1 Configure Accounting Entities

1. On the Entities tab, place a checkmark next to the ledgers (EBS/Fusion) or Business Units (PeopleSoft) from which balances should be imported.

2. For EBS/Fusion source systems, if drill-back to the general ledger is desired, select a Responsibility Name that has proper system security required for viewing journal summaries and details. If drill-back is not desired, leave Responsibility Name blank.

11. Press the Save button.

2 Configure Entity Groups

Within the same source system, if multiple accounting entities (ledgers/business units) exist that contain the same chart of accounts and have balances that will be assigned the same currency bucket, then an Entity Group can be created for these entities. When configuring Data Load Rules, a single Rule can be created for the Entity Group, rather than having to create separate rules for each entity.

Consider an example of an EBS general ledger that contains the following individual ledgers (all of which utilize the same chart of accounts):

|Ledger A |Contains entered and functional currency balances for all transactions associated with Entity A. |

|Ledger B |Contains entered and functional currency balances for all transactions associated with Entity B. |

|Ledger C |Contains entered and functional currency balances for all transactions associated with Entity C. |

In this case, an Entity Group could be created for Ledger A, B, & C, since they share the same chart of accounts and currency bucket configuration.

To configure Entity Groups:

1. Click the Entity Groups tab.

2. Click the Add button.

[pic]

3. Type a Name, and optionally a Description for the Entity Group.

[pic]

4. In the Entity Group Entities table, place a checkmark next to each Accounting Entity that should be included in the Entity Group.

5. Press the Save button.

8 Configure Import Formats

Import Formats determine which fields (columns) are extracted from the source system and how the data is stored in the ERPi staging table. Import Formats are created for a single Accounting Entity. However, if you are importing data from multiple Accounting Entities that have the same COA, you can define one Import Format using a representative Accounting Entity and then use it for importing data for all Accounting Entities with the same COA.

To configure Import Formats:

1. Click the Import Format link located within the Setup section on the Tasks navigator.

[pic]

2. Click the Add button to add a new Import Format.

1 Configure Details

1. Provide a Name for the Import Format. In general, it is good practice to include the Source Name and information about the ledger configuration in the Name of the Import Format. This will make it easier to select the proper Import Format when configuring the Location.

2. Select the Source System

3. Select a representative Accounting Entity (a ledger that contains the correct chart of accounts configuration). Note that the Import Format can be used to load balances from any Accounting Entity or Entity Group that shares the same chart of accounts. The actual selection of the chart of accounts to use occurs within the Data Load Rule configuration.

4. Select the Account Reconciliation Manager as the Target Application.

5. Click the Save button.

2 Configure Mappings

The Mappings section determines how data from the source system is stored in the ERPi staging table. The procedures vary based on the type of source system for which the Import Format is being configured.

1 Mapping ERP sources

The values appearing in columns Source Segment 1 through Source Segment 5 are the actual segment values that exist within the source system being confirmed. When configuring ARM, only Source Segment 1 column is used, because only one source segment value is stored in a single staging table column. The other Source Segment columns would be used if source values were concatenated together into a single column in the staging table (which is not a use case expected to apply to ARM).

For each source segment appearing in the Source Segment 1 column that should be imported from the source system and stored in the staging table, perform the following procedures:

1. In the Dimensions column, locate the row that contains the corresponding staging table column name (the staging table columns were configured in the LOOKUP Dimensions section of Register Target Application).

2. Assign the appropriate source segment column in the Source Segment 1 column on the same row.

Then, assign the Account source segment to the Profile dimension. The Source Type dimension should not be mapped.

Click the Save button once all mappings have been configured.

[pic]

In the example above:

• the Account segment from the source system will be stored in the Account column of the ERPi staging table

• the Account segment is also mapped to the Profile dimension, which is a requirement for the data to load properly

• the Company segment will be stored in the Company column of the ERPi staging table

• the Department segment will be stored in the Dept column of the ERPi staging table

Note that the word “Dimension” is synonymous with “ERPi staging table column”.

2 Mapping File-Based sources

When configuring mappings for file-based sources, the procedures are similar, but slightly different. Every column that exists in the source file has to be mapped to a Target, which refers to a column in the ERPi staging table.

1 Configuration of Delimited Files

Consider the following sample comma-delimited file:

[pic]

The file contains 5 columns:

1. Company

2. Account

3. Department

4. Amount

5. Currency Code

For each column in the file, perform the following procedures:

1. In the Target column, locate the row that contains the staging table column name associated with the column in the file (the staging table columns were configured in the LOOKUP Dimensions section of Register Target Application).

2. Assign the appropriate file column in the Source column on the same row. The actual text typed into Source Column is used for display purposes in ERP only. The text does not need to match a column heading in the file (in fact the file is not required to even include a header row).

3. Field Number: Provide the column number of the field in the file. This value is important, as it used by ERPi to locate the data in the file that should be stored in the staging table column specified in the Target column. In the example above, Company would have a value of “1”, since it is the first column in the file. Department would have a value of “3”.

4. Number of Fields: The total number of fields in the file. In the example above, the value would be “5”, since 5 columns exist in the file.

5. Expression: If values in the file require manipulation or conversion, Expressions may be used. One expression that is key for file-based sources is NZP, which ensures that zero balances are imported. To import zero balances (a typical account reconciliation requirement), type “NZP” (without the quotes) into the expression column for the Amount field. If this expression is omitted, zero balances will not be imported. Refer to the ERPi Administrator’s Guide for details on other expressions.

Then, map the Account column to the Profile Target.

If the file contains a Currency Code column, this column must also be mapped to the staging table. By default, the Target column does not include the currency staging table column. To add the Currency staging table column to the Target column, perform the following procedures:

1. Click the Add button

2. Select Currency Row

[pic]

3. Map the column in the file containing the Currency Code to the Currency Target.

The following image demonstrates how the sample file, once configured, would appear in ERPi.

[pic]

2 Configuration of Fixed Width Files

Configuration of fixed width files varies from delimited files in one way: instead of Field Number and Number of fields, Start and Length are required.

• Start: Identifies the starting position within the row of the value to be imported. For example, if configuring the mapping for Currency Code, and Currency Code begins in position 65 of each row, then enter 65 in the Start field.

• Length: Identifies the length of the data field. For example, since Currency Codes are always 3 digits in length, enter 3 in the Length field.

3 Configuration of Skip Rows

Data files may include rows that need to be ignored. ERPi includes a robust feature set for configuring rows that should be skipped, or ignored, during import. To add Skip Rows, perform the following procedures:

1. Click the Add button

2. Select Skip Row

3. Configure the Skip Row, using the following example as guidance.

[pic]

The first 5 rows in the file should be skipped, since it contains heading information. In addition, the rows containing the column headers and the heading underlines should also be skipped. Since these rows repeat on each page, they’ll need to be skipped every time they appear. The following image demonstrates how ERPi was configured to ignore these rows.

[pic]

When the value appearing in the Expression column appears in the range identified by the Start Position and Length, then the row should be skipped. For example, consider the Source Column “Skip 3” in the image above. Any time the word “Account” appears in positions 1-7 of the file, the entire row will be skipped. This will cause the row marked with the arrow below to be skipped:

[pic]

3 Regenerate ODI Scenario

Each time an Import Format is added or updated for data sources other than EBS, PeopleSoft, or Fusion, then a Regenerate ODI Scenario message will appear, requiring the Regenerate ODI Scenario button to be pressed. Failure to perform this action will cause the import to fail. See Appendix 2 for a typical ODI Studio Error Message resulting from failure to Regenerate ODI Scenario. Note that in version 11.1.2.2, Import Formats requiring regeneration of an ODI Scenario cannot contain spaces in the Import Format name. Including a space will cause the Regenerate ODI Scenario action to fail.

9 Configure Locations

Refer to the Planning Locations section for assistance with determining the Locations required. To configure Locations:

1. Click the Location link located within the Setup section on the Tasks navigator.

[pic]

2. Click the Add button.

3. Provide a Name for the Location. In general, it is good practice to include in the Location name descriptive information about the source system from which balances are obtained and the ARM Process for which Profiles will be mapped. The Location name is visible in ARM and can be used to initiate specific data loads. Therefore, having a descriptive name will be helpful. For example:

a. EBS_GL_BSProcess (Oracle EBS general ledger balances for the Balance Sheet Reconciliation Process)

b. EBS_GL_ConsolProcess (Oracle EBS general ledger balances for the Consolidation System Reconciliation Process)

c. EBS_AP_BSProcess (Oracle EBS Accounts Payable subledger balances for the Balance Sheet Reconciliation Process)

4. Select the Import Format that should be used when importing balances from this Location. Recall that the Import Format determines which information is extracted from the source system and how it is stored in the ERPi staging table.

5. Functional Currency: If the Location pertains to a Source System of “Flat File” and the file does not contain a currency code column (because all balances in the file pertain to a single currency), then the currency must be specified in the Functional Currency column. If applicable, enter the 3 digit ISO currency code associated with the balances in the file. Refer to Appendix 2 for the list of supported currencies.

6. Press the Save button.

Note that Accounting Entity typically should be left blank. When configuring the Data Load Rules associated with the Location, an Accounting Entity or Entity Group can be assigned to each Data Load Rule, enabling a single Location to be used for importing balances from more than one Accounting Entity. If an Accounting Entity is specified at the Location level, then the Location can only be used for importing balances from this single Accounting Entity.

10 Configure Data Load Rules

Data Load Rules determine which records (rows) are extracted from the source system, including which balance types are selected (Entered/Functional), whether zero balances are included, and whether currency rates are imported along with the balances (for ERP sources only).

For each Location, one Data Load rule must be configured for each currency bucket for which balances are imported. For example, if Location A contains ledgers from which Entered and Functional currency balances are required to be imported, then two Data Load Rules will exist for this Location: one for importing Entered currency balances, and one for importing Functional currency balances. Which bucket is enabled for each reconciliation is controlled by settings within ARM.

To configure Data Load Rules:

1. Click the link located within the Data Load section on the Tasks navigator.

[pic]

2. Select a Location by clicking the Search Location icon. After selecting a Location, the Target should display “Account Reconciliation Manager”. Period and Category may contain values; these can be ignored. These are default values that are ignored by ARM when data loads are run.

[pic]

3. Click the Add button in the Data Rule Summary section to add a Data Load Rule.

1 Configuring Data Load Rules for ERP Sources

If the Location references an ERP source system, perform the following procedures:

1. In the Details section:

a. Name: Provide a Name for the Data Load Rule. In general, it is good practice to include in the Data Load Rule name descriptive information about the source system from which balances are obtained and the currency bucket to be assigned to the balances.

b. Category: Select the currency bucket to be assigned to the balances from the Category selection.

c. Include Adjustment Periods: If Adjustment periods should be included, select Yes. Otherwise, select No.

d. Period Mapping Type: Select Default to use the Application Mapping settings in the Period Mapping configuration. If period Source Mappings were configured for this source system, select Explicit.

1 EBS, Fusion, & SAP source systems

If the Source system is EBS, Fusion, or SAP:

1. In the Source Filters section:

a. Amount Type: Select “Monetary”.

b. Include Zero Balance: Select “Yes”.

c. Amount for Balance Sheet Accounts: Select “YTD”.

d. Amount for Income Statement Accounts: Select “YTD”.

e. Currency Type: Select the value that corresponds with the currency bucket to be assigned in this Data Load Rule (per the Category value selected in the Details section).

[pic]

i. Select “Entered” if Category = Entered (or its equivalent in ARM)

ii. Select “Functional” if Category = Functional (or its equivalent in ARM)

iii. Select “Translated/Group” if Category = Reporting (or its equivalent in ARM)

f. Currency Code should be left blank, if the objective is to import all balances from the Location. If a value were provided here, it would limit the balances imported to those that contained a matching currency code.

g. Balance Method: Select “Standard”.

h. Exchange Rate Options: Select the same currency rate that is used to revalue period-end balances in the source system.

i. Click the Save button.

2 PeopleSoft source system

If the source system is PeopleSoft:

1. In the Source Filters section:

a. Amount Type: Select “Monetary”.

b. Amount for Balance Sheet Accounts: Select “YTD”.

c. Amount for Income Statement Accounts: Select “YTD”.

d. Currency Type: Select the value that corresponds with the currency bucket to be assigned in this Data Load Rule (per the Category value selected in the Details section).

[pic]

i. If the ledgers associated with this Data Load Rule are the primary (not translated) ledgers, then Entered and Functional currency types are typically mapped to the Entered and Functional currency buckets within ARM:

1. Select “Entered” if Category = Entered (or its equivalent in ARM)

2. Select “Functional” if Category = Functional (or its equivalent in ARM)

ii. If the ledgers associated with this Data Load Rule are translated ledgers, then the Entered currency type is not mapped since it was already mapped from the primary ledger. The Functional currency bucket (containing the translated balances) is mapped to the Reporting currency bucket in ARM:

1. Select “Functional” if Category = Reporting (or its equivalent in ARM)

e. Ledger Group: Select the appropriate Ledger Group.

f. Ledger: Select the appropriate Ledger.

g. Exchange Rate Options: Select the same currency rate that is used to revalue period-end balances in the source system.

h. Click the Save button.

2 Configuring Data Load Rules for File-Based Data Loads

If the Location references a file, perform the following procedures:

1. In the Details section:

a. Name: Provide a Name for the Data Load Rule. In general, it is good practice to include in the Data Load Rule name descriptive information about the source system from which balances are obtained and the currency bucket to be assigned to the balances.

b. Category: Select the currency bucket to be assigned to the balances from the Category selection.

c. File Name: Provide the static name of the file (the part of the name that will not change from period to period).

d. File Name Suffix Type: If a suffix will be appended to the file name each period, then choose one of the following two options (refer to the File Naming Convention section for a discussion about using file suffixes):

i. Period Key: If this option is chosen, then the value appended to the file must exactly match the Period Key value associated with the Application Mapping in the Period Mapping configuration.

ii. Period Description: If this option is chosen, then the value appended to the file must exactly match the Period Name value associated with the Application Mapping in the Period Mapping configuration.

e. Period Key Date Format: If Period Key is chosen as the File Name Suffix Type, then specify the format for the provided date. Format must be specified using the symbols in the table below. For example, consider the following format variations for July 1, 2012:

i. MM-dd-yyyy (07-01-2012)

ii. MMM-d-yy (Jul-1-12)

|Symbol |Meaning |Examples |

|M |Month |M ( 7 |

| | |MM( 07 |

| | |MMM ( Jul |

| | |MMMM ( July |

| | | |

| | |Note the “M” must be capitalized. |

|d |Day |d ( 1 |

| | |dd( 01 |

| | |MMM ( Jul |

| | | |

| | |Note the “d” must be lower case. |

|y |Year |yy ( 12 |

| | |yyyy( 2012 |

| | | |

| | |Note the “y” must be lower case. |

11 Configure Data Load Mapping

Data Load Mapping determines how ARM Profile ID’s and balance Source Types are assigned to source system balances. Mapping rules are associated with Locations and can be assigned using several mapping methods: Explicit, Between, Multi-Dimension, and Like.

To configure Data Load Mappings:

1. Click the link located within the Data Load section on the Tasks navigator

[pic]

2. Select the Location for which mappings are being configured.

[pic]

1 Rules Assigning ARM Profile ID’s

For ARM, mapping rules to assign ARM Profile ID’s are expected to be configured using the Multi-Dimension method, which enables Profile ID’s to be assigned to source system accounts based on values contained in one or more source account segments.

To manually create mapping rules to assign ARM Profile ID’s, perform the following procedures (refer to the Import Data Load Mappings for instructions on importing mapping rules):

1. Select “Profile” from the Dimension selection. This means that the mapping rules specified will be used for assigning an ARM Profile ID.

[pic]

3. Click the Multi-Dimension tab.

[pic]

2. Click the Add button to add a mapping rule.

[pic]

3. Target Value: Enter the ARM Profile ID, or click the browse icon to select from the list of Profile IDs.

4. Rule Name: We recommend using the ARM Profile ID as the rule name, too.

5. Click the Add button to add criteria for determining which source system accounts are assigned this Profile ID. For example, if assigning Profile ID 100-1510 to all accounts where Company Code = 100 and Account = 1510, then two rows should be added to the Multi-Dimension table:

a. The first row contains a condition on the source system Company segment:

i. Dimension: Company

ii. Condition: Explicit (the source segment value must exactly match the value specified in the Value field in order for the Profile ID to be assigned)

iii. Value: 100

b. The second row contains a condition on the source system Account segment:

i. Dimension: Account

ii. Condition: Explicit

iii. Value: 1510

The segments that appear in the Dimension selection are those that were configured as LOOKUP Dimensions. When multiple criteria are specified by adding multiple rows to the Multi-Dimension table, all specified criteria must be met in order for the Profile ID to be assigned (the criteria are joined together with an implicit “AND” conjunction).

If the criteria needs to accommodate a range of values, consider using the “Between” Condition. Specify the starting and ending range, with a comma in between. For example: 1510, 1520 would select accounts in the range from 1510 to 1520.

If the criteria needs to accommodate a partial value in a source account segment, consider using the “Like” Condition. For example, if Profile ID 100-1510-2XXX should be assigned to all accounts where Company = 100, Account = 1510, and Department starts with 2, then the Condition for Department should be created using the “Like” Condition, using the Asterisk (*) character to behave has a wildcard. For example, “2*” would select all accounts where Department starts with 2. Refer to the ERPi Administrator Guide for information on other special characters.

6. Once finished adding criteria, click the Ok button to close the Multi-Dimension dialog.

7. Change Sign: The Change Sign checkbox, when checked, causes ERPi to adjust the signage of the balance. Whether or not the box should be checked depends on the interface method used by the Location for which mapping rules are being configured:

a. If the Location is importing balances from a supported ERP source system, then balances are always imported in absolute value:

i. Assets and expenses are positive if the value is a debit and negative if the value is a credit

ii. Liabilities, revenue, and equity are positive if the value is a credit and negative if the value is a debit

b. If the Location is importing balances from a file using File-Based Data Loads, then the balances will be imported using the signage existing in the file.

ARM requires debit balances to be positive, and credit balances to be negative, regardless of the account type. Therefore, the Change Sign checkbox should be checked for liability, revenue, and equity accounts when importing balances from supported ERP source systems.

For File-Based Data Loads, it depends on the structure of the data in the file. If the data conforms to ARM’s requirements (debits are positive and credits are negative), then the box does not need to be checked. If the signage is based on the account type, then the box will need to be checked for liability, revenue, and equity accounts.

1 IGNORE Mapping Rules

Some source system accounts may have a legitimate reason for being excluded from mapping rules. For example, when mapping accounts to Profiles in ARM that are part of the Balance Sheet reconciliation process, only balance sheet accounts should be mapped. Income statement accounts are not relevant to this process and should be ignored.

Accounts that should be excluded from mapping must be provided an IGNORE mapping rule, using the procedures outlined below. If this does not occur, these accounts will appear in ARM as “Unmapped Accounts” when data loads are executed. To configure IGNORE mapping rules:

1. Click the Add button to add a row to the Multi-Dimension table.

2. In the Rule Name and Target Value, type IGNORE.

[pic]

3. Click the Add button to configure the criteria determining which source system balances should be ignored. For example, if Income Statement accounts should be ignored, and the account number for these accounts start with “3” or “4”, then two rules should be added, both using the Like condition:

a. Accounts starting with a “3”

a. Dimension: Account

b. Condition: Like

i. Value: 3*

b. Accounts starting with a “4”

c. Dimension: Account

d. Condition: Like

i. Value: 4*

2 Conflicting Mapping Rules

It is possible to define conflicting mapping rules (rules that attempt to assign a different Profile ID to the same source system account. If this occurs, the rule that appears first in the list “wins”. Subsequent rules affecting the same source system account will be ignored.

2 Rules Assigning ARM Balance Source Types

Balance Source Types enable ARM to classify a balance as either a source system balance or a subsystem balance.

Consider the following examples:

• A reconciliation is performed as part of the Balance Sheet reconciliation process in ARM, comparing a general ledger balance to the corresponding AP Subledger balance. The objective of the reconciliation is to verify that the general ledger balance is correct. In this case, the general ledger balance should be assigned a Source Type of “source system”, and the AP subledger balance should be assigned a Source Type of “sub-system”.

• A reconciliation is performed as part of the Consolidation System reconciliation process in ARM, comparing balances in HFM to the general ledger balances. The objective of the reconciliation is to verify that the HFM balance is correct. In this case, the HFM balance should be assigned a Source Type of “source system”, and the general ledger balances should be assigned a Source Type of “sub-system”.

The key point to remember is that Source Type “source system” should be assigned to the balance to be reconciled, whereas the Source Type “sub-system” should be assigned to balances used for comparison purposes.

Mapping rules to assign balance Source Types are expected to be configured using the Like method, which enables Source Types to be assigned to source system accounts based on a single “wildcard” criteria.

To configure mapping rules to assign Source Types, perform the following procedures:

1. Select “Source Type” from the Dimension selection. This means that the mapping rules specified will be used for assigning an ARM balance Source Type.

[pic]

2. Click the Like tab

[pic]

3. Click the Add button to add a mapping rule, using the following configuration:

[pic]

4. Source Value: Enter “*” to select all source values, since all source values will be assigned the same Target Value.

5. Target Value: Click the browse icon and select the appropriate value (source system or sub-system) from the list provided.

6. Rule Name: We recommend using the Target Value as the Rule Name, for simplicity.

Note that an IGNORE mapping rule is not required for the Source Type dimension. The IGNORE rule configured for the Profile dimension will cause the same accounts to be ignored for the Source Type dimension.

3 Import Data Load Mappings

Customers using ERPi to import balances to ARM will have at least one mapping rule for every reconciliation performed in ARM. For many companies, thousands of mapping rules will exist. Therefore, importation of mapping rules is a feature expected to be used widely, as it offers a far more efficient method for configuring mapping rules than entering each rule manually. We recommend turning off the validate option when importing large numbers of mappings. Invalid mappings will be detected during data import, and can be corrected at that time.

1 Import File Format

Mappings can be imported from .txt and .csv files. The file format depends on which dimensions are used when specifying mapping criteria and how these dimensions were mapped to the staging table in the Import Format configuration. In general, the import file contains the following four columns, in the order listed (from left to right):

• Mapping criteria

• Target Account

• Rule Name

• Description

Columns in the import file may be separated by any of the following characters:

• ,

• ;

• |

Consider the following example where source system segments Company and Account are used as mapping criteria. These segments were configured as LOOKUP Dimensions and mapped in the Import Format to the UD2 and UD3 staging table columns, respectively:

|Source System Segments |Mapped to Staging Table Column |

|Company |UD2 |

|Account |UD3 |

In this example, the import file would appear as follows:

[pic]

Note the file does not contain a header row. Column A contains the mapping criteria, column B contains the Target Account, column C contains the rule name, and column D contains a description of the rule (description is optional, so this column may be blank).

The mapping criteria column is prefixed with “#MULTIDIM”, which identifies to ERPi that Multi-Dimension mapping is being used. Following this prefix, the mapping criteria column contains a concatenation of all of the criteria required to assign a Profile ID to a source system account. Row 1, for example, will assign Profile ID 100-1500 to any source system account where Company (UD2) equals 100 and Account (UD3) equals 1510.

Since mapping rules are generally related to ARM profile segment values, once the structure of the mapping file is understood, the concatenate function in spreadsheet programs should provide a handy mechanism for creating import files based on ARM Profile Segment values.

To use the concatenate function, split the text from Column A into the following component columns, leaving empty columns for the segment values:

[pic]

Then, copy the ARM Profile Segment values into the empty columns:

[pic]

Add a concatenate function to column F that concatenates the values from columns A-E:

[pic]

Add a concatenate function to column G to create the Target Account value:

[pic]

To create the Rule Name column, add a formula to column H to set the value equal to column G:

[pic]

Copy the formulas in columns F, G, & H to each row to be imported. Then, when you are ready to finalize the import file, copy the columns F-H, and “paste special” to paste the values. Then delete columns A-E, and your import file should be ready:

[pic]

2 Checking the Change Sign checkbox for Imported Mappings

The Change Sign setting is incorporated into the Target Account column. If Change Sign should be checked for a given rule, then the Target Account value should be preceded by a hyphen. For example, if the Target Account value should be “100-1500”, then to cause the Change Sign checkbox to be checked for this rule, the value appearing in the Target Account column should be “-100-1500”:

[pic]

3 Create a Template to Import Data Load Mappings

An easy method for determining the proper Import Format is to first create a mapping rule manually using the procedures described above, and then using the Export feature to export the mapping rule. The resulting file will contain the proper format that should be used for importing rules.

To create a template to import Data Load Mappings:

1. Click the link located within the Data Load section on the Tasks navigator

[pic]

2. Select the Location for which mappings are being configured.

[pic]

3. Click the Multi-Dimension tab.

[pic]

4. Select the Dimension for which mapping rules are being created (either Profile or Source Type), click the Export button, and choose the Current Dimension option.

[pic]

5. In the Specify file location dialog, provide a file name, and click the Ok button. Once the import is complete, click on the name of the file in the file list and choose to save the file to your computer. Once saved, you can edit the file.

4 Re-Importing Mapping Rules

Mapping rules can be imported multiple times to either replace existing mapping rules, or to update mapping rules (using the merge option) so they match the configuration in the latest file. The merge option uses the Rule Name to identify records to be updated. If this option is selected, then any record in ERPi with a Rule Name that matches a Rule Name in the file will be updated.

Appendix 1: Supported Currency Codes

The following currencies are supported in ARM:

|AED |UAE Dirham |

|AFN |Afghani |

|ALL |Lek |

|AMD |Armenian Dram |

|ANG |Netherlands Antillean Guilder |

|AOA |Kwanza |

|ARS |Argentine Peso |

|ATS |Austrian Schilling |

|AUD |Australian Dollar |

|AWG |Aruban Guilder |

|AZN |Azerbaijanian Manat |

|BAM |Convertible Mark |

|BBD |Barbados Dollar |

|BDT |Taka |

|BEF |Belgium |

|BGN |Bulgarian Lev |

|BHD |Bahraini Dinar |

|BIF |Burundi Franc |

|BMD |Bermudian Dollar |

|BND |Brunei Dollar |

|BOB |Boliviano |

|BOV |Mvdol |

|BRL |Brazilian Real |

|BSD |Bahamian Dollar |

|BTN |Ngultrum  |

|BWP |Pula |

|BYR |Belarussian Ruble |

|BZD |Belize Dollar |

|CAD |Canadian Dollar |

|CDF |Congolese Franc |

|CHE |WIR Euro |

|CHF |Swiss Franc |

|CHW |WIR Franc |

|CLF |Unidades de fomento  |

|CLP |Chilean Peso |

|CNY |Yuan Renminbi |

|COP |Colombian Peso |

|COU |Unidad de Valor Real |

|CRC |Costa Rican Colon |

|CUC |Peso Convertible |

|CUP |Cuban Peso |

|CVE |Cape Verde Escudo |

|CYP |CYP |

|CZK |Czech Koruna |

|DEM |German Mark |

|DJF |Djibouti Franc |

|DKK |Danish Krone |

|DOP |Dominican Peso |

|DZD |Algerian Dinar |

|EEK |Estonia |

|EGP |Egyptian Pound |

|ERN |Nakfa |

|ESP |Spain |

|ETB |Ethiopian Birr |

|EUR |Euro |

|EUR |Euro |

|FIM |Finland |

|FJD |Fiji Dollar |

|FKP |Falkland Islands Pound |

|FRF |French Franc |

|GBP |Pound Sterling |

|GEL |Lari |

|GHS |Cedi |

|GIP |Gibraltar Pound |

|GMD |Dalasi |

|GNF |Guinea Franc |

|GRD |Greece |

|GTQ |Quetzal |

|GYD |Guyana Dollar |

|HKD |Hong Kong Dollar |

|HNL |Lempira |

|HRK |Croatian Kuna |

|HTG |Gourde |

|HUF |Forint |

|IDR |Rupiah |

|IEP |Ireland |

|ILS |New Israeli Sheqel |

|INR |Indian Rupee |

|IQD |Iraqi Dinar |

|IRR |Iranian Rial |

|ISK |Iceland Krona |

|ITL |Italian Lira |

|JMD |Jamaican Dollar |

|JOD |Jordanian Dinar |

|JPY |Yen |

|KES |Kenyan Shilling |

|KGS |Som |

|KHR |Riel |

|KMF |Comoro Franc |

|KPW |North Korean Won |

|KRW |Won |

|KWD |Kuwaiti Dinar |

|KYD |Cayman Islands Dollar |

|KZT |Tenge |

|LAK |Kip |

|LBP |Lebanese Pound |

|LKR |Sri Lanka Rupee |

|LRD |Liberian Dollar |

|LSL |Loti |

|LTL |Lithuanian Litas |

|LUF |Luxembourg |

|LVL |Latvian Lats |

|LYD |Libyan Dinar |

|MAD |Moroccan Dirham |

|MDL |Moldovan Leu |

|MGA |Malagasy Ariary |

|MKD |Denar |

|MMK |Kyat |

|MNT |Tugrik |

|MOP |Pataca |

|MRO |Ouguiya |

|MTL |Malta |

|MUR |Mauritius Rupee |

|MVR |Rufiyaa |

|MWK |Kwacha |

|MXN |Mexican Peso |

|MXP |Old Mexican Peso |

|MXV |Mexican Unidad de Inversion (UDI) |

|MYR |Malaysian Ringgit |

|MZN |Metical |

|NAD |Namibia Dollar |

|NGN |Naira |

|NIO |Cordoba Oro |

|NIS |Israel Shekel |

|NLG |Dutch Guilders |

|NOK |Norwegian Krone |

|NPR |Nepalese Rupee |

|NZD |New Zealand Dollar |

|OMR |Rial Omani |

|PAB |Balboa |

|PEN |Nuevo Sol |

|PGK |Kina |

|PHP |Philippine Peso |

|PKR |Pakistan Rupee |

|PLN |Zloty |

|PTE |Portugal |

|PYG |Guarani |

|QAR |Qatari Rial |

|RON |Leu |

|RSD |Serbian Dinar |

|RUB |Russian Ruble |

|RWF |Rwanda Franc |

|SAR |Saudi Riyal |

|SBD |Solomon Islands Dollar |

|SCR |Seychelles Rupee |

|SDG |Sudanese Pound |

|SEK |Swedish Krona |

|SGD |Singapore Dollar |

|SHP |Saint Helena Pound |

|SIT |Slovenia, Tolar |

|SKK |Slovakia, Koruna |

|SLL |Leone |

|SOS |Somali Shilling |

|SRD |Surinam Dollar |

|STD |Dobra |

|SVC |El Salvador Colon |

|SYP |Syrian Pound |

|SZL |Lilangeni |

|THB |Baht |

|TJS |Somoni |

|TMT |New Manat |

|TND |Tunisian Dinar |

|TOP |Pa’anga |

|TRY |Turkish Lira |

|TTD |Trinidad and Tobago Dollar |

|TWD |New Taiwan Dollar |

|TZS |Tanzanian Shilling |

|UAH |Hryvnia |

|UGX |Uganda Shilling |

|USD |US Dollar |

|USN |US Dollar (Next day)  |

|USS |US Dollar (Same day)  |

|UYI |Uruguay Peso en Unidades Indexadas (URUIURUI) |

|UYU |Peso Uruguayo |

|UZS |Uzbekistan Sum |

|VAL |Vatican City |

|VEF |Bolivar Fuerte |

|VND |Dong |

|VUV |Vatu |

|WST |Tala |

|XAF |CFA Franc BEAC  |

|XCD |East Caribbean Dollar |

|XOF |CFA Franc BCEAO  |

|XPF |CFP Franc |

|YER |Yemeni Rial |

|ZAR |Rand |

|ZAR |South African Rand |

|ZMK |Zambian Kwacha |

|ZWL |Zimbabwe Dollar |

Appendix 2: Troubleshooting

1 ODI Studio Error Message

If a message like the following appears in ODI studio, it means the Regenerate ODI Scenario button needs to be pressed on the Import Format configuration page:

Com.sunopsis.sql.SnpsMissingParametersException: ODI-30058: -SCEN_NAME parameter is mandatory.

at com.sunopsis.dwg.tools.StartScen.verifyProperty(StartScen.java:762)

at com.sunopsis.dwg.function.SnpsFunctionBaseRepositoryConnected.execute

Index

Accounting Entities, 19

Category Mapping, 16

Change Sign, 36

Currency Buckets, 6

Data Load Mapping, 9, 30

Create an import template, 37

Importing, 34

Data Load Process, 8

Data Load Rules, 9, 27

Dimension Details, 12

ERP Source Systems

Configuring Data Load Rules for, 27

Registering source systems for, 18

File Naming Convention, 5

File-Based Data Loads, 5

Configuring Data Load Rules for, 29

File columns, 6

Registering source systems for, 18

Import Format, 9

Import Formats, 21

Load, 8

Location, 9

Locations, 26

LOOKUP Dimensions, 13

Open Interface Method, 5

Registering source systems for, 18

Period Key, 15

Period Mapping, 14

Period Name, 15

Period Suffix, 5

Post-Processing, 8

Reconciliation Processes, 10

Regenerate ODI Scenario, 26

Related error messages, 42

Source System Segments, 6

Source Systems, 18

Source Types, 33

Staging, 8

Static File Name, 5

Target Application, 11, 12

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download