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..

COGS / DCOGS

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.

India – Goods and Services Tax(GST) Overview


Goods and Services Tax(GST) is a destination based tax applicable for supply of goods and services or both administered concurrently by the Center and State Governments through out the value chain except:

  • Exempted goods and Services => Very few items with common list for CGST and SGST.

Find below the quick snapshot of the proposed GST Structure:

Following 3 new tax types got proposed in GST:
CGST (Central Goods and Services Tax)
SGST (State Goods and Services Tax)
IGST (Integrated Goods and Services Tax)

GST Rates are based on Revenue Neutral Rates. Following are the proposed rate types and the rates are not yet finalized as on the blog posted date:

1. Merit rate => For essential goods and services.
2. Standard rate => For goods and services in general.
3. Special rate => For precious metals and for specified goods and services.
4. Zero rate => For exports, supply to EOU/SEZ etc.

Goods and Services outside the purview of GST:

  • Alcohol for Human consumption =>  will continue with State Excise and VAT
  • Electricity => will continue with Electricity Duty
  • Petroleum Products => will continue with the current tax structure, likely to be brought under GST regime later
  • Tobacco products expected to be taxed under the GST regime along with Excise dutyGoods and Service Tax

GST is considered the largest indirect tax reform in India and will replace multiple indirect taxes that are administered by the Central and State Governments.

The Goods and Services Tax Network (GSTN), has been tasked by the Government of India with building and maintaining the centralized, national level government IT infrastructure required for GST.

In reference to the Government of India’s roll out of the Goods and Services Tax (GST) planned for April 2017, the Oracle E-Business Suite (EBS) team has already put a plan in place and the details of the same shall be shared shortly in the next post.

EBS: Oracle Financials for India(OFI) – India Localization GST Update


The EBS India GST Information Center is now available on My Oracle Support. This information center is the central source for EBS information on India GST including:
Documentation:
  • Functional scope summary
  • Order to Cash Setup
  • Order to Cash User Guide
  • Purchase to Pay Setup
  • Purchase to Pay User Guide
  • Early access — information on early access to phased software updates information on requirements, limitations and how to register to request access.
Troubleshooting guides and FAQs:  These will accumulate with time based on customer and partner interaction.
The EBS India GST Legislative Update document has also been updated to let customers and partners know the info center is now available.

You may please register your request for early access through  EBS India GST Information Center.

Oracle Assets – Difference Between Amortized and Expensed Adjustments


Just thought of sharing this information as in my blog i am getting this query again and again —

When you perform a financial adjustment on an asset such as a cost adjustment, a depreciation method change, or a date placed in service change, the effect that the adjustment will have depends on whether the adjustment is expensed or amortized.

If the transaction is an Expensed Adjustment, the effect of the adjustment will be from the Date Placed In Service (DPIS) of the asset.  Oracle Assets recalculates depreciation using the new information starting from the DPIS and derives the expected depreciation. The expected depreciation reserve will be compared with the existing depreciation reserve of the asset and any excess or deficit amount will be accounted in the period in which the adjustment is done.

If you want the adjustment to be effective from a specific period and not from the DPIS, the transaction needs to be an Amortized Adjustment.  For amortized adjustments, the effect of the adjustment will be from the period in which the amortization start date falls and the accumulated depreciation prior to the amortization start date will not be re-validated.  When an amortized adjustment is performed, Oracle Assets spreads the adjustment amount over the remaining life or remaining capacity of the asset.

Note that once an asset has an amortized adjustment, it is no longer possible to perform an expensed adjustment on that asset.

How do you perform an Expensed or an Amortized adjustment?

While performing the transaction, whether it is expensed or amortized depends on these selections:

 

amort

Here is an example of how expensed and amortized adjustments work:

Let’s take an asset that has these parameters:
Cost = 12000
DPIS = 01-JAN-2016
Depreciation method and life = STL for 12 months
In the Aug-16 period, the life is changed to 15 months.

If the adjustment is expensed:

The depreciation, with an asset life of 12 months, would be 12000 / 12 = 1000 per month.
The depreciation, with an asset life of 15 months, would be 12000 / 15 = 800 per month.
Until the Aug-16 period, the asset was depreciating based on a life of 12 months.  The existing depreciation reserve of the asset is 1000 * 7 months = 7000.
Based on the new life, the accumulated depreciation should be 800 * 7 months = 5600.
The depreciation catch-up in Aug-16 is 7000 – 5600 = (1400).
From the Aug-16 period onwards, the monthly depreciation for the asset will 800.

Now, if that adjustment is amortized:

The depreciation, with an asset life of 12 months, would be 12000 / 12 = 1000 per month.
The depreciation reserve amount charged up to Aug-16 is 1000 * 7 months = 7000.
So, the net book value of the asset as of Aug-16 is 12000 – 7000 = 5000.
The remaining life of the asset as of the Aug-16 period is:  Total life – life already completed = 15 months – 7 months = 8 months.
From the Aug-16 period onwards, the monthly depreciation for the asset will be Net Book Value / Remaining Life = 5000 / 8 months = 625.

Comments and Suggestions most welcome.

Thanks,

~KKT~

ERP R12: Upgrade vs. Reimplementation (Financials)


This document discusses important considerations to make when determining whether your project to move to E-Business Suite Release 12 should be a standard upgrade or a reimplementation. It includes suggestions and advice from professionals in Oracle’s Product Development organization that will help you to understand the issues that your project team should consider when analyzing the two options.

DEFINITIONS
Let’s start by distinguishing what we mean by the terms “implementing” and “upgrading.” If you adopt Release 12 by implementing, you install the Release 12 software and implement it to reflect your enterprise structure and operating practices. You then load any historical data from your legacy systems into your freshly-implemented Release 12 system using public interface tables and application programming interfaces (APIs) that Oracle provides. Generally, you use custom scripts to transform your historical data into a format that is compatible with those public interfaces. If the legacy system from which you migrate your historical data is an earlier release of the E-Business Suite, then your fresh implementation may be described as a “reimplementation”.

If you are moving from an existing release of Oracle E-Business Suite to Release 12, you can adopt Release 12 by upgrading. With this alternative, you install the Release 12 software and use Oracle-supplied tools and scripts to transform your historical data in place to the new Release 12 data model. The standard upgrade process converts your existing setup to Release 12 – reimplementation is not required.

BASIC CONSIDERATIONS
If you are moving from an existing release of Oracle E-Business Suite to Release 12, you need to consider whether to perform a standard upgrade versus a reimplementation. A standard upgrade allows you to take advantage of supported tools, scripts and documentation to move your existing Release 11i setups and historical data to Release 12. A reimplementation, on the other hand, allows you greater flexibility in your setup and in how you migrate your historical data using supported public interfaces. It is a project that you would generally undertake with the support of a professional services provider, such as Oracle Consulting. You would consider doing a reimplementation under circumstances such as:

  • You wish to change configurations that are not easily changed, such as your chart of accounts definition, costing method, or calendar.
  • Your enterprise has undergone significant change in the number and structure of its business units and organizations since your original Oracle implementation. For example, you have grown through acquisition and you want to establish a new standard applications setup for all of your business units, which are currently running disparate application systems. In this case, you might choose to freshly implement Release 12, and then migrate historical data from your existing businesses, even if some of those businesses were running E-Business Suite.

STANDARD UPGRADE EXAMPLE
To crystallize the issues, let’s look at the characteristics of a deploying company who would most likely choose to do a standard upgrade to Release 12. Such a company would most likely:

1. Run a single global instance of Oracle applications
2. Have a single chart of accounts or is satisfied with their current chart of accounts
3. Use standardized business processes with minimal customizations
4. Run shared service centers for back office functions

Enterprises with all of the above characteristics can most readily benefit from Release 12’s centralized accounting architecture, global tax engine, new ledger and ledger set architecture, multi-org access control features, centralized banking model, advanced global intercompany system and so on. This is not to say that a company must have all of the above characteristics to be able to do a standard upgrade – but we’ll now go into some of the reasons why each of the above makes the upgrade option more likely.
In Release 12, Sets of Books have been replaced by Ledgers. Ledgers sharing the same chart of accounts, calendar and period type can be combined into Ledger Sets which allow operations to be performed on multiple ledgers at the same time. These operations include viewing information, reporting, opening and closing periods, creating journal entries and performing allocations across ledgers. This ability gives improved visibility and control across all ledgers assigned to a ledger set. Therefore, enterprises that have standardized on a single chart of accounts are in the best position to do a straight upgrade to Release 12 and to see immediate benefits.

It’s most beneficial for the enterprise to have standardized business processes – so that each ledger and operating unit has unified procedures. This would allow a deploying company to do cross-ledger allocations or month-end journal entry creation, for example. Further, having a single global instance of Oracle applications would allow single step actions with the use of Ledger Sets – so closing the books could be done once per Ledger Set rather than closing each Set of Books on each application instance.
Enterprises that have implemented shared service centers to perform back-office functions for multiple operating units will immediately see the benefit of Multi-Org Access Control features added throughout Release 12. A user who has access to multiple operating units (OUs) will no longer have to switch responsibilities or ‘hats’ to get to information in the correct OU. Multi-Org Access Control will allow them to enter and access transactions in multiple OUs with a single responsibility.

REIMPLEMENTATION EXAMPLE

Now let’s take a look at an enterprise that would want to consider reimplementation in order to move to Release 12. Such a company would most likely:

1. Run multiple instances of Oracle applications and would like to consolidate.
2. Have multiple charts of accounts and would like to move to one.
3. Use disparate business processes and see the benefit in having standard global business processes.
4. Maintain decentralized back-office functions but see value in moving to a shared services model.
5. Have many customizations and understand that R12 could eliminate some of them.

This type of implementation would benefit from moving to a best-practice implementation of E-Business Suite.

With Release 12’s added features and centralized architecture, you may be able to eliminate many of the customizations your enterprise has had to cultivate in order to support your unique business processes. Furthermore, you might want to consider moving to a best practice implementation in order to centralize on a single ERP vendor and even application instance. Much research has recently come out from various analysts indicating that that standardizing on a single ERP vendor has multi-layered benefits, not the least of which is tremendous costs savings. A single chart of accounts will simplify reporting, giving you a global view of your business. And finally, centralized and standardized back-office functions can dramatically lower costs by removing redundancies and inefficiencies from your business processes and giving you better information more quickly. Altogether, the benefits of moving to a best practice implementation have inherent value – no matter what ERP system you are using.

SUMMARY

In summary, it is our hope that this paper helps you understand some of the issues that you should consider when designing your migration to Release 12 so that your enterprise will get the most out of its E-Business Suite deployment now and going forward.