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

Bug 8636919 : ENG: INVENTORY TRANSACTION WORKER PROCESS (INCTCW) ENDS WITH ERROR UESTNT

Type B – Defect Fixed in Product Version 11.5.10.2
Severity 2 – Severe Loss of Service Product Version 11.5.10.2
Status 93 – Closed, Not Verified by Filer Platform 226 – Linux x86-64
Created Jun 26, 2009 Platform Version NO DATA
Updated Sep 25, 2009 Base Bug N/A
Database Version 10.2 Affects Platforms Generic
Product Source Oracle
Hdr: 8636919 10.2 TRNSACTION 11.5.10.2 PRODID-508 PORTID-226

Abstract: ENG: INVENTORY TRANSACTION WORKER PROCESS (INCTCW) ENDS WITH ERROR UESTNT

*** 06/26/09 10:33 am *** (ADD: Impact/Symptom->FUNCTIONAL )
*** 06/26/09 10:33 am ***

  BUG TYPE CHOSEN
  ===============
  Data Fix

  Product: Oracle Inventory Management (508)
  ==========================================
  PROBLEM STATEMENT
  =================
  Customer from Brazil

  On 11.5.10.2 in Production:

  Customer have 5802 records in MTI stuck with some errors.
  There are 4080 records of the above, with error code "ERRO ORACLE"
  The log of the concurrent request shows for one of this tarnsactions
  the message: Inventory:(INCTCW) with the error UESTNT.

  DATA COLLECTED
  =================
  1) Inventory Debug file shows the following error:

  INV_TXN_MANAGER_GRP: Error in tmpinsert: sqlerrm : ORA-1: unique
  constraint (INV.MTL_MATERIAL_TRANS_TEMP_U1) violated

  2) Running the standard duplicate transactions script, the log shows the
  following:

  select a.transaction_temp_id,
  a.picking_line_id from mtl_material_transactions b,
  mtl_material_transactions_temp a
  where a.picking_line_id = b.picking_line_id
  and a.trx_source_line_id = b.trx_source_line_id
  and a.inventory_item_id = b.inventory_item_id
  and b.transaction_type_id = a.transaction_type_id
  and b.transaction_source_type_id in ( 2,8)
  and b.picking_line_id is not null;

  => 26 records found...
  This records were deleted with:

  delete from mtl_material_transactions_temp where transaction_temp_id in
  (select transaction_temp_id from mmt_mmtt_records_v );

  => 26 records found.

  There are still a huge quantity of transactions stuck with the error above.

  WORKAROUNDS
  ===========
  None

*** 06/26/09 10:42 am ***
*** 06/26/09 10:45 am *** (CHG: Sta->16 Pri->1)
*** 06/26/09 10:45 am ***
*** 06/26/09 10:49 am ***
*** 06/26/09 11:49 am *** (CHG: Sta->11 Pri->2)
*** 06/26/09 11:49 am ***
*** 06/26/09 11:51 am *** ESCALATED
*** 06/26/09 01:56 pm ***
*** 06/26/09 02:58 pm *** 
*** 06/26/09 04:36 pm *** (CHG: Sta->30)
*** 06/26/09 04:36 pm ***
*** 07/02/09 01:24 pm *** (CHG: Sta->11)
*** 07/02/09 01:24 pm ***
*** 07/03/09 06:09 am ***
*** 07/06/09 11:28 am *** (CHG: Sta->30)
*** 07/06/09 11:28 am ***
*** 07/08/09 06:07 am ***
*** 07/08/09 06:17 am ***
*** 07/08/09 06:18 am *** (CHG: Sta->11)
*** 07/08/09 06:18 am ***
*** 07/08/09 11:49 am *** (CHG: Sta->30)
*** 07/08/09 11:49 am ***
*** 07/08/09 11:51 am ***
*** 07/09/09 06:06 am *** (CHG: Sta->11)
*** 07/09/09 06:06 am ***
*** 07/09/09 11:24 am *** (CHG: Sta->30)
*** 07/09/09 11:24 am ***
*** 07/09/09 12:36 pm *** (CHG: Sta->11)
*** 07/09/09 12:36 pm ***
*** 07/10/09 11:34 am *** (CHG: Sta->30)
*** 07/10/09 11:34 am ***
*** 07/10/09 01:03 pm ***
*** 07/10/09 01:03 pm *** (CHG: Sta->11)
*** 07/10/09 04:37 pm *** (CHG: Sta->30)
*** 07/10/09 04:37 pm ***
*** 07/10/09 04:39 pm ***
*** 07/16/09 02:04 pm ***
*** 07/16/09 02:04 pm *** (CHG: Sta->11)
*** 07/16/09 05:35 pm ***
*** 07/17/09 02:50 pm *** (CHG: Sta->30)
*** 07/17/09 02:50 pm ***
*** 07/27/09 02:30 pm *** (CHG: Sta->33)
*** 07/27/09 02:30 pm ***
*** 07/27/09 04:39 pm ***
*** 08/04/09 05:49 am *** ESCALATION -> CLOSED
*** 08/04/09 07:51 am ***
*** 09/25/09 01:33 pm *** 
*** 09/25/09 01:33 pm *** (CHG: Sta->93)
*** 09/25/09 01:33 pm ***
Solution

delete mtl_material_transactions_temp;

commit;

All Receiving Transactions Fail with rvtptcontrol or RVTII-060 or RVTTH-445 or RVTTH-448 or RVTII-030 or RVTII-080 or RVTPT-020

Applies to:

Oracle Inventory Management – Version 11.5.1 to 12.1.3 [Release 11.5 to 12.1]
Information in this document applies to any platform.
FORM:RCVRCERC.FMB – Enter Receipts GUI
FORM:RCVTXERT.FMB – Enter Receiving Transactions GUI
FORM:RCVTXECO.FMB – Enter Corrections GUI
FORM:RCVTXERE.FMB – Enter Returns GUI
EXECUTABLE:RVCTP – Receiving Transaction Processor

Symptoms

Receiving transactions fail with rvptcontrol or RVTII-060 or RVTTH-445 or RVTTH-448 or RVTII-030 or RVTII-080 or RVTPT-020 error (and sometimes there is no error). Sometimes the error only occurs when using RCV: Processing Mode=On-line, and sometimes only certain document types (like RMAs or Expense Purchase Orders) are affected.

Changes

In some cases this occurs after a patch has been applied.

Cause

When many transactions fail with same error it is usually because the receiving executables (RVCTP and RCVOLTM) are out of sync. The exact cause may not be known, but could be caused by one of the following:
patch application
environment parameter change
invalid objects
database crash

Solution
  1. Resolve INVALID Objects
  2. Relink receiving executables
    cd $PO_TOP/bin
    $ adrelink force=y ranlib=y “PO RCVOLTM”
    $ adrelink force=y ranlib=y “PO RVCTP”
  3. Bounce Receiving Transaction Manager:
    – $ps -ef | grep RCVOLTM (to see how many processes are running)
    -Deactivate Receiving Transaction Manager
    (System Administrator > Concurrent > Manager > Administer)
    -$ps -ef | grep RCVOLTM (repeat until no processes are running)
    -Restart Receiving Transaction Manager

    For additional information about above steps, please refer to the following notes:
    Note 1325394.1 (Troubleshooting Guide – invalid objects in E-Business Suite Environment 11i and 12)
    Note 552702.1 (How To Relink and Bounce the Receiving Executables?)
  4. Perform transaction.
  5. If the transaction still fails, bounce the database and then perform another transaction.
  6. If bouncing the database or flushing Shared Pool resolves the issue only for a few days (or a few weeks) and bounce database (or flush Shared Pool) must be repeated periodically to resolve the issue, please review the following notes:
    Note 351306.1 (RCVRCERC Receipts Fail with No Errors)
    Note 436947.1(How to Avoid OM error: ORA-06508: PL/SQL: Could Not Find Program Unit Error.)
  7. If all transactions still fail after performing the steps above, please log a Service Request with Inventory / Receiving and provide the following information:
    a. Output from “Diagnostics: Apps Check” Report using a Purchasing Responsibility:
    – Reports > Run
    – Submit a Single Request
    – Name: Diagnostics: Apps Check
    – Parameters: Application 1: Oracle Purchasing
    – Parameters: Application 2: Oracle Inventory
    – Submit the request
    – View > Requests
    – Select the Report Output (not the Log)
    **output contains file versions and other information that may be needed to progress issue or verify potential solutions; also required if bug is loggedb. Resolve all INVALID Objects; if any INVALID Objects cannot be resolved, provide Excel spreadsheet, including Column Headings of output from the following:

    select owner, object_name, object_type
    from all_objects
    where status=’INVALID’
    order by owner, object_name

    c. Provide database trace for one occurrence:

    NOTE: Make sure trace is not enabled at forms or concurrent program level when profile below is set

    1) Enable trace for a specific user:
    – Bring up the Core application – System Administrator responsibility – Move to Profile/System
    – Check off the USER box – and enter your username that you are using when getting the error
    – Search on the following profile option – ‘Initialization SQL Statement – Custom’

    2) Set this value at the User Level:
    BEGIN FND_CTL.FND_SESS_CTL(”,”, ”, ‘TRUE’,”,’ALTER SESSION SET TRACEFILE_IDENTIFIER=’||””||’rcvtrace.trc’ ||””||’ EVENTS =’||””||’ 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 ‘||””); END;

    Cut and paste the above sql statement for the ‘Initialization SQL Statement – Custom’ Profile at the User Level. This must be one complete line of text – so may be best to copy the string into notepad prior to putting it into the profile.
    **it is not required to use ‘rcvtrace.trc’; please ensure the filename is unique so only one transaction will be captured in the trace (this value is required in next step to locate the trace file)

    3) Once the profile is set, change Responsibilities then reproduce the issue

    4) To locate the trace file, use the following sql in sqlplus:

    select name, value
    from v$parameter
    where name like ‘user_dump_dest’;

    – The value is the location of the trace file on the database server
    – Please move to this directory and search for the file having trace.sup in the filename
    – This is the trace file created – please tkprof it:
    tkprof <filename.trc> <output_filename> sys=no explain=apps/<password>

    5) Upload BOTH the raw and tkprof trace files

    6) Ensure that the profile option is unset before exiting the Application.

    This is a very important step; if the Profile is not unset, unnecessary trace files will be generated.