EBS FAH12BestImplPractices PDF

Oracle Financials Accounting, Best Implementation Practices, E-Business Suite R12
An Oracle White Paper

May, 2012
Oracle Financials Accounting Hub

Best Implementation Practices
E-Business Suite R12
Executive Overview ........................................................................... 1

Introduction ....................................................................................... 1
Glossary ............................................................................................ 2
Best Practice 1: Recommended Implementation Approach ............... 3
Best Practice 2: Number of Applications .......................................... 13
Best Practice 3: Event Model Design ............................................... 14
Best Practice 4: Journal Line Type Definitions ................................. 16
Best Practice 5: Minimal Usage of Constant Values ........................ 18
Best Practice 6: Minimal Usage of Custom Sources ........................ 20
Best Practice 7: Set Up Components Reusability ............................ 21
Best Practice 8: Summarization ....................................................... 22
Best Practice 9: Supporting Reference Definitions .......................... 23
Best Practice 10: Mapping Set Definitions ....................................... 25
Best Practice 11: Default Values in Mapping Sets ........................... 26
Best Practice 12: Proper Source Assignments ................................ 26
Best Practice 13: Usage of Numeric Identifiers in the Setup ............ 28
Best Practice 14: Correct Usage of Gain / Loss Flag in Event Class 29
Best Practice 15: Naming Conventions............................................ 29
Best Practice 16: Effective Dates and Versioning ............................ 29
Best Practice 17: High Volume Manual Adjustments ....................... 29
Best Practice 18: Performance Improvements ................................. 30
Conclusion ...................................................................................... 31
Executive Overview
The purpose of this document is to share the learning from several Oracle Financials
Accounting Hub (FAH) implementations that is based on the interaction and feedback from
existing FAH customers and Oracle consultants, and to aid the implementer with guidance on
best implementation practices for optimal deployment of FAH.
Introduction
Best business practices of an enterprise differ, depending on industry standards and
requirements. Oracle Financials Accounting Hub (FAH) provides flexibility to help any
enterprise in any industry define accounting rules for external or legacy source systems to
address the unique accounting requirements that are specific to its business.
FAH efficiently creates detailed, auditable, and reconcilable accounting for external or legacy
source systems. FAH includes an accounting transformation engine and accounting and rules
repositories. The accounting transformation engine enables companies to enforce accounting
policies in a very controlled and consistent manner, while the repositories enable companies to
simultaneously meet diverse corporate, management and reporting requirements that are
complete with audit trails.
This white paper provides the best implementation practices for FAH with implementers to
improve overall product experience.
1
Glossary
ACRONYM DESCRIPTION
AAD Application Accounting Definition
ADR Account Derivation Rule
AMB Accounting Methods Builder
FAH Oracle Financials Accounting Hub
GL General Ledger
IFRS International Financial Reporting Standards
JED Journal Entry Description
JLD Journal Line Definition
JLT Journal Line Type
SLA Oracle Subledger Accounting
SLAM Oracle Subledger Accounting Method
SR Supporting Reference
2
Best Practice 1: Recommended Implementation Approach

Before you implement Oracle Financials Accounting Hub (FAH), you should consider the following
areas:
1. Reporting Needs
2. Applications Architecture
3. Chart of Accounts Structure
4. Analysis of Source Systems
5. Setup Configuration Options
6. Gradual Deployment
7. Integration Automation
8. Next Steps to Get You Started
Follow the tasks in the order listed above, during the implementation of FAH. Omitting some of the
tasks could lead to considerable rework during the project.
1. Reporting Needs
Consider your reporting needs for all of your data that flows through Oracle Financials Accounting
Hub to Oracle General Ledger and to your analytical reporting platform.
Analysis should be performed to identify:

 Which (future) systems provide the reporting information?
 Do you plan to have a thin GL or a thick GL? A “thin GL” contains summarized balances,
while details are kept in subledgers. A “thick GL” maintains balances at a very detailed level
across many charts of account segments. Oracle recommends a thin GL.
 What are the dimensions in GL, what are they in FAH, and which balances do you want to
maintain in your analytical application?
 What are your reporting needs – what type of detail is required?
 What information is required to track in Financials Accounting Hub to support the reporting
(for example, FAH transaction identifiers and supporting references)?
The above analysis of the reporting needs will help drive the subsequent architecture and chart of
accounts discussions.
3
2. Applications Architecture
The Applications Architecture analysis should entail:

 Identifying the number of source systems
 Identifying other ETL (Extraction, Transformation, and Load) processes / data stores / data
warehouses that are in place or need to be created
 Determining the ETL tool role and scope (for example, deciding which tool to use for various
mapping options (ETL or FAH) whilst taking the error handling process into consideration)
 Determining if there is a central mapping repository and consider the consequences,
propagation, mapping execution and error handling
 Assessing your current valuation engines that you have in place (for example, Financial
Services)
 Determining if the current systems provide the information needed
 Determining if the preprocessing / pre-validation of data is needed
 Identifying the number of target ledgers (for example, do you need multiple ledgers to support
multiple GAAPs?)
 Identifying other systems, other than the General Ledger, that need to feed into FAH
 Identifying other systems, other than the General Ledger, to which FAH must feed data
 Identifying your data retrieval flow requirements (online and / or batch)
 Identifying the source systems that need to be reworked, to provide transaction events versus
journal pass-through
 Determining if a pre-defined structure of data from the various source systems already exists
(for example, due to the use of an existing data warehouse)
 Identifying whether new transaction object tables and views need to be defined
4
Below are some examples of various architecture integrations:
Figure 1.Direct connect between the source system and FAH
Figure 2.Use of staging area (custom transaction tables)
5
Figure 3.Use of Transaction Data Store
Figure 4.Use of Data Warehouse
6
3. Ledgers and Chart of Accounts Structure
When analyzing your ledger and chart of accounts structure, consider your reporting requirements and
the decision to have a thin or a thick ledger in Oracle General Ledger. A thin ledger or GL is where
details of transactions are maintained in the subledgers, keeping summarized balances in the GL. A
thick GL is a very detailed ledger that duplicates many of the details maintained in subledgers.
Oracle Financials Accounting Hub utilizes the E-Business Suite’s Accounting Flexfield for the
definition of the chart of accounts structure, which can include up to 30 segments and 25 characters
per segment, and up to 240 characters in total. When deciding on the number of segments to define,
consider how it will affect transaction data entry for Oracle subledgers (for example, Payables,
Receivables etc.). The more segments that you have will require more data entry and typing.
You might have to perform multi-GAAP reporting, such as US GAAP, IFRS, and local accounting
principles, for a given country and therefore have to decide upon whether multiple charts of accounts
structures are required along with the definition of multiple ledgers.
You can configure accounting rules through Oracle Financials Accounting Hub to generate accounting
entries for multiple accounting representations, by posting them to multiple ledgers, such as primary
and secondary ledgers in Oracle General Ledger.
Thin Ledger
You should consider a thin ledger if your requirements are:
 Minimal disclosure to the authorities
 Fiscal only adjustments
 Allocations and revaluations done for segments in your chart of accounts
If you want to maintain a thin General Ledger, consider maintaining additional business / analytical
dimensions via FAH supporting reference balances so that the balances are stored in FAH instead of
General Ledger. You can make your online inquiry or reporting on supporting reference balances from
FAH instead of General Ledger. Supporting references are appropriate to use for "deferred" reporting
of financial balances, broken down by an operational dimension that is applicable to a small subset of
financial balances.
If you intend to replace a segment in your chart of accounts with a supporting reference in FAH, only
consider this option if you expect the segment to support a small subset of your balances. If the chart
of accounts segment supports a large proportion of your balances, you should not consider using the
supporting reference in FAH but instead keep the segment as part of your chart of accounts. Do not
try to replace segments in the chart of accounts with supporting references in FAH if these segments
are accounting flexfield qualifiers, such as the primary balancing, natural account, cost center or
intercompany.
7
Thick Ledger
You should consider implementing a thick ledger if you are not a customer in the Financial Services
Industry and you have business requirements to:
 Track entered currency balances at the level of an operational (for example, analytic)
dimension
 Perform currency revaluation at the level of an operational (for example, analytic)
dimension
 Perform financial allocations at the level of an operational (for example, analytic)
dimension
 Produce real-time reporting at the level of an operational (for example, analytic)
dimension
 Report on the majority of financial balances based on an operational (i.e. analytic)
dimension
 Report using multiple layered and versioned hierarchies of an operational (i.e. analytic)
dimension
In the above cases, include the operational dimension as a segment in your chart of accounts in either
your primary or secondary ledger (or both).
However, if you are a customer that operates in the Financial Services Industry and you need average
daily balances for operational business dimensions not stored in your Chart of Accounts, you can track
business dimensions through supporting reference balances in FAH and export these supporting
reference balances to Financial Services Analytics Applications (OFSAA). You can use OFSAA to
calculate Average Daily Balances, perform allocations and revaluations, whilst still keeping a thin ledger
in Oracle General Ledger. Balance sheet account reconciliation, where the financial balance is broken
down by an operationally significant dimension specific to the type of external system, typically
requires the use of supporting references in FAH.
Thin and Thick Ledger

You should consider a thin ledger in addition to a thick ledger, if your requirements are as outlined for
the thick ledger above but you also have a general business requirement for a thin ledger with:
 Minimal disclosure to the authorities
 Fiscal only adjustments, allocations and revaluations (which don't impact the analytical
thick ledger)
Of course, if you maintain multiple ledgers there is an additional burden in terms of processing and
maintenance.
The deciding factor between a thick primary or secondary ledger could be how the values for
operational dimensions are derived. If the values for the operational dimension are always entered by
the user (like other segments of the chart of accounts), then a thick primary ledger primary would be
appropriate. However, if values for the operational dimension can be automatically derived from other
attributes on the transactions in FAH rules (perhaps as part of a mapping set), then a thick secondary
8
ledger would be more appropriate because the user never needs to see nor enter the operational
dimension through a user interface.
The decision on reporting needs, architecture, ledgers and chart of accounts are all preliminary tasks
that should be completed prior to setting up the configuration for FAH.
Secondary Ledgers / Reporting Currencies

Secondary ledgers and reporting currencies enable you to track your transaction data using a different
accounting representation, whether for a different currency, a different chart of accounts, a different
accounting method, a different calendar, or some combination of these.
They can provide large functional benefits. However, they also produce large volumes of additional
journal entries and balances data, resulting in additional performance and memory costs. When adding
a secondary ledger or reporting currency, consider your needs with regards to that secondary ledger or
reporting currency, and choose the least costly data conversion level that satisfies your requirements.
For secondary ledgers, there are four data conversion levels available:
 Adjustment only
 Balance
 Journal
 Subledger
Of the above four data conversion levels, the adjustment data conversion level is typically the least
costly, producing the smallest amount of additional data. The balance data conversion level is also
relatively inexpensive, depending on how often the balances are transferred from the primary ledger to
the secondary ledger. The journal and subledger data conversion levels are much more expensive,
requiring duplication of most GL journal entries and most subledger journal entries respectively, as
well as balances.
For reporting currencies, there are three data conversion levels available:
 Balance
 Journal
 Subledger
Of these three data conversion levels, the balance data conversion level is typically the least expensive,
requiring duplication of only the balance level information. The journal and subledger data conversion
levels are much more expensive, requiring duplication of most GL journal entries and most subledger
journal entries respectively, as well as balances.
9
For example, if you wanted to maintain a secondary ledger for IFRS while your primary ledger is US
GAAP, you might choose to define a subledger level secondary ledger for IFRS. However, since 80-
90% of the accounting is identical between US GAAP and IFRS, you would be better off doing an
adjustment only secondary. A subledger level secondary ledger would require duplication of most
subledger journal entries, GL journal entries, and GL balances. With an adjustment-only secondary
ledger, the secondary ledger only contains the adjustment journal entries and balances necessary to
convert the US GAAP accounting to IFRS accounting. Given the similarity between US GAAP and
IFRS accounting, this means that an adjustment-only secondary ledger would require only 10-20% of
the resources that a full subledger level secondary ledger would.
4. Analysis of Source Systems
Take an inventory of all the source systems in scope and all the life cycle steps within each source
system.
Each source system and life cycle steps need to be mapped to the event model in FAH.
FAH provides an event model with 3 levels:
 Application
 Event Class
 Event Type
The accounting is driven by event type. Configure your Event Model for performance reasons, thus
creating your Event Model in such a way that will distribute processing so that it can happen
concurrently for multiple products, hence reducing the risk of bottle necks and meeting the close
process deadlines. For example, you could consider defining multiple applications in FAH to enable
processing to be executed concurrently across applications.
5. Set Up Configuration Options
The accounting rules that you functionally implement in the FAH Application Accounting Definition
(AAD) are compiled into “source code” during the validation of the AAD. The source code resides in
the Oracle database. Specifically, for every single Application Accounting Definition (AAD) which you
create through the FAH front-end, one PL/SQL package is created in the database. At a technical
level, the size (lines of code) of this package can have a direct impact on the performance of the
following two concurrent programs in FAH:
 Validate Application Accounting Definition (used to verify and validate changes to the AAD
before it can be put in use)
10
 Create Accounting (the physical creation of accounting entries for subledger transactions)
During the design stage of your FAH implementation, the building blocks or FAH components that
constitute the application should not only implement your business requirement, but also be defined in
a manner that ensures reusability, modularity and flexibility at both the functional and the technical
level.
Before commencing the FAH configuration, complete the following prerequisites:

 Review this FAH Best Practices document in full
 Review your chart of accounts
 Review the transaction objects
 Review the event model
You must then perform the minimal setup required for Oracle General Ledger.
To configure FAH:
 Start with the easier source systems
 Configure the full product lifecycle
 Validate the correctness of the accounting by running “Draft Accounting” in FAH
 Expand the FAH configuration to more complex source systems; be sure to include business
users in this part of the setup
 Automate accrual reversals – FAH can automate accrual reversals for accruals
 Increase transaction volumes and ensure that you include performance benchmark testing
 Add reporting & reconciliation to your testing and validation of the expected outcomes
Supporting References
Use Supporting Reference balances wisely. Large numbers of supporting reference balances use extra
resources to process. However, they can be very useful in many cases. Use Supporting Reference
Balances for:
 Meeting IFRS segment reporting
 Facilitating reconciliation back to source systems
 Supporting P&L Balances by high level key business dimensions not tracked in your chart of
accounts
6. Gradual Deployment
It is recommended that FAH be gradually deployed by:

 Analyzing a small number of source systems
 Configuring a FAH prototype setup for those selected source systems
 Validating and testing end-to-end processing from the selected source systems through FAH
to the General Ledger
11
 Refining and performance tuning the system
After satisfactory results and processing are proven, you can add additional configurations for more
source systems and repeat the steps above.
7. Integration Automation
To optimize your FAH implementation, analyze where you can increase the integration automation by
considering the following:
 On line processing
 Error Handling: Notifications, resubmissions, automatic replacements
 Manual Entries: Workflow enabled in transaction objects
 Reconciliation: Dashboards and notifications
 Reporting
 Post-processing
 Write-back to feeder applications
8. Next Steps to Get You Started

 Obtain sponsorship and resourcing for your FAH project:
o Strong Executive Sponsorship is needed
o Strong Project Management skills are needed (across IT & Business)
o Involvement of business users and source system experts is key
o Technical resources needed in FAH-implementations from the start
o Collaboration with the implementation team and the accounting and business
functions is critical
 Decide on implementation approach
o Review this FAH Best Practices document for guidance
o Start small, extend and improve: applies to both definition of scope and to approach
during build and design
o Implement in a modular way by source system
o Include multiple target ledgers as needed
o Use pass-through where needed
o Analyze and rationalize to minimize event classes, event types and rules
o Respect the order of implementation steps
o Don’t underestimate the scope of business rules
 Perform early performance testing and capacity planning of the overall solution
12
Best Practice 2: Number of Applications

The number of Financial Accounting Hub applications that you define is a decision that strongly impacts
performance. Using a single application for all of your FAH transactions has some functional benefits,
as the data is centralized for inquiry and reporting and is generated using a single set of rules. However,
using multiple applications can enable you to better compartmentalize and secure your data. It can give
you more flexibility in defining rules. It also provides substantial performance and concurrency
benefits.
In general, if you are going to be processing large volumes of data through FAH, you should consider
defining multiple applications. Each application is stored in a separate partition in most FAH tables,
enabling better concurrency, especially on a RAC system. The data for the different applications is
processed independently, enabling processing for higher priority or smaller applications to complete
earlier and processing to run more frequently for more critical applications.
A good rule of thumb is to define a different application for each different data source. However, in the
case of very small data sources, you could combine them. In the case of very large data sources, you
should consider splitting them up using an existing logical attribute of the data. For example, you could
split the data by business unit, line of business, or geographical region. In the absence of such an
attribute, another option is to just split the data arbitrarily. For example, if there were 63 M transactions
to split among three applications, the first 21M transactions could be assigned to the first application, the
second 21M transactions to the second application, and the rest to the third application. However, this
sort of solution can be problematic when reversing transactions or transaction lines; ensure that the
original event for the transaction and the reversal event both get assigned to the same application. In
general, it is best practice to split data by some existing logical attribute.
The multiple applications approach splits a single large AAD package into multiple smaller AAD
packages which can benefit performance.
Note that all setup components exist within the context of an application and cannot be reused across
applications.
13
Best Practice 3: Event Model Design

The accounting event type represents the business operation that is performed on the end-user
transaction type (event class). These accounting event types are the lowest level of detail in the event
model hierarchy.
Event types are grouped into event classes, which are grouped into event entities. These groupings play
a prominent role in the setup of the lower level AAD components such as JLTs, ADRs, etc.
Example
In the Financial Services industry a Trade Position might include certain activities such as Notional
Amount on Trade Position, Premium Amount, Premium Settlement, Premium Sweep and Mark to
Market Valuation, which are categorized as event types. These event types are then grouped into a
single event class, such as Trade Positions. Another type of event class could be Trade Loans with event
types such as Principal Loan and Loan Interest. The event classes Trade Loans and Trade Positions can
be grouped into a single event entity, such as Trade.
Journal Line Definition (JLD) groups and assigns the journal line types, account derivation rules, and
journal entry descriptions within an event class or event type. You can assign a JLD to an event class
and event type combination under the AAD. The Oracle FAH application gives the flexibility to define
a single JLD for one event class with all the event types. For example, if you define multiple event
types under a single event class, this does not mandate you to define as many JLDs as event types. You
can instead choose to define one JLD for this event class with the value of event type as “ALL”. This
JLD then executes for all the event types under this event class. Within this single JLD, you can base
the execution of the Journal Line Types (JLT) on different JLT conditions which check the event type
code. If needed, you can seed a new source (say EVENT_TYPE) in the transaction object and then
check against this source in the JLT condition as shown below.
14
EVENT_TYPE (Source) = (Constant) $Event Type$;

TABLE 1. FOUR JOURNAL LINE DEFINITIONS DEFINED FOR ONE EVENT CLASS
JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE
DEFINITION
1 A E1 A
2 A E2 B
3 A E3 C
4 A E4 D
In the above example, the approach is to define four JLDs defined for one event class A since four
different event types exist. The recommended approach, however, is to define a single JLD using the
event type ‘ALL’. To ensure one JLT is only processed for a given event type, the event type can be
stored as a source in the transaction object. Such an approach reduces the size of the AAD package
since it reduces the number of procedures created per event type. It also reduces maintenance.
However, care should be taken not to group event types together that have significantly different
business meanings because it could make the rules difficult to understand.
TABLE 2. ONE JOURNAL LINE DEFINITIONS WITH EVENT TYPE “ALL” FOR ONE EVENT CLASS
DEFINITION
(CONDITION: EVENT_TYPE = 1)
1 A ALL
The above illustration can further be improved by minimizing the hard coding of the values in the JLT
conditions. This is further explained in Best Practice 5.
15
Best Practice 4: Journal Line Type Definitions

If the attributes of different JLTs, such as Side, Balance Type, Merge Matching Lines, etc. are the same,
then instead of defining different JLTs with all attributes being the same with the exception of a
different name, you can pull these different JLTs into a single JLT.
TABLE 3. THREE JOURNAL LINE DEFINITIONS DEFINED FOR ONE EVENT CLASS
DEFINITION
1 A E1 X
2 A E2 Y
3 A E3 Z
In the above example, the JLT attributes of the X, Y and Z JLTs are the same. Therefore, you can use
a single JLT W to achieve the same effect as 3 different JLTs. Again, such an approach increases
functional component reusability and helps reduce the AAD package size. It also reduces maintenance.
However, care should be taken not to group together JLTs which have significantly different business
meanings because it could make the rules difficult to understand.
TABLE 4. THREE JOURNAL LINE DEFINITIONS WITH A SINGLE EVENT CLASS AND A SINGLE JOURNAL LINE TYPE
DEFINITION
1 A E1 W
2 A E2 W
3 A E3 W
The above setup can further be simplified by using the ‘ALL’ event type as described in ‘Best Practice
3’ above.
TABLE 5. SINGLE JOURNAL LINE DEFINITION WITH A SINGLE EVENT CLASS, EVENT TYPE “ALL” AND A SINGLE JOURNAL LINE TYPE
DEFINITION
1 A ALL W
16
The variations within the accounting rules should be built as low as possible within the AMB hierarchy,
making maximum use of mapping sets and/or conditions at the ADR level.
A possible best case example would then be:

TABLE 6. SINGLE JOURNAL LINE DEFINITION WITH A SINGLE EVENT CLASS, EVENT
TYPE “ALL” AND A SINGLE JOURNAL LINE TYPE
JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE ADR MAPPING SET
DEFINITION (USING EVENT TYPE
AS INPUT VALUE)
1 A ALL W S M
The diagram below outlines the Accounting Methods Builder (AMB) hierarchy, such as the FAH
components, and how they relate to each other. The object at the start of the arrow is used in the
definition of the other object to which the arrow points.
Figure 5.Accounting Methods Builder Hierarchy
17
Best Practice 5: Minimal Usage of Constant Values

Always try to minimize hard coding constant values in the setup. You can use sources instead of hard
coding the constant values. View the example below to understand how you can use sources instead
of constant values in the setup.
TABLE 7. ONE JOURNAL LINE DEFINITION, ONE EVENT CLASS, EVENT TYPE “ALL”, FOUR JOURNAL LINE TYPES AND FOUR DESCRIPTIONS
JOURNAL LINE EVENT EVENT JOURNAL LINE TYPE DESCRIPTION
DEFINITION CLASS TYPE
A D1
(CONDITION: EVENT_TYPE = 1) ‘Event Type is 1 and the side is DR’
B D2

1 A ALL
C D3
D D4
In the above example, static journal entry descriptions are used for each accounting line, even in the
JLT conditions.
18
You can create a source (Event Type) to retrieve the event type from the transaction object and use
this source in the JLT conditions, as shown above. You can use this same source (Event Type) and
define just one journal entry description (D1) as shown below.
Event Type is || source (Event Type) || and the side is || source (Side) ||
TABLE 8. ONE JOURNAL LINE DEFINITION, ONE EVENT CLASS, EVENT TYPE “ALL”, FOUR JOURNAL LINE TYPES AND ONE DESCRIPTION
JOURNAL LINE EVENT EVENT JOURNAL LINE TYPE DESCRIPTION
DEFINITION CLASS TYPE
(CONDITION: EVENT_TYPE = 1) D1
B
D1
1 A ALL C D1
D1
D
Since each journal entry description is stored in a different PL/SQL function, reducing the number of
journal entry descriptions by making them reusable not only saves functional effort in defining these
multiple descriptions but also reduces the size of the AAD package.
In cases where there are a few possible values, it might be more appropriate to use constant values in
an ADR. If there are only two or three possible values, you can use constant values instead of a
mapping set.
19
Best Practice 6: Minimal Usage of Custom Sources

It is preferable to use the custom sources as little as possible, and instead build the intelligence into the
transaction object, if possible. You can build the intelligence in the transaction object instead of using
the custom sources to reduce the processing overhead on the accounting program.
Example
You have the following base table (TABLE) with the following three columns:
TABLE 9. BASE TABLE WITH THREE COLUMNS
NAME AGE GENDER
(COLUMN 1) (COLUMN 2 (COLUMN 3)
For example, you want to use the names of people over the age of 50 to either create a custom source
or build the intelligence in the transaction object.
The following shows the impact of both of these options on the performance of the accounting
program in FAH.
Creating a Custom Source
The custom source should return the value ‘TRUE’ or ‘FALSE’ by comparing the Age in the base
table. This means the PL/SQL package has to be executed for each name to return the value. This
process is repeated for every condition in which this custom source is used in the setup components
such as the JLT, JED and ADR.
Doing so can adversely impact performance of the accounting engine because it causes a row-by-row
execution of the PL/SQL package for each extracts line.
20
Build the intelligence in the Transaction Object (Extract View)
You can build this intelligence in the transaction object instead of creating a custom source. In the
above example, the extract view (TABLE_V1) will also have the same columns of the TABLE. In
addition to this, you should add a new column called AGE_OVER_50 as shown below.
TABLE 10. ADDITIONAL FOURTH COLUMN ADDED TO TRANSACTION OBJECT
NAME AGE GENDER AGE_OVER_50
(COLUMN 1) (COLUMN 2 (COLUMN 3) (COLUMN 4)
The extract should return value ‘True’ if the age is greater than 50 and ‘FALSE’ if the age is less than
50. This logic runs only once and takes minimal time to return the values on the 4th column along with
the other three columns.
This will improve the performance of the accounting program in FAH.
Best Practice 7: Set Up Components Reusability

The accounting rules repository enables users to separately define and reuse setups for each
component of a journal entry, such as the journal lines, descriptions and summarization criteria. These
setups can be reused to rapidly integrate new source systems into Oracle Financials Accounting Hub.
Users can quickly create rules, copy and reuse them to meet similar, yet distinct requirements.
Example
 If a source system is expected to book fee income, cash receipts or disbursements, etc. to the
same general ledger account, you can create and use a single rule to account for each of these
systems.
 If the source is the same for the different Account Derivation Rules (ADRs) defined, then it is
sufficient to define only one ADR, which can be reused within that particular application
wherever required.
21
Best Practice 8: Summarization

The level of summarization has a direct impact on both the data growth in the FAH and GL tables and
on performance of the Create Accounting program. Although the exact level of summarization
depends on your requirements, it is safe to say that an increased level of summarization is preferable
since it helps implement a thin GL approach without losing the granularity stored in the FAH tables.
At a technical level, increased summarization helps achieve greater data normalization and decreases
the storage requirement. Because core tables store less data, the performance of the Create Accounting
program, reports and inquiries are improved.
The Journal Entry Summarization Option determines the amount of summarization done when
subledger journal entries are transferred to General Ledger and become GL journal entries.
Specifically, this option controls whether each GL journal entry is potentially made up of several
subledger journal entries or if there is always only a single GL journal entry per subledger journal entry.
Similarly, it controls whether each GL journal entry line is made up of several subledger journal entry
lines or if there is always only a single GL journal entry line per subledger journal entry line.
The Journal Entry Summarization Option greatly impacts performance. As the more GL journal
entries and journal entry lines are created, the greater the performance impact is in posting, reversing,
inquiring, and reporting on these journals throughout General Ledger.
In addition, the Oracle General Ledger system is designed from both a functional and technical
standpoint to work best with summary journals.
With the lowest level of summarization and when the journal entry summarization option is set to “No
Summarization”, a separate GL journal entry is produced for each subledger journal entry, and a
separate GL journal entry line is produced for each subledger journal entry line. As a result, there is
one, and sometimes multiple, GL journal entries created for each subledger transaction. This results in
creating redundant data in GL, as the GL journal entries are duplicates of the subledger journal entries.
It provides no additional information or audit trial compared to running at a higher level of
summarization, as even with the highest level of summarization, all of the detail is still maintained in
the subledger journal entries.
Setting the Journal Entry Summarization Option to “No Summarization”, results in a substantial
increase in the number of GL journals created. These journals are generally small journals, with just a
few lines. The performance of General Ledger is impacted, as it is tuned to perform best for journals
with a larger number of lines. It also impacts the functional behavior, as that too is designed to work
with a smaller number of large journals.
You should avoid setting this option to “No Summarization”. If you set the Journal Entry
Summarization option to 'No Summarization', there is no summarization even if you set the Transfer
to GL option at the Journal Line Type in FAH to 'Summary'. For optimum performance and
functionality, the Journal Entry Summarization option should be set to some other level.
22
You can specify the Journal Entry Summarization option for an application in the Accounting Options
screen.
Note: The Journal Entry Summarization option shouldn't be confused with the “Merge Matching
Lines” option of the Journal Line Type in FAH that summarizes journals lines within the FAH table.
However, with that option, configured to Merge Matching Lines, increased summarization improves
performance and decreases the storage requirement.
Best Practice 9: Supporting Reference Definitions

You can use supporting references to store additional source information about a subledger journal
entry either at the header or line level. The line level supporting references can establish a subledger
balance for a particular source and for a particular account. The sources are attached to the supporting
reference ‘Detail’. The details are grouped into one supporting reference.
If the supporting references are assigned at line level without maintaining the balances, then it would
be better practice to maintain such supporting references at the header level, if possible. You should
not define supporting references to store user transaction identifiers. Instead, you can define the user
transaction identifiers in the Accounting Event Class Options form. Also, you should evaluate using
journal entry descriptions to store any additional information instead of defining supporting references.
The grouping of the supporting reference details plays a prominent role in improving the performance.
Example
A, B and C are defined as three supporting references and each contains one detail with one source
attached to it. You can further improve this definition by defining A, B and C as three details under
one supporting reference.
Review the points below before implementing the Supporting Reference in your FAH implementation.
 Supporting reference balances are not maintained in the ‘Entered Currency’.

 Supporting reference balances for non-balance sheet accounts are not transferred to the
‘Retained Earnings Account’ at year end.
 Supporting reference details are limited to five per one supporting reference.
 You can define supporting references up to a maximum of 100, including some that are
seeded by Oracle.
 Supporting references exist within the context of an application
 You can reduce the number of supporting reference records by using multiple segments
in a single supporting reference.
23
 All of the accounting lines created from an extract line will have the same values for their
supporting references. Thus, if a single extract line creates both debit and credit lines,
those lines will have the same values for each of their supporting references
 Supporting reference values cannot be posted to Oracle General Ledger
Supporting reference balances are NOT an out-of-the-box extension of the GL balances

 Supporting reference balances for non-balance sheet accounts are not transferred to a
supporting reference balance retained earnings account at year end
 Supporting reference balances are only stored for those accounting lines that have a value
for the supporting reference. If a particular accounting line has no value for a particular
supporting reference, the accounting line won't be included in the balances for that
supporting reference. This means that supporting reference balances are not necessarily as
complete as general ledger balances. It also means that the two are not necessarily in sync.
 Each supporting reference is tracked through a separate supporting reference balance.
Therefore, if you have three supporting references, they are tracked through three
different supporting reference balances. If these are instead three additional general ledger
segments, then they are tracked as three additional dimensions in a single general ledger
balance. This means that analysis across multiple supporting references using supporting
reference balances is harder than analysis across multiple general ledger segments using
general ledger balances, while analysis within a single supporting reference is easier.
24
Best Practice 10: Mapping Set Definitions
The mapping sets can take only one input source for a given output. However, if multiple or different
input sources are required to be mapped to a single output value, then it can be implemented in the
transaction object as illustrated below.
Example:
Assume a company frequently makes acquisitions and mergers or frequently introduces new products;
you need to map new input values to output values. In the mapping sets, you can define a one to one
mapping between an input value and output value. If multiple input sources make up the mapping to
one output value, then consider a concatenation of the input value (concatenating say three sources
into a string) to an output value. There is an effective start date and end date on each row within a
mapping set. You can share or assign mapping sets to multiple Account Derivation Rules.
There are three columns in the transaction objects, such as A, B and C, that should be mapped to a
single output value (for example, value X). To implement this using Mapping Sets, you can add
column D in the transaction object that should provide the concatenated value of columns A, B and C.
TABLE 11. TRANSACTION OBJECT COLUMNS
EVENT ID A B C D
(INPUT SOURCE) (INPUT SOURCE) (INPUT SOURCE) (CONCATENATED VALUE OF
COLUMNS A, B AND C)
1 A1 B1 C1 A1+B1+C1
2 A2 B2 C2 A2+B2+C2
3 A3 B3 C3 A3+B3+C3
After adding the new concatenated column D, you can define the Mapping Set as follows with the
input and output values correctly mapped as per the requirement.
TABLE 12. MAPPING SETS
INPUT VALUE OUTPUT VALUE
(SOURCE COLUMN D)
A1+B1+C1 X1
A2+B2+C2 X2
A3+B3+C3 X3
25
Best Practice 11: Default Values in Mapping Sets

Ensure that all input source values are mapped in the Mapping Set definition. If the input source
returns a value that is not available in the mapped input values, then the accounting engine will return a
‘null’ output value. This results in the creation of a journal line with an unexpected account
combination, because FAH picks the default value for the segment from GL and creates the account
combination.
To avoid such cases, you should always either map all input source values in the Mapping Set definition
or define a ‘Default’ output value for the Mapping Set.
If multiple Account Derivation priorities are defined such that they use Mapping Sets, the priorities are
executed based on priority condition alone, irrespective of whether input source value found a match
in a Mapping Set.
Best Practice 12: Proper Source Assignments

Accounting Attributes
The accounting program derives the values of accounting attributes by looking at the sources that are
assigned to them. There are two accounting attribute levels: Header and Line. The accounting
attribute level refers to the way in which the accounting program uses the accounting attribute values
to generate the journal entries as shown below:
 Header level – To create subledger journal entry headers

 Line level – To create subledger journal entry lines
Source Data - Transaction Objects
The accounting attribute level should not be confused with the transaction object type. The
transaction object type refers to the kind of transaction object that is used to store the source values.
In general, there are two transaction object types: Header and Line.
The transaction details that do not vary by transaction line or distribution should normally be stored in
header transaction objects. The transaction details that vary by transaction line or distribution should
normally be stored in the line transaction objects. The standard source values are stored in these
transaction objects.
26
Example
 The source ‘Invoice Number’ for an invoice or the ‘Bank Account Number’ for a receipt is
stored in the header transaction object.
 The source ‘Invoice Line Number’ for an invoice or ‘Invoice Number’ for a payment is stored
in the line transaction object.
You should not store the sources in the line transaction objects that are required to create a journal
entry header. This causes the data growth in the line extract views for each line pertaining to the
journal entry header even though such information is not required at the line level.
You should make sure that all of the sources you plan on using when accounting for an event class are
assigned to that event class. Failure to do so may cause problems when defining or using your
accounting rules. For example, you will not be able to pick a custom source or journal entry description
that uses sources that are not assigned to your event class.
Source assignments to the Accounting Attributes
Review the points below before assigning the sources to the accounting attributes.
TABLE 13. SOURCE ASSIGNMENTS TO ACCOUNTING ATTRIBUTES
SOURCE – TRANSACTION ACCOUNTING ATTRIBUTE LEVEL PERMITTED
OBJECT TYPE
Header Header Yes
Header Line Yes
Line Header No
Line Line Yes
27
Best Practice 13: Usage of Numeric Identifiers in the Setup

It is always recommended to use the numeric identifiers for the sources instead of using the sources
with data type character. This practice increases the flexibility and simplifies the definition of the setup
components.
Example
You can use Department Identifiers as source in the setup component definition instead of
Department codes.
TABLE 14. USING NUMERIC IDENTIFIERS
DEPARTMENT ID DEPARTMENT CODE
1 Services
2 Consulting
3 Manufacturing
4 Admin
Your requirement is to define the ADR ‘X’ for the departments ‘Services’ , ‘Consulting’ and
‘Manufacturing’ but the ADR ‘Y’ for the department ‘Admin’. The condition of the ADR ‘X’ can be
better defined using the DEPARTMENT_ID instead of DEPARTMENT_CODE as shown below.
ADR (X) CONDITION: DEPARTMENT_ID =< 3
You can also define a lookup to store the department identifier and the department name and assign it
to the source definition, so that the department name rather than the department identifier is displayed
to users while creating and maintaining FAH rules.
28
Best Practice 14: Correct Usage of Gain / Loss Flag in Event Class
The FAH accounting engine performs the gain or loss calculation for each line in the transaction
object if the ‘Calculate Gain/Loss’ flag is enabled at the event class level. If this flag is incorrectly set,
then it will adversely impact the performance of the accounting program. If any application does not
require the accounting engine to calculate the gain or loss for a transaction object line, then this flag
should not be enabled at the respective event classes.
Best Practice 15: Naming Conventions

For the configuration of the application, it is important to define clear naming conventions and use
these consciously for all setup components. The naming convention should be consistent by following
the standard Oracle subledger naming standards in the seeded Subledger Accounting Rules setup.
Best Practice 16: Effective Dates and Versioning

The effective dating of rules in FAH is controlled at the AAD level and the row level in Mapping Sets.
At a strategic level, usually accounting policies don’t change frequently. It might be that new
regulations, such as transitioning to IFRS, require a change to some accounting policies. If so, then
you can copy an existing AAD and modify those JLT and ADRs that need to be changed.
For frequent changes to account value mappings, it is best practice to use Mapping Sets that are
effective dated at the row level in the Mapping Sets. This enables you to specify a new mapping to a
new account as of a specific date. Rather than copying application accounting definitions and all of its
assignments, an easier option is to work with multiple assignments (using different date ranges) in the
mapping set.
On the other hand, you can export the rules to a different context, make the changes and import the
rules under the ‘DEFAULT’ context as a new version.
Best Practice 17: High Volume Manual Adjustments

Oracle Financials Accounting Hub’s (FAH) Subledger Accounting (SLA) Journal Entry window
enables a user to enter journals in SLA with the ability to add supporting reference data for the
particular journal. Unfortunately, if you have a high volume of manual adjustments that you need to
process, there is no Excel-like integration available out-of-the box. You can, however, build a
Microsoft Excel-like integration to suit your specific business needs to process high volume
29
adjustments using Oracle E-Business Suite Desktop Integration Framework for Release 12.1.2 and
onwards.
Oracle E-Business Suite Desktop Integration Framework is a new development tool that lets you
define custom integrators for use with Oracle Web Applications Desktop Integrator. An integrator is a
set of metadata layers that encapsulate all the information needed to integrate a particular Oracle E-
Business Suite task with a desktop application. With Oracle E-Business Suite Desktop Integration
Framework, you can define custom integrators for tasks in a standard Oracle E-Business Suite
application that are not covered by seeded integrators or for tasks in custom applications developed for
your instance. Desktop Integration Framework (DIF) supports embedded EBS UI widgets, such as
LOVs, Date pickers, pop lists, and flexfields. Apart from the support for default validations provided
by Web ADI Framework, DIF enables an Integrator Developer to extend the validation and business
rules on the data as per business requirements.
You can find more information on the Oracle E-Business Suite Desktop Integration Framework
through My Oracle Support as follows:
 Oracle E-Business Suite Applications Technology Readme, Release 12.1.2 (Note:
845809.1)
 Oracle Web Applications Desktop Integrator Release Notes, Release 12.1.2 (Note:
950876.1)
 Oracle E-Business Suite Desktop Integration Framework Developer's Guide, Release
12.1 (Note: 979354.1)
Best Practice 18: Performance Improvements

Please refer to note 791049.1 - R12 SLA/FAH: How to Improve Performance in Subledger
Accounting & Financials Accounting Hub.
30
Conclusion
The authors of this document hope that you have found this white paper useful to aid you in
optimal deployment and configuration of Oracle Financials Accounting Hub (FAH).
31
White Paper Oracle Financials Accounting Hub Copyright © 2012, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
Best Implementation Practices contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
E-Business Suite R12 warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
May, 2012 fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
Author: Tarakeswara Rao Janapareddy formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
Contributing Authors: Alexander Andersson, means, electronic or mechanical, for any purpose, without our prior written permission.
Albert Verschuuren, Angela Borth, Deborah
Ogg, Helle Hennings, Kapil Kumar, Michel Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Muylle, Preeti Shukla and Sven Van Leemput.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
Oracle Corporation are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
World Headquarters trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark licensed through X/Open
500 Oracle Parkway Company, Ltd. 0112
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

EBS FAH12BestImplPractices PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

EBS FAH12BestImplPractices PDF

Cargado por

Copyright:

Formatos disponibles

Oracle Financials Accounting, Best Implementation Practices, E-Business Suite R12

An Oracle White Paper

Oracle Financials Accounting Hub

Executive Overview ........................................................................... 1

AAD Application Accounting Definition

ADR Account Derivation Rule

AMB Accounting Methods Builder

FAH Oracle Financials Accounting Hub

IFRS International Financial Reporting Standards

JED Journal Entry Description

JLD Journal Line Definition

JLT Journal Line Type

SLA Oracle Subledger Accounting

SLAM Oracle Subledger Accounting Method

Best Practice 1: Recommended Implementation Approach

Analysis should be performed to identify:

The Applications Architecture analysis should entail:

Below are some examples of various architecture integrations:

Figure 1.Direct connect between the source system and FAH

Figure 2.Use of staging area (custom transaction tables)

Figure 3.Use of Transaction Data Store

Figure 4.Use of Data Warehouse

3. Ledgers and Chart of Accounts Structure

Thin and Thick Ledger

Secondary Ledgers / Reporting Currencies

4. Analysis of Source Systems

5. Set Up Configuration Options

Before commencing the FAH configuration, complete the following prerequisites:

It is recommended that FAH be gradually deployed by:

 Refining and performance tuning the system

8. Next Steps to Get You Started

Best Practice 2: Number of Applications

Best Practice 3: Event Model Design

EVENT_TYPE (Source) = (Constant) $Event Type$;

JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE

JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE

Best Practice 4: Journal Line Type Definitions

JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE

JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE

JOURNAL LINE EVENT CLASS EVENT TYPE JOURNAL LINE TYPE

A possible best case example would then be:

TYPE “ALL” AND A SINGLE JOURNAL LINE TYPE

DEFINITION (USING EVENT TYPE

Figure 5.Accounting Methods Builder Hierarchy

Best Practice 5: Minimal Usage of Constant Values

JOURNAL LINE EVENT EVENT JOURNAL LINE TYPE DESCRIPTION

DEFINITION CLASS TYPE

(CONDITION: EVENT_TYPE = 1) ‘Event Type is 1 and the side is DR’

(CONDITION: EVENT_TYPE = 2) ‘Event Type is 2 and the side is DR’

(CONDITION: EVENT_TYPE = 3) ‘Event Type is 3 and the side is DR’

(CONDITION: EVENT_TYPE = 4) ‘Event Type is 4 and the side is DR’

JOURNAL LINE EVENT EVENT JOURNAL LINE TYPE DESCRIPTION

DEFINITION CLASS TYPE

Best Practice 6: Minimal Usage of Custom Sources

NAME AGE GENDER

(COLUMN 1) (COLUMN 2 (COLUMN 3)

Creating a Custom Source

Build the intelligence in the Transaction Object (Extract View)

TABLE 10. ADDITIONAL FOURTH COLUMN ADDED TO TRANSACTION OBJECT

NAME AGE GENDER AGE_OVER_50

(COLUMN 1) (COLUMN 2 (COLUMN 3) (COLUMN 4)

This will improve the performance of the accounting program in FAH.

Best Practice 7: Set Up Components Reusability