What is Subledger Accounting for Cost Management? (Doc ID 466513.1)

APPLIES TO:

Oracle Cost Management – Version 12.0.0 and later
Oracle Inventory Management – Version 12.0.0 and later
Oracle Purchasing – Version 12.0 and later
Information in this document applies to any platform.
Checked for Relevance 17-OCT-2010

 

ABSTRACT

This document describes the SLA process in the Cost Managment product area.

This is a simple overview of what the new functionality is and how it impacts on Inventory, Purchasing, Work in Process transactions and the transfer of the costs to GL.

HISTORY

Author : Laura Miller
Create Date 09-NOV-2007
Update Date 16-MAR-2012

DETAILS

Subledger Accounting Cost Management -Overview

Subledger accounting in R12 is an enhanced accounting process. The SLA process allows customers to customize the process for specific events.

***IMPORTANT NOTE***:

If there are NO rules entered into the SLA engine, the accounts defined the traditional way will be used to generate the journal entries posted to General Ledger. The only difference is that the Transfer to GL is run via the Create Accounting process. The process can be run for draft or final.

Upgrade to R12 SLA is automated and migrates the legal accounting data for the current fiscal year. The customer can migrate Cost Management SLA for historical transactions for a selected number of periods.
With SLA, account generation is now centralized as opposed to each application being responsible for its own accounting. This causes the setup steps for SLA to be the same across products, i.e., Payables, Receivables, and Cost Management.

Benefits of SLA include:
– For customers users define and manage accounting parameters in once centralized place. Users do not have to have different setups for each subledger application.
– Gives customers flexibility to address different and changing accounting requirements to meet business needs
– Allows users to define all components of the journal entry in a simple way as opposed to generating accounting through logic embedded in the accounting programs.
– Allows users to change accounting rules in response to new legal requirement changes in business practices or acquisition of new companies.
– Users can easily control and modify accounting rules. SLA tracks all changes and ensures the programs creating the journal entries are using the latest rules. This is called Compilation and is a PL/SQL package that validates and checks the rules that are being used.
– SLA rules can be date based. So journal entries can be created according to rules depending on accounting date of the transaction.

SLA Engine
SLA uses a rules-based accounting engine that posts entries into GL. The rules used
by the engine are user defined. The rules are stored in a common repository for all subledger applications.
A subledger application would be a product area, such as Inventory, Payables, Receivables, Purchasing, etc. The R12 SLA process has created a common accounting process to be used across all applications.

This allows the customer to have a single method for defining accounting behaviors. For R12, the subledger application for Inventory and Purchasing are combined into the subledger Cost Management.
The SLA process allows for the display of the inventory valuation accounts to be seen for a user defined date range. The engine also allows the accounting department maintain control over accounting and chart of accounts.

When rules are created, the rules engine will override user entered accounts that might be incorrect. This is important to control user errors that can occur within a period. The rules will automatically redirect the costs to the correct account. The rules can be created for most item attributes to allow for granularity of costs if the customer requires this level of detail.

Pre-R12 Accounting Process:
A transaction is received and accounted for in the local subledger
-or-
A transaction is costed and accounted for in the local subledger
The transaction is specifically passed to GL via the Transfer to GL process.
View Accounting Windows will then show the details for these transactions.
R12 Subledger Accounting Process:
After the Rules are established, the Cost Management SLA responsibility allows for the creation of the user-defined accounting data. The request group related to this process includes all SLA processes as well as standard accounting processes. A transaction would be received or costed.

The transaction will then be passed to GL via the Create Accounting Cost Management program. The process categories for this include:
Inventory
Manual
Receiving
Third Party Merge
Work in Process

The Create Accounting – Cost Management request creates accrual journal entries, accrual reversals, and multi-period journal entries.
To transfer the details to GL:
1- Set the parameter in the Create Accounting to Yes
2- If parameter is set to No, then the Transfer to GL process must be run manually.

View Accounting Windows will then allow the details be displayed for these transactions.
To View Accounting Events
Cost Management SLA Responsibility
SLA > Inquiry
Tools Menu Options
Then select Accounting Events, Journal Entries, or Journal Entry Lines to open.

The Transaction Number refers to various event classes including, receiving accounts, PO number for Period End Accruals, transaction id from rcv_transactions, accrual write offs, material account events transaction_id from mtl_material_transactions, WIP account events transaction_id from wip_transactions. Also you can view the Account Journal Entries and Accounting Events from the following View Transaction Windows:
View Receiving Transactions
View Material Transactions
View Resource Transactions

The Use of the Tools > Options is only available if SLA is being used for the transaction. If there is no SLA being used, the distributions button will show the transaction details.

For the Cost Management application, Oracle ships three application accounting definitions. These include:

1- Cost Management – US GAAP
2- Cost Management Encumbrance US GAAP with Encumbrance Accounting
3- Federal costing Supports Federal requirements

The Cost Management application accounting definition comes shipped with the standard accrual accounting method. When the customer creates a new ledger, they have to associate it with the subledger accounting method to be used.

All setups to use preR12 functionality are automatic. The default base setup is US GAAP. This uses the traditional account definitions. This is delivered and works out of the box.

Specific Steps for SLA:

Responsibility: Cost Management – SLA
1. Create Account Derivation Rule (ADR)
2. Copy Journal Line Definition (JLD).
3. Assign ADR to JLD’s Journal Line Type (JLT).

*Perform above steps for all JLDs.
*Following are one time setups:

4. Copy Application Accounting Definition (AAD) and set chart of accounts.
5. Assign JLDs created (in step 2) to corresponding Event Class and Event Type.
6. Validate AAD. Either through screen (‘Validate’ button) or using Concurrent program (‘Validate Application Accounting Definition’).
7. Resolve any issues determined during validation. Verify output file.
8. Copy Subledger Accounting Method (SLAM) and set chart of accounts.
9. Locate and end date (Oracle owned) AAD assigned to this SLAM.
10. Assign SLAM to Ledger.

SLA uses events for processing transactions. An event is the recording of a change of status in the transaction life cycle, i.e., invoice approved, payment received, period closed, etc. This allows for a clear separation between transactions and accounting representation. Events are the bridge between transactions and journal entries, so product teams are involved for coordinating actions based on event models.

4 Main Entities for Cost Management (preseeded):
Material Accounting Events
WIP Accounting Events
Receiving Accounting Events
Write Off Accounting Events

Profile Options for SLA:
SLA: Enable Subledger Transaction Security in GL
SLA: Enable Data Access Security in Subledger
SLA: Additional Data Access Set
SLA: Allow Reports Journal source Override
*These first 4 are used by GL for overall setup of SLA for GL

SLA: Enable Diagnostics
This is only enabled when there are errors in the Create Accounting process.
The value is set to Yes and then the Create Accounting process is run again. The details are then captured and can be reported in the Transaction Objects Diagnostic Report. Because of performance issues, the profile option needs to be reset right away to turn this off and the System Administrator can run the Purge Transaction objects Diagnostics process to clean up the tables.

CST: Receiving Accounting Option
This profile option controls whether the Receiving Transactions Processor creates the accounting entries online or if the transaction accounting entries need to be created via the Create Accounting process.

Cost Management- SLA Responsibility
This is a new responsibility that allows for the setup of SLA and also to access the Create Accounting Cost Management process. The Create Accounting process that can be used for receiving transactions are Create Accounting Cost Management    …  Use Process Category = Receiving
OR
Create Accounting Receiving.

This last process, Create Accounting Receiving, is part of Purchasing responsibility and can only be run for receiving transactions.

For Accrual reconciliation:
—————————
The R12 Accrual reconciliation process will use the accounting entries from SLA as SLA is the source of truth for the real accounting entries. Hence the accrual load can not report any transactions prior to SLA upgrade start date.

Most users processing the receiving transactions would use instead of the Create Accounting – Cost Management is run via the Cost Management SLA responsibility.  This responsibility should have more security and restrictions from users.

Project Manufacturing and SLA-
For the GL posting option set to manufacturing, the cost collector will continue to post the transaction information just as before. The cost collector will pick the account information from mtl_transaction_accounts and wip_transaction_accounts. So if the user has set up any account derivation rules in SLA, they will not be respected by the cost collector.

For the other setup option, i.e when GL posting is set to Projects, depending on whether the auto accounting option has been set to yes or no, the accounts will be passed in or not passed in. If the auto accounting rule option has been set to Yes, no accounts will be passed to Oracle Projects by the cost collector. In this case, the user is responsible for setting the auto accounting rules in Oracle projects setup to derive the accounts. If the auto accounting option has been set to No, the accounts will continue to get passed in just as before (from MTA and WTA).
However, the cost collector will pass in the distribution link from MTA and WTA to Oracle projects. This distribution link will enable Oracle projects to link the distributions created in SLA tables back to the MTA and WTA tables. The distribution links are stored in the columns inv_sub_ledger_id and wip_sub_ledger_id in the MTA and WTA tables.

Periodic Average Costing and SLA – Presently there is no support for SLA for Periodic Average Costing. This is on the enhancement list but as of 12.1.1, this is not supported but is still under review from product development.

Some Reports that have been changed:
CSTRSCCR Supply Chain Cost Rollup
CSTREIVR – Elemental Inventory Value Report

With Implementation of Subledger Accounting Architecture feature in R12, the role of Cost Group/Sub Inventory is limited to maintaining the Unit Cost in the Reports. All the Account Generation for Transaction will be taken care by SLA Engine rules. So all account-related information has been removed from the valuation reports.
The following cost hook is impacted: CSTSCHKB.pls. The SLA setups will take the place of the std_cost_dist_hook, which allows the user to modified the accounts that are used for distributions. This will no longer be used as the user can use standard SLA process for this.

Troubleshooting suggestions:
1- Review logfile for the Create Accounting Cost Management
2- Enable FND: Debug to provide more details
3- Review the Transaction Objects Diagnostic Report
4- Confirm transactions are costed successfully via cost Manager
5- Check if the Create Accounting Cost Management process is successful when using traditional accounts.
6- Run the Subledger Period Close Exceptions Report and review errors, if any.


 

For additional information, please review the following notes:

802966.1 SLA Data Flow and Table Links
471057.1 SLA Cost Management Overview
876190.1 R12: FAQ on Transfer to GL in R12
740215.1 How To Transfer Transactions To GL (Summary) in Cost Management

REFERENCES

NOTE:876190.1 – R12: FAQ on Transfer to GL in R12
NOTE:802966.1 – SLA Data Flow and Table Links

Advertisements

Oracle E-Business Suite Objects Mapping Between 11i and R12

Oracle E-Business Suite Objects Mapping Between 11i and R12

You can download the Oracle E-Business Suite Objects Mapping Between 11i and R12 files from the following link:

Oracle_E-Business_Suite_Objects_Mapping_Between_11i_and_R12_(11.5.10.2_12.1.3).rar

 

 

 

 

 

 

Case Study: A Case Study on Subledger Accounting, Oracle Release 12

Case Study: A Case Study on Subledger Accounting, Oracle Release 12

Author: Jaya Kiran Pidatala – Chartered Accountant from the Institute of Chartered
Accountants of India
Organization: Satyam Computer Services Ltd, India
About the Author:
Jaya Kiran is a Chartered Accountant and has more than five years of IT experience on
Oracle ERP Financials.  His experience includes implementation, upgrade and support
projects.

 

About Oracle Partner Case Studies 
Oracle Partner Case Studies are intended as learning tools and for sharing
information or knowledge related to a complex event, process, procedure, or to a
series of related events.   Each case study is written based upon the experience that
the writer/s encountered.

 

You can download the Case Study on Subledger Accounting, Oracle Release 12 PDF document from the following link:

Case Study on Subledger Accounting Oracle Release 12

Viewer: Text Profile Option

Viewer: Text

The Viewer: Text profile option allows you to send report output directly to a browser window rather than using the default Report Viewer. Enter “Browser” in this profile option to enable this feature.

Users can see and update the Viewer:Text profile option.

This profile option is both visible and updatable at all four levels.

 
Level Visible Allow Update
Site Yes Yes
Application Yes Yes
Responsibility Yes Yes
User Yes Yes

The internal name for this profile option is EDITOR_CHAR.

JSP Pages Hanging in R12 After Removing Cached Class Files in _pages (Doc ID 433386.1)

Applies to:

Oracle Applications Technology Stack – Version 12.0.6 to 12.1.3 [Release 12.0 to 12.1]
Information in this document applies to any platform.
***Checked for relevance on 03-April-2013***

Symptoms

In Release 12 after removing a compiled class files from the JSP pages in the directory $COMMON_TOP/_pages and then bouncing the 10GiAS server, calling JSP pages results in a hanging ‘blank’ screen.

In Release 11i when performing the same steps, new class files are created automatically when the JSP page is called from a browser session and JSP was rendered fine.

In Release 12 it’s observed that when calling the JSP no class file is created in the directory $COMMON_TOP/_pages

Changes

Removing a class files from $COMMON_TOP/_pages

Cause

The root-cause of the hang is the fact that the JSP is not ‘translated’ into the associated class file in the _pages directory. This is a mandatory step for processing the JSP page.

The reason this is not happening in R12 is because of the following setting the $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/html/orion-web.xml

<init-param>
<param-name>main_mode</param-name>
<param-value>justrun</param-value>
</init-param>
</servlet>

When main_mode = justrun the OC4J container running the OACoreGroup is told that no compilation on the fly is allowed and only (pre)compiled classes are picked up. Since these have been removed, the processing of the JSP page is blocked.

Solution

Use the ojspcompile.pl perl script to perform a manual pre-compilation of the JSP pages. The following command will compile all the JSP pages and build up the JSP cache again.

Unix: # perl $FND_TOP/patch/115/bin/ojspCompile.pl –compile –flush -p 2

Windows: C:> perl -x <FND_TOP>\patch\115\bin\ojspCompile.pl -compile -flush

This utility is also used by the AD utilities to perform this action such as when patches are applied that replace one or more JSP pages.  See Note:215268.1 for other command line options and examples.

An alternative is to change the value for the main_mode parameter to recompile (instead of justrun)

This can be achieved with the following steps

  • Use the Context editor to change the value for “s_jsp_main_mode” in the <SID>_<hostname>.xml file used by autoconfig and change value from justrun to recompile
  • Run Autoconfig to propagate the changes to the configuration files
  • Verify that now the $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/html/orion-web.xml  has

    <init-param>
    <param-name>main_mode</param-name>
    <param-value>recompile</param-value>
    </init-param>

  • Test the scenario failing before.
  • See that now a new _<jspname>.class is created when the JSP page is called.
For production environment the manual ‘ojspcompile.pl’ method is recommended for the following reasons

  • With ‘justrun’ a fixed set of JSPs are used which will not automatically change. With ‘recompile’ the JSP pages replacing existing ones will recompile automatically while the environment is up and running.  This may lead to errors for the users when compilation fails or in having different versions of the JSP being used within a single session.
  • Using ‘justrun’ improves performance by skipping the check for compilation being needed.

How To Clear The Cache Using Functional Administrator? (Doc ID 759038.1)

Applies to:

Oracle iProcurement – Version 11.5.1 to 12.0.0 [Release 11.5 to 12]
Information in this document applies to any platform.

Goal

How can the ‘Clear all Cache’ be selected through the Functional Administrator responsibility to ensure newly changed profiles that pertain to iProcurement are now being considered?

Solution

WARNING: Clearing the OA Framework cache in a PRODUCTION instance can cause data issues if multiple users are engaged and transacting data in the application at the time cache is cleared.  Please only utilize this in Production if advised by Oracle Support Services or Oracle Development.

Many times when setting profile options that pertain to iProcurement, to ensure that the new profile values are invoked immediately, the following actions can be taken using the Functional Administrator.

Examples that may require this action to be taken are as follows:
–  iProcurement Preferences (these values actually are User level profile options)
– FND Diagnostics – to enable diagnostics
– FND Debug Log Enabled – which engages further debugging to FND_LOG_MESSAGES table
– Personalize Self Service Defn – commonly used profile to enable the Personalization Links
– Newly added responsibility is not visible in the list of Responsibilities after logging into the application

The following steps are to be utilized to clear all the cache, forcing a refresh and requery of all profile values for the user in question.

1. Login and choose the Functional Administrator responsibility – then choose Home.

image12.  Choose the Core Services Tab – then the Caching Framework Sub-Menu (In the dark blue region).
– Proceed to choose ‘Global Configuration’ from the left hand side menu that appears
– In the far right choose ‘Clear all Cache’ button

image23. A screen prompts and confirms that the action will clear all cache on the middle tier server – choose Yes.
Essentially, this just forces all user sessions to engage and validate – rather than using cached values.

image3
4.  A confirmation message is displayed, confirming that all cache has been cleared across middle tiers.

image4
5. Proceed to test and confirm whatever change was made to the preference, profile, etc….

WARNING: Clearing the OA Framework cache in a PRODUCTION instance can cause data issues if multiple users are engaged and transacting data in the application at the time cache is cleared. Please only utilize this in Production if advised by Oracle Support Services or Oracle Development.