R12 Federal Financials

Subledger Accounting Teardown

Larry Baugh
Apps Ingenuity LLC
April 24,2012

Introduction
Larry Baugh
13+ years Oracle Federal Financials Functional/Technical/Mgmt Experience
Emphasis Areas: GL, Budget Execution, Fed Admin (FV), AR, AP, IBY, FA,
Fed Reporting, PA, PO, iProc, Proc Contracts, XLA, XML/BI Publisher,
Discoverer, SQL, PL/SQL, etc.
Sample Federal Customers: DOI-NBC, USAF/USTRANSCOM-DEAMS,
DFAS, TMA, SBA, Other DOE, DoD, and misc Federal Civilian entities.
Recent Role: Solution Architect/Co-PM for US Dept. of Interior National
Business Center (DOI-NBC) Shared Services Environment Release 12.1.3
Upgrade (Go-Live = Feb 12).

Agenda

SLA Intro: What is SLA? How is SLA invoked? What does the Engine Do?
SLA Rules Configuration Framework, the Accounting Methods Builder
Event Processing Which components are applicable When?
Other Key AMB Components

SLA Sources and Custom Sources

Accounting Attributes & other Journal Line Type Pieces
Account Derivation Rules
SLA Debugging and Accounting Event/Entry Analysis
Accounting Methods Builder Context
Goal: To familiarize attendees with the
11i vs R12 GL Drilldown differences
internals of Federal SLA, enabling
enhanced capabilities for troubleshooting
SLA vs XLA vs FAH
and maintaining Agency-specific SLA
GL Transfer Summarization Level in R12
Configurations.
Takeaways

What is SubLedger Accounting (SLA)

A centralized, rules-based accounting engine/service utilized throughout R12 to

create an agencys required USSGL accounting entries.
A schema and toolset to support various features including enhanced
drilldown/reconciliation between the GL/Subsidiary modules and additional
reporting capability around accounting transactions/balances.
FV

PO

AP

PA
XLA

AR

FA

GL
Primary Ledger

Federal Financials Customers must implement SLA when deploying R12.

USSGL Transaction Codes are no longer an option for accounting events
except for manual or custom interfaced GL Journals.

How is SLA invoked to create the Acctg?

SLA processes are triggered differently depending on
whether the transaction event is subject to Budgetary
Control/Encumbrance processing.
For events not subject to Budgetary Control, SLA
processes are initiated via:
Submitting the Create Accounting concurrent
process (or wrapper, e.g. AR Submit Accounting)
Form Actions

How is SLA invoked to create the Acctg?

For events subject to Budgetary Control (i.e. FV Budget, PO Reqs/POs/Releases, AP
Invoice Validation), SLA processes are initiated via Funds Check and Funds
Reservation Actions.
Funds Check actions will create the SLA entries in a temporary Draft status.
Funds Reservation actions will create the SLA entries in a Final status.

What does the SLA Engine do?

As the SLA engine processes, it:
Creates the appropriate accounting entries from defined
SLA rules consisting of key attributes including base CCIDs,
Natural Account Segments, Accounted/Entered Dr/Cr,
Journal Line Descriptions, etc.

Creates new accounting journal entry and

subsidiary-linkage records in the XLA tables.
Optionally transfers to General Ledger
Updates XLA Balance tables

SLA Rules Configuration Framework - AMB

The rules and configurations which dictate the accounting entries created by SLA are setup using
the Accounting Methods Builder (AMB). The AMB Framework provides a hierarchical
mechanism for creating and maintaining a Ledgers SLA configuration.
Organizational Components:
Subledger Accounting Methods (SLAM) (e.g. the US Federal Method)
Application Accounting Definitions (AAD) (e.g. the PO AAD)
Event Classes/Types (e.g. Purchase Order and Agreements)
Journal Line Definitions (JLD) (e.g. Federal Purchasing)
The AMB Components that create the Fundamental Journal entry lines & CCIDs:
Journal Line Types (JLT) (e.g. FV PO Unanticipated Budget)
Account Derivation Rules (ADR) (e.g. Base CCID, SGL)
Supporting Components: Sources, Accounting Attributes, Journal Descriptions, Mapping Sets,
Supporting References, Business Flows, etc.

SLA Rules Configuration Framework - AMB

AADs and supporting components across modules roll-up to the SLAM.

SLA Rules Configuration Framework - AMB

A SLAM is tied to the Ledger using the
R12 Accounting Setup Manager.

SLA Rules Configuration Framework - AMB

The seeded US Federal Accounting SLAM serves as helpful guide in understanding how SLA
can be used for Federal Financials customers, but most Fed installs will likely have to
build/copy to custom rules based on their agency-unique USSGL structure, SLA posting
requirement variations and to overcome any bugs in the seeded US Federal SLAM.
For Federal Upgrades, note that upon initial upgrade,
Ledgers will not be automatically assigned to the US
Federal SLAM. The upgrade process will assign the
Accrual with Encumbrance Accounting SLAM.
Be sure to update the Ledger SLAM assignment to
start becoming familiar with the US Federal SLA
baseline.

SLA Rules Configuration Framework - AMB

An agency-specific SLAM can be configured with AMB
Component objects created (i.e. copied & tweaked) to
meet specific requirements. This will also help better
insulate a SLAM from future patch releases/changes.

SLA Rules Configuration Framework - AMB

Note that in the Seeded Federal AADs, the Natural Account segment ADRs are all tied to the
FV_ADR_ACCOUNT value-set. In order to utilize the seeded FV ADRs, an instances Natural
Account Values must match the values in the FV_ADR_ACCOUNT set.

SLA Rules Configuration Framework - AMB

If creating a new agency-specific JLD, if the JLD is mapped to a Chart of Accounts (COA), the
FV Seeded ADRs cannot be copied/associated into the new COA-specific JLD.

This is because the copy

process enforces that the
value-set used on any
ADRs, must be the valueset of the matching
segment in the defined
COA.

SLA Processing Whats Applicable When?

With all of the various AMB Components, it can be a bit confusing at first to understand how
JLTs and ADRs are turned on/off for specific transactions. execution
Which
AAD?
Which
Event
Class?
Which
JLD(s)?
Which
JLTs?
Which
ADRs?

SLA Processing Whats Applicable When?

Factors that control which JLTs/ADRs are applicable and fire for specific transaction events:
Module of the transaction: Controls which AAD of the SLAM will be evaluated
SLA Event Class/Type of the transaction: Controls which JLD(s) of the AAD will be
evaluated
Is the transaction subject to Budgetary Control: Controls which JLD(s) of the AAD will be
evaluated
JLT Conditions: Once the SLA Event processing identifies a transaction as applicable to a
JLD, the SLA engine will evaluate the transaction attributes against all the JLT conditions within
the JLD to determine which JLTs will fire for the transaction.
ADR Conditions: For all JLTs turned on, the mapped ADRs will then be evaluated based on
their conditions.
Which
AAD, Event Class, JLD(s), JLTs, ADRs?

SLA Event Processing Which EventType?

The method of associating a specific SLA Event Type code to a transaction differs between
modules, but there is no straight-forward way of precisely mapping the SLA Event Type Codes
to typical transaction events. However, the Event Type Codes/Names are mostly
understandable.

SLA Event Processing Which EventType?

Example: For Purchasing, Event_Type_Codes for PO Transactions are created by the
po_encumbrance_postprocessing.get_event_and_entity_codes procedure which is executed
by a Purchasing Funds Check/Reserve action, just prior to a call to SLA Event Processing.
PROCEDURE get_event_and_entity_codes(
p_doc_type
IN
VARCHAR2,
p_doc_subtype
IN
VARCHAR2,
p_action
IN
VARCHAR2,
x_entity_type_code
OUT NOCOPY VARCHAR2,
x_event_type_code
OUT NOCOPY VARCHAR2
)
IS

IF (p_doc_type = 'REQUISITION') THEN

x_entity_type_code := 'REQUISITION';
l_entity_str := 'REQ';
ELSIF (p_doc_type IN ('PO','PA')) THEN
x_entity_type_code := 'PURCHASE_ORDER';
l_entity_str := 'PO_PA';
ELSIF (p_doc_type = 'RELEASE') THEN
x_entity_type_code := 'RELEASE';
-- Bug 5015010
l_entity_str := 'RELEASE';
ELSE
l_error_flag := 'Y' ;
END IF;

IF (p_action = g_action_RESERVE) THEN

l_action_str := 'RESERVED';
ELSIF (p_action = g_action_UNRESERVE) THEN
l_action_str := 'UNRESERVED';
ELSIF (p_action = g_action_ADJUST) THEN
l_action_str := 'ADJUSTED';
ELSIF (p_action = g_action_CANCEL) THEN
l_action_str := 'CANCELLED';
ELSIF (p_action = g_action_FINAL_CLOSE) THEN
l_action_str := 'FINAL_CLOSED';
ELSIF (p_action = g_action_UNDO_FINAL_CLOSE) THEN
l_action_str := 'UNDO_FINAL_CLOSED';
ELSIF (p_action = g_action_REJECT) THEN
l_action_str := 'REJECTED';
ELSIF (p_action = g_action_RETURN) THEN
l_action_str := 'RETURNED';
-- Bug 4684263 Begin
ELSIF (p_action = g_action_INVOICE_CANCEL) THEN
l_action_str := 'INV_CANCELLED';
ELSIF (p_action = g_action_CR_MEMO_CANCEL) THEN
l_action_str := 'CR_MEMO_CANCELLED';
x_event_type_code := l_entity_str||'_'||l_action_str;

SLA Event Processing Which EventType?

SLA Event Classes and Types
are seeded and not modifiable
for standard E-Business Suite
transactions.
Event Class to GL JE Category
configurations can be updated if
desired.
For external E-Business Suite
transactions, custom Event
Classes/Types & other XLA
configs can be accomplished
with a Financials Accounting
Hub (FAH) license.

SLA Event Processing Which JLD?

In some cases, the Budgetary Control Flag on the JLD will be a factor on whether a JLD is
applicable for a particular transaction event. (Example: Federal Payables AAD - Invoices JLDs)
For the Event Class = Invoices, two JLDs are assigned.
During Invoice Validation, the Funds Checking engine invokes
SLA to determine any Accounting Impacts subject to Budgetary
Control, i.e. any JLDs with the Budgetary Control flag checked.
Afterword, the Create Accounting
process is run which invokes SLA to
create accounting with any JLDs
that dont have the Budgetary
Control flag checked.

SLA Event Processing Which JLTs??

Typically, when a JLD is valid for an event,
only some of the JLTs defined within the
JLD will be applicable, not all.

SLA Event Processing Which JLTs??

All conditions of the JLT must be true for the transaction, in order for the JLT to be activated.

SLA Event Processing Which JLTs??

For our two example JLTs, key condition differences are:
XXAAA PO Unpaid Obligation JLT

XXAAA PO Unpaid Obligation PYA JLT

Federal Prior Year Flag = N

Federal Prior Year Flag = Y

FV Accounted Unpaid Obligation Amount !=0

FV Accounted Unpaid Obligation PYA Amount != 0

Functionally, the
conditions make sense
in the Federal
environment, but fully
understanding the
values represented by
the sources requires
more digging into SLA
Sources.

SLA Sources
Sources are R12 data elements that can be used in AMB rule definition. Sources
are assigned to the Event Classes they are applicable to. R12 provides thousands
of seeded sources and also provides the capability for Custom Sources.

SLA Sources
SLA Sources map to columns of database views. These views represent numerous data
elements directly related to or derivable from a transaction and its data attributes
% _extract_%v Views:
e.g.
PO_EXTRACT_HEADER_V
PO_EXTRACT_DETAIL_V
PO_DISTS_REF_V

Fv_xla% _ref_%v
Views:
e.g.
FV_XLA_PO_REF_V
FV_XLA_AP_REF_V

EBS Core
Tables

Source_Code

Source Name

PO_DISTS_REF_V Column

PO_DISTRIBUTION_ID

PO Distribution Identifier

PO_DISTRIBUTION_ID

PO_DISTRIBUTION_NUMBER PO Distribution Number

PO_DISTRIBUTION_NUMBER

PO_SHIPMENT_NUMBER

PO Shipment Number

PO_SHIPMENT_NUMBER

PO_LINE_ID

PO Line Identifier

PO_LINE_ID

PO_HEADER_ID

PO Header Identifier

PO_HEADER_ID

PO_DISTRIBUTION_TYPE

PO Distribution Type

PO_DISTRIBUTION_TYPE

PO_LINE_LOCATION_ID

PO Line Location Identifier PO_LINE_LOCATION_ID

GL_DATE

Gl Date

GL_DATE

SLA processes include creating a variety of temporary Extracts during event

Processing. Transaction attribute values are gathered and inserted into specific
Global Temporary (_GT) tables, to be efficiently exposed as SLA Sources for use in
conditions, accounting attributes, journal line descriptions, etc.

SLA Sources
Multiple Federal Financials-specific sources are collected/derived and inserted into the
fv_extract_detail_gt by a variety of R12 FV SLA Processing packages. These sources
are made available to the SLA rules engine via a set of fv_xla_%ref_v views.
TIP: If the FV: Debug Profile option is
enabled, the extract data populated
during the XLA event processing is
archived into
fv_extract_detail_gt_logs.

fv_sla_%_processing_pkgs
e.g.
fv_sla_po_processing_pkg

Fv_xla% _ref_%v
Views:
e.g.
FV_XLA_PO_REF_V
FV_XLA_AP_REF_V

FV_EXTRACT_DETAIL_GT
EBS Core
Tables
FV_EXTRACT_DETAIL_GT_Logs

SLA Sources
To 100% understand the driving field or logic behind the seeded SLA
Sources, the sources extract object view needs to be interrogated and in
some cases, PL/SQL needs to be searched to understand the datas
origination.

SLA Available
Sources by Event Class

SLA Sources
In the case of our Federal Prior Year Source, the originating source is the
fv_sla_utl_processing_pkg.get_prior_year_status procedure. The
fv_sla_utl_processing_pkg is triggered by a series of hooks originating from the
xla_accounting_pkg.
The procedure compares the period_year of
create or replace
the current transactions GL Date versus the
PACKAGE BODY
fv_sla_utl_processing_pkg
AS
BFY on the transaction to determine if the
..
PROCEDURE get_prior_year_status
BFY is Prior Year.
(
p_application_id
p_ledger_id
p_bfy_value
p_gl_date
p_pya
p_pya_type
p_error_code
p_error_desc
)

IN NUMBER,
IN NUMBER,
IN VARCHAR2,
IN DATE,
OUT NOCOPY VARCHAR2,
OUT NOCOPY VARCHAR2,
OUT NOCOPY NUMBER,
OUT NOCOPY VARCHAR2

Note: If the GL Date Year is not setup in the

FV Define Federal Options form (aka BFY
Mapping table), the procedure will throw an
exception, preventing SLA Entry creation.

Custom Sources
Although thousands of seeded SLA Sources are available, the potential exists that
some data attribute desired for use may not be available as a seeded source. R12
provides the capability for developing custom PL/SQL functions that can then return
values to be used as sources.
Seeded sources are passed as
input parameters into the custom
functions, in the order they are
configured in the Custom Source
definition form.
Custom Sources can be utilized as
Accounting Attributes if defined.

Custom Sources
Custom Source Development Recommendations:
Consolidate the custom sources into a single or few packages, i.e.
XXAAA_SLA_UTL_PKG or XXAAA_PO_SLA_UTL_PKG.
Utilize a debug mechanism to be able to capture key data/variables utilized during
custom source execution. The potential exists that some data may only be available
inside the XLA Event processing session.
IF l_debug = 'Y' THEN
INSERT INTO CUS01.XXAAA_XLA_DEBUG
(id,creation_date,message_text, module)
VALUES (xxaaa_xla_debug_s.nextval, sysdate,
'2: Values - p_pay_hist_dist_id: '||p_pay_hist_dist_id||', l_exchange_rate: '||l_exchange_rate||'
l_event_type: '||l_event_type, l_module);
END IF;

Try to standardize on input Sources that are consistently solid & code from there.
Many sources are null, depending on the transaction (even sources like Ledger_ID)
Keep as simple and high performing as possible.
Version control the code.

JLT Components Accounting Attributes

All JLTs must include Accounting Attribute Assignments. The Accounting Attribute
Assignments are used to populate numerous columns in the XLA_AE_LINES,
XLA_DISTRIBUTION_LINKS and GL_JE_LINES depending on the accounting entry
summarization level utilized.
For example, the value for the SLA Source
mapped to the Accounted Amount will be the
Accounted_Dr or Accounted_Cr amount
created in XLA_AE_LINES/GL_JE_LINES if
detail level summarization is utilized.
Otherwise, the value will be summarized with
other XLA_AE_LINES or
XLA_DISTRIBUTION_LINKS records.

JLT Components Side

The Side setting on JLTs can be a bit
confusing when first getting familiar with SLA.
The Side value does not represent that a JLT
will always 100% create a Credit entry or always
create a Debit entry, it depends on the sign of
the JLTs accounted amount value.
If accounted_amt > 0 & the side value = Debit,
then the JLT will create a Debit.
If accounted_amt < 0 & the side value = Debit,
then the JLT will create a Credit.

JLT Components Balance Type

To create the required Federal Trial Balance
journal entries, the Balance Type for all typical
Federal Journal Entries should be Actual.
In Federal Government business processes,
Actual journals are used for Funds Budget
Distribution, Funds Status reporting and Funds
Checking.
Encumbrance journals are typically utilized
more in State & Local Governmental
Accounting.

JLT Components Business Flow

In my analysis to-date, I have not
implemented the use of Business
Flows in Federal JLTs.
For US Federal R12 Upgrade
customers, Im concerned about
the viability of Business Flows to
properly link between 11i and
R12 created Budgetary
Accounting events.
This is due to the lack of a SLA Historical Upgrade process for pre-R12 entries
created by USSGL Transaction Codes.

Account Derivation Rules (ADRs)

Once the SLA engine determines a JLT
will be invoked for an event, the ADRs
provide the framework for creating the
Code Combination ID (CCID) or Line of
Accounting the JLT that will be posted.
Every JLT must at least include a
mapping to an All Segments ADR that
will result in a valid CCID. The All
Segments ADR will lay-down the
baseline CCID for the Accounting Entry.
Additional segment ADRs, i.e. SGL or Natural Account, can then be mapped and
configured to override the basline CCID values for the applicable segment.

Account Derivation Rules (ADRs)

Conditions based on SLA
Sources are the key
components that drive ADR
value selection, just like JLTs

Journal Line Descriptions

As desired, R12 supports flexible configuration of constant text and dynamic source
values to be included in the SLA and GL journal header & line description fields.

Mapping Components to Charts of Accounts

Most AMB Components may be mapped to a Transaction and Accounting Chart of
Accounts.
Mapping Components to a
Transaction Chart of Accounts
allows for:
In the case of JLTs, ADRs and Line
Descriptions, non-qualified Flexfield
Segments (i.e. not the balancing,
natural, cost center, etc. segments),
become available for use as
sources.

Mapping Components to Charts of Accounts

Mapping JLDs to an Accounting Chart of Accounts value provides the capability to
include ADRs for non-qualified segments.

Vs.

Mapping Components to Charts of Accounts

The primary downside of mapping AMB Components to Transaction and
Accounting Chart of Accounts values is that when multiple Chart of
Accounts are used in an environment, the AMB Components will need to
be duplicated.

As an additional FYI, mapping AMB Components to different Accounting Chart

of Accounts values is utilized when SLA is utilized to create multiple
accounting representations in secondary ledgers.

SLA Debugging and Analysis

Debugging of SLA Configurations is likely required when
1.Budgetary Control event errors (i.e. Funds Reservation) prevent document
processing
2.Erroneous Accounting entries are being created

SLA Debugging and Analysis

Key SLA Debugging tools/approaches include:
1.Using SQL Queries to analyze the accounting entries being created for a
particular event, including understanding the JLTs which are firing to create the
XLA_AE_LINE entries.
XLA AE Line Data

2.When exceptions occur that prevent data from being committed to the XLA tables
for an event, the XLA actions can typically be caught by using standard FND Debug
functionality.
1. Turn on FND Debug at Statement Level (Profile Options) FND_Lo g_Me s s a g
e s ke
2. Select Max(Log_Sequence) From Fnd_Log_Messages
My XLA Attribute de
3. Execute XLA Action (e.g. Funds Check/Reserve, Create Acctg)
4. Extract the fnd_log_messages created

SLA Debugging and Analysis

3: Enable the FV: Debug Profile option to see the extract data populated during the
XLA event processing in fv_extract_detail_gt_logs. Querying this table is the best
method to see the FV source values derived for a transaction event.

4: Other extract
source values are
often written as
fnd_log_message
records during XLA
processing.

SLA Debugging and Analysis

Oracle also provides a standard SLA Diagnostics capability, which is helpful as long as
exceptions dont prevent the processing data from being committed to the XLA tables.
The SLA Diagnostics provides features to help with:
reviewing the source values for the transaction objects during XLA event processing
analyzing issues related to the generation of subledger journal entries.
To engage the Diagnostics features:
Set Profile Option- SLA: Enable Diagnostics to Yes
Enter Transactions
Run Request: Create Accounting
Run Request: Transaction Objects Diagnostics

SLA Debugging and Analysis

Lessons Learned:
The majority of Purchasing exceptions encountered to-date are due to XLA Event
Processing attempting to create unbalanced journal entries. This was often either due
to JLTs not being invoked in some cases (sometimes due to bugs in seeded FV amount
sources), or the multiple JLT accounted_amounts not balancing to zero.
e.g.
xla.plsql.XLA_AE_LINES_PKG.SetAcctLineType p_accounting_line_type_code = C- p_accounting_line_code= FV_RLS_RE_RES_OBL_UNPAID
xla.plsql.XLA_AE_LINES_PKG.SetDebitCreditAmounts Accounted_DR =
xla.plsql.XLA_AE_LINES_PKG.SetDebitCreditAmounts Accounted_CR = 239.97
xla.plsql.XLA_AE_LINES_PKG.SetAcctLineType p_accounting_line_type_code = C- p_accounting_line_code= FV_RLS_UNANTIC_BUD
xla.plsql.XLA_AE_LINES_PKG.SetDebitCreditAmounts Accounted_DR = 319.96
xla.plsql.XLA_AE_LINES_PKG.SetDebitCreditAmounts Accounted_CR =
xla.plsql.XLA_AE_LINES_PKG.SetAcctLineType p_accounting_line_type_code = C- p_accounting_line_code= XXNBC_FV_RLS_UNPAID_OBL_PYA
xla.plsql.XLA_AE_LINES_PKG.SetDebitCreditAmounts Accounted_DR =
xla.plsql.XLA_AE_LINES_PKG.SetDebitCreditAmounts Accounted_CR = 319.96

AMB Object Data Model

Understanding the AMB
Object Data Model helps
provide enhanced
capability for analyzing a
SLAM for any defects, e.g.
improper condition
configurations between or
duplicated across JLTs.

R12 Simple ERD of

SLA AMB Components.pdf

SLA JLT and ADR

Detail fo r AMB Co mpo nent

FV 9000001
FV_PURCHASING_AAD

Accounting Methods Builder Context

The flexibility for using different
AMB Context values is quite helpful
in SLA testing and troubleshooting.
Utilizing different AMB Context
values, allows for working with AMB
Component configurations
executing transactions
independently, without impacting
users in other AMB Contexts, e.g.
the Default.

Accounting Methods Builder Context

To enable the use of a separate AMB Context:
1.Create a new lookup value for lookup type
XLA_AMB_CONTEXT_TYPE, e.g. LARRY1
2.Utilize the Export Application Accounting Definitions
utility to export AADs from all desired modules from the
source AMB Context. Coordinate with the DBA/UNIX
team on a temp OS directory if needed.
3.Switch the AMB Context value to the desired new
value.
4.Utilize the Import Application Accounting Definitions
utility to import AADs into all desired modules from the
source ldt file created in Step 2.

11i vs R12 GL Drilldown differences

Data model changes in the GL -> Subsidiary
Drilldown will likely require significant rework
to Agencys reporting and outbound
interfaces.
gl_je_lines.referenceX are null in R12 or
represent different data than in 11i.
An additional complicating factor for Federal
agencies upgrading to R12 is that the SLA
Historical Upgrade process does not
populate the XLA tables with data created
from 11i Transaction Codes.

Blended detail transactional reporting

across both the 11i and R12 data
models can get a bit complex.

11i vs R12 GL Drilldown differences

11i Requisition GL Journal Lines Drilldown
gl_je_lines.reference_2: req_header_id
gl_je_lines.reference_3: req_distribution_id
gl_je_lines.reference_4: Req Number

R12 GL to
Requis itio n Drilldo wn.s ql

R12 xla.xla_distribution_links join logic:

Where source_distribution_type = 'PO_REQ_DISTRIBUTIONS_ALL' and application_id = 201
Then:
source_distribution_id_num_1 = Po_Req_Distributions_All.distribution_id
Where applied_to entity_code = REQUISITION
Then:
applied_to_source_id_num_1 = po_requisition_headers_all.requisition_header_id

11i vs R12 GL Journal Source/Category

A number of changes to the GL Journal Source and Journal Category values for
transaction types have been introduced with R12. This could impact any custom
GL drilldown-based reporting/interfaces.
Transaction Type
FV Treasury Confirmation

11i Je Source/Category
Payables/Treasury Confirmation

FV Budget Distribution

Budgetary
Budgetary
Budgetary
Budgetary

Purchase Releases (Blanket & Sched)

Purchasing/Purchases

Purchasing/Releases

Purchasing Receipts

Purchasing/Receiving

Cost Management/Receiving

Receivables Standard Receipts

Receivables/Trade Receipts

Receivables/Receipts

Transaction/Appropriation
Transaction/Apportionment
Transaction/Allotment
Transaction/SubAllotment

R12 Je Source/Category
Budgetary Transaction/Treasury
Confirmation
Budgetary Transaction/Budget Distribution

SLA vs XLA vs FAH

Great post at: http://sleemput.blogspot.com/2010/12/difference-between-fah-and-sla.html
Technically, XLA = SLA = FAH.
XLA the application short name and prefix for the common
database schema/objects which support R12 SLA and FAH.
SLA Subledger Accounting, the terminology of using the
XLA framework to create accounting for seeded E-Business
Suite modules/events.
FAH Financials Accounting Hub, the terminology of using
the XLA framework to create accounting for external, custom
applications into E-Business Suite GL. (addl license)

Summary and Detail XLA/GL Posting in R12

In 11i, Federal Financials required Detail General Ledger posting to support FACTS,
224 and some other Federal Reporting needs.
I asked (via SR) if Summarization was an option with R12. Support responded with
Please note that irrespective of the Mode of Transfer (Detail or Summary), Drilldown
will work from GL to all the Subledgers that are using the SLA Engine.
Analysis of some of the R12 FACTS & 224 code, showed that FV Reporting should
work with Summarized GL postings (since everything drills back through the
xla_distribution_links table).
In the environment Ive been working in, GL Transfers are done every hour. Based on
the minimal additional GL Journal summarization that would have occurred due to that,
we just decided to stick with detail-level SLA and GL Journal entries.

Summary and Detail XLA/GL Posting in R12

In the SLA Configuration, there are 3 components which are factors in the SLA and GL
Line Summarization Level
1.JLT Merge Matching Lines option
2.JLT Transfer to GL option
3.Accounting Setup Manager: General Ledger Journal Entry Summarization Option
The JLT Merge Matching Lines option controls summarization of
XLA_DISTRIBUTION_LINKS (100% Detail) into the XLA_AE_LINES table. The
options are described in MOS Note: 876190.1:
ALL
DR/CR
NO

Summary and Detail XLA/GL Posting in R12

In the JLT Configuration, the
Transfer to GL configuration is
only applicable in some cases.
Key MOS Notes:
R12: FAQ on Transfer to GL in
R12 [ID 876190.1]
Impact of R12 Subledger
Accounting (SLA) on General
Ledger (Drilldown and Journal
Import) [ID 434226.1]

Summary and Detail XLA/GL Posting in R12

If detail-level posting is chosen,
it is probably best to utilize the
Group by GL Date
Summarization option.
This option provides for GL
Journal Lines to be posted at
the lowest detail level, but
groups the lines into GL Journal
Entries (Headers) by GL Date.
Using the No Summarization option will result in GL Journal Entries (Headers)
being created for every individual XLA Event Id.

Key Takeaways
The introduction of SLA for Federal Financials, while much more flexible and
provides multiple benefits, is significantly more complex to implement,
maintain and troubleshoot than 11i USSGL Transaction Codes. Be prepared.
Having a strong blend of Federal functional and technical capability (can be
across multiple resources) will likely be crucial to Federal SLA success.
Due to the wide variety in transaction attributes and event actions that may result
in source value differences used in SLA conditions, significant SLA testing must be
robustly employed when initially implementing, changing or patching an agencys
SLA Configuration.

Additional Resources
Various Oracle Docs:
Oracle Subledger Accounting Implementation Guide, Oracle Financials
Implementation Guide, Oracle Financials Concepts Guide
Oracle Applications Upgrade Guide, Oracle Financials and Oracle Procurement
Functional Upgrade Guide

MOS Notes:
Note 396829.1: Oracle Subledger Accounting Documentation Resources, R12
Note 985539.1: R12 SLA: Subledger Accounting Reference Articles

The Seeded US Federal Accounting Method (FV Imp Guide)

Solution Beacon R12 SLA: What It Is, What It Does, and How to Use It
Various R12 Blogs & R12 Apps Related Sites online (XLA, SLA, FAH)
http://sleemput.blogspot.com/

Thanks for attending

Larry Baugh
Larry.Baugh@AppsIngenuity.com

Blog - http://www.OracleFedApps.com
Twitter - @OracleFedApps
Be sure to check the blog for the latest version of this presentation
and other info!
Addl session:
R12 Federal Financials Recent Enhancements and Upgrade Impacts
Wednesday, 25-April, 1PM, South Seas A