Oracle R12 Upgrade - Sub Ledger Accounting

Outcomes-Driven Value-Centric.
Sub Ledger Accounting:
In line with R12 upgrade from 11i

In R12, Oracle has introduced new functionality named Sub ledger accounting.
Oracle Sub ledger accounting is a rule based engine, for generating accounting
entries based on source transactions from all the modules of Oracle application.
This paper covers brief introduction to Sub ledger accounting with its key
features. This paper also attempts to cover the technical upgrade process for
11i customer, who wishes to upgrade from Oracle E Biz 11i to Oracle Release
12. Briefly this paper touches the set up process and bottom up account building
process required to make Sub Ledger accounting functional in Implementation or
upgrade process.
Release 12 of Oracle has significantly improved the accounting capabilities of
E Business suite. Sub ledger accounting is a rule based accounting engine
that centralizes accounting for Oracle E Business suite products. Sub Ledger
accounting is not a separate product in itself, but is Oracle’s engine catering to
the accounting needs of Oracle Applications.
Earlier accounting events were stored within individual sub ledgers. In Oracle
R12, a new schema (XLA) is defined and the accounting events were stored
within centralized data model. Within the same engine, Oracle released a new
functionality named as ‘Accounting method builder’. With this functionality users
will be able to define and maintain custom accounting rules. Previously, this was
handled by Work flow Account Generators. However accounting method builder
is not replacing workflow account generator, and can be used in conjunction.
Introduction

Accounting method builder is more robust and user friendly and together
with new ledger support, sub ledger accounting enables support of multiple
accounting requirements, concurrently in a single instance. Different accounting
regulations can be satisfied by maintaining and applying different sets of
transactions; or accounting for the same transaction with multiple methods.
There are no sub ledger accountings responsibilities and sub ledger accounting
forms are embedded within standard Oracle application responsibilities (e.g.
Costing Manager, Payable Manager, etc). Sub ledger accounting provides
following services to Oracle applications
• Generation and storage of detailed accounting entries
• Flexible Journal Entry Set Ups
• Storage of Subledger balances
• Subledger accounting entries along with
bi-directional drilldown to transactions
• Subledger reporting
• Multiple Accounting Representations
Key Features of Sub Ledger Accounting
In 11i, the account used during transaction flows to the GL, and there is no
option of configuring the accounts once the distribution is created. While in
R12, account re configuration is possible event after transaction is recorded in
Subledger.
The difference between 11i and R12

To further understand this, we will take example of one application (Cost
Management) and explore it. And we will consider following three scenarios for
better understanding,
1. No customization in SLA
2. Customization in SLA for changing GL Code of combinations
3. Creation of shadow journals for reporting purpose
If a company chooses to pass the accounting as it is, there is no customization
required. This application came as hand in and completely integrated with other
modules of Oracle e-business suite. The customization or transformation terms
used in SLA refer to GL code combination or additional entries required only.
SLA is required in R12; it’s not option but mandatory requirement. The data first
pass to Subledger accounting engine before moving to General Ledger.

Let say, Inventory application creates an accounting entry for X.Y.Z Account and
would like to see this code as it is in General Ledger,
Let say, Inventory application creates an accounting entry for X.Y.Z Account and
would like to see this code as X.Y1.Z1 in General Ledger
Oracle provides seeded rules and set up, by using that, this can be achieved,
without any customization. This is standard functionality.
No customization in SLA (Seeded Set up)
Customization in SLA for changing GL
Code of combinations
This can be achieved by attaching custom rules to Event types, however as per
Oracle suggestion if implementer has to change the seeded rule, he/she has to
copy the custom definition (or seeded set up) and then make the changes. This
would affect the entire chain in SLA set up.

Creation of shadow journals for reporting purpose
This is the most important and significant change, which oracle has introduced
through Sub Ledger accounting. Let us take an example, of “Smart Inc”
organization; it might have operations in France, which is “Smart Inc France” and
with UK being the parent company, the French company has to do accounting
journals in formats that can be reported as per French legislation and also as
per UK legislation. For example, in France an inventory item is accounted as
expense, whereas in UK the inventory item is accounted as an asset. In the
example below, X.Y.Z is never passed to the GL. Instead to GL X.Y1.Z1 is
passed to the Primary Ledger FRANCE and X.Y2.Z2 is passed to the Secondary
Ledger UK. The picture below shows the role that SLA plays in such scenario.
*Cost Management used above is just for an example, similar results can be
achieved with all other Sub ledger applications as shown in following diagram,

Account Generators to SLA (11i to R12)
On upgrade from Release 11i to Release 12, all Account Generators are
retained. It is Oracle’s recommendation that post upgrade users transition
account generation from the Workflow Account Generators to the Subledger
Accounting Engine. The Subledger Accounting Engine will be the technology
moving forward and Workflow will not be technology available in Fusion.
In Fixed Assets, the FA Account Generator (FAFLEXWF) is retained. A new
profile option, FA: Use Workflow Account Generation is set to Yes by default.
Once rules are defined in the Accounting Methods Builder and the custom
account generation is accomplished by the Subledger Accounting Engine, set
the Profile Option to No. Picture 6 shows the account derivation rule in SLA.
Note that two different accounts are generated based on the conditions that are
set. The first rule which is selected uses the Account generated by the Workflow
Account Generator.

Notice that the condition is ‘Generated Code Combination Identifier IS NOT
NULL’. So, if the account is generated by the Workflow Account Generator, use
the generated account. Otherwise, use the default account. So even if using the
Workflow Account Generator, SLA still has rules to manage for that scenario.
The Fixed Assets Account Generator has three journal type account levels: Book,
Category, and Asset. Journal types are divided up into the different account
levels. SLA now provides greater flexibility because it does not utilize journal
type account levels. Every journal type can be modified individually to book
according to requirements, so users are not required to have only one account
generation methodology for a journal type account level. On a side note, in SLA
each Fixed Assets book can now feed a ledger directly. Users can have multiple
representations for both corporate and tax books.

Even with the SLA account derivation, AutoAccounting setup in Receivables
and Projects is still required. AutoAccounting creates the default accounts for
transactions. The SLA accounting rules are configured to accept these default
accounts without change. Optionally, additional user-defined accounting rules
can be defined in SLA. These SLA rules will override default accounts or
individual segments of accounts. One of the reasons AutoAccounting setup is
still required is because the default accounts are used for processing before
being transferred to SLA. For example, Oracle Projects cost distribution, revenue
generation, and accounting event generation processes require AutoAccounting
to create default accounts during processing. SLA allows multiple Receivables
distributions. However, they are not definable in AutoAccounting, only in SLA. By
utilizing configurable account derivation in SLA, users could reduce the number
of Transaction Types needed in Receivables to support AutoAccounting. It is
recommended that users setup basic default accounting in AutoAccounting and
then let SLA override this accounting using rules based on user requirements.
It is important to realize that accounting rules can only be applied to transactions
coming from the subledgers. Manual Journal Entries and/or entries uploaded
through Web/ADI are not processed by the subledger accounting engine
and therefore cannot leverage user-defined accounting rules. The following
subledgers (see Figure 2) use the Subledger Accounting Engine when
accounting entries are generated. Following applications are integrated with SLA,
Purchasing Asset Receivables
Payables Cash Management Intercompany
Cost Management Process Manufacturing Projects
Payroll Loans Lease Management
Property Manager Public Sector/Federal Globalizations

Implementation considerations –
R12 SLA (Subledger Accounting) Pre-Upgrade program
• SLA Pre Upgrade program
• Historic data conversion
• SLA Post Upgrade program & Hot patch
• SLA Set up
During the upgrade, existing accounting data from the subledgers (i.e., AR, AP)
is upgraded into the new Oracle Subledger Accounting (SLA) data model. By
default, the upgrade updates the data for the current fiscal year, as well as the
necessary periods of the previous fiscal year, to ensure that there are at least six
periods included in the upgrade (occurs when the upgrade is performed in the
first half of the fiscal year). This is the minimum downtime upgrade.
You may need to run the SLA Pre-Upgrade program if you are using Oracle
General Ledger and at least one of the following subledgers: Assets, Cost
Management, Payables, Receivables, Purchasing, or Project Accounting. This
optional program allows changing the default number of periods of historic data
to be upgraded.
The R12 SLA Pre-Upgrade program is run on your 11i instance. In order to run
the R12 SLA Pre-Upgrade program to change the default number of periods
of historic data to upgrade, you must apply Patch 5233248 to your Release
11iAPPL_TOP and submit the SLA Pre-Upgrade Program.

Historical Data
As per Oracle, “Evaluate your business requirements carefully with regards
to historical data before deciding how far back you wish to keep detailed
accounting information. The R12 SLA Upgrade will upgrade the transactions in
the accounting periods you specify. Your decision can have an impact on the
increased data volume and your system resources. We recommend that you
upgrade the data that you need.
Some Key notes
1. The records considered by pre-upgrade program are for AP, AR, Project
Accounting, FA, Inventory /Costing and PO products only.
2. The accounting period under consideration must be a NON-Adjustment
period.
3. The period has a status of closed, open, future, and never opened.
4. The GL_PERIOD_STATUSES table is updated by pre-upgrade program.
5. The R12 SLA Pre-Upgrade Program does not perform the actual upgrade.
This program writes out to the GL_PERIOD_STATUSES table. It is the subledger
(i.e., AP, AR, FA, Costing etc.,) upgrade programs that actually perform the
upgrade by reading the accounting information in the subledger (FA, AP, AR
etc.,) tables and writing the corresponding records to the SLA tables for future
reference.
6. The R12 upgrade works differently for AP transactions. For AP only, all
records in the ap_accounting_events_all, ap_ae_headers_all, and ap_ae_lines_
all tables are upgraded into the respective SLA tables. Only the xla_distribution_
links records for AP are migrated based on the xla_upgrade_dates and the
accounting period in the gl_period_statuses tables

For example, upgrade data for periods that have open transactions--i.e., invoices
that have not been paid and invoices you plan to cancel. You will also need
historical data to clear payments, cancel payments, and reconcile payments.”
The SLA pre-upgrade program selects the first date of the current fiscal year as
its START DATE. If there are not enough periods to make up 6 months, then the
system will look at the periods in the prior fiscal year.
Current Accounting Period
in Fiscal
R12 downtime upgrade
Default
R12 downtime upgrade
Default R12 SLA Pre-
Upgrade Program
Sep-11 Jan-2011 to Sep-2011 Allow you to specify the
number of periods
Feb-11 Sep-2010 to Feb-2011 Allow you to specify the
number of periods
R12 SLA Post-upgrade program and Hot Patch
If you do not perform a complete upgrade of the accounting data, Oracle
Subledger Accounting allows you to perform an additional upgrade of the data by
running the SLA post-upgrade process whenever the missing data is required.
SLA hot patch can be run during uptime to upgrade historical data, if user chose
to only a partial or minimal upgrade during downtime. Before running any SLA
post-upgrade process (i.e., SLA Hot Patch), user must enter the initial date to be
used to determine the initial period to be upgraded. This date is entered in the
SLA: Initial Date for Historical Upgrade profile option. This profile option must be
populated in order to run the process. Run the process as follows:
1. Run AutoPatch with options=hotpatch.

Technical flow of the R12 SLA Upgrade
2. Specify $XLA_TOP/patch/115/driver/xla5584908.drv when prompted for the
unified driver.
Note: The SLA Hot Patch can be run multiple times, each time by specifying a
date that covers a range that has not been upgraded.
Caution: Running the Hot Patch could take several minutes or several hours to
complete depending on the date range you specify and the amount of data to be
upgraded.
This is the technical flow of the R12 SLA Upgrade, which is performed in the
main r12 udriver file.
1. Identify what accounting periods will be upgraded. The periods to be
upgraded depend upon the minimum Downtime upgrade or initial period setup in
the pre-upgrade or uptime upgrade. (Files Used: XLA_UPGRADE_DATES and
GL_PERIOD_STATUSES )
2. The periods to be upgraded are stamped with an intermediate status
(P-pending). (The same set of periods are populated in the XLA_UPGRADE_
DATES)
3. The data in the Subledger accounting tables are upgraded into the SLA
accounting tables. (The periods in the XLA_UPGRADE_DATES is checked in
this step)
4. The Subledger products call the SLA API to update the period status
column in the General Ledger. They stamp the data for the periods specified to
indicate that they have been upgraded (U-upgraded). The SLA API stamps the
GL_JE_HEADERS table for the upgraded applications. The column je_from_sla_
flag=U is also stamped.
This completes the R12 SLA Upgrade cycle.

Set up considerations
Since SLA is a new enhancement in Oracle R12, we should know few
terminologies,
Accounting Method Builder:
Accounting Method Builder (AMB), enable users to define accounting rules using
Standard Oracle Forms. The AMB gives users the ability to create and maintain
user-defined accounting rules. This provides the user with great flexibility while
maintaining necessary control. Users can also more easily comply with multiple
geographic, legislative, or industry requirements. By putting accounting rules
in place, manual journal entries and customizations can be reduced. An added
benefit is that because these user-defined accounting rules are created and
maintained through the forms, all user-defined accounting rules will be retained
in subsequent upgrades. The AMB supports logic such as prioritization and
conditional statements without using SQL
To customize an accounting method, users must create a user-defined
Subledger Accounting Method. A Subledger Accounting Method is composed of
multiple Application Accounting Definitions. For example, the Standard Accrual
Subledger Accounting Method is made up of the following Application Accounting
Definitions: Asset Standard Accounting, Cash Management Standard Accounting,
Load Standard Accrual, Cost Management, Accrual Basis (which is the Payables
definition), Process Standard Accounting, Projects Standard Accounting, Property
Manager Normalized Accounting, and Receivables Default Accrual. Notice these
represent the different sub ledgers that will create accounting entries in the
General Ledger.
Set up considerations

Subledger Accounting Method (SLAM) - This is the Subledger accounting
method that is built and assigned to a Ledger. This will be created via the
Accounting Methods Builder and includes all the details needed to create the
appropriate journal entries.
Application Accounting Definitions (AAD) - The application accounting
definitions is made up of the Journal Line Definition, Journal line types, and
Accounting Derivation Rules. These are developed using the event classes and
types. A new AAD can be created or a seeded AAD can be used. The details are
assigned and validated to be certain the setup at this level is correct.
Journal Line Definitions (JLD) - JLT, ADR and JED are combined to create the
JDL for an event. These can be shared across AADs and can be used to create
sets of line assignments for event classes and types.
Journal Line Types (JLT) - The types are defined for each particular class to be
used. These must be assigned to the Journal Line Definition (JDL) to be used.
These determine the journal entry line options to be used. These options include
identifying the natural side used (debit, credit, gain/loss), accounting class,
summarization, and other conditions that will cause the rule to create a journal
entry.
Accounting Derivation Rule (ADR) - This is used to determine the accounting
combinations that will be used for the journal entries. Various rules can be
defined. These can be defined by segment, accounting combination, or value set.
The simplest way to derive an account is to establish the account as a constant
value-use the account combination that is defined in the accounting chart of
accounts.

Mapping Sets -These sets are optional and user defined. If the user determines
that the seeded details are insufficient, then mapping sets can be setup to allow
for more specialization in the accounts. This is not supported by development
as this would require customization. Seeded details are supported as they are
provided by Oracle code.
Transaction Objects/Sources- Transaction objects and sources carry
transaction information into the rules defined for the accounting chart of
accounts.
Event- An event is the recording of a change of status in the transaction life
cycle, i.e., invoice approved, payment received, period close, etc. These are
defined for each SLAM used. Event classes and event types are used to create
the events to be used
Event Class- This classifies the types of transactions that are to be accounted
for. An example of an event class is WIP Variance.
Event Type- This defines actions that are possible for an event class that has
potential accounting significance. Examples for the WIP Variance Event CLASS
would have event TYPES defined for Period Close Variance, Job Close Variance,
and Final Completion Variance

Basic Steps to Build Accounts

The process is built from the bottom up as mentioned below,
1. Create Account Derivation Rule (ADR). The source information in the ADR
refers to various distribution tables.
2. Define conditions required for the ADR created in step 1.
3. Create Journal Line Definitions (JLD) for an event class
a. Query the LOV of seeded event classes
b. Copy the seeded event class using the Copy Definition button
c. Replace existing ADR in the Journal Line type form with the new ADR.
This is in the Line Assignments sections, using Line Type
4. Create new Applications Accounting Definition (AAD)
a. Query for the seeded AAD
b. Copy from this to create a new AAD
c. Associate the new JLD assignments created in Step 3
d. Validate the definition. If successful continue to next step or continue
creating the JLDs required. If unsuccessful, check the setup for all steps above
before moving to next steps.
5. Associate the new AAD with the Subledger Accounting Method (SLAM)
a. Query SLAMs to view existing methods
b. For the existing AAD enter an end date to stop this from being used
c. Attach the new AAD with the start date
6. Assign the SLAM to the Ledger
Each of these definitions except sources can be copied and modified from the
Oracle seeded definitions to meet your accounting needs. Sources are the
components of a transaction such as a supplier or distribution line. If a user
needs a customized source then a developer must develop custom code and it
can be plugged into the list of sources.

When replicating Account Generator logic in the Subledger Accounting Engine
using the Accounting Methods Builder the components highlighted in red will
have to be copied and modified. Notice that even though the Account Derivation
rules is the component that is the focus of the account generation each of the
components above this have to be copied and modified all of the way up to the
Subledger Accounting Method.
If a customer has 11i instance with very complex customization, in deriving
the accounting configuration, they can prefer to use the old customizations
in upgraded instance (R12) also. However extensive testing is required in
migrating custom code and this can be balanced out from investing in Sub
ledger accounting. Some of the technical customization can be avoided by using
source and mapping based accounting rules; however possibility of the technical
customizations at code level cannot be ruled out in Sub ledger accounting.
Most of the customers use SLA functionalities for out of box solution for account
transformations and also configure the accounts at sub ledger level for complex
requirements. This is completely situational and has to be a business decision
and should be treated on individual customization level.
Business considerations

1. Oracle Subledger Accounting Implementation Guide (B13984-02)
2. R12.0 and R12.1: FAQ for the SLA Upgrade: SLA Pre-Upgrade, Post-
Upgrade, and Hot Patch [ID 604893.1]
3. R12.1 Oracle Applications Upgrade Guide: Release 11i to Release 12.1.3
E16342-03
4. R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4
E12011-02
5. Detailed instructions for the SLA Post Upgrade (aka SLA Hot Patch) can be
found in Note: 751160.1
6. Transitioning from Account Generators, White paper by Solution Beacon
Reference
The above information is compiled and
written by Jitendra Gahlot
Jitendra Gahlot, an Oracle Certified
E-Business Consultant from Enrich IT
Inc. Jitendra has Over 10 years of ex-
perience of Implementing, Supporting
and Development of Oracle E-Business
Suite.

Oracle R12 Upgrade - Sub Ledger Accounting

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (11)

Similar a Oracle R12 Upgrade - Sub Ledger Accounting

Similar a Oracle R12 Upgrade - Sub Ledger Accounting (20)

Último

Último (20)

Oracle R12 Upgrade - Sub Ledger Accounting