R12 GL Study

R12: How Does Primary to Secondary Ledger COA Mapping Work In Create Accounting
Process? (Doc ID 1308391.1)
APPLIES TO:
Oracle Subledger Accounting - Version 12.0.0 and later

Information in this document applies to any platform.
GOAL
How does the Create Accounting process use COA mapping defined between the
primary and secondary ledgers and derivation rules defined in SLA to derive the
secondary ledger account?
SOLUTION
The ADR attached to the secondary ledger will be applied after deriving the CCID by
applying COA mapping on the distribution account of the transaction.
When primary ledger and secondary ledger have different SLAMs attached then the
CCID first will be derived by applying COA mapping on the distribution account of the
transaction.
The ADR attached to the secondary ledger's SLAM will then be applied subsequently to
derive the final CCID for the secondary ledger.
(CCID = code_combination_id ADR = Account Derivation Rules SLAM = Subledger

Accounting Method)
Example:
Transaction Distribution Account (Revenue account) = 01-1000-000
Result after applying the COA mapping from primary to secondary ledger = 01-10-000
Then apply the ADR of the secondary ledger SLAM.

If here, the rule for segment2 (in above example) = constant 40, then the final account
will be
derived = 01-40-000
How To Derive Accounts Using Account Derivation Rules in R12 SLA Architecture (Doc
ID 797115.1)
APPLIES TO:
Oracle Purchasing - Version 12.0 to 12.1.3 [Release 12 to 12.1]
Oracle Cost Management - Version 12.0.0 to 12.1.3 [Release 12 to 12.1]
Oracle Receivables - Version 12.1.3 to 12.1.3 [Release 12.1]
ABSTRACT
This document explains how to derive a code combination using Account Derivation
Rules with the help of SLA Architecture that can be used for an event type in a Procure
to Pay cycle with a proper business case. It also explains about the pre-requisites for an
account to be a source for the Account Derivation Rules(ADR).
This Account Derivation Rules applies only to SLA and GL where the derived accounts
will get hit on performing the transactions such as Receipt or Invoice and on doing the
Create Accounting process. But the Requisition and PO Account Generator follows the
same old logic as in 11i and not the Account Derivation Rules in SLA. Hence the
requisition or PO distributions will not have the accounts as per the setups done in ADR.
DETAILS
Let us consider a business case where there is a need to derive the account that should
be used in the Procure to Pay cycle.
Business Case: Balancing segment of Expense AP Accrual account used in a
PO Receipt Journal should be derived from its corresponding Purchase Order
distribution Charge account.
Business Requirement:
Under one operating unit, there are multiple inventory organizations or locations for
which multiple expense accounts with different balancing segments are defined. When
a purchase order is created with expense destination, the charge account will get
defaulted with different balancing segments based on the expense accounts defined for
the ship to organization and locations specified in the purchase order where as the
Expense AP Accrual account gets defaulted in the PO from Purchasing Options for which
the balancing segment remains constant for that operating unit irrespective of inventory
organizations and locations. Now the requirement is to derive the balancing segment of
Expense AP accrual account based on the balancing segment of PO Charge account.
Example:
Expense AP Accrual account defined under Purchasing options for the operating unit
is XX-000-ZZZZ-0000-000
Under this operating unit, there are two inventory organizations A and B.
Expense account defined for the organization A is AA-000-XXXX-0000-000
Expense account defined for the organization B is BB-000-YYYY-0000-000
When a Purchase Order is created with ship to organization as A, the charge account
that gets defaulted in the PO will be AA-000-XXXX-0000-000 where as the Expense AP
Accrual account will be
XX-000-ZZZZ-0000-000.
Current Process:
When this PO is received in organization A, the accounting will happen with a mismatch
in balancing segment as follows:
Accrual a/c XX-000-ZZZZ-0000-000 CR
Charge a/c AA-000-XXXX-0000-000 DR
Desired Accounting entries in SLA and GL:

When this PO is received in organization A, the accounting should happen as follows:
Accrual a/c AA-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c AA replaces

the balancing segment XX of Expense AP accrual a/c
If the PO is received in organization B which belongs to the same operating unit, the
accounting should happen as follows:
Accrual a/c BB-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c BB replaces

Charge a/c BB-000-YYYY-0000-000 DR
Pre-requisites to get the accounts in SLA and GL:
 Account Derivation Rule (ADR)

 Journal Line Type (JLT)
 Journal Line Definition (JLD)
 Application Accounting Definition (AAD)
 Subledger Accounting Method (SLAM)
To derive the accounts, Account Derivation Rules (ADR) has to be defined and attach
this ADR to the respective Journal Line Type (JLT) under the Journal Line Definition
(JLD) for the respective event type code. But you would not be able to make any
changes to the seeded JLD,seeded AAD and seeded SLAM and hence the user defined
ADR cannot be attached directly to the seeded JLD. Therefore it is mandatory to define
an user defined JLD,AAD and SLAM so that the user defined ADR can be used to derive
the accounts and to get those derived accounts in SLA and GL.
Steps to get the accounts in SLA and GL:
Let us consider two scenarios in a Procure to Pay cycle and see how the accounts can
be derived using Account Derivation Rules (ADR) and how those derived accounts hit
the Subledger (SLA) and General Ledger (GL) to meet this business requirement.
a) PO set to accrue at receipt
b) PO set to accrue at period end
1. Defining the Account Derivation Rule:

Navigation: Cost Management,SLA responsibility > SLA > Accounting Setup >
Accounting Methods Builder > Journal Entry Setups > Account Derivation Rules
 Click the New button

 Define the Rule code and Rule name
 Choose the output type as 'segment' and select the value 'Balancing segment'
from the LOV.
 Under Priorities, choose the source as "Distribution Charge account" from the
LOV and segment as 'Balancing segment'. You can refer to Note.802003.1 if you
are not able to get the source "Distribution Charge account" in the LOV.
 Save the form
Note: The output type should be 'segment' only if the requirement is to derive a particular
segment from the chart of accounts. If there is a requirement to derive the entire code
combination, then the output type should be 'flexfield'.
It has to be ensured that the following setups are in place before defining the ADR.
a) The value that is selected as a source in ADR form should be defined as a source for any of
the applications such as Cost Management or Purchasing and the Key flexfield check box should
be enabled for that source with the flexfield application as General Ledger.
Navigation: Cost Management SLA responsibility > SLA > Accounting Setup > Accounting
Methods Builder > Sources
If the source does not have the Key flexfield check box enabled, it won't appear in the
LOV of ADR form. But this Key flexfield checkbox is not editable and hence the source
which you are choosing in the LOV of ADR form should have the key flexfield enabled
as seeded setup.
Note: The examples which have been discussed in this whitepaper requires the
Distribution Charge account as the source to be used in ADR. Also this source will be
required whenever the accounts are derived based on any code combinations used in
the Purchase Orders. But this source will have the key flexfield enabled only after
getting a particular file version of the file poxlaem.ldt. Please refer to Note.802003.1 for
more details on this.
b) The source value defined in the ADR should be assigned to the respective event class
such as "period end accrual" or "receipt into receiving inspection" in Source
Assignments form with extract object level as Header.
Navigation: Cost Management SLA responsibility > SLA > Accounting Setup >
Accounting Methods Builder > Sources > Source Assignments
c) The source value defined in the ADR should be available in the view defined under
Transaction Objects or Reference Objects for the respective event class.
To identify this view, navigate to Cost Management SLA responsibility > SLA >
Accounting Setup > Accounting Methods Builder > Events > Accounting Event Class
Options and query for the respective event class and verify the view under Objects tab.
For the scenario what we have considered, PO_DISTS_REF_V is the view defined under
Reference Objects for the event class "period end accrual" and "receipt into receiving
inspection" and the source "Distribution Charge account" is available in this view.
If the source choosen in the ADR form is not available under the corresponding view, ADR will
get created but the program "validate AAD" will error out and ADR cannot be successfully used
to derive the account.
2. Defining the Journal Line Definition:

Navigation: Cost Management,SLA responsibility > SLA > Accounting Setup > Accounting
Methods Builder > Methods and Definitions > Journal Lines Definitions
a) If the PO is set to accrue at period end
 Query the event class "Period end accrual" and seeded definition code
"PERIOD_END_ACCRUAL" and click on Find button
 Click on Copy definition button and create a new JLD which gets copied from the
seeded JLD existing for this event class
 For this user defined JLD, attach the user defined ADR for the Journal line type
'Accrual' under Account Derivation Rules tab by choosing segment as the
balancing segment in addition to the default rule name "Cost Management
Default Account".
Note: If the ADR is defined for the entire flexfield, then the default rule itself should be
replaced by the user defined ADR.
 Save this user defined Journal line definition
b) If the PO is set to accrue at receipt
 Query the event class "Receipt into Receiving Inspection" and seeded definition
code "RCPT_REC_INSP"
Default Account"
3. Defining the Application Accounting Definition:
Accounting Methods Builder > Methods and Definitions > Application Accounting
Definitions
 Query the seeded AAD code "COST_MANAGEMENT" or

"COST_MANAGEMENT_ENCUMBRANCE"
 Click on Copy button and create a new AAD which gets copied from the seeded
AAD
 For this user defined AAD, attach the user defined JLD for the event class 'Period
end accrual' after deleting the seeded JLD "Period End Accrual"
 Save the user defined AAD and click on "Validate" button so that this user
defined AAD will get validated.
 For this user defined AAD, attach the user defined JLD for the event class
'Receipt into Receiving Inspection' after deleting the seeded JLD "Receipt into
Receiving Inspection"
4. Defining the Subledger Accounting Method:

Accounting Methods Builder > Methods and Definitions > Subledger Accounting
Methods
 Query the seeded SLAM "STANDARD ACCRUAL" or "ENCUMBRANCE ACCRUAL"
 Click on Copy button and create a new SLAM which gets copied from the seeded
SLAM
 Attach the user defined AAD under the user defined SLAM for the application
Cost Management
 Save the user defined Subledger Accounting Method
5. Setting up the SLAM in Accounting Setup Manager:
Navigation: General Ledger Responsibility > Setup > Financials > Accounting Setup Manager >
Accounting setups
Query the ledger and click on "Update Accounting options"
Click on Update icon for the description "Define and update the journal processing options for
your ledger"
Under Subledger Accounting, set the user defined SLAM as the subledger accounting method
Save the Accounting setup Manager page
6. Getting the derived account in SLA and GL for a PO receipt:
 Create an Expense PO set to accrue at period end with charge account having
the balancing segment as "02" and accrual account defaulted from Purchasing
options having the balancing segment as "01".
 Approve the Purchase Order
 Receive the PO and do not match invoice to the PO or receipt
 Run the Receipt Accruals-period end program and let the create accounting
process gets completed
 Verify the accounting entries in SLA Inquiry by navigating to Cost Management
Responsibility > SLA > Inquiry > Journal entries
Following accounting entries are shown in SLA:
PO Charge a/c - 02-510-7530-0000-000 DR @ (Received qty * PO Unit Price) + Non-
Recoverable tax
AP Accrual a/c - 02-000-2215-0000-000 CR @ (Received qty * PO Unit Price) + Non-
Recoverable tax
You can see the balancing segment of AP Accrual a/c "02" which got derived from PO
Charge account even though the PO distribution has the accrual account with balancing
segment as "01"
If the ADR is not defined for this Journal line type "Accrual", then the accounting entries
for the same scenario would be as follows:
Recoverable tax
Recoverable tax

 Create a PO set to accrue at receipt with charge account having the balancing
segment as "02" and accrual account defaulted from Purchasing options or
inventory organization parameters depending on the destination type having the
balancing segment as "01"
 Ensure that the Receiving Inspection account in Receiving options has the
balancing segment "02" which is same as the balancing segment of PO Charge
account. If it is different, then ensure that the Automatic offset method is set to
"Balancing" in Purchasing > Setup > Organizations > Purchasing options. This
has to be ensured because this would create an intercompany journal as the
balancing segments differ for the accounts in a particular journal which is the
intended design. So to avoid this intercompany journals, this set up needs to be
verified.
 Receive and deliver the PO
Following accounting entries will be shown in SLA:

RECEIVE:
Receiving Inspection a/c - 02-000-1222-0000-000 CR @ (Received qty * PO Unit Price) +
Non-Recoverable tax
Recoverable tax
DELIVER:
Recoverable tax
Receiving Inspection a/c - 02-000-1222-0000-000 CR @ (Received qty * PO Unit Price) +
Non-Recoverable tax
segment as "01". Similarly you can see the balancing segment of Receiving Inspection a/c
"02" which got populated based on the balancing segment of PO Charge account which has
happened due to the Automatic Offset method set to Balancing. If this option is not set to
"Balancing" and the balancing segment of Receiving Inspection a/c is not the same as PO
Charge a/c, then there would be a mismatch between the balancing segments of journal
belonging to the DELIVER transaction. At the same time, if the option is set to "Balancing"
and ADR is not defined for the Journal line type "Accrual", then there would be a mismatch
between the balancing segments of journal belonging to the RECEIVE transaction. Hence
when the ADR is defined to meet this kind of business requirement, then the Automatic
Offset method should also be set to Balancing to avoid intercompany journals if the
Receiving Inspection a/c has a different balancing segment from that of the PO Charge a/c.
Note: When the ADR is defined to derive the accrual account for transactions related to POs
set to accrue at receipt, then it has to be ensured that this derived code combination is
defined in "Select Accrual Accounts" form so that accrual reconciliation can be done for this
account using AP PO Reconciliation reports.
SUMMARY
The requirement as mentioned in the business case is achieved by configuring the SLA
accordingly which resulted in generation of accounting entries for PO Receipt
transactions without creating any intercompany journals as required.
Apart for this configuration which has been done to meet the above mentioned
business case, there are some more advanced features in Account Derivation Rules
using mapping sets or giving SQL conditions for picking up the accounts which is not
included as a part of this case study.
How To Derive Accounts Using Account Derivation Rules in R12 SLA Architecture (Doc
ID 797115.1)
APPLIES TO:
Oracle Purchasing - Version 12.0 to 12.1.3 [Release 12 to 12.1]

Oracle Cost Management - Version 12.0.0 to 12.1.3 [Release 12 to 12.1]
Oracle Receivables - Version 12.1.3 to 12.1.3 [Release 12.1]
ABSTRACT
This document explains how to derive a code combination using Account Derivation
Rules with the help of SLA Architecture that can be used for an event type in a Procure
to Pay cycle with a proper business case. It also explains about the pre-requisites for an
account to be a source for the Account Derivation Rules(ADR).
This Account Derivation Rules applies only to SLA and GL where the derived accounts
will get hit on performing the transactions such as Receipt or Invoice and on doing the
Create Accounting process. But the Requisition and PO Account Generator follows the
same old logic as in 11i and not the Account Derivation Rules in SLA. Hence the
requisition or PO distributions will not have the accounts as per the setups done in ADR.
DETAILS
Let us consider a business case where there is a need to derive the account that should
be used in the Procure to Pay cycle.
Business Case: Balancing segment of Expense AP Accrual account used in a
PO Receipt Journal should be derived from its corresponding Purchase Order
distribution Charge account.
Business Requirement:
Under one operating unit, there are multiple inventory organizations or locations for
which multiple expense accounts with different balancing segments are defined. When
a purchase order is created with expense destination, the charge account will get
defaulted with different balancing segments based on the expense accounts defined for
the ship to organization and locations specified in the purchase order where as the
Expense AP Accrual account gets defaulted in the PO from Purchasing Options for which
the balancing segment remains constant for that operating unit irrespective of inventory
organizations and locations. Now the requirement is to derive the balancing segment of
Expense AP accrual account based on the balancing segment of PO Charge account.
Example:
Expense AP Accrual account defined under Purchasing options for the operating unit
is XX-000-ZZZZ-0000-000
Under this operating unit, there are two inventory organizations A and B.
Expense account defined for the organization A is AA-000-XXXX-0000-000
Expense account defined for the organization B is BB-000-YYYY-0000-000
When a Purchase Order is created with ship to organization as A, the charge account
that gets defaulted in the PO will be AA-000-XXXX-0000-000 where as the Expense AP
Accrual account will be
XX-000-ZZZZ-0000-000.
Current Process:
When this PO is received in organization A, the accounting will happen with a mismatch
in balancing segment as follows:
Accrual a/c XX-000-ZZZZ-0000-000 CR
Desired Accounting entries in SLA and GL:

When this PO is received in organization A, the accounting should happen as follows:
Accrual a/c AA-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c AA replaces

If the PO is received in organization B which belongs to the same operating unit, the
accounting should happen as follows:
Accrual a/c BB-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c BB replaces

Charge a/c BB-000-YYYY-0000-000 DR
Pre-requisites to get the accounts in SLA and GL:
 Account Derivation Rule (ADR)

 Journal Line Type (JLT)
 Journal Line Definition (JLD)
 Application Accounting Definition (AAD)
 Subledger Accounting Method (SLAM)
To derive the accounts, Account Derivation Rules (ADR) has to be defined and attach
this ADR to the respective Journal Line Type (JLT) under the Journal Line Definition
(JLD) for the respective event type code. But you would not be able to make any
changes to the seeded JLD,seeded AAD and seeded SLAM and hence the user defined
ADR cannot be attached directly to the seeded JLD. Therefore it is mandatory to define
an user defined JLD,AAD and SLAM so that the user defined ADR can be used to derive
the accounts and to get those derived accounts in SLA and GL.
Steps to get the accounts in SLA and GL:
Let us consider two scenarios in a Procure to Pay cycle and see how the accounts can
be derived using Account Derivation Rules (ADR) and how those derived accounts hit
the Subledger (SLA) and General Ledger (GL) to meet this business requirement.
a) PO set to accrue at receipt
b) PO set to accrue at period end
1. Defining the Account Derivation Rule:

Accounting Methods Builder > Journal Entry Setups > Account Derivation Rules
 Click the New button

 Define the Rule code and Rule name
 Choose the output type as 'segment' and select the value 'Balancing segment' from the
LOV.
 Under Priorities, choose the source as "Distribution Charge account" from the LOV and
segment as 'Balancing segment'. You can refer to Note.802003.1 if you are not able to
get the source "Distribution Charge account" in the LOV.
 Save the form
Note: The output type should be 'segment' only if the requirement is to derive a
particular segment from the chart of accounts. If there is a requirement to derive the
entire code combination, then the output type should be 'flexfield'.
It has to be ensured that the following setups are in place before defining the ADR.
a) The value that is selected as a source in ADR form should be defined as a source for
any of the applications such as Cost Management or Purchasing and the Key flexfield
check box should be enabled for that source with the flexfield application as General
Ledger.
Accounting Methods Builder > Sources
If the source does not have the Key flexfield check box enabled, it won't appear in the
LOV of ADR form. But this Key flexfield checkbox is not editable and hence the source
which you are choosing in the LOV of ADR form should have the key flexfield enabled
as seeded setup.
Note: The examples which have been discussed in this whitepaper requires the
Distribution Charge account as the source to be used in ADR. Also this source will be
required whenever the accounts are derived based on any code combinations used in
the Purchase Orders. But this source will have the key flexfield enabled only after
getting a particular file version of the file poxlaem.ldt. Please refer to Note.802003.1 for
more details on this.
b) The source value defined in the ADR should be assigned to the respective event class
such as "period end accrual" or "receipt into receiving inspection" in Source
Assignments form with extract object level as Header.
Accounting Methods Builder > Sources > Source Assignments
c) The source value defined in the ADR should be available in the view defined under
Transaction Objects or Reference Objects for the respective event class.
To identify this view, navigate to Cost Management SLA responsibility > SLA >
Accounting Setup > Accounting Methods Builder > Events > Accounting Event Class
Options and query for the respective event class and verify the view under Objects tab.
For the scenario what we have considered, PO_DISTS_REF_V is the view defined under
Reference Objects for the event class "period end accrual" and "receipt into receiving
inspection" and the source "Distribution Charge account" is available in this view.
If the source choosen in the ADR form is not available under the corresponding view,
ADR will get created but the program "validate AAD" will error out and ADR cannot be
successfully used to derive the account.
2. Defining the Journal Line Definition:

Accounting Methods Builder > Methods and Definitions > Journal Lines Definitions
 Query the event class "Period end accrual" and seeded definition code
"PERIOD_END_ACCRUAL" and click on Find button
Default Account".
Note: If the ADR is defined for the entire flexfield, then the default rule itself should be
replaced by the user defined ADR.
 Query the event class "Receipt into Receiving Inspection" and seeded definition
code "RCPT_REC_INSP"
Default Account"
3. Defining the Application Accounting Definition:
Accounting Methods Builder > Methods and Definitions > Application Accounting
Definitions
 Query the seeded AAD code "COST_MANAGEMENT" or

"COST_MANAGEMENT_ENCUMBRANCE"
 Click on Copy button and create a new AAD which gets copied from the seeded
AAD
 For this user defined AAD, attach the user defined JLD for the event class 'Period
end accrual' after deleting the seeded JLD "Period End Accrual"
 For this user defined AAD, attach the user defined JLD for the event class
'Receipt into Receiving Inspection' after deleting the seeded JLD "Receipt into
Receiving Inspection"
4. Defining the Subledger Accounting Method:

Accounting Methods Builder > Methods and Definitions > Subledger Accounting
Methods
 Query the seeded SLAM "STANDARD ACCRUAL" or "ENCUMBRANCE ACCRUAL"
 Click on Copy button and create a new SLAM which gets copied from the seeded
SLAM
 Attach the user defined AAD under the user defined SLAM for the application
Cost Management
 Save the user defined Subledger Accounting Method
5. Setting up the SLAM in Accounting Setup Manager:
Navigation: General Ledger Responsibility > Setup > Financials > Accounting Setup
Manager > Accounting setups
Query the ledger and click on "Update Accounting options"
Click on Update icon for the description "Define and update the journal processing
options for your ledger"
Under Subledger Accounting, set the user defined SLAM as the subledger accounting
method
Save the Accounting setup Manager page
6. Getting the derived account in SLA and GL for a PO receipt:
 Create an Expense PO set to accrue at period end with charge account having
the balancing segment as "02" and accrual account defaulted from Purchasing
options having the balancing segment as "01".
 Receive the PO and do not match invoice to the PO or receipt
 Run the Receipt Accruals-period end program and let the create accounting
process gets completed
Following accounting entries are shown in SLA:
Recoverable tax
Recoverable tax
segment as "01"
If the ADR is not defined for this Journal line type "Accrual", then the accounting entries
for the same scenario would be as follows:
Recoverable tax
Recoverable tax
 Create a PO set to accrue at receipt with charge account having the balancing
segment as "02" and accrual account defaulted from Purchasing options or
inventory organization parameters depending on the destination type having the
balancing segment as "01"
 Ensure that the Receiving Inspection account in Receiving options has the
balancing segment "02" which is same as the balancing segment of PO Charge
account. If it is different, then ensure that the Automatic offset method is set to
"Balancing" in Purchasing > Setup > Organizations > Purchasing options. This
has to be ensured because this would create an intercompany journal as the
balancing segments differ for the accounts in a particular journal which is the
intended design. So to avoid this intercompany journals, this set up needs to be
verified.
 Receive and deliver the PO
Following accounting entries will be shown in SLA:
RECEIVE:
Receiving Inspection a/c - 02-000-1222-0000-000 CR @ (Received qty * PO Unit Price)
+ Non-Recoverable tax
Recoverable tax
DELIVER:
Recoverable tax
Receiving Inspection a/c - 02-000-1222-0000-000 CR @ (Received qty * PO Unit Price)
+ Non-Recoverable tax
segment as "01". Similarly you can see the balancing segment of Receiving Inspection
a/c "02" which got populated based on the balancing segment of PO Charge account
which has happened due to the Automatic Offset method set to Balancing. If this option
is not set to "Balancing" and the balancing segment of Receiving Inspection a/c is not
the same as PO Charge a/c, then there would be a mismatch between the balancing
segments of journal belonging to the DELIVER transaction. At the same time, if the
option is set to "Balancing" and ADR is not defined for the Journal line type "Accrual",
then there would be a mismatch between the balancing segments of journal belonging
to the RECEIVE transaction. Hence when the ADR is defined to meet this kind of
business requirement, then the Automatic Offset method should also be set to
Balancing to avoid intercompany journals if the Receiving Inspection a/c has a different
balancing segment from that of the PO Charge a/c.
Note: When the ADR is defined to derive the accrual account for transactions related to
POs set to accrue at receipt, then it has to be ensured that this derived code
combination is defined in "Select Accrual Accounts" form so that accrual reconciliation
can be done for this account using AP PO Reconciliation reports.
SUMMARY
The requirement as mentioned in the business case is achieved by configuring the SLA
accordingly which resulted in generation of accounting entries for PO Receipt
transactions without creating any intercompany journals as required.
Apart for this configuration which has been done to meet the above mentioned
business case, there are some more advanced features in Account Derivation Rules
using mapping sets or giving SQL conditions for picking up the accounts which is not
included as a part of this case study.
R12: How To Map Accounts For Manual Journals To The Secondary Ledger (Doc ID
746556.1)
GOAL
How to Map Accounts for Manual Journals to the Secondary Ledger
SOLUTION
1. Does the Subledger Accounting Method have anything to do with journals that originate in
General Ledger (manual journals) and are duplicated for the secondary ledger?
No, General Ledger does not use the setups done in SLA for creation of manual journal
entries in the secondary ledger.
The Posting program will create the journal in the secondary ledger as a copy of what is
stored in the GL tables for the primary ledger.
In General Ledger there is a concept of Chart of Accounts Mapping used especially

when the primary and secondary ledgers use different charts of accounts. It is also
used by the
Consolidation program in GL. The chart of account mappings are not attached to a
journal category; they apply to all journals.
2. How to add a Chart of Accounts Mapping (COA) to an existing Secondary Ledger? The Primary
to Secondary Ledger Mapping page in Accounting Setup Manager does not show this option.
To assign the chart of accounts mapping, use the Primary to Secondary Ledger Mapping
page in Accounting Setup Manager. The Chart of Accounts Mapping appears in
the Primary
to Secondary Ledger Mapping page in the Accounting Setup Manager only when the
accounting setup has not yet been complete.
Assigning a chart of accounts mapping is not required when the chart of accounts used
by the primary and secondary ledgers are the same. However it can be assigned for
Journal and Balance level secondary ledgers even if the Chart of Accounts are same as
this allows you more flexibility to use different rollup rules when transferring journals or
balances from the primary ledger to the secondary ledger. For example, you can
maintain more detailed information in your primary ledger but maintain more
summarized information in your secondary ledger, depending on the rollup rules you
define for your chart of accounts mapping.
-- From the Oracle General Ledger Implementation guide, Release 12:

Page 1-92
Note: To assign the chart of accounts mapping, use the Primary to Secondary Ledger
Mapping page in Accounting Setup Manager.
Other pages:
For secondary ledgers that use a different chart of accounts from their associated
primary ledgers, the chart of accounts mapping enables you to transfer journals and
balances from the primary ledger to the secondary ledger.
If your primary and secondary ledgers use the same chart of accounts, you can
optionally assign a chart of accounts mapping to the Journal level and Balance level
secondary ledgers.
3. Why is it not possible to assign a COA mapping for a Subledger level secondary ledger that
uses the same chart of accounts than the primary ledger?
The issue is with SLA. SLA will NOT recognize a chart of accounts mapping for
propagating Subledger if the primary and secondary ledger share the same chart of
accounts.
That's why the Chart of Accounts Mapping field is hidden for Subledger level Secondary
Ledgers that use the same COA as the Primary Ledger.
R12: Accounting Setup Manager Concepts (Doc ID 462088.1)
ABSTRACT
The purpose of this document is to familiarize the users of Oracle E-Business Suite with
the new setup tool in Release 12 for the definition of ledgers and accounting setups
called Accounting Setup Manager (ASM) as well as with some implementation
considerations regarding the assignment of legal entities to ledgers.
It will also describe the underlying tables for the Accounting Setup Manager user
interface.
DETAILS
Introduction
Oracle Accounting Setup Manager (ASM) is the new configuration tool for accounting
setups in Oracle General Ledger in the Release 12 of Oracle E-Business suite.
This paper provides information to help familiarize the users of Oracle E-Business Suite
with the new setup tool for the definition of ledgers and accounting setups
as well as with some implementation considerations regarding the assignment of legal
entities to ledgers and the use of subledger accounting methods. It will also describe
the underlying tables for the Accounting Setup Manager user interface.
1. What is the Accounting Setup Manager?
It is one of the main features of the Ledger Architecture introduced in Release 12,
which replaces the Set of Books form using a web-based interface.
Accounting Setup Manager or ASM is the central place where all the accounting setup is
defined and maintained for:
 Legal Entities
 Ledgers
 Reporting Currencies
 Balancing Segment Value assignment
 Sequencing (Accounting and Reporting)
 Other accounting options like retained earnings account, suspense account, currency
conversion type, etc.
2. Accounting Setup Manager Concepts
In release 12 the following concepts are introduced:
 Ledgers: sets of books are now called ledgers.

 Reporting Currencies: this is the new implementation of reporting sets of books.
 Inter and Intra Company Balancing: inter - across multiple legal entities and intra -
within a legal entity. A new product called Advanced Global Intercompany System
(AGIS) now handles intercompany transactions but the Intracompany setup and the
definition of intercompany accounts can be done via ASM.
 Accounting and Reporting Sequencing: additional ways to assign document numbers to
journal entries to satisfy legal requirements as gapless journal numbers. There are 2
types of sequencing that can be setup via ASM: Accounting sequencing and Reporting
Sequencing.
 Subledger Accounting Method: determines the accounting standards to be followed
according to industry or local country laws. The default Accounting Method is Accrual
accounting.
 Legal Entities: This is not new in Release 12 but that has had some changes. The
modeling of legal entities can be done as one legal entity per ledger or multiple legal
entities in one ledger depending on business needs. It is not mandatory to have a legal
entity. Legal entities are mandatory if Oracle Subledgers require a legal environment or
if AGIS is going to be used.
Ledgers
Ledgers are defined by 4Cs as opposed to 3 in previous releases:
 Chart of Accounts
 Calendar
 Currency
 AcCounting Method
The 4Cs must be defined prior to starting an accounting setup. ASM does not provide access to
the forms to perform that setup.
The setup for the first 3Cs is still done in General Ledger.
The setup for the Accounting Method, if one different than the default is to be used, is done via
the Accounting Methods Builder.
Please review the Oracle Subledger Accounting Implementation Guide for more information.
There are 3 types of ledgers: Primary and Secondary ledgers and reporting currency ledgers.
Primary Ledger or PL:

It is the main ledger and has the most detail of information.
It can have more than one secondary ledger assigned.
Secondary Ledger or SL:
It is optional and differs in one or more of the 4Cs from the PL.
It provides an additional accounting representation of the PL to comply with legal
requirements.
The SL can only be assigned to one PL.
Reporting Currency or RC:

Used when the only element that differs from the PL is the Currency.
It is stored in the tables as a ledger but does not need to be setup as a ledger via ASM.
Primary and secondary ledgers can have RCs assigned.
If a RC has not been assigned to a PL/SL, when Translation is run in a ledger the reporting
currency is automatically added to the ledger setup.
The secondary and reporting currency ledgers store additional accounting representations of
the information present in the primary ledger. There are different levels of detail in which this
information is stored, which are called Conversion levels.
Conversion Levels for Secondary Ledgers:
Secondary ledgers have the following four conversion levels:
 Subledger Journals level: This level maintains subledger journals, general ledger journal
entries, and balances in the additional accounting representation. SLA creates the
information directly into the SL for sources/categories that use SLA. For other
sources/categories that do not use SLA, the GL Posting program creates the information
in the SL.
 Journal level: This level maintains primary ledger journal entries and balances in an
additional accounting representation. Every time a journal is posted in the Primary
ledger, it gets created in the Secondary Ledger. Posting in the Secondary ledger
happens in a separate step. It can be determined which journal sources/categories will
be replicated when posting takes place. This is done in ASM in the Journal Conversion
Rules.
 Balances level: This level maintains primary ledger balances in another accounting
representation. It uses the Consolidation program to transfer balances from the PL to
the SL.
 Adjustment only level: This type of ledger only provides an incomplete accounting
representation holding only adjustments, which can be manual GL adjustment entries,
or automated adjustments from SLA. The chart of accounts, accounting calendar, and
currency must be the same as the primary ledger.
Note: Journals can be entered directly into any type of secondary ledger.
Conversion Levels for Reporting Currency Ledgers:

Reporting currencies have the following three conversion levels:
 Subledger level: Use SLA and the GL Posting programs. This level is equivalent to full
MRC. A subledger level RC can only be assigned to primary ledgers.
 Journal level: The GL journals only are replicated via the Posting program. The journal
created for the RC is created within the same batch of the primary ledger journal batch
and is automatically posted. This level is the equivalent of thin MRC.
 Balances level: Use the GL Translation program to maintain balances in the reporting
currency.
Note: Journals can be entered directly into the subledger and journal level reporting currencies.
Following is a graphical representation of the conversion levels discussed above for

secondary and reporting currency ledgers:
3. ASM Implementation Considerations
Legal Entities
Legal entities are used to provide a legal environment for Oracle financial subledgers or
transactions that require a legal entity context.
The general rule is to have a primary ledger per legal entity.
If legal entities differ in any of the 4Cs or require different ledger processing options like:
average daily balances, journal approval, or sequencing a different primary ledger is required.
Legal requirements will also drive the decision of how many legal entities per primary ledger
should be assigned.
Assigning balancing segment values to legal entities is strongly recommended to make easier
the identification of transactions and for reporting purposes. Assignment of balancing segment
values to legal entities is required for Intercompany accounting.
Subledger Accounting Methods
The subledger accounting method is required if using Oracle Subledger Accounting.

A subledger level secondary ledger requires a subledger accounting method for both the
primary ledger and the secondary ledgers.
The accounting method can be changed at any time. It will only affect new journals.
Additional accounting methods may be defined. This is done in Subledger Accounting.
There is optional information needed when an accounting method is selected in ASM, for
instance: Entered Currency Balancing Account, Balance Subledger Entries by Ledger Currency.
The screen shot belows shows the fields under the Subledger Accounting section.
Setup Steps
The accounting setup manager allows creating an accounting setup including the tasks
below. The items in bold are required:
1. Create/assign a legal entity if required.

2. Assign a ledger name, a chart of accounts, accounting calendar-period
type, currency and accounting method.
3. Complete ledger options: retained earnings account, first ever open period,
subledger accounting options, suspense account, rounding difference
account, enable intracompany, journal approval, journal tax, rate type,
cumulative translation adjustment account, enable journal reconciliation,
budgetary control.
4. Define and assign operating units to the primary ledger.
5. Complete reporting currencies.
6. Define intercompany accounts.
7. Define intracompany balancing rules.
8. Define sequencing options.
9. Specify the ledger attributes for one or more secondary ledgers.
10. Assign balancing segment values to legal entities.
11. Assign balancing segment values to ledgers.
12. Complete accounting setup.
The navigation steps to access the ASM in General Ledger are:

- Setup : Financials : Accounting Setup Manager: Accounting Setups
Completing an Accounting Setup
An accounting setup needs to be complete before it can be used.

When clicking on the [Ã‚ Â˜ Complete]Ã‚ Â™ button in ASM, a message appears to
confirm whether the setup should be saved. If the response is 'Ã‚ Â˜ YesÃ‚ Â™ , the
General Ledger Accounting Setup Program is launched automatically. This is a new
program in Release 12, which is a flattening program introduced to pre-calculate data
that can be used to speed up queries and data processing.
The General Ledger Accounting Setup program performs the necessary validations to
make the setup components of an accounting setup ready for transaction processing
and journal entry.
The following message appears in ASM when the program in launched:
Confirmation
JavaScript enabled browser required. You have just completed the accounting setup:
<primary ledger name example: CN1 PL (Corp) (USD)>. The General Ledger
Accounting Setup Program has been submitted. Please review concurrent request id,
<request id>. Make sure this request completes successfully before you enter
transactions.
Upon completion, some components cannot be deleted: legal entities, balancing

segment values, and reporting currencies.
This program creates the following Data Access Sets:
a. One for the Primary Ledger and the Reporting Currencies.
b. One for the Reporting Currencies
c. One for each Secondary ledger
d. One for a ledger set
The General Ledger Accounting Setup program is also launched upon:

- The creation of a ledger set
- The creation of a data access set
Profile Options
Once the setup program has completed successfully it is necessary to define the
following profile options:
"GL: Data Access Set"Ã‚ Â™ replaces the "Ã‚ Â˜ GL: Set of Books"Ã‚ Â™ name
profile option of previous releases.
This profile option can be assigned to a single ledger or a ledger set. This profile option
is used by GL responsibilities.
The Oracle subledgers use the profile option "GL Ledger Name"Ã‚ Â™ to determine the
ledger a subledger responsibility will have access to.
The "SLA: Enable Data Access Security in Subledgers" profile option determines
whether the General Ledger Data Access Set security mechanism is applied for a
subledger application responsibility when viewing, reporting, or creating subledger
journal entries associated with a given ledger.
4. Technical Overview
There are several new tables with ASM. Following is a description of the tables and
what they store.
ASM Main Underlying Tables:
 GL_LEDGERS: Replaces GL_SETS_OF_BOOKS. The field set_of_books_id is now called

ledger_id. A backward compatible view called Gl_Set_Of_Books was created.
 GL_LEDGERS_CONFIGURATIONS: stores every accounting setup.
 GL_LEDGER_CONFIG_DETAILS: Keeps track of various configuration steps and statuses.
 GL_LEDGER_RELATIONSHIPS: stores all ledger relationships such as PL to RC and PL to
SL.
 GL_JE_INCLUSION_RULES: stores Source-category conversion rules.
 GL_LE_VALUE_SETS and GL_LEGAL_ENTITIES_BSVS: store Balancing segment value
(BSV) assignments to legal entities.
 GL_LEDGER_NORM_SEG_VALS: stores BSV assignments to ledgers. Every BSV or
balancing segment value assigned to the legal entity is also assigned to the ledger. If no
values are assigned to the legal entity, then all values are valid for the legal entity.
Each event could result in multiple tables getting updated. E.g. If you add a new ledger
to a ledger set, then in addition to the ledger set tables, the data access set tables that
store data to access the ledger set would also get updated.
Following is a graphical representation of the tables used in ASM:
Other tables:
 GL_ACCESS_SET_ASSIGNMENTS and GL_ACCESS_SET_LEDGERS store flattened

information to improve security checks on data access sets that contain
privileges for ledger sets or parent segment values.
 GL_LEDGER_SET_ASSIGNMENTS stores flattened information to speed up
queries on ledger sets that contain other ledger sets.
 GL_LEDGER_SEGMENT_VALUES stores information on balancing segment value
assignments to ledgers. If a parent segment value is assigned, it will be
expanded and stored as detail segment values.
 GL_SEG_VAL_HIERARCHIES stores parent and child segment value mappings
based on the segment value hierarchy. Programs like MassAllocation and FSG
use this data.
Conclusion
This document covered the main concepts of Accounting Setup Manager, some
implementation considerations and the underlying tables for this accounting setup
interface.
SUMMARY
The Accounting Setup Manager (ASM) is one of the main features of the Ledger
Architecture introduced in Release 12, which replaces the Set of Books form using a
web-based interface.
This document covers the main concepts of the Accounting Setup Manager, some
implementation
considerations and a high level technical overview of this new feature.
General Ledger FAQ for Accounting Setup Manager (ASM) (Doc ID 778826.1)
PURPOSE
This FAQ provides the answers to the most frequently asked questions regarding
Accounting Setup Manager in Oracle General Ledger.
QUESTIONS AND ANSWERS
1. What is the best source of information regarding Definition Access Sets?
See the Release 12 General Ledger Implementation Guide, beginning on page 1-

137: Definition Access Sets.
2. How to properly assign/remove Definition Access Sets in Oracle General Ledger?
Follow Document 415901.1 for steps on how to remove the Definition Acess Sets,
but please note that DAS definitions cannot be deleted. These will remain in the
Definition Access Sets -> Define form but will not have the definition name
assigned to it (if all definitions were removed - in this example we only created one
- then deleted it).
3. R12 Accounting Flexfield and GL Ledger Flexfield are not matching, is this a problem?
As documented in the General Ledger User Guide and Implementation Guide, the
new GL Ledger Flexfield is automatically created and maintained. Users should
ignore this Flexfield and never change it. Development has confirmed that the value
for the dynamic insertion will not cause a problem. So if you notice any
inconsistencies between Accounting Flexfield and GL Ledger Flexfield can be
completely ignored.
See Document 418154.1 for more information.
4. How can I setup a Legal Entity country, if the country is not available in LOV?
Navigate into Legal Entity manager responsibility ->Setup -> Jurisdictions -> create
identifying jurisdiction by setting identifying to Yes and territory to the country
required, enter any name. Then enter registration codes. If the jurisdiction is
already set to yes, then go to System Administrator Responsibility> go to Profile
options> select the application name as General Ledger> then select the user by
your user> in the profile choose <Default Country> , change the default country to
the country required.
See Document 438089.1, Document 444633.1 for more information.
5. How do I remove Balancing Segment Value assignments from a Ledger?
Initially it was not possible to remove a BSV assigned to a Ledger once the setup
has been complete, but it was delivered via recommended Patch
7529614:R12.GL.A.
However, this functionality does not apply to a Legal Entity. There is no possible
way to remove a BSV assigned to a Legal Entity once the setup is complete.
6. Can I change the Ledger Currency after setup is complete?
No, it is not possible to change the ledger currency after the accounting setups
have been completed. Same as in R11, in R12 the chart of accounts, calendar and
currency cannot be changed after the setup has been completed and any attempt
to perform such a change in the tables will not be supported and is highly un-
recommended.
7. Can I enable Average Balances for a ledger after the ledger setup is complete?
No, it is not possible to enable average daily balances for a ledger once the ledger
has been saved. Once the ledger setup is complete, the option to enable average
daily balances is not available as part of the accounting setup manager. There will
not be any datafix to enable the average balances option after ledger setup is
complete as confirmed in the Bug 24415260
8. Is it possible to change the Subledger Accounting Method (SLAM) assigned to Ledger?
The accounting method should not be changed without advice from the subledger
support team. Changing it can cause severe corruption, if, for example, you go
from standard accrual to MFAR or the other way around. Please log a service
request with the relevant subledger team to get further advice on whether the
change is possible.
9. Can I delete, disable or end-date Primary Ledgers?
Document 782244.1 says that it is not possible to delete or end date the primary
ledger whenever created and completed.
Yet, you can workaround this through the responsibilities - create a new Data
Access Set, to prevent access to the ledgers that you wanted to delete and only
allow access to the Primary Ledger required and attached this Data Access Set to
the users responsibilities.
10. Can a Secondary Ledger be associated with more than one Primary Ledger?
No, a secondary ledger can only be associated with a single primary ledger.
11. How do I disable a Reporting Ledger?
Disable the Reporting currency from Accounting Setup Manager. In Accounting

Setup Manager disable the conversions to the reporting ledger.
Create a new ledger set and a new data access set that contains only the Primary
ledger
Update the GL: Data Access Set profile option at the responsibility level with this
new data access set.
12. How do I disable a Secondary Ledger already created?
Query for your Primary Ledger from the ASM and click on the "Disable" icon next to
the secondary ledger you in the Secondary Ledger table.
13. How do I set up the Responsibilities and Data Access Sets needed for a Primary Ledger and
Secondary Ledger, when the ledgers have different charts of accounts? Can a Ledger Set be used
in this case?
All ledgers in a Ledger Set must share the same chart of accounts and accounting
calendar/period type combination. So a Ledger Set cannot be used in this case,
where the charts of accounts are different. Instead, separate responsibilities must
be used for access to each ledger. See Document 460654.1 for more information.
14. Can I change Primary Ledger to Secondary and Secondary to Primary?
No, changing ledger types is not permitted for the time being. The only way is to
create new ledger after R12 implementation and use consolidation to put the
'history'.
See Document 603624.1 for more information
15. How to generate Reporting Sequence?
The ledger is setup to have Sequencing Context defined for GL Period Close - GL
Journal Entry or GL Period Close - Subledger Journal Entry.
16. Is it possible to modify "Retain Transaction Rate Type" setup for the Reporting ledger?
Once a choice is made for the flag as Yes/No and the changes are applied, this
cannot be modified.
The solution will be to define a new Reporting ledger and disable the existing
reporting ledger with wrong setup. In case transactions are also entered, you will
need to consolidate the data from the exiting Reporting ledger to the new reporting
ledger.
17. Can you re-enable a Reporting Currency Ledger after disabling it ?
No this is not possible.

18. Is it possible to re-enable a disabled Secondary Ledger ?
No this is not possible.

19. Is Assigning Balancing Segment Values to Legal Entity Mandatory?
Per the Financials Implementation Guide, the Balancing Segment Value assignments to
the Legal Entities must be done before the Balancing Segment Value assignments to
the Ledger. Availability of the balancing segment values under different type of
assignments would be as follows.
a) If the balancing segment values are neither assigned to ledger nor assigned to legal
entity then all the valid segment values defined for the balancing segment would be available
for use
in general ledger and subledger
b)If the balancing segment values are assigned to legal entity and no balancing segment
values are assigned to ledger, then only balancing segment values assigned to legal entity
would be
available for use in general ledger and subledger
c)If balancing segment values are assigned to both legal entity and ledger , then balancing
segment values assigned to legal entity only would be available for subledger. Balancing
segment values assigned
to legal entity and balancing segment values assigned to ledger would be available in
general ledger.
General Ledger FAQ for Balances Translation (Doc ID 1499690.1)
PURPOSE
This FAQ document is aimed at providing troubleshooting guidelines for Balances

Translation related functionality.
This is a consolidation of various issues faced in this area, and thus provides the tips to
resolve them.
When investigating problems in these areas the solution is often in the relevant White
Papers which also provide a useful insight into the Topic. Please refer to the following
White Papers:
 Document 139717.1 Translating from One Functional Currency To Another
QUESTIONS AND ANSWERS
1. How to define Period Rates in R12 to use in Translation?
Period Rates are obsolete in R12. They are replaced by daily rates.
You assign the rate types you want to use for period-end and period-average
translation rates in Accounting Setup Manager under Currency Processing options.
Then you need to populate the daily rates for that rate type to use for translation in
each period. The daily rate that is defined for the last day of the period is used as
the translation rate. If the rate for the last day of the period does not exist,
translation searches back within the period until a rate is found. If no rate exists for
the period, translation ends in an error.

2. What is and How to verify the Cumulative Translation Adjustment (CTA) Account?
When you run Translation, a set of balances is created for the translated currency
as result of the conversion of the functional balances. The used rates depend on
the account types, so the total of the translated balances could be unbalanced -
that is what the CTA is used for: account for the differences to keep the translated
balances balanced for this currency.
Mathematically, this is how a user can verify what is in the Translation Adjustment
account, for a given period:
1. Take the total of your P&L (Revenue and Expense) accounts and multiply
this amount by the period average rate defined.
2. Take the total of assets and liabilities and multiply this amount by the
period end rate.
3. Take the total of your retained earnings and use the historical amount or
Multiply by historical rate (whichever way you have defined it).
4. Add 1,2 and 3 together. This should equal the amount in your translation
adjustment account, with the opposite sign.
5. Make sure no other entries have been made to the account. If there are
they would have to be backed out in order to reconcile the amount
3. Why the large Rate Adjustment amount in the first period ever translated when using Historical
Amounts?
In some situations, you may want to use Historical Amounts to translate certain
accounts. However, when Historical Amounts are used in the very first period ever
translated, this creates a large Rate Adjustment for the same amount which distorts
the Cumulative Translation Adjustment account.
The translation code cannot distinguish between how much of the Historical
Amount defined is attributable to the Beginning Balance and how much is
attributable to rate fluctuation in the period, so the entire amount is thrown into
the Rate Adjustment bucket.
For example, in the first period ever translated where there is no period activity for
the account, when you use Historical Amounts, you may see:
Beginning Translated Balance = zero.

Rate Adjustment = the Historical Amount defined.
Ending Translated Balance = the Historical Amount defined.
By definition, when translating on YTD basis, the Historical Amount defined is equal
to the YTD Translated Balance.
You would like to know how to correct the situation so that you do not have a large
Rate Adjustment in the first period translated.
The workaround is to "back into" an Historical Rate, based on the Historical Amount
that you want to achieve for the period.
You should use this Historical Rate in the first period ever translated, then in the
subsequent months use the appropriate Historical Amount.
This eliminates the large Rate Adjustment in the first period ever translated.
4. How is translated a manually entered beginning balance to Retained Earnings?
You manually entered a beginning balance to the Retained Earnings. How this is
translated will depend on how you have the profile option 'GL: Owner's Equity
Translation Rule' set.
Set to YTD:
- First period Translation, the translated amount for the retained earning will
equal 0.
- Subsequent Translations will have a translated amount for the retained
account
Set to PTD:
- You will have a Translated amount for the retained earnings in the first
period.
5. Does the Translation of Owner's Equity Accounts comply with FASB 52?
The profile option 'GL: Owner's Equity Translation Rule' should be set PTD to
comply with FASB 52.
Calculation when set to PTD:
Ending Translated balance =

Beginning Translated Balance +
(Current month activity in Functional Currency x Current Month Historical Rate)
Calculation when set to YTD:

Translated Currency YTD = Functional Currency YTD * Rate
YTD translation of Owner's Equity Accounts calculation does not take into
account the historical rates that were in effect at the time of each transaction
in the account.
6. How do I change Translation Historical to Period Rates?
You will need to do the following:
1.
1. Delete the historical rate from the Historical Rate Form. (Note if you have a
'Prior' Historical Rate - this will have to be deleted also. You may have a prior
historical rate if you deleted the historical rate and reran translation without
purging the original translations using the original historical rate).
2. Before r12 you will need to have defined a period-end rate in the Period Rates
form. After R12 you define the daily rates assigned to the ledger in Accounting
Setup Manager under Currency Processing options.
3. Purge translated balances to get rid of the original historical rate.
7. If I change a period or historical rate for a prior period, do I have to go back and re-run
translation for the prior period?
NO. Translation of the current period will automatically retranslate all prior periods
where the translation is not current, limited by the parameters specified for
translation run.
8. Are new Operating Units translated by using the 'All' functionality?
Specifying ALL as the balancing segment, the translation program will only go back
as far as the earliest ever translated period that is common to all balancing
segments.
Therefore, balancing segments with a different first ever period translated, need to
be re-translate separately in order to be able to go back to the first ever period for
each one.
9. Can I upload period rates automatically?
For releases prior to R12 the period rates must be entered through the period rates
form. See Document 158613.1 for more information.
Since 11i some rates can be uploaded automatically by importing from

GL_DAILY_RATES_INTERFACE, but not applicable to period rates.
In 11i Family Pack E (Patch:2842697) or with standalone Patch:3602600 and in R12

the Currency Rates Manager presents a new interface to easily manage the daily
and historical rates.
Since R12, the period rates are no longer used, and were replaced by daily rates
with the rate Type defined in Accounting Setup Manager - translation rate type,
therefore you can now quickly upload and download translation rates via
spreadsheets, or you can enter and maintain rates using the new web-based user
interface.
See Document 433564.1 and Document 279283.1 for more information.
It is recommended you use the Microsoft Internet Explorer web browser to utilize
the full functionality of the Currency Rates Manager.
10. Can I delete a period end rate?
No it is not possible to delete a period end rate. This was prevented in internal Bug
267398.
11. What is the Rate Adjustment Column in the Translation Trial Balance?
The Rate Adjustment is a column found in the Translation Trial Balance (Short
Name GLXXTB.rdf).
The Translation Trial Balance shows the Opening Balance, Period Debits & Credits
and Ending Balance apart from the Rate Adjustment in Foreign Currency.
Rate Adjustment is calculated to show the effect of the change in Period Rates.
The Period Rates - Average Rate/End Rate - for the current period may be different
from the Previous Period.
The Rate Adjustment Column tries to capture the effect of the same - it is the
adjustment resulting from period rate differences between the reporting period and
the previous period.
The Rate Adjustment is relevant mainly to the Balance Sheet Accounts as the
Translation happens on the YTD Basis.
12. How can I update the Cumulative Translation Adjustment (CTA) account in Accounting Setup
Manager (R12)?
This is the expected functionality: if Translation has already been run, the CTA
account is protected against update.
After Purging the Translated Balances the CTA account can be updated to a
different one, and the balances need to be re-translated to impact the new CTA
account.
Revaluation -- Revaluation adjusts asset or liability accounts that may be materially understated or
overstated at the end of a period due to a significant fluctuation in the exchange rate between the
time the transaction was entered and the end of the period.
Translation -- Translation restates an entire ledger or balances for a company from the functional currency to a
foreign currency.
Ideally, one should run revaluation program first and then translation program. This will make sure that reval JE is
also translated to required currency.
Revaluation does need to be run before translation. The reason is as follows:
Revaluation = creates journals to restate Ledger's functional (accounted) currency balances relating to
foreign currency transactions. Revaluation of functional currency is based on ongoing FX rate changes
between functional currency and originating foreign currency.
Translation = translates Ledger's functional (accounted) currency balances into a foreign currency - purely
for the purposes of reporting / consolidation etc. in that foreign currency.
So if you do no revalue functional currency balances before you translate them - then your translated balances
will be incorrect (strictly from a FX exposure perspective).

R12 GL Study

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

R12 GL Study

Caricato da

Copyright:

Formati disponibili

R12: How Does Primary to Secondary Ledger COA Mapping Work In Create Accounting

Process? (Doc ID 1308391.1)

Oracle Subledger Accounting - Version 12.0.0 and later

(CCID = code_combination_id ADR = Account Derivation Rules SLAM = Subledger

Then apply the ADR of the secondary ledger SLAM.

Desired Accounting entries in SLA and GL:

Accrual a/c AA-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c AA replaces

Accrual a/c BB-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c BB replaces

Pre-requisites to get the accounts in SLA and GL:

 Account Derivation Rule (ADR)

Steps to get the accounts in SLA and GL:

1. Defining the Account Derivation Rule:

 Click the New button

2. Defining the Journal Line Definition:

 Save this user defined Journal line definition

b) If the PO is set to accrue at receipt

 Query the seeded AAD code "COST_MANAGEMENT" or

a) If the PO is set to accrue at period end

4. Defining the Subledger Accounting Method:

a) If the PO is set to accrue at period end

b) If the PO is set to accrue at receipt

Following accounting entries will be shown in SLA:

Oracle Purchasing - Version 12.0 to 12.1.3 [Release 12 to 12.1]

Desired Accounting entries in SLA and GL:

Accrual a/c AA-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c AA replaces

Accrual a/c BB-000-ZZZZ-0000-000 CR - Balancing segment of charge a/c BB replaces

Pre-requisites to get the accounts in SLA and GL:

 Account Derivation Rule (ADR)

Steps to get the accounts in SLA and GL:

1. Defining the Account Derivation Rule:

 Click the New button

2. Defining the Journal Line Definition:

 Save this user defined Journal line definition

b) If the PO is set to accrue at receipt

 Query the seeded AAD code "COST_MANAGEMENT" or

a) If the PO is set to accrue at period end

4. Defining the Subledger Accounting Method:

a) If the PO is set to accrue at period end

b) If the PO is set to accrue at receipt

How to Map Accounts for Manual Journals to the Secondary Ledger

In General Ledger there is a concept of Chart of Accounts Mapping used especially

-- From the Oracle General Ledger Implementation guide, Release 12:

R12: Accounting Setup Manager Concepts (Doc ID 462088.1)

1. What is the Accounting Setup Manager?

In release 12 the following concepts are introduced:

 Ledgers: sets of books are now called ledgers.

Ledgers are defined by 4Cs as opposed to 3 in previous releases:

Primary Ledger or PL:

Reporting Currency or RC:

Conversion Levels for Secondary Ledgers:

Secondary ledgers have the following four conversion levels:

Conversion Levels for Reporting Currency Ledgers:

Following is a graphical representation of the conversion levels discussed above for

The subledger accounting method is required if using Oracle Subledger Accounting.

1. Create/assign a legal entity if required.

The navigation steps to access the ASM in General Ledger are:

Completing an Accounting Setup

An accounting setup needs to be complete before it can be used.

Upon completion, some components cannot be deleted: legal entities, balancing

The General Ledger Accounting Setup program is also launched upon:

ASM Main Underlying Tables:

 GL_LEDGERS: Replaces GL_SETS_OF_BOOKS. The field set_of_books_id is now called

 GL_ACCESS_SET_ASSIGNMENTS and GL_ACCESS_SET_LEDGERS store flattened