, , , ,

R12 Upgrade Vs Re-implement

When a company is planning to adopt R12 from previous versions, the first question arises is whether to Upgrade or Re-implement?

First let us see what is the difference between an upgrade and re-implement.

An R12 upgrade involves running the scripts on a database to transform it into R12 structure. During the upgrade all the data will be moved to the respective  tables in R12.

A re-implementation involves creating a completely new oracle applications installation, doing all the set-ups from scratch and moving the data using data conversions to the new R12 database.

Let us see the advantages and disadvantages of an upgrade and re-implement

Upgrade:

The major advantages of an upgrade process are:

1. The upgrade process has become easy as the technology, tools and the upgrade scripts are significantly improved
2. There will be no effort of data conversions and testing, as the data will be moved during the upgrade process
3. Not many customizations are needed
4. No changes in the functional setups
5. Upgrade is often cheaper as it involves significantly less work for setting up the applications

But an upgrade process requires very significant effort technically and is more challenging. In comparison with re-implementation process an upgrade is risky in technical perspective.

Re-implement:

The main advantage with Re-implementation process is that the technical risk is low when compared with an upgrade.

Disadvantages:

1. Re-implementation process is very extensive as the data conversions and testing is involved.
2. Lot of effort is needed for application configuration.

Organizations generally go for following considerations before going for the re-implementation.

1. There are major changes in the Organization structure or business processes, and the existing application configuration doesn’t fit for the business
2. There are lot of customizations that can be avoided with the new features and functionality
3. The original implementation has disturbed and unusable.
4. There is lot of bad data exists.

, , , , , , , ,

Period-End Process

Period-End process is performed at the end of each period(depends on the organization). It is very important in any organization because if the period is not closed, the accounting for that period can not be closed, which will affect the financial results reporting of the respective period.
One can not close any module without following the order.

The suggested module wise sequence to be followed for Period-End process is as follows.

1. Projects
2. Payables
3. Purchasing
4. Assets 
5. Receivables
6. Inventory
7. General Ledger

, , , ,

Collection Element ‘REV’ has no LOV in R12 Oracle Quality

In Oracle Quality module, the Quality Element ‘Revision’ on Enter Quality Results window has no list of values after R12 upgrade, where it was available in 11i. The users who want to capture the ‘Revision’ for an item on quality plans have no option to select the list of values for Revision. 
According to Oracle, this is expected functionality in R12. The Item revision collection element would be enabled and editable only for a Revision controlled Item. 
The behavior in 11.5.10 was a bug because of which even though the revision field was grayed out, the user could still enter Revision values by invoking the LOV. This was fixed in R12.
The following are the three possible options available to resolve the issue:

Srl# Option Remarks
1 Activate “Revision Control Code” for the items in question:
All items for which Revision needs to be captured in the Quality Collection Plan’s results, using an LOV, we need to active the Revision Control code for the items in inventory.
The drawback of this option is that all material transactions would mandate the entry of Revision of the item, which makes it very cumbersome for the Inventory and other modules’ users.
Hence, may not be a viable option
2 Go with the new functionality suggested by Oracle This also may not be a good option if users need to capture the Revision of items on QC plans
3 Creation of a new Quality Collection Element that has the capability of accepting Revision of items;
In this option, the “Revision Control” code for items need not be activated.
This workaround would enable the users to capture Revision of items during the entry of Quality Results.
This option is explained in detail in the subsequent section.
  

Solution for Option 3: Create new collection Element

  1. Create a new collection element with SQL Validation statement to populate the LOV. The following screen shot show the details of the new custom collection element to be created
     Navigation:  Quality Setup Collection Elements

The “select” statement to fetch the item’s revisions within the LOV is as under: 
  
2.   Identify all the QA Plans that use the standard / seeded QA element “Revision” for all the inventory organizations 
3.   Add the new custom QA element to all the QA Plans (stored in the table QA_PLAN_CHARS) identified in step 2. This could be programmatically done using an open API

4.  Using standard APIs, copy the existing data present in the “Revision” column of QA_RESULTS table into the column of newly added “custom revision” of the same table. Once the change is activated, the data captured under the new “custom revision” column would be stored in one of the custom (user-defined) columns titled CHARACTER1 through CHARACTER100. 

 
5.   Finally, once the copying of the Revision data is completed into the QA_RESULTS table (via Oracle APIs), nullify the data in “Revision” column
 
6.   Modification of Reports: All reports (Oracle Reports / SQL / Discoverer based) that were referring to “Revision” column should now be referring to the custom / user-defined columns defined for the new “custom revision” QA collection element.