John Wilson is a Prescience Technology Oracle Functional Consultant currently engaged in a major R12 upgrade for a manufacturing client. He is a Chartered Accountant with more than 16 years experience working hands-on with the Oracle ERP system, 11 of those years with Oracle Australia and NZ.

In this article he addresses some of the common questions around undertaking an Oracle R12 upgrade, and explains some of the benefits of the new functionality.

Do you have a stable Oracle ERP 11.5 implementation and no burning desire for new functionality but are facing the prospect of increased support costs and, eventually, being unsupported if you don’t upgrade?

You are not alone.

There is no doubt that Oracle wants you to move to R12. The challenge however is that it does cost to upgrade, not only in skilled implementation manpower but also effort from the business to learn and adjust to new processes. It would also be fair to say that there are a number of organisations that have not fared well from their R12 upgrade – the war stories are out there and I have quite a few battle scars of my own.

So how can you take advantage of an upgrade and how do you minimise the risk? This article will be the first in a series designed to share some of the lessons I’ve learnt and to dispel some of the rumours that abound as a result of some of the previous, shall we say, “challenging” upgrades.

When is the right time?

The first question is when to do it. You generally don’t want to be an early adopter – there is no valid business case for that unless there is some ‘must have’ functionality requirement. Those organisations that installed R12.04 or even 12.06 may still be in recovery mode. Fortunately, the opportunity to be an early adopter has now largely passed.

However, the additional good news is that finally there is a landmark R12 version – 12.1.3+ (I added the ‘+’ due to the number of patch sets that came out after the initial release). I am currently in the early stages of my second major 12.1.3 upgrade and all is surprisingly stable – many of the past issues have gone, the upgrade process itself seems remarkably robust and even AP looks ok, although I will be keeping my fingers crossed until completion of UAT!

So, if you have to do it – now is looking like a good time.

What kind of upgrade should you do?

One option is to limit your scope to a purely technical upgrade but don’t forget that things have changed in the new version, so users will be impacted regardless – new forms, new processes, new buttons.

Even a pure technical upgrade will require effort on change management and documentation.

So, if you are going to do it, I recommend you spend a bit of time looking through the new features explained in the release content documents and include items in scope that could add value to the business, replace customisations or just make the daily operations more efficient.

The amount of extra testing and change management could be minimal. Plus, it will help with business buy-in and make that business case more palatable to the boss.

In the remainder of this article, I’ll focus on some of the new functionality around Sub-Ledger Accounting. It’s a good place to start as it overcomes some common pain points.

Sub Ledger Accounting (SLA)

The first thing to know is that you don’t have to do anything – it will just be there from day one, like the moat around the castle that is the General Ledger (GL). Auto Accounting and Account Generators are still supported and will seamlessly pass through to the GL via the new “Create Accounting” concurrent process.

But before you make the ‘Do Nothing’ decision consider how the new functionality could help with the following common issues:

Meaningless or irrelevant journal header and/or line descriptions

In the new version, you can build your own descriptions by journal type using the many pre-seeded sources or, if you need to, you can add your own custom source. 240 characters is the only limit to what you can do.

Perhaps you want to see the Asset Number in the GL when the accounting transaction is an addition or a disposal but not when it relates to depreciation? The flexibility is all there – in the Fixed Assets module alone you can choose from 797 data sources, including Descriptive Flex Fields (DFF’s) to be displayed on the journal line.

Inadequate default accounting set-ups, which require additional manual journals or allocations

The classic example is the need to allocate out the Trade Creditors balance to support non-balancing, segment-based balance sheet reporting. It’s usually a tricky business as you have to dig into AP to look at the expense distribution of each unpaid invoice to work out where to move the balance.

However, the new SLA Account Deviation rules allow you to accept the full code combination generated by Oracle but then change one or many segments, based on one or many rules. One less process to run and reconcile at month-end, and the linkage back to the source transactions is maintained. I guarantee this will reduce the number of manual journals each month!

Tracking accounting entries in the GL for a specific data object, for example, a Project or a type Discrete Manufacturing job

The new optional ‘supporting references’ feature in SLA is potentially a very powerful tool, enabling you to:

  • Enhance journal line or header information based on the source transaction;
  • Optionally, maintain a SLA balance based on that source value or even a combination of source values;
    and / or
  • Provide an additional layer of information for financial or management reporting.

Suddenly, instead of querying financial information from the GL and drilling into related transactions, because the source value can be completely independent of the code combination, the user can now query the sub ledger source value and see all the related financial transactions, by period and across financial years.

Reliance on technical staff to update account generators

It is fair to say that on first look SLA is pretty scary – the forms are busy and it is difficult to
conceptualise the relationships between the various pieces. However, once you realise it is a “knee bone is connected to the thigh bone etc” relationship, it’s just a matter of completing one set-up and attaching it to the next level up and finally attaching the modified definition to the Ledger.

While it is not for the average user, a competent System Administrator or functional person can build and maintain it. The rule used to generate a Journal line is visible to the user, so troubleshooting is a system support task, and again, technical gurus are not required.

Manually managing different financial accounting representations in the same Book

The R12 Ledger Architecture introduces the concept of a secondary ledger and SLA provides full support to manage multiple representations of the same transaction data. This is achieved by the introduction of a new “C”:

  • Chart of Accounts;
  • Currency;
  • Calendar; and now
  • Convention (Accounting Convention).

If you need a different Accounting Convention, you need to enable a secondary ledger. You can then use SLA to create accounting treatments for the secondary ledger.

For example, to enable local vs international revenue recognition, you can use SLA to recognise revenue in the primary ledger but post to deferred revenue in the secondary ledger based on the same transaction. When you view the accounting from the sub ledger you will be able to see both treatments.

I hope this gives you the sense that there are distinct advantages to be gained from upgrading to R12.1.3+. In the next article, I’ll review some of the other new features, including Services Procurement, and Project Management.