11i to R12 Decision: Upgrade or Reimplement

 

Most organizations will upgrade if possible, since that is the easiest path for enterprise software product upgrades. However, there are a number of factors, including the new Financials architecture and concerns about product quality, that have led many to decide to reimplement or to delay. With the introduction of eprentise software, you can eliminate obsolete fundamental setup configurations and multiple instances as reasons that lead organizations to select reimplementation. If you like what R12 offers and you want to save time, money, and resources on the transition, you can combine eprentise Transformation software with Oracle® upgrade to upgrade EBS 11i instances to a single global instance of R12.

The transition from 11i to R12 is a high-stakes major initiative for any E-Business Suite (EBS) customer. We have observed that companies plan the transition for approximately a year, then set budgets, line up resources, and do the work over one to two years. Projects may cost in the range of several million dollars to tens of millions and are often proportional to the size and complexity of the business. We believe E-Business Suite 11i customers can upgrade instead of reimplement, shorten the time-to-value at a lower cost, and provide a better R12 result for both the Business and IT. Why reimplement?

As customers look at whether they should reimplement or upgrade, these are some of the decision points that they are considering.

Oracle E-Business Suite (EBS) R12 is a significant new version with valuable new features and capabilities. Most people currently think some customers are forced to reimplement in order to take advantage of R12, but that other customers may be lucky enough to reap the new release benefits via Oracle’s upgrade process. EBS customers with brand new implementations are not impacted by the transition complexities.
Most EBS customers upgrade if given a choice because that is the path of least resistance. Compared to reimplementation, it is simpler, uses fewer resources, will likely cost less, and the time-to-value is shorter. We observe that software vendors usually make upgrades easier than starting from scratch, if they know how and can do so at an acceptable cost. If not, individual customers shoulder the reimplementation burden.
We also observe that some customers’ business users and IT staff have been frustrated with their current EBS implementation and its restrictions. They accept the requirement to reimplement as an opportunity to break with the past and get a clean start with Oracle. Because it’s perceived as a requirement, they have an easier time justifying the additional expense, effort, and delay of putting R12 into production.
Nevertheless, reimplementation drains the business’s resources more than a typical major release EBS upgrade.

Your organization’s Oracle specialists, consulting firms, and industry analysts should look at the current situation and re-think why they accepted that the new architecture required you to start over and reimplement.
Your E-Business Suite 11i environment may have conditions that seem to require Customer reimplementation plus data migration. An Oracle document, R12: Upgrade vs. Reimplement (Financials) clearly defines the terms and introduces some of the key factors. Our Decision Factors – 11i to R12 table below lists the conditions, including ones that are strong indicators for reimplementation, according to Oracle.
Here are some reimplementation consequences in the areas of implementation, data history, disposition of the 11i instance, reporting, and business intelligence:
You have to implement a fresh installation of R12.
You are on your own to get your historical data from the legacy 11i instance into R12.
You have to decide what history to load and what to do with the remainder. You will need a policy for each different type of data. The usual choices include most recent and current fiscal year, current year, and only open transactions.
Even though data conversion tools these days are powerful, and programmers in the global data centers are inexpensive, dealing with data history will be a significant part of your reimplementation project. It will cost money and require several iterations to get it right.
You will keep the 11i instance in “legacy” mode. Some call this a “sunset” instance. It must be frozen and restricted to read-only access.
You will devise reporting mechanisms to span the legacy 11i and operational R12 instances. That includes translations, reconciliations, mappings, and external reporting environments.
If you have a business intelligence environment or data warehouse, you will make changes to incorporate the frozen legacy 11i and operational R12 environments.
Oracle’s description of R12 reimplementation comments on configuration setups and data migration:
There is “greater flexibility in your setup and in how you migrate your historical data using supported public interfaces.”
“Flexibility” here means you have another opportunity to make major IT decisions to live with for a long time. This is an advantage if you are not satisfied with your 11i setups. If you upgrade, Oracle provides no such opportunity for change within R12.
There is little to gain from custom historical data migration across the numerous EBS tables compared to the controlled historical data migration performed by Oracle’s upgrade process.
Oracle’s description concedes that reimplementation is more difficult, complex, and resource intensive compared to an upgrade.
“It is a project that you would generally undertake with the support of a professional services provider, such as Oracle Consulting.”
You now have a choice. Despite the conditions that apparently require reimplementation, consider eprentise Transformation software plus Oracle upgrade:
Use eprentise software to:

Transform the fundamental setups of your 11i instance(s) to eliminate the reimplementation conditions.
Adjust or re-do any unsatisfactory setups.
Transform the 11i data to reflect the removal of reimplementation conditions and new setups.
Consolidate 11i instances as required so there is only one instance to upgrade.
Run the Oracle upgrade.

With this R12 transition approach, you retain more of your investment in the 11i instance. You also take advantage of Oracle’s upgrade software, for which you pay as part of Oracle Support.

The result is an R12 instance with all the desired target characteristics and all the historical data. All the transactions in all subledgers reflect the new setup parameters.
You have the same opportunity to change setups (flexibility) to define the target R12 instance as you would have if you were to reimplement.
You can choose to bring all historical data or select subsets from 11i.
eprentise Transform plus Oracle upgrade is cheaper, faster, and better than Customer reimplementation plus data migration.
You will likely reduce the consulting services required.
You may be able to launch R12 and start capturing the business benefits from 1 to 2 quarters earlier.
We need to know more about your situation before we can talk about transition cost savings.
We understand that if your organization has already made a decision and you have started the reimplementation project, you may be reluctant for your people “to get distracted” by a new idea, even if there could be potential material savings or faster time-to-value. Would it be distracting to look for several hundred thousands of dollars savings?
One way to discover if eprentise plus upgrade would be better for your organization is to invest about six person days of your R12 program management team and IT financial analysts’ time with us. They may already have analyzed R12, collected your business users’ requirements, and inventoried what needs to change from 11i to R12. What is the state of their reimplementation estimates for resources, costs, and schedule? The more detailed, the better.
Within two weeks, we can deliver a preliminary proposal of how you could use eprentise Transformation software to upgrade to R12, how long it would take, and what it would cost.

Conclusion
It is important to keep the upgrade vs. reimplementation discussion in the context of the overall transition to R12. First understand what the R12 target needs to be. Compare that to the 11i instance(s). Itemize and inventory everything that needs to change. Then consider how you would make each change via upgrade (with eprentise Transformation software plus Oracle upgrade), and via reimplement (implement it and migrate your historical data). A parallel analysis considers everything in the 11i instance(s) that does not need to change on the path to R12. What do you not need to touch if you upgrade? What do you need to replicate anew if you Reimplement? What extra historical data that is supposed to be unchanged must be managed and migrated if you reimplement? There will be other project components impacted by the 11i to R12 transition, virtually everything that touches the E-Business Suite. Some are mostly independent of the upgrade vs. reimplementation decision, such as reports and interfaces. Another set of items will be dependent, such as what happens in the Business Intelligence environment.

When planning the transition to R12, focus on the components that are dependent on the specific transition methods. Cost/benefit and resource expenditure analyses will assist in your transition planning, specifically aiding you in deciding which method will be best for your organization’s adoption of R12 and the new features that come along with it.

Purchasing Setup of Approval Hierarchies in Oracle R12

R12 Financial Setups in Payables

Setup>Options>Financials

Overview:

Use the Financials Options window to define the options and defaults that you use for your Oracle Financial Applications. The values entered here are shared by Oracle Payables, Oracle Purchasing and Oracle Fixed Assets.

Accounting

The values entered here are used for accounting of payable transactions.

Future Periods: Payables uses this value to limit the number of future periods you can maintain in the Control Payables Periods window. This value comes from the GL Set of Books definition.

Liability Account: Payables assigns this account as the default Liability Account for all new suppliers you enter. You can override this value during supplier entry.

Prepayment Account: This account refers to Prepayment account. The Financials Option value defaults to new suppliers, and the supplier value defaults to new supplier sites.

Future Dated Payment Account: This account refers to future dated payment account. This value defaults to all new suppliers and new bank accounts. The supplier value defaults to all new supplier sites.

Discount Taken Account: This account refers to discount taken account.

PO Rate Variance Gain/Loss: Payables uses these accounts to record the exchange rate variance gains/losses for your inventory items. Any exchange rate variance for your expense items is recorded to the charge account of the purchase order.

Expenses Clearing Account: Payables uses this as a temporary account to record information about credit card transactions imported from Self-Service Expenses using the Invoice Import program.

Supplier Entry

This region is used to control supplier entry and PO matching.

RFQ Only Site: The value entered here will default to all new supplier sites created in the system. You cannot create purchase orders in Purchasing for a supplier site, if this flag is enabled.

Hold Unmatched Invoices: If you enable this option for a supplier site, Payables applies a Matching Required hold to an invoice if it has Item type distributions that are not matched to either a purchase order or receipt. Payables applies the hold during Validation. The value entered here will default to all the new suppliers created in the system.

Invoice Match Option: This option indicates how you want to match the invoices. The value entered here will default to the new suppliers created in the system.

• Purchase Order: Match invoices to purchase orders.
• Receipts: Match invoices to purchase order receipts.

Supplier Number Entry: This option specifies if supplier number will be manually entered or automatically generated by the system.

• Automatic: The system automatically assigns a unique sequential number to each supplier when you enter a new supplier.
• Manual: You enter the supplier number when you enter a supplier.

Supplier Number Type: Type of supplier number you want Payables to use for supplier number entry. If you choose automatic as supplier number entry, then supplier number type should always be Numeric.

• Alphanumeric: Numbers, characters, or a combination.
• Numeric: Numbers only.

Next Automatic Number: If you select the Automatic Supplier Number Entry method, enter the starting value you want the system to use for generating unique sequential supplier numbers. After you enter a number and save your changes, the system displays the number that it will assign to the next new supplier you enter.

Supplier Payables

The values entered in this region will default to new suppliers being defined.

Payment Terms: Payables uses payment terms to automatically calculate due dates, discount dates, and discount amounts for each invoice you enter. The value entered here will default to all the new supplier entered in the system.

Payment Method: Payment method refers to method of payment. The value entered here will default to all the new suppliers entered in the system.

• Check
• Clearing
• Electronic
• Wire

Receipt Acceptance Days: If you create interest invoices for late payment, enter the number of days in your receipt acceptance period. If you enable the Recalculate Scheduled Payment Payables option, Validation recalculates your invoice due date based on this value.

Always Take Discount: Enable this option to have Payables always take an available discount for a supplier, regardless of when you pay the invoice. The values entered here will default to all the new supplier created in the system.

Pay Alone: If an invoice has the Pay Alone option enabled, Payables creates a separate payment for each invoice. If the Pay Alone option is not enabled for an invoice, the invoice will be paid with other invoices for the same supplier site on a single payment. The value entered here will default to all the new suppliers created in the system.

Supplier Purchasing

The values entered here will default to the Purchasing region of the Suppliers window. The supplier values default to new supplier sites for the supplier, which default to new purchasing documents for the supplier site.

For reference of the fields, please refer Process 2.1.1 Supplier Header Definition, Purchasing Region section.

Encumbrance

This region is used to enable encumbrance accounting and to specify the default encumbrance types.

Use Requisition Encumbrance: Enable this option to encumber funds for requisitions. If you enable this option, Purchasing creates journal entries and transfers them to General Ledger to encumber funds for purchase requisitions.

Encumbrance Type: If you enable Use Requisition Encumbrance, you must select an encumbrance type by which you can identify your requisition encumbrance journal entries. Purchasing assigns this encumbrance type to the encumbrance journal entries it creates for purchase requisitions.

Reserve at Completion: If you enable Use Requisition Encumbrance, indicate whether you want requisition preparers to have the option to reserve funds. If you do not enable this option, only requisition approvers will have the option to reserve funds.

Use PO Encumbrance: Enable this option to encumber funds for purchase orders, purchase order and receipt matched invoices, and basic invoices (not matched). If you enable this option, Purchasing encumbers funds for purchase orders and Payables encumbers funds for variances during Validation for purchase order and receipt matched invoices. If you enable this option and enter a non-purchase order matched invoice, Payables will encumber funds for it during Validation. All Payables encumbrances are reversed when you create accounting entries. If you enable Use Requisition Encumbrance, you must also enable this option.

PO Encumbrance Type: If you enable Use Purchase Order Encumbrance, select a purchase order encumbrance type by which you can identify your purchase order encumbrance journal entries. Purchasing assigns this encumbrance type to the encumbrance journal entries it creates for purchase requisitions and purchase orders.

Invoice Encumbrance Type: If you use purchase order encumbrance, select an invoice encumbrance type by which you can identify your invoice encumbrance journal entries. Payables assigns this encumbrance type to the encumbrance journal entries that it creates when Validation approves an unmatched invoice or an invoice matched to a purchase order or receipt for which there is a variance. We recommend that you use an encumbrance type different from the Purchasing encumbrance type so you can identify invoice encumbrances.

Tax

This region is used to default tax code to suppliers and define the rounding rule for tax amounts.

Default Tax Code: The value entered in this field will default to all new suppliers defined in the system.

VAT Registration Number: The field refers to Value Added Tax (VAT) registration number for your organization.

Default Recovery Rate: If you want to specify a rate that will default to tax recovery rules and tax codes you define, then enter the rate.

Calculation Rules: Used to determine the rounding rule and precision of tax amounts.

Human Resources

This region is used for the options and defaults for entering employee information in the Enter Person window.

Business Group: Enter the name of the business group that you want to associate with Purchasing.

Expense Reimbursement Address: Select the default address you want to use on payments for employee expense reports: Home or Office. The system uses this default for each new employee you enter. You can override this default during employee entry or expense report entry.

Use Approval Hierarchies: Enable this option to use positions and position hierarchies to determine approval paths for your documents within Purchasing.

Employee Number Method: You can enter your employee numbers manually or let the system generate sequential employee numbers.

• Automatic: The system automatically assigns a unique sequential number to each employee when you enter a new employee.
• Manual: You enter the employee number when you enter an employee.
• Use National Identifier Number: The system automatically enters the employee’s National Identifier Number as the employee number. For example, a Social Security number for a United States employee.

Next Automatic Number: If you select the Automatic Employee Numbering method, enter the starting value you want the system to use for generating unique sequential employee numbers.

Create an Inventory Organization in R12 PO

 

Create an Inventory Organization

Responsibility = Purchasing, Vision Operations

1. Navigate to the Organizations window:

• (N) Setup > Organizations > Organizations

2. (B) New

• Name = XXManufacturing
• Type = Plant
• Enter a date in the From field early enough for any historical information that you need to enter. (The default is the current date.)
• To Date = Leave Blank
• Location = XXManufacturing

3. Save

Note: Multiple inventory organizations can share the same physical location if the Inventory Organization field associated with the Location was left blank (as in the prior exercise!).

4. For the Name field in the Organization Classifications region, use the list of values to select Inventory Organization.

5. Select the Enabled check box (use the mouse or the space bar).

6. Save

7. (B) Others

8. In the Additional Organization Information window, select Accounting Information.

9. OK, then click in the Accounting Information field.

• Primary Ledger = Vision Operations
• Legal Entity = Vision Operations
• Operating Unit = Vision Operations.

10. OK

11. OK

12. (B) Yes to save changes.

13. Close the Organization Parameters window but do NOT close the Organization window.

Assign the Organization to an Existing Item Master

14. Re-open the Organization Parameters window:

• (B) Others

15. In the Additional Organization Information window, select Inventory Information.

16. (T) Inventory Parameters

• Organization Code = XXM
• Item Master Organization = Vision Operations
• Calendar = Vision01
• Demand Class = West US

17. (T) Costing Information

Account Type	Account
Material	01-000-1410-0000-000
Outside Processing	01-000-1450-0000-000
Material Overhead	01-000-1420-0000-000
Overhead	01-000-1430-0000-000
Resource	Leave field blank
Expense	Leave field blank

18. (T) Other Accounts

Account Type	Account
Purchase Price Variance	01-540-5210-0000-000
Invoice Price Variance	01-540-5220-0000-000
Inventory AP Accrual	01-000-2215-0000-000
Sales	01-540-4160-0000-000
Cost of Goods Sold	01-540-5200-0000-000
Deferred COGS Account	01-540-5200-0000-000

19. (I) Save

(Enter 1 for Starting Serial Number and click OK when the pop-up note concerning Organizational Costing Methods appears.)

Note: A huge difference between a Location and an Inventory Organization is that Inventory Organizations determine a lot of accounting that gets sent to the General Ledger! For Purchasing, we are mainly concerned about Purchase Price Variance, Invoice Price Variance and Inventory AP Accrual accounts.

20. Close the Organization Parameters window but do NOT close the Organization window.

Specify Receiving Information

21. Re-open the Organization Parameters window:

• (B) Others

22. In the Additional Organization Information window, select Receiving Information.

• Days Early = 5
• Days Late = 5
• Receipt Days Exceed-Action = Warning
• Tolerance = 5%
• Over Receipt Action = Warning
• Receipt Routing = Standard
• Allow Unordered Receipts = Checked
• Allow Express Transactions = Checked
• Allow Cascade Transactions = Checked
• Next Receipt Number = 1000
• Receiving Inventory Account = 01-000-1410-0000-000
• Clearing Account = 01-000-2929-0000-000

23. (B) Save and exit window.