Overview of the Financial Services Accounting Hub for Implementers

Financial Services Accounting Hub Solutions

The Financial Services Accounting Hub includes the following elements:

Accounting Representations Closely Tied to the Originating Transactions

By providing an accounting representation closely tied to the originating transaction, the subledger accounting solution facilitates drill-down, third party control accounts, subledger reporting, and supporting references. Using the Financial Services Accounting Hub, companies can comply with fiscal subledger accounting and detailed audit regulations in countries where accounting must be supported by the source document.

Note: Supporting references can be used to store additional source information about a subledger journal entry either at the header or line level. They can also be used to establish a subledger balance for a particular source, for a particular account.

See:Accounting Representations

Flexible Application Accounting Definitions

Application accounting definitions are the journal entry setups including the following that are used to create subledger journal entries:

journal entry descriptions
journal line types
account derivation rules
supporting references

Flexible application accounting definitions enable you to control the manner in which subledger transactions are accounted. By providing this flexibility, the Financial Services Accounting Hub enables enterprises to tailor subledger journal entries to both local and vertical market needs. Standard cross-application features enable you to define and distribute application accounting definitions for different accounting standards and regulations.

See: Application Accounting Definitions, Oracle Subledger Accounting Implementation Guide

Multiple Representations

Multiple representations enable companies to maintain corporate global subledger accounting standards, while at the same time complying with detailed local regulations. For example, companies can create standardized financial reports in the presence of accounting standards and regulations that vary by region or country.

Scalability

Scalability enables users and others outside application development to create and distribute new application accounting definitions. Enterprises can rapidly define and distribute new or modified subledger application accounting definitions to meet specific and changing requirements for their accounting.

Accounting Representations

Typically, an accounting representation refers to all journal entries that are stored in a ledger. A ledger's subledger accounting method, accounting currency, calendar, and chart of accounts determine the nature of the accounting representation.

For example, the French Fiscal accounting representation refers to all journal entries stored in one of the ledgers created for the firm's French subsidiary. The French Fiscal accounting representation is generated using the French Fiscal subledger accounting method, Euro accounting currency, the French fiscal calendar, and French Fiscal chart of accounts.

The same firm can have a corporate accounting representation that refers to all journal entries stored in a separate corporate ledger. The corporate accounting representation is generated using the standard accrual subledger accounting method, U.S. dollar accounting currency, the corporate fiscal calendar, and a corporate chart of accounts.

Using the Accounting Methods Builder (AMB), you can create accounting representations for multiple ledgers.

Note: Using the AMB, you can create and modify subledger application accounting definitions. Group these definitions into subledger accounting methods and assign them collectively to a ledger.

See: Subledger Accounting Methods, Oracle Subledger Accounting Implementation Guide

Introduction to Events and Sources

Event Model

Accounting events represent transactions that have a financial accounting impact. Examples of accounting events are issuing an invoice and disposing an asset. Financial accounting information can be recorded for these events. Accounting events cannot be compared to system events and programs that update transaction tables; instead they should be analyzed from a business perspective. Events are captured when transactions are committed in the subledgers.

As an example, a Payables invoice is created, then approved, possibly adjusted, and then paid or canceled. The accounting events representing these transactions can create one or more subledger journal entries and subsequently link the originating transaction to its corresponding journal entries.

Accounting events are categorized into event types. Event types are grouped into event classes that in turn are grouped into event entities. These groupings play a prominent role in the setup of the AMB. The definition of several components in the AMB is by event class or event type.

See:

Accounting Methods Builder (AMB) Introduction, Oracle Subledger Accounting Implementation Guide

Sources and Source Data

Sources are a key component of the AMB. They are defined as the appropriate contextual and reference data of transactions. All contextual and reference data of transactions that are set up as sources can be used in an application accounting definition.

The sources that are most distinctly available are those that are purely accounting in nature. These include items such as Accounting Flexfields entered on transactions, currency codes, and currency amounts. Sources that are less obviously required for application accounting definitions include items that are related to the transaction, but not necessarily only for accounting purposes. These can include items such as the asset location, vendor information, or an organization used to book a Project Accounting expenditure batch.

With the AMB, users create custom application accounting definitions that determine how the transaction is accounted. Accounting definitions in turn use source values to create the accounting for a subledger transaction.

Implementers therefore need to furnish a broad variety of sources for maximum flexibility in creating definitions for subledger journal entries. Seeded sources are provided as part of the startup data of the application.

The Financial Services Accounting Hub differentiates between sources and source values. Sources are defined (seeded) in the AMB. This is a predefined step which must be undertaken before the Financial Services Accounting Hub can be used to create journal entries. Source values are stored in the transaction objects and the Financial Services Accounting Hub uses them to create journal entries for the events.

To enable the creation of subledger journal entries, implementers must complete seeding the sources in AMB and then storing source values in the transaction objects, which can be tables or views.

See: Introduction to Transaction Objects

Overview of the Financial Services Accounting Hub

The Overview of the Financial Services Accounting Hub figure below provides a high-level overview of the Financial Services Accounting Hub process used to create subledger journal entries and is described in the succeeding text.

Financial Services Accounting Hub Process Overview

the picture is described in the document text

Note: The enclosed numbers provide a chronological order to the diagram.

The above diagram illustrates the process used to create subledger journal entries.

The Financial Services Accounting Hub uses the AMB tool to create and modify subledger application accounting definitions.

In conjunction with these application accounting definitions, the Accounting Program uses the transaction objects data to create subledger journal entries. For example, if an application accounting definition specifies that the customer name should appear in the description of a subledger journal entry line, then the customer name is taken from the data provided by the transaction objects.
When transactions are committed in a subledger, accounting events are captured and stored in the Financial Services Accounting Hub.

The Accounting Program identifies all accounting events eligible to be processed. For each of these events, the transaction objects process provides the Accounting Program with transaction objects data (source information). This is the contextual data of the transaction, such as amounts and GL dates.
When the accounting program is run, application accounting definitions and accounting transaction objects data are applied to transactions to create subledger journal entries.

Subsequently, these entries can be summarized and transferred to General Ledger.

Financial Services Accounting Hub Uptake Process

Implementers seed startup subledger application accounting definitions. Users can use the seeded definitions, copy and modify them, or create their own definitions. These definitions are applied to accounting event information to create subledger journal entries.

Before creating or modifying application accounting definitions using the AMB, several components of the Financial Services Accounting Hub need to be set up. They include the following:

Accounting events
Source information
Default application accounting definitions

These initial setup steps are referred to as the Financial Services Accounting Hub uptake process.

The uptake process serves as the foundation on which other elements, such as new application accounting definitions of the architecture are constructed. While the Financial Services Accounting Hub provides the mechanisms for these elements, all implementers using the architecture need to complete the uptake process for their applications before users can create or modify application accounting definitions.

Financial Services Accounting Hub uptake involves the tasks described in the following sections and are fully described in successive chapters:

Summary Listing of Uptake Steps

The diagram below shows the order of tasks to be performed when implementing the uptake of the Financial Services Accounting Hub.

the picture is described in the document text

The table below lists the steps shown in the diagram above and are described in the succeeding sections. Complete these steps in the order shown to implement the uptake of a subledger application to the Financial Services Accounting Hub.

Uptake Steps
Step No.	Description
	Analysis
1.	Analyze accounting events to determine what events to capture for the subledger application.
2.	Analyze transaction objects requirements. These requirements determine what transactional or environmental information (source data) should be captured as well as the transaction objects data model and objects (tables and views) to store this data.
3.	Analyze and map the application's current subledger journal entries.
	Definition and Build
4.	Register subledger applications and seed event information (event entities, event classes, process categories, and event types) in the AMB.
5.	Code calls to the Financial Services Accounting Hub event capture routines.
6.	Build transaction objects programs and objects to store the source data.
7.	Run the Create and Assign Sources program.
8.	Revise source definitions and map accounting attributes.
	Integration
9.	Modify subledger application code to integrate with the accounting program and drill-down routines.
	Implement and Test
10.	Create application accounting definitions in the AMB.
11.	Perform comprehensive testing to ensure that all accounting is correctly generated by the Financial Services Accounting Hub.

Analysis

1. Analyze Accounting Events

Some business events have financial accounting significance and require the recording of financial information. These business events are known as accounting events. The Financial Services Accounting Hub is only concerned with business events that are accounting events. Examples of business events that are accounting events, include the following:

Issuing an invoice to a customer
Issuing a payment to a supplier
Retiring an asset

An accounting event and its associated transaction data typically relate to a single document or transaction.

See: Introduction to Events and Sources

The first task is to carry out a complete analysis to determine which events to capture. This task may need to be done in tandem with functional teams, to ensure that all possible events are accurately mapped. Event capture routines, described in Step 3. Analyze and Map Current Subledger Journal Entries below, can only trap accounting events that have been identified.

Complete the following analysis to identify accounting events:

Identify the life cycle of documents or business objects and the transactions that affect their status.
Identify events in the life cycle that may have fiscal implications.

All events that impact financial reports are significant and must be captured.
Identify all business events for which contextual data and transaction amounts are available.

This is not a mandatory requirement, but it provides maximum flexibility for creating application accounting definitions.

Oracle recommends that users thoroughly document all accounting events.

See: Introduction to Events and Sources

2. Analyze Transaction Objects Requirements

Sources are the appropriate contextual and reference data of transactions and are used to establish many of the items in a subledger journal entry. Complete an analysis to determine what information (source data) is necessary to successfully create subledger journal entries from transactions.

Flexibility in creating application accounting definitions is dependent on the number of sources available. Verify that all sources that can potentially be used to create subledger journal entries are included in the accounting transaction objects. The following list provides examples of sources:

Amounts (entered, accounted, and conversion data) and dates
Descriptions
accounts
Sequencing information
Third party details

Study the accounting transaction objects data model used in the Financial Services Accounting Hub. The data model provides detailed information on the different types of transaction objects used by the application. Accounting transaction objects are the views and tables that store transaction data in the standardized form required by the accounting program.

When specifying header, MLS header, lines, or MLS lines objects that are optional, specify them as single table views. If you specify optional objects as multi-table views, then could result in poor performance.

Data stored in transaction objects must also satisfy accounting transaction objects validation rules. These rules concern both completion and validation of the data.

See: Introduction to Transaction Objects

3. Analyze and Map Current Subledger Journal Entries

Complete an analysis of the journal entries currently generated by their applications and then compare this information to the options provided in the AMB. This exercise determines what AMB components must be seeded for their applications to enable the creation of those journal entries.

Seeded components include the journal entry descriptions, account derivation rules, and journal line types. These AMB components are referred to as subledger journal entry setup components. The objective is to make the upgrade to the Financial Services Accounting Hub transparent to users.

Such an analysis should, at a minimum, answer the following questions for the subledger journal entries created by the product:

Under what conditions are each of the lines in the subledger journal entry created?
Do the journal lines have actual, encumbrance, or budget balances?
What is the side, debit or credit, of each subledger journal entry line?
What description is used for the subledger journal entry?
How are the accounts derived for the entry?

This list is not comprehensive. Ensure that all elements of current accounting are analyzed and mapped to AMB components and seed data.

Definition and Build

4. Seed Events Information in AMB

Once the events are determined, event information is seeded into the AMB. The AMB is used to create application accounting definitions.

Note: Before seeding events information or sources in the AMB, register the applications with the Financial Services Accounting Hub.

See: Registering Subledger Applications

Each accounting event should be represented by an accounting event type. These types are registered in the AMB. When subledger journal entries need to be created, the event type determines which application accounting definitions should be used to process the accounting event. Application accounting definitions created in the AMB determine the lines, descriptions, accounts, and other elements of subledger journal entries.

You can also group event types that allows for the sharing of journal entry setups and source assignments for a collection of related event types. Group event types as event classes and event entities.

Event Classes (intermediate level of grouping)

Group accounting event types into user-orientated transaction categories called event classes. For example, group the event types Invoice Approved, Invoice Adjusted, and Invoice Canceled into the event class Invoices.

Then assign AMB components, such as journal line types, by event class within the application accounting definition. This assignment simplifies setup when the accounting requirements for all event types in a class are the same. Also, sources assigned to an event class are available for the accounting of all event types in that event class.

Event Entities (highest level of grouping)

Group event classes into technical transaction models called event entities. For example, group the event classes Invoices and Prepayments into the event entity Invoices because both classes of transaction are stored in the Payables invoice transaction table (AP_INVOICES_ALL). Event entities enable you to treat events for a single transaction model in the same way. The event entity often logically corresponds to a single document used as a basis for several related transactions.

The following windows in the AMB relate to the seeding of event information:

Entities
Event Classes and Types
Process Categories
Event Class Predecessors

See: Seeding Event Information Using Accounting Methods Builder (AMB) Introduction

5. Code Calls to the Financial Services Accounting Hub Event Capture Routines

Using APIs provided by the Financial Services Accounting Hub, create programs to capture their accounting events. The accounting program uses the events to create subledger journal entries.

The Financial Services Accounting Hub provides the following APIs for creating and updating accounting events:

Get Event Information APIs to get event information related to a document or a specific event
Create Event APIs to create accounting events, individually or in bulk
Update Event APIs to update events and keep them consistent with related transaction data
Delete Event APIs to delete events

See: Seeding Calls to Subledger Event Capture Routines Introduction

6. Build Transaction Objects and Programs

The transaction objects process captures source data for accounting events and stores them in transaction objects. To successfully process the accounting event, the accounting program selects the source values it requires from these transaction objects.

Implementers are responsible for building and supporting the transaction objects. Complete the following tasks to accurately secure and prepare the transaction objects data:

Create transaction objects that are used to store the transaction objects data.
Write programs that populate the transaction objects with source values for each accounting event.

Note: First register all transaction objects in the AMB.

There are four types of accounting transaction objects as listed below. The differences in these objects relate to whether they are used for header, line level, or ledger currency sources and whether they hold translated values. The accounting transaction objects are as follows:

Transaction Objects Headers for untranslated header level sources
Transaction Objects Headers MLS for translated header level sources
Transaction Objects Lines for untranslated line level source values
Transaction Objects Lines MLS for translated line level sources

Transaction Objects table or view names are accounting event class specific. The Create and Assign Sources program uses the transaction objects column names to generate source codes.

It is possible to define multiple tables or views for a single transaction object type and event class. For example, define two transaction objects line tables or views for the event class Invoices.

It is also possible for event classes to share transaction objects. For example, use the same transaction objects line table or view for the event class Invoices and the event class Credit Memos.

See:

Types of Sources
Overview of Building Your Database Objects, Oracle Applications Developer's Guide
Overview of Using PL/SQL in Oracle Applications, Oracle Applications Developer's Guide

7. Run the Create and Assign Sources Program to Seed Sources in the Financial Services Accounting Hub

The Create and Assign Sources program automatically generates sources and source assignments based on the transaction objects definitions that are established in the previous step. (The transaction objects column names are used to generate sources.) These sources are available to create journal entries for transactions in the subledger and are part of the startup data for the Financial Services Accounting Hub. By seeding sources and source assignments, the program ensures a consistency between accounting transaction objects and the source and source assignments.

The Create and Assign Sources program also validates the transaction objects and journal entry setups as follows:

The program verifies that each transaction object exists for an event class and that it is valid.
If sources or source assignments exist, the program validates that the definitions are consistent with the transaction objects.
If accounting attributes are mapped, the program validates that these mappings are consistent with the accounting attribute definitions.

See: Create Sources and Assignments

8. Revise Source Definitions and Assign Accounting Attributes

Once the Create and Assign Sources program has completed successfully, revise the source definitions before they can be used in the Financial Services Accounting Hub. These revisions include the following:

Source names should be consistent with the Financial Services Accounting Hub attribute naming standards.
Sources that correspond to Accounting Flexfield identifiers should are marked as Accounting Flexfield.
Whenever appropriate, sources should have lookup types or value sets assigned.
Sources that implementers anticipate will be used frequently in journal entry setups should be marked as displayed.

Manual Creation and Assignment of Sources

If users choose to manually create sources instead of running the Create and Assign Source program, then a source definition includes manually assigning each source to event classes. Assigning sources to an event class makes them available for creating application accounting definitions using that class.

Assigning Sources

Once standard sources are assigned to event classes, you may need to assign them to accounting attributes. Accounting attributes are a special category of standard sources. If an accounting attribute is relevant to the accounting event's underlying transaction, then its value is required to generate subledger journal entries for the transaction. Examples of accounting attributes are Entered Currency Code and Entered Amount.

Use the following windows in the AMB to seed and assign sources and accounting attributes:

Sources
Source Assignments
Accounting Attribute Assignments

See: Revise Source Definitions and Assign Accounting Attributes Introduction

Accounting Program Integration

9. Integrate Subledger Applications with the Accounting Program

To enable the implementation of the Financial Services Accounting Hub, integrate the Create Accounting program into their applications. For Oracle Applications, this integration is made using APIs. For customizations, the Financial Services Accounting Hub provides workflow business events.

In addition, there are some changes that need to be undertaken to application windows. Some of these changes are as follows:

Change application windows to accommodate the Financial Services Accounting Hub solution.

This includes changing application windows to call the Create Accounting program.
Remove obsolete windows and menu options.

For example, options to transfer journal entries to the General Ledger become obsolete upon the uptake of the Financial Services Accounting Hub.
Add the Financial Services Accounting Hub menu options.

The Financial Services Accounting Hub provides seeded menus for users and implementers.

The menu options should be added to seeded application responsibilities as appropriate.

See: Accounting Program Workflow Business Events for Non-Oracle Ledgers

Implement and Test

An application accounting definition is a grouping mechanism in the Financial Services Accounting Hub used to assemble a consistent set of application accounting definitions for an application. The application accounting definitions determine the accounting for an application's events.

An Application accounting definition includes assignment of the following components:

journal entry descriptions (both header and line)
journal line types
account derivation rules
journal lines definitions
supporting references

All of these components along with the application accounting definition are created in the AMB. To users without custom requirements, the upgrade to the Financial Services Accounting Hub should be transparent. Therefore, application accounting definitions that replicate the pre-Financial Services Accounting Hub uptake journal entries, need to be seeded in the AMB.

The following sections describe the tasks that must be completed to create application accounting definitions.

10. Seed Application Accounting Definitions in the AMB

Seed default subledger journal entry setup components in the AMB. These setups are assigned to startup application accounting definitions.

The startup application accounting definitions should enable users to create subledger journal entries that are equivalent to the accounting generated before the uptake of the Financial Services Accounting Hub. For implementers, the goal should be to at least replicate the current default subledger journal entries. However, users can choose to enhance a subledger journal entry using any of the features provided by the AMB.

You can attach conditions to many of these components. A condition combines constants, source values, and operands and indicates when a particular journal line type, description, or account derivation rule should be used based on the source values.

All subledger journal entry setups are assigned to an accounting event class or type to determine how subledger journal entries for that class or type should be created.

Once the seed data is created, users must set up at least one application accounting definition for every subledger application.

See: Application Accounting Definitions, Subledger Accounting Implementation Guide

This section describes the components that must be seeded for subledger journal entry setup.

Journal Line Types

Journal line types determine basic information about a subledger journal entry line. Such information includes whether the line is a debit or credit, whether it should be transferred to the GL in summary or detail mode, whether matching lines should be merged, and its balance type (Actual, Encumbrance, or Budget).

Journal Entry Descriptions

Descriptions are included on subledger journal entry headers and lines. Include constant and source values in descriptions.

Account Derivation Rules

Account derivation rules determine which account should be used for a subledger journal entry line.

Journal Lines Definitions

Journal lines definitions enable users to group and assign journal line types, account derivation rules, and journal entry descriptions into a complete set of journal entry setups for an event class or event type. These sets can be shared across application accounting definitions for the same application.

Supporting References

Supporting references can be used to optionally store additional source information about a subledger journal entry and are useful for accounting reconciliation and analysis.

11. Test the Uptake of the Financial Services Accounting Hub.

Once the setup is complete, testing should be comprehensive to ensure that all accounting is correctly generated by the Financial Services Accounting Hub. Testing by implementers must incorporate accounting events, transaction objects data, and seed data. This should, at a minimum, include the following:

Test that accounting events are successfully created.

In addition, an accounting event must only be created when appropriate.
Test that the sources seeded in the AMB are available for creating subledger journal entries.

This should include testing sources that are not included in the default or seeded application accounting definitions.
Test that subledger journal entries are successfully created for accounting events.

This includes, where appropriate, testing of reversing, cross currency, and deferred subledger journal entries.
Test that subledger journal entries contain the appropriate dates, amounts, descriptions, and accounts.

If conditions are used to determine journal line types, account derivation rules, or descriptions, test these conditions as well.
Test that all the subledger journal entries and lines are of the appropriate balance type (Budget, Actual, or Encumbrance).
Test that all the seeded application accounting definitions can be successfully copied and modified by users.
Test that all entries are successfully summarized when transferred to General Ledger if the summarization option is selected.
Test that all the subledger journal entries can be successfully transferred and posted to General Ledger.
Test that the accounting program creates subledger journal entries, transfers them, and posts them to General Ledger.
Test that it is possible to successfully run inquiries on subledger journal entries using the Financial Services Accounting Hub inquiry functionality.
Test that upgrade strategies are successful.

The above list is not intended to be comprehensive. Determine and complete appropriate testing before releasing the Financial Services Accounting Hub for your application.

The following points on security and upgrading security must also be taken into consideration when implementing the uptake of the Financial Services Accounting Hub.

Security

Incorporate event security guidelines when integrating with the Financial Services Accounting Hub.

As the implementation of the uptake to the Financial Services Accounting Hub is generic for all applications, the architecture provides a common solution to enforce event security. Event security refers to the way in which subledger accounting events are secured; only events to which users have access, under the subledger's security mechanism, are eligible to be processed.

The Financial Services Accounting Hub secures events by storing the security context of the transaction to which the event belongs. As an example, consider a transaction secured by operating unit. When events are created for the transaction, subledgers provide the operating unit data as well. This information is stamped on the event representing that transaction. Events inherit the security of their source transactions.

Determine the security policies needed to establish security on accounting events. Guidelines are provided to help you set up your application security when integrating with the Financial Services Accounting Hub.

See: Financial Services Accounting Hub Security Introduction

Upgrade Strategy

Complete an upgrade strategy for your application. The strategy should address the following issues:

The cutover mechanism for current customers

This ensures that all transactions completed before the uptake of the Financial Services Accounting Hub are accounted. Otherwise, it might be necessary to create events during the upgrade to account for transactions that are completed before the uptake.
The need to modify or remove accounting options that are obsolete due to the uptake of the Financial Services Accounting Hub.

Complete an analysis of current accounting options to determine which ones to make obsolete. Then devise a strategy for eliminating or migrating these options to the Financial Services Accounting Hub.
Changing or eliminating accounting based subledger reports

Since applications no longer store journal lines, any reports based upon such lines must be examined.

Consider whether the Financial Services Accounting Hub reports fulfill their requirements, thereby making current reports obsolete.
Removal or modification of journal entry inquiries

The Financial Services Accounting Hub includes inquiries on both accounting events and subledger journal entries. However, Financial Services Accounting Hub inquiries can only be used to inquire on entries created by the Financial Services Accounting Hub.

Roles in the Uptake and Use of the Financial Services Accounting Hub

Although the term implementer is used throughout this guide, multiple roles are involved in the uptake and use of the Financial Services Accounting Hub. Whereas there may be some overlap of the tasks described in this chapter, the primary roles are as follows:

Note: All roles should take part in testing to ensure that accounting is correctly generated by the Financial Services Accounting Hub.

See: Summary Listing of Uptake Steps

Application Analyst

The application analyst first undertakes a complete analysis to determine what events to capture. This analysis results in identifying all relevant events and their attributes. In addition, an analysis of events establishes the information to set up event entities, event classes, and event types.

Application analysts also analyze transaction objects requirements to determine what information (source data) is necessary to successfully create subledger journal entries from transactions. All sources that are required to complete the journal entry must be identified.

Finally, application analysts analyze and create application accounting definitions for a subledger.

See: Application Accounting Definitions, Oracle Subledger Accounting Implementation Guide

Implementer

Using event information provided by application analysts, implementers perform the following tasks:

Seed event information like event entities, classes and types in the AMB
Code the API calls to event capture routines
Define transaction objects to store the source values
Write programs that populate the transaction objects with source values for each accounting event
Run the Create and Assign Sources program to define and assign sources

These sources are available to application accounting definitions that create subledger journal entries. Before using them, certain source attributes must be revised. They must also be assigned to accounting attributes in the AMB.
Integrate their applications with the accounting program

User

User refers to the following:

Subledger accounting implementers who seed the appropriate application accounting definitions in the AMB to enable the creation of journal entries

These definitions include those for journal entry descriptions, account derivation rules, journal line types, journal lines definitions, and supporting references.
Implementers who define and modify application accounting definitions on an ongoing basis as required by the business environment
Users who submit the accounting program to create subledger journal entries for transactions that have taken place

Secondary or Reporting Ledger Historical Upgrade

Using this functionality you can upgrade your secondary and reporting ledger data into Financial Services Accounting Hub.

If you are a:

New Oracle Applications Release 12 customers and have a Secondary or Reporting ledger to an existing primary ledger that has open transactions
Existing customer who upgraded from previous releases of Oracle Applications and then added Secondary or Reporting ledger to the Primary ledger

This utility lets you create Secondary or Reporting ledger representations for the newly added Secondary or Reporting ledger in Subledger Accounting tables. You can choose the historical starting period for converting the transactions. Secondary or Reporting ledger representations are created based on the Primary ledger data by using the exchange rate on the initialization date in the setup. All the historical transactions are converted based on single exchange date so there are no exchange gain or loss.

Prerequisites

The following prerequisites apply to this feature:

Exchange rate exists between all the transaction currencies and the reporting functional currency for the initialization rate date and type.
All the SLA data for the primary ledger is balanced.
Data in the reporting ledger may not be balanced (that is sum of the accounted debit may not be equal to sum of the accounted credit for a given header).
Data is committed after all the records are inserted in the tables for any given period. If the volume of transaction is high, then sufficient rollback segment size must have been used.
You cannot update the Enable ALC flag. If you add a Secondary or Reporting ledger and run the upgrade utility, then the entries are not replicated for that Secondary or Reporting ledger if the application is not ALC enabled in SLA.
You cannot drilldown from GL as entries replicated are not transferred to GL.
Secondary ledger conversion is not performed if the secondary ledger SLAM is different from the primary ledger. The secondary ledger only the currency, chart of accounts, or calendar may differ during conversion from the primary ledger.

The upgrade utility for SLA resolves the open, reversible, and future dated transaction conversion issues by converting the transactions to the Secondary or Reporting ledger. To maintain consistency and synchronization between the Secondary or Reporting ledger amounts in SLA and General Ledger, all transactions are converted using a daily rate based on the user-defined conversion rate date and conversion type. Run the utility for each reporting currency separately Convert all transactions using a daily rate based on the user defined conversion rate date and conversion type. The utility converts from the transaction currencies to the Secondary or Reporting ledger. If the transaction currency is same as the Secondary or Reporting ledger then the utility converts it using an exchange rate.

Fixed Number of Periods

This utility does not convert transactions that are prior to fixed number of periods even though they may not have completed the accounting life cycle. You have rerun the upgrade utility for those periods that may have open transactions.

Initial Balances for Supporting References

You can uploade initial balances for Supporting References (also known as Analytical Criteria). Initial balance is the starting balance for a supporting reference (Analytical criteria) in context of an application, ledger and CCID. There is no Journal Entry in SLA to support initial balances. Initial Balance is in the Ledger currency.

Defining Initial Balance for Supporting Reference Source Value

You define initial balances for a supporting reference source value combination for applications such as ledger and CCID. An initial balance is in the ledger currency for a period and contribute to the supporting reference source value combination balance calculated on any day going forward the date of initial balance.

The balance for supporting reference source value combination on any period prior to the date of initial balance will be non-existent.

You can define initial balances as Net of Debit and Credit balance. You can define initial balance for a closed period and even after the SAL has created balances and entries for supporting reference value.

Updating Initial Balances

Once the initial balance has been entered, you can modify the initial balance. It impacts balances in the periods following the initial balance.

To change the initial balance, upload a record for the same period, ledger, CCID for the supporting reference detail value combination for which the initial balance is uploaded. The program adds the delta (difference between the original uploaded value and changed value) to subsequent balance records.

Deleting Initial Balances

You can delete initial balances.

To insert or update Initial Balances for Balances by Supporting References:

Upload data into the interface table.
Submit concurrent program to Import data from interface table into the base table.
View report generated from the concurrent program.

Upload Data to Interface Table

You can use the PL/SQL to load this interface table with control account initial balances from the legacy systems. Other EBS suite products, such as Oracle Lease Management can compute the initial balances for their seeded supporting references and populate this interface table.

Import Supporting References Initial Balances Concurrent Program

A concurrent program, Import Supporting Reference Initial Balances, is added to import data from interface table to the base table. This concurrent program is submitted as a request from SRS form.

Import Supporting Reference Initial Balances Using the XML Publisher Template

This feature includes a new template, Import Supporting Reference Initial Balances Report, to provide information about the Import Supporting Reference Initial Balances process. You can implement using this for data migration from Legacy systems for uploading balances.