Types of Reports

These are the various types of reports available in oracle applications. According to the client requirement we can use them:

Objects:

            We have mainly two types of objects

1.      Custom Objects:

           Developing  a new objects as per business requirements called as custom objects

 Eg: Developing a Reports, Forms etc…

2.      Customization of Objects:

           Modifying the existing objects as per client requirements called as customization objects

Eg: Modifying Reports, Forms, Workflow etc…

Reports:

            A production reporting tool to dynamically retrieve, format and distribute database information.

Reports are of three types they are

1.      .rdf  Reports

2.      Pl/Sql Reports

3.      SQL*Plus Reports

Question: When to use RDF, when to use PL/SQL procedure and when to use SQL*Plus ?

RDF Reports:

            If we have more than one group in the document then we can go to RDF Report method.

PL/SQL Reports:

            If we have only group it is better to do in PL/SQL procedure because it makes the query easy, Database will work fast etc.. If we have more than one group then we can go for pl/sql but it will take more time we can go for pl/sql but it will take more time to generate the output. So, it’s better to go for RDF method only.

SQL*Plus Reports:

            SQL*Plus is a formatting reporting tool which will convert SQL query output into formatted output as per client requirement we should use SQL*Plus commands for developing.


Note:

·         If client required fully formatted output we go for the RDF report

·         If client required plain output then we go for PL/SQL output

·         If client requires plain data with same format then we go for sql*plus.

R12 Decision To Re-implement or Upgrade

R12 Decision To Re-implement or Upgrade

The information below offers best practices and advice to customers currently in 11.5.X who are not able to take decision to upgrade or re-Implement and who are in dilemma. After going through these details they can understand the benefits, pro and cons and decide either to upgrade or re-implement based on the business goals and requirements.

R12 is the latest and most advanced version of the E-Business Suite running on Fusion Middleware. Many of the technology components and new features in R12 will carry over to the Fusion Applications. For customers running earlier release of 11i, upgrading/Re-implementation to R12 will allow you to move to the Fusion Architecture in an incremental manner. Here are a few things to consider for R12

If you are moving from an existing release of Oracle E-Business Suite to Release 12, you should consider whether to perform a standard upgrade versus a reimplementation.

Let us understand the definition of Re-implementation and Upgrade.

Re-Implementation: If the legacy system from which you migrate your historical data is an earlier release of the E-Business Suite (i.e. Treat Current System as Legacy System) then your fresh implementation may be described as a “reimplementation”.
-Setup applications.
-Migrate data
-Migrate customizations
-Go live with small data
-Phased conversion of remaining data

Upgrade: Use of a process or Oracle Tool kit to ‘convert’ data from current Oracle Applications release to R12.
- Supported tools, utilities, and documentation used
- Entire data and application available after upgrade
- Clear, straightforward, proven method




Source: My Oracle Support
Note: Extended Support for Release 11i10 requires the minimum baseline patches defined in My Oracle Support Document 883202.1(Minimum Baseline Patch Requirements for Extended Support on Oracle E-Business Suite 11.5.10).


EBS Release Road Map:



S ource:oracle open world/stevenChan


Release 12, which became available in January 2007, included major architectural improvements to the Financials products to support global and shared service operations, improve operational efficiencies, and reduce risk. It also incorporated the latest revisions to Oracle’s middleware and database technologies.

Release 12.1, which became available in May 2009, rounds out Release 12 with significant enhancements to the other product areas, including Procurement, Supply Chain Management, Human Capital Management, Customer Relationship Management and Master Data Management. It also contains usability improvements and centralized life cycle management.

There are few customers who are still in dilemma and not able to decide to go with Upgrade or re-Implementation but few customer based on the business goals and requirements have decided In favor of re-implementation and few in favor of upgrade

Gartner, the IT research and advisory firm, published research in February 2009 that advised caution and careful planning for the 11i to R12 transition. They found some customers experienced problems due to the architectural changes in the Financials, both with the end state software and with the transitional upgrade process. The paper recognizes that customers may use reimplementation as an opportunity to make fundamental changes to the configuration setups. “In a reimplementation, the user wants to leverage the new global financials functionality and may therefore revisit the whole conceptual design of their financials implementation.”

R12 has several important new capabilities, but this doesn't mean all customers should start planning an upgrade/Re-implement now. Existing customers should use the decision Criteria parameters to plan when they should consider moving to R12.

Decision Criteria:
- Current Oracle EBS Version.
- Oracle Skills
- Geographic’s Focus
- Legal Compliance and Market Force
- Implementation Scope
- Customizations
- Fusion Middle ware
- Risk Aversion
: Source: Gartner

Why should Companies move to R12:

- Stay in Oracle Support to eliminate the de-support risk since older versions of Oracle EBS applications are not supported by Oracle Suppoort.
- Obtain better support when patches currently.
- Take advantage of Tech Stack improvements.
- Change in business directions.
- New Features and functionalities to assist business
- Replicate customization with oracle standard features and retire RICE components
Get Ready for Fusion.

Driving Factors:
- IT Drivers: Supportability, Stability, Improved performance, New Features, Reduce , maintenance cost, Out of box use, Retire Customizations.

- Business Drivers: New modules, New features and functionality, New requirements, Operational efficiency, Design improvements, Opportunity to re-engineer,More business-handling Capabilities.

Upgrade vs Reimplementation:

Before suggesting any approach or its pros and cons we should understand the requirments, Issues and business goals by raising few questions like.

1. What are the issue in the current 11i Version.
2. What is the scope of the resounces availability
3. What are the key reasons to go to R12.
4. What is the budget.
5. What is the scope of the Project (any new additions to the business , any additions to the existing modules).

In upgrade if there are more number of customizations then it will take more time, oracle provided scripts for the entire standard /seeded components, the customization requires careful planning and development effort for non standard components. In Re-Implementation , taking the advantage of new features and functionalities customer have the opportunity to improve upon the existing components either by eliminating or retiring few of the RICE components.

Upgrade:

Pros:
- Least Expense option
- Less Implementation time with low customization
- Shared services will work as prescribed
- No Major Process changes
- No changes to COA, Currency, Calendar
- No major Business/organizational restructuring
- No Data conversion.
- Small team compared to re-Implementation.

Cons:
-User Interface overhaul will change to look and feel of the application.
-Limited ability to change configuration.
-Certain Modules have significant modifications and enhancements
-Critical upgrade issues require oracle support for fix/solution.
- Reporting tools have been impacted hence Technical/Development cost will increase.
- Have to leave with existing Issues.
- Continue use of Tax code.
- May not be able to use the new tax accounting and compliance model (EBtax).

Re-Implementation:

Pros:
1. Reconfigure of existing Process hence opportunity to correct mistakes and optimize process.
2. Opportunity to cleanup existing bad data.
3. Opportunity to change configuration may improve data quality and optimize process.
4. Opportunity to use new features and functionalities there by reduces issues.
5. Avoid catch-up Patching.
6. Opportunity to eliminate /retire RICE componets by using addded features and functionalites and centralized architecture .

Cons:
1. Implementation Time will be high.
2. Expensive cost option (Training/Development/Resource/tesingetc)
3. Configuration time willl be high
4. Data convertion would be required.
5. Big team size compared to Upgrade.
6. Most complicated and Resource intensive option.