Академический Документы
Профессиональный Документы
Культура Документы
Expenditures
Revenue
Budgets
Each event entity is tied to one or more event classes, which are business event categories (e.g., Labor Cost,
Usage Cost,..). An event class is tied to an event type (e.g., The Labor Cost Event Class ties to the Labor
Cost Distribution event class). The event type is the lowest level for storing the corresponding accounting
rules. To minimize the scope of SLA while achieving the authors objectives, the presentation will focus
on the expenditures event entity. The material referenced at the end of the document can be utilized to
obtain additional information on the other event entities or for additional information on the expenditures
event entity not covered in this material.
COLLABORATE09
Page 1
Lookup Sets
Intermediate Value
AA Rules
Parameter
AA Function Transactions
AA Functions
AA Rule Assignment
Table 1
Separate AG
Function Assignment
Mapping Sets
Input Value
Account Derivation Rules
Source
Conditions on Account
Derivation Rules
Journal Line Types
Journal Line Definitions
Processes - The processes required to create the applicable CCIDs via SLA has changed slightly from
previous releases of Oracle Projects. The following table provides a list of processes that are required to
create CCIDs for cost transactions along with notes and the comparable process, if applicable, from
previous releases.
SLA r12 Cost Processes
Process
CCID Notes
PRC: Distribute XX
(XX can be labor,
miscellaneous
transaction,..)
PRC: Create
Accounting
Exist in
previous
release
Yes
No
No
No
Table 2
The SLA r12 Cost Processes table is helpful in comparing AA functionality to SLA functionality as forms
previously called AG and therefore processes were not required to create the CCID for payables/purchasing
transactions.
Other Differences The following list is intended to highlight other significant differences between
AA/AG and SLA functionality.
COLLABORATE09
Page 2
SLA allows effective dates within its Mapping Sets (e.g., An expenditure type could map to
account 1234 in 2008 and 5678 in 2009)
SLA allows adjustments to have their own set of accounting rules. Examples of adjustments
are transactions resulting from transfers or reversals whereas changes to a transaction at the
distribution line (recalculating cost or marking the transaction billable or nonbillable) are not
considered adjustments.
SLA does not have the concept of function transactions. AA provided function transactions
to allow for different set of accounting rules based upon transaction characteristics without
building the logic into the rule itself (e.g., The Capital, All set of transactions would allow
users to have a set of rules applicable to all capital transactions without building the
condition into the AA rule). SLA needs to build this logic into the rule (e.g., If a capital
transaction gets mapped to Account 1234 and non capital transactions get mapped to 5678
then the Account Derivation Rule would have to check to see if the transaction is capital or
not).
SLA comes with a seeded setup that cannot be modified. As mentioned previously, the
seeded setup accepts the CCIDs created by the applicable AA rule. In order to change the
configuration, the seeded setup needs to be copied then modified (i.e., The seeded setup
cannot be changed).
SLA allows the users to populate the entire CCID within one rule versus populating each
segment independently as is the case for both AG and AA.
Ledger based setups that control program defaults and the overall mapping of the collective
rules for the application to utilize.
Accounting Methods Builder configurations allow the users to build their own detailed logic
to control the population of transaction CCIDs based upon their own requirements.
Ledger setup In r12 the Implementation Options for Oracle Projects maps to a ledger (Set of Books
(SOB) is no longer used). A ledger has its own set of SLA configuration options. The ledger SLA
configuration options are grouped into two additional categories: Ledger Definition and Accounting
Options. The following is a description of the different options for both categories.
Ledger Definition Within the ledger definition, there is a section for Subledger Accounting setups. The
following screen shot displays all the different options but the most important option to consider for setting
up SLA is the Subledger Accounting Method. The value entered in this configuration option determines the
rules that will be used by all the subledgers that reference the applicable ledger. This is the hook that needs
to be set to change how the accounting will work when the applicable processes run. In the screen shot
below the Subledger Accounting Method has been changed to a User Defined Method (Test) from the
seeded setup value.
COLLABORATE09
Page 3
Accounting Options Each ledger has a set of Subledger Accounting Options for each Subledger (e.g.,
Projects has its own Subledger Accounting Options,) that cover the following items:
-
General Accounting Options set some high level application settings such as: General Ledger
summarization method; Reversal Method; Rounding Rule; Third Party Merge Accounting
Option. These configuration options are relatively straightforward and additional
configuration details can be provided in the Oracle Subledger Accounting Implementation
Guide.
Accounting Program Defaults These configuration items control the defaults that will be
used by the applicable SLA process (e.g., PRC: Create Accounting). In addition, there is a
configuration for each default that determines if the default can be overridden or not. The
program default settings are: Accounting Program Mode; Transfer to GL; Post in GL;
Accounting Report Level; Stop at Error Level. These configuration options are relatively
straightforward and if additional configuration details are needed then please reference the
Oracle Subledger Accounting Implementation Guide.
Event Class Options For each event class (e.g., Burden Cost, Labor Cost, Inventory Cost,..)
a journal category can be set that will be referenced when the Subledger entries are interfaced
into the General Ledger.
The following screen shot details the different settings referenced above:
COLLABORATE09
Page 4
Accounting Methods Builder (AMB) The AMB is the collective group of rules that can be configured to
allow the users to build the transaction CCID logic based upon their requirements. Note: This would be
done if the users determined that they did not want the project transactions to be ultimately posted to the
GL based upon the logic created in AA.
The following steps need to be followed to implement the AMB:
Step 1: Journal Line Types Sets the characteristics of the Subledger journal lines such as if the balances
are actual, budget or encumbrance.
Step 2: Journal Entry Descriptions Allows the users to configure the descriptions passed to the journal
header and lines.
Step 3: Mapping Sets Users can map transaction characteristics to segment values (or complete CCID
string). These mappings have effective dates.
Step 4: Account Derivation Rules The rules that determine how the CCID will be populated.
Step 5: Journal Line Definitions Groups the journal line types, account derivation rules and journal entry
descriptions for different event types (e.g., Labor Cost has a set of definitions).
Step 6: Application Accounting Definitions Ties all the different application event classes to journal line
definition.
Step 7: Subledger Accounting Methods The Subledger accounting ties the application accounting
definitions to each individual application.
Configuration Strategy Determining the appropriate method (i.e., Utilize the seeded SLA or utilize AA)
to implement the accounting logic for your business requires analyzing several factors including:
COLLABORATE09
Page 5
The conclusion of this document provides a recommendation on the SLA configuration strategy.
Upgrade Considerations
Data - Although the upgrade to r12 is the initial introduction to the Subledger Accounting functionality, the
r12 upgrade still needs to consider the Subledger Accounting data requirements. During the upgrade,
accounting data from the affected applications (Projects, Payables,..) will be upgraded to the SLA data
model. The default for upgrading the data is the current fiscal year or six months, whichever is greater.
However, the default can be changed to as many periods as deemed necessary. The recommendation
provided within Metalink is to upgrade the data that you need. In order to determine the data you need,
it is helpful to consider the use of the upgraded data by the applications. The data facilitates queries, drill
down functionality between products and reports. Therefore, defining the amount of data that is needed
should be a pre-upgrade task that considers: System Space, Reporting Requirements and On-line Analysis
Requirements. The upgrade to the SLA data model is a two-step process and allows the users flexibility in
timing the data migration. The two-steps are:
-
Pre-Upgrade The pre-upgrade process allows customers to increase the default number of
periods that are being upgraded (e.g., If the customer decides that they want two years of data
v. only six periods then the pre-upgrade process would be used to change the default). The
pre-upgrade process does not upgrade any data but changes the setting in the
GL_Period_Statuses table. This process cannot be run in r12.
Post-Upgrade The post-upgrade process populates the Subledger accounting tables. The
process, SLA post-upgrade process, can be run after the upgrade during business hours or
during scheduled down-time to minimize the affect on the users and other processes.
Configuration The AutoAccounting rules implemented in the previous releases will be upgraded to r12.
As is the case with a fresh install, the default seeded SLA configuration is to accept the CCIDs provided by
the applicable AA function. As is the case with a fresh install, consideration must be given to implementing
the new SLA accounting model. The conclusion of this document provides a recommendation on the SLA
configuration strategy when upgrading to r12.
Conclusion
The differences between AutoAccounting/Account Generator and Subledger Accounting are numerous but
conceptually the process is very similar (i.e., The user can populate segments of the accounting code
combination based upon transaction attributes). Therefore, it is only a matter of getting used to the new
terminology/processes versus relearning the underlying concept of populating the CCID for Oracle Project
Transactions.
The fact that r12 Oracle Projects still requires the setup of AutoAccounting and the seeded Subledger
Accounting Setup accepts the values created by AutoAccounting means that there is a decision to be made
when building your accounting logic for Oracle Project transactions (i.e., Use AA to build the accounting
logic or SLA?). It is recommended for new implementations that the accounting logic is built using SLA
and only set constant values for AA. This recommendation is based upon the following: SLA appears to be
the future accounting engine (AA/AG will no longer be used in Fusion), SLA is used by other financial
applications and therefore users are cross training for other applications when configuring SLA (i.e., The
configuration AA Rules are unique to Oracle Projects), Users will not have to learn a temporary skill set
and SLA is more robust than AutoAccounting (e.g., Users can effective date rules, populate the entire
CCID in one rule,). For upgrades it is recommended to utilize the AA rules until there is time to
reconfigure SLA with the AA logic (or new logic if applicable). This recommendation is based upon the
fact that the AA skill set is already in house (i.e., No learning curve), AA is already configured (No extra
upgrade time would be required) and this will allow the users to focus on other issues during the time
sensitive upgrade (i.e., Adding the setup of SLA would be another cutover task).
Reference Material
COLLABORATE09
Page 6
The following documents (and referenced sections where listed) provide valuable information on the use of
Subledger Accounting within Oracle Projects along with the information on upgrading Subledger Data.
-
Oracle Projects Implementation Guide Release 12 Part No. B25623-02: Appendix G (pps.
G52 G57) and Accounting for Costs (pps. 3-40 3-47)
Oracle Subledger Accounting Implementation Guide Release 12 Part No. B19384-03
Oracle Projects Fundamentals Release 12 Part No. B25617-02: Integrating with Oracle
Subledger Accounting (pps. 12-9 12-33)
Oracle Applications Upgrade Guide: Release 11i to Release 12.04 Part No. E12011-02
Metalink Document - R12: FAQ for the SLA Upgrade: SLA Pre-Upgrade, Post-Upgrade, and
Hot Patch (Doc ID 604893.1)
COLLABORATE09
Page 7