High Level Comparison of OPM Financials R12 and 11i

Changes to OPM Fiscal Policy setup

In Release 11.5.10 the Fiscal Policy (GL_PLCY_MST) record is linked to an OPM Company, and defines among other things which Operating Unit that Company is linked to and which Set of Books is used when looking at Account Code Combinations.

From Release 12 the Fiscal Policy record is keyed on Legal Entity and Ledger.  There is no longer any requirement to set up ‘Segment’ information linking MAC Accounts and GL Code Combinations.

From Release 12 the Event Fiscal Policy form (basically information relating to postings for Purchasing transactions) is accessed directly from the Fiscal Policies form GLFISCP.fmb – previously it was a separate menu entry.

OPM Organizations / Inventory Organizations

As is well known, from Release 12 the OPM and Oracle Inventory products have ‘converged’, meaning that the Release 11i entities in OPM like Organizations (SY_ORGN_MST) and Warehouses (IC_WHSE_MST) have disappeared.

Furthermore all transaction information is now saved in the Discrete Inventory tables like MTL_Material_Transactions – the Release 11i tables IC_TRAN_PND and IC_TRAN_CMP are not used at all.

Although Item Cost information is still held in OPM-specific tables (CM_CMPT_DTL, GL_ITEM_CST), all tables now use Organization_Id where previously Company Code and/or Warehouse Code would have appeared.  The Organization_Id column always joins to View ORG_Organization_Definitions.

Fir this reason you will see that the Release 11i ‘Cost Warehouse Associations’ setup form is now ‘Cost Organization Associations’.

OPM Items

In Release 11i each Item Number appeared once only in table IC_ITEM_MST.  This table is now obsolete, and all Items (Process and Discrete) are defined in table MTL_System_Items.

Each Item can be assigned to multiple Organizations (both Discrete and Process-Enabled) and appears that many times in the MTL_System_Items table.

From Release 12 the restriction where OPM Item Numbers could only consist of one Segment is lifted.

Cost Method / Cost Type

Name changes from Cost Method to Cost Type, but the setup form (CMMTMSED.fmb) is still owned by and accessed from OPM Financials, and writes to table CM_MTHD_MST.

Cost Calendars

In Release 11i Cost Calendars are keyed on Company Code and Cost Method.

From Release 12 they are still owned by OPM Financials (tables CM_CLDR_HDR, CM_CLDR_DTL) but are defined as an independent entity which can then be assigned to one or more Legal Entity and Cost Type combinations.

Costing Basics

OPM Costing Types (Actual, Standard, Lot) are still available as before.

In Release 12 you still need to run your cost calculation process and then Cost Update in order to populate tables GL_ITEM_CST and GL_ITEM_DTL ready for Period-End processing.

OPM Inventory Period Close

In Release 11i ‘Inventory Close’ is run from the OPM Inventory Control menu, and populates table IC_PERD_BAL.

From Release 12 the same function is carried out by concurrent program ‘GMF Period Close Process for Process Organizations’, run from the standard report submission form.  This writes to table GMF_Period_Balances and can be run ‘Final’ or ‘not Final’ as before.

Manufacturing Accounting Controller vs Subledger Accounting

Although the change from MAC to SLA appears to be massive and daunting, once you are familiar with the setup hierarchy in Release 12, that is to say:


Subledger Accounting Method (SLAM)
Application Accounting Definition (AAD)
Event / Journal Line Definition (JLD)
Account Derivation Rules (ADR)

.. you will find parallels between the Release 11i and Release 12 setup.

Release 11i Release 12
Events : (PORC, BTCH, OMSO, IADJ and so on) Entities
Sub-Events (CERT, RELE) Event Class > Event Type
Sub-Event link to Account Titles Journal Line Definition link to Journal Line Types
Account Mapping Account Derivation Rules

The Release 11i concept of mapping an Account in two halves (the Accounting Unit and the Account Number) no longer exists in Release 12, however the logic which you can apply in Account Derivation Rules is enormously powerful and flexible.

Depending on the transaction type in question (for example an MTL_Material_Transactions row) you can use a wide range of column values in the source transaction to drive the selection of either the entire Code Combination as a single string, or individual Segment values.

Contrast this with the Release 11i mapping setup, where you could specify which Account Number was to be used based on a relatively short list of available Selection Criteria.

There is a basic accounting setup seeded in a Release 12 database but you will need to update this.  Seeded records always show an Owner of ‘Oracle’, and to change the setup you must always make a copy of the relevant record which will be owned by ‘User’, and this can then be updated.

Custom Sources in Derivation Rules

As noted above, the list of ‘Sources’ upon which you can base Account (or Segment) Derivation logic is limited to columns which appear in the relevant transaction record.

You can extend this list of Sources to look at data in other tables by providing your own PL/SQL code.  For example, say the current transaction record contains an Inventory Item Id but not the Item Class, but you wish to post to different Accounts based on the Item Class.

This can be achieved – please see Note 1356816.1  (“How to Create a Custom Source for use in OPM Financials Create Accounting”) for details.

Mapping Sets

Another way in which you can extend the Account Derivation logic is by using Mapping Sets.

A Mapping Set is basically a translation table – one value is passed in and a different value is returned.  For example you might have 10 ‘branch’ Organizations but the same Account is to be used for six of these, and another Account for the other four.

You can code for this using the regular ADR logic, but the neater solution is group these Organizations in a Mapping Set which is then associated with the ADR.

See Note 1115473.1 for a worked example.

Period End Processing

After Item Costs have been finalized and the OPM Cost Update process run, in Release 12 the basic process is :


– run the OPM Accounting Pre-Processor (GMFXUPD)
– run ‘Create Accounting for OPM Financials’ in Draft mode
– run ‘Create Accounting for OPM Financials’ in Final mode

The Accounting Pre-Processor is fundamentally the same process as the Release 11i Subledger Update program.  Until Create Accounting is run in ‘Final’ mode, the Pre-Processor can be run over and over again for the current Period until it is successful (that is to say, there are no unexpected errors reported, and the results from the Detailed Subledger Report are as expected)

Create Accounting sweeps through all the rows written by the Accounting Pre-Processor and builds postings which can optionally be posted automatically to GL..


In Release 11i the processing of Order Management transactions caused postings to the COGS (Cost of Goods Sold) Account by default.

In Release 12 the default posting will be to Deferred COGS (DCOGS) unless the three COGS Recognition concurrent processes (owned by the INV Product) have been successfully run before the OPM Accounting Pre-Processor.

The three processes must be run in this sequence:

– Record Order Management Transaction
– Collect Revenue Recognition Information
– Generate COGS Recognition Events.


Saving Planning Webform / Smartview Results in Error : “There was an error during the save process”

On : version, Product Usage

When attempting to submit data in Hyperion Planning web form ,
the following error occurs.

There was an error during the save process

This is due to Essbase Exceeded block limit.

Was identified from the Essbase log with the below error Message:

Request [SpreadsheetOperation] from user [admin@Native Directory] was terminated since it exceeded the block limit

Remove the setting QRYGOVEXECBLK from Essbase.cfg file, restart service for Essbase to fix the issue.



DRM- How to Lock DRM Users Out of Applicaition for Short Periods of Time

What are the ways to lock DRM users out for short periods of time?

There is no one way to lock people out of DRM. Some workarounds would include the following depending on how DRM is configured:

1. If user are CSS ( shared service users) one could change the authentication mode of DRM to be just internal. Bounce DRM; Then use only an internal user to run the updates.

2. One could go through and change each user in DRM to Lock them out but this is very manual and if there are a lot of users , time consuming

3. If user are apart of NAG’s, then all of the roles could be revoked, then added back after the black out period is over



DRM – How to create a workflow model

The new request tab under worklist is greyed out for the user as workflow model was not created.

Scenario: Create a Workflow Model(WFM) which has two stages one is Submit and the other is Commit. This WFM is used for adding new base node.

1.Create users with the below roles:

Governance user, governance manager and workflow user

2.Create required Node Access Group(NAG).

3.Create the workflow task.

4.Create the workflow model.

–Click on Edit of Submit Stage in Action column and assign Workflow Task and Node Access Group to that Stage.

–Select the respective Workflow Task in the available list and push to selected list.

–Select the respective NAG in available list and push to selected list.

–Click on Save which is on the right-hand side

–Click on Edit of Commit Stage in Action column and assign Node Access Group to that Stage

–Select the respective NAG in Available list and push to selected list

Note: No Workflow Task will be there in Commit Stage.

–After completion of all Stages updates, Click on Save.

5.Assigning Hierarchy Node Access to NAGs
–Login to DRM.

–Select Version and open respective hierarchy.

–Go to Nodes->Assign->Node Access

–Select respective NAG group and select the appropriate access level and click on Save.


The new request tab in the work list will be available now.