Steps for Conversion of Oracle Projects Data into Oracle EBS | Oracle...

February 14, 2014 //

http://ebscircle.com/steps-for-conversion-of-oracle-projects-data-into-...

0 Comments

Search
In this article, you will be knowing the general steps involved in any Conversion/Data Migration of Oracle Projects module.
Stages in Oracle Projects Conversion
How to setup the Oracle Projects module for the conversion/Data Migration
Options for the Load (Flat file, csv, or Direct Load)
Oracle Projects AMG APIs needed to perform the Data Conversion
Testing the Conversion Process

AGIS (1)

Verifying the Conversion Process

How to deal with it ?

Alerts (1)
AOL (7)

Now the question arises: What data to migrate from the legacy system to Oracle Projects?. Well, it depends upon the type
Concurrent Program (3)

of projects.
If the Projects are used for Internal Administration and tracking of costs, you may want to migrate the existing projects, tasks(the
work break down structure), Cost Budgets, Cost (Timecards, Employee Expenses, Miscellaneous Expenses) etc.

Discoverer (3)
FAQs (1)

If the Projects are used for billing the Clients for the work done (Typical Contract Projects), then you may want to Revenue,
Agreements(Contracts), Revenue budgets and Invoices in addition to the above data.

Flexfields (1)

Once the decision is made to which data to migrate, then the next step would be setting up the Oracle Projects for the

FNDLOAD (1)

conversion purpose, which we will see in detail sooner. Once the System has been setup, the technical elements(programs,
concurrent processes etc) have to be created in order to migrate the data from Legacy System to Oracle Projects.
Stages in Oracle Projects Conversion:

Forms (31)
Forms FAQs (2)
General (2)

1. The First Stage is to obtain the data from the Legacy System which needs to be migrated to Oracle Projects.
2. The Second Stage will be most crucial step in the process which is to massage the data according to the Oracle Projects

General Ledger (3)

Conversion Interface(Programs built using AMG APIs). This Step is indeed time consuming, manual labor intensive to massage
and rectify the errors etc. But completing this step successfully pays dividends in the consecutive processes / Stages.

iExpenses (5)

3. The Third Stage is uploading the data obtained from legacy systems into the Staging Area(Staging Tables created to hold

Messages (1)

the data temporarily till it gets migrated into Oracle Projects). Once the data is uploaded to the Staging tables, the programs
built for migration(We will see how to build these programs in detail) will validate the Staging Table data to confirm that it is in
compliance with the Projects Conversion Program( The AMG APIs used in the programs indeed needs data in certain format,
also the data should be validated against the Oracle Projects Setup. For instance, when migrating the cost or hours from legacy
to Projects, we might need to validate if the expenditure type is already setup in Oracle Projects, if the expenditure type is not
setup, the program/APIs will throw an error. So it is always better to capture these kind of scenarios in the Validation Step of the
Migration.
4. The Fourth Stage is the actual migration process which will migrate the data from the Staging Tables to the Oracle Projects
Base tables. Once this step is done, the projects, tasks and other data are available in Oracle Projects for use.

OA Framework (6)
OA Framework FAQs (1)
OBIEE (1)
Oracle BoM (3)
Oracle Inventory (6)

Before going through the stages, we will look at some of the basic setups that needs to be done in Oracle Projects.
Oracle Order Management (9)
Oracle Projects Setup For Conversion
Oracle Projects (5)
Product Code:
Oracle Purchasing (4)
The Product Code needs to be setup in Oracle Projects in the AMG Gateway Source Products Form in the Oracle
Projects Implementation Super User Responsibility. This setup is mandatory since this product code needs to be
passed when using the Oracle Projects AMG APIs.
Project Types and Project Templates:
The project types and project templates for conversion projects need to be setup up. This is a mandatory setup since

Oracle SCM (1)

Oracle Workflow (5)
Order Management FAQs (1)
Payables (1)

while migrating projects we need to tell the APIs which project template/type the projects use.
For Contract Projects, setup the Contract Project Type Template. For administrative or internal projects, setup the
Indirect Project Type templates.
If you are migrating Cost and Revenue Budgets, then the Plan Types need to be attached to the templates in order

Profile Options (1)

Purchasing FAQs (1)
R12 (11)

to create the budgets for the migrated projects.

Implementation Option Setup:

1 of 5

Receivables (7)

23/05/2015 11:59 PM

Steps for Conversion of Oracle Projects Data into Oracle EBS | Oracle...

http://ebscircle.com/steps-for-conversion-of-oracle-projects-data-into-...

Project Numbering: This implementation option is by default set to Automatic which means when creating projects

Reports (16)

in Oracle Projects, the project number is automatically derived and users are not required to provide any project

SQL*Loader (2)

numbers. This option is best suitable when creating projects in Oracle Projects. But when migrating the projects from
the third party systems, there is an option to migrate the projects with the same project number as in the legacy
system. This is not mandatory but is recommended since it will be easy to refer back the projects in the source

SQL-PL/SQL (69)
System Administrator (1)

system using the project numbers.

In order to pass the project number to the Migration program, this implementation option needs to be setup to
Manual. Once the migration is done, this setup can be reverted back to Automatic.
Setup Transaction Source:

Technical SQL Queries (6)

Uncategorized (3)
UNIX (3)

The Transaction Source needs to be setup in Oracle Projects in the Transaction Sources form in Oracle Projects

Valuesets (1)

Implementation Super User Responsibility. This is a mandatory setup for the Costs/hours migration from the legacy
system to Oracle Projects. We need to tell the migration APIs what is the source system and how the data is

XML/BI Publisher (3)

handled when it is imported to Oracle Projects.

Setup Expenditure Types:
Expenditure Types are needed to categorize the cost/hours when it is imported to Oracle Projects. This is a
mandatory setup for Cost/hours migration. We need to tell the system which expenditure type the cost/hour belongs
to.

Form Personalizations in brief

Setup Employee Cost Rates:

Installing and setting up JDeveloper for OAF
Customization R12x
Setting up cost rates for employees is not mandatory. But if you need to cost the hours that are migrated in the
system, the labor cost distribution process in Oracle Projects do need the rates setup in order to calculate the costs.

The easiest way to get COA Segments and

description

But if you are migrating the costs directly from the legacy instead of hours then this step is not needed. But ideally
the cost rates are required in a general production scenario wherein the employees/contractors enter their

FAQs in Oracle Receivables

timecards.
You can setup job rate schedule, employee level rate schedule or employee level overrides. Alternatively, the costing

Right strategy of conversion (Data Migration)

of Invoices in Receivables

client extension can be setup to calculate the cost according to the business scenario.
*Refer to the Oracle Projects User Guide for how to setup the employee cost rates.
First Stage: Obtain Data from Legacy System

The first stage deals with obtaining the data from the legacy system in the desired format. The data can be obtained in the form
of flat text file or comma separated file csv, tab delimited file or file with any delimiters. Generally tab delimited files are

R12: You can make a payment run across

multiple OUs
New Features in Approving Expense Reports
in Oracle Internet Expenses (iExpenses) using
AME
Important iExpenses Tables and their usage

recommended since comma separated files behave strange when there is a comma in the data itself.
FAQs
If there is a database link created between the Source Legacy database and the Oracle Projects Database then the data can be
obtained directly using the select statements against the Source DB from within the Oracle Projects DB. But this method is not

SQL Functions

preferred as it is more performance intensive when it comes to selecting large data over the network.
For Projects Migration, generally 2 files are obtained. One file for Projects Data and the other file for Tasks Data.
For Transaction Migration, single file is enough with all the cost/hours data.
For Cost/Revenue Budget migration, single file is enough with all the Budgets Data.
Create SQL Loader concurrent program which will upload the obtained data into the Oracle Staging Tables.
Also it is always the best practice to create a control table in the Staging area, which will control the data migration. For example
your control table might look like the one below:
Parameter Type

Parameter

Parameter Value

Template
Template
Expenditure Type
Expenditure Type
Transaction
Product Code
Project
Project
Cost Budget
Revenue Budget

Contract
Indirect
Hours
Expenses
Transaction Source
Product code
Publish Workplan
Baseline Workplan
Baseline
Baseline

Contract_Template
Indirect_Template
Labor
Employee_Expense
Legacy1
LEGACY1
Yes
Yes
Yes
Yes

alter table AP/AR Netting APIs AutoInvoice Business Events

Cash Management Commands Contra Charging Create
Accounting Create Accounting Customer DCL Commands
Delete statement Deploy OAF Page DML commands DROP
Database FNDLOAD Late Charges OBIEE OM Payables

Period-end process Period Close

Query for getting Profile Options

R12

Documentation RDBMS select database

R12

SQL

Constraints SQL Drop table SQL Group By SQL

Operators SQL Order by SQL Select SQL Sorting SQL
Syntax SQL Table creation SQL Table insert SQL Top SQL
Update SQL where clause Steps

Suppliers WFLOAD

Workflow

This control table is looked upon by the migration program. So whenever there is a change in the templates, expenditure types
it is easy to change this control table instead of the code. So the advise is never hard code any values in the code, always
handle it using the control table.
Also it will be better to have a form based on this table, so that this table data can be changed from the front end.
Second Stage & Third Stage: Validate and Format the Data

Iam coupling the second and third stage because both are interdependent. Validating data is very important and it prevents
some of the time consuming tasks in actual migration such as trouble shooting the errors due to the invalid data.
Below are some of the key validations that need to be done before doing the actual migration.
Projects/Tasks Migration:

Though the projects and tasks are in different staging tables, the migration of projects/tasks are doing using a single program.
We can always migrate projects and tasks separately, but the issue is with the performance when adding task by task to each
project. So it always better to create projects and tasks together because of the bulk loading of tasks.

2 of 5

23/05/2015 11:59 PM

Steps for Conversion of Oracle Projects Data into Oracle EBS | Oracle...

http://ebscircle.com/steps-for-conversion-of-oracle-projects-data-into-...

Project/Task Setup Validations:

Validate the Product code is setup.

Validate if the required Project Templates are setup.
Validate if the Project Numbering is set to Manual for creating projects with the predefined project numbers.
Project/Task Data Validations:

Validateif the project name is unique. Project with the same name should not exist in Oracle Projects.
Validate if the project number is unique. Project with the same number should not exist in Oracle Projects.
Validate if the project long name is unique. Project with the same long name should not exist in Oracle.
Validate the project reference(this field is mandatory in the projects file, it can be the projects identifier of the source project or
project number of the source project, but it has to be unique in the source system as well. This field needs to be populated in all
the converted projects in order to track back and identify the project in the source system)
Project name and project number should be 30 chars in length. Project long name should be 240 chars in length. Project
Description should be 250 chars in length. Project description is not a mandatory field when creating project.
Check if the project has a project manager and the project manager is active in Oracle HR and has an assignment and a Job
assigned. Also the project manager has to be active from the project start date, else you cannot create a project with that
project manager.
In case of contract projects, check if the customer of the project is a valid customer defined and with a valid Bill To site
assigned.
Check if the Tasks in the Task file has a project in the Projects file.
Apart from the above necessary validations, you may have to validate the additional data such as Projects DFF Data you may
want to populate with your custom field values. For example you may want to populate the Project cost center value in the
Segment1 of the Project DFF. In such case you have to validate if the cost center value is a valid value for that
Segment1(sometimes you may have attached an LOV to that segment1, so in that case, the cost center has to be validated
against that LOV Values).
For tasks, values for task types, work type, task manager has to be validated. Task types and work types have to be defined in
Oracle Projects before the task with those values are migrated, else the task will not be created.
Cost/hours validation

Setup Validations:

Validate if the Transaction source is setup.

Validate if the Expenditure type is setup.
Data Validations:

Check if the hours value is greater than zero.

Check if the employee number is valid in HR and is active on the timecard date.
If the transaction source is setup as costed, then the cost has provided while migrating the transactions. If the transaction
source is setup as accounted, then the code combination ids need to be provided when migrating transactions.
Apart from the above validations, you may want to validate the additional DFF segments that you are going to populate for that
expenditure item.
Budgets Validation

Setup Validations:

Validate the project template has the required financial plan type attached. Financial plans are the project management
versions of the Budget types in the Forms applications.
Budget amount has to be greater than zero.
There is no need to create revenue budgets if the Baseline funding without budget option is checked at the project or project
type level. Whenever the funding is created for the contract project and is baselined, the revenue budget is automatically
created and baselined. If that option is not checked, it is necessary that a revenue budget with the same amount as the funding
amount needs to be created and baselined in order to baseline the funding.
Data Validations:

The cost budget for the project can be from the source systems budgeting system. If there is no budgeting in the source
system, a cost budget with the total cost of the project can be created in Oracle Projects.
For revenue budgets, it has to be equal to the funding amount of the project. If there is no funding amount in the source system,
the sum of the revenue amount can be the funding amount and it is the revenue budget amount as well.
Agreements and Funding Validation

Data Validations:

Agreement type should be valid.

Agreement Amount should be greater than zero.
Hard Limits can be setup according to business rules. If the hard limits are setup for revenue and invoice then the revenue
and invoice has to be within the funding limits for that project.
Funding amount has to be within the Agreement amount.
If the funding at the top task level, then the Customer at top task has to be enabled and the customer should have been
assigned at the top task.
Funding amount should be same as the Revenue budget amount which in general will be same as the total revenue amount
for that project. If there are no hard limits then the revenue or invoice can exceed thefunding amounts.
Records which fail the above validations have to be rectified before doing the actual migration.

3 of 5

23/05/2015 11:59 PM

Steps for Conversion of Oracle Projects Data into Oracle EBS | Oracle...

http://ebscircle.com/steps-for-conversion-of-oracle-projects-data-into-...

Revenue and Invoice Validations:

Data Validations:

Project / Task should already been converted to Oracle.

Event amount should be non zero.
For revenue event revenue amount should be populated.
For invoice event invoice amount should be populated.
Generally for a project, the total revenue is obtained from the source system and is created as a revenue event for that project.
The total invoiced amount is calculated per project and an invoice event is created for each project.
Once these events are created successfully in the system, the Generate Draft Revenue process and Generate Draft Invoice
process needs to be run so that the desired revenue and invoices are generated.
The revenue and invoice automatic approval and release client extensions can be used to automatically release the revenue
when it is generated and approve/release invoices respectively.
If the revenue amounts are already interfaced to General Ledger(GL) through a different interface, then uncheck the Interface
Revenue to GL option in the implementation options and run the Interface Revenue to GL process in Oracle projects. This will
turn the flags in the revenue records as accepted in GL, though it is not interfaced. Once this is done, revert back the
implementation option back to its original state.
If the invoice amounts are already interfaced to Accounts Receivables(AR) by different means, it is not desired to interface the
projects invoices to AR again since it will double the invoice amount in AR. In this case, we do not have an implementation
option like we had for Revenue. So a script can be created to update the Invoices flag to Accepted State. Alternatively the
generated projects invoices can be interfaced to AR, tied back to Oracle and then the invoices can be deleted in AR.
Stage 4: Actual Migration

Once the data is validated, the program for conversion is executed to migrate the data into oracle projects base tables. There
might be still errors due to AMG APIs which has to analyzed and resolved. But the chances of such AMG API issues is just
below 10% in any migration(based on my experience in Oracle Projects Conversion).
Below is a table with Conversion and which AMG APIs are used for that conversion:
Conversion

AMG APIs

Projects/Tasks Conversion
Budgets Conversion

PA_PROJECT_PUB.CREATE_PROJECT
PA_BUDGET_PU B.CREATE_DRAFT_BUDGET,
PA_BUDGET_PUB.BASELINE_BUDGET
PA_AGREEMENT_PUB.CREATE_AGREEMENT
PA_AGREEMENT_PUB.ADD_FUNDING
PA_EVENT_PUB.CREATE_BILLING_EVENT
PA_PROJECT_PUB.LOAD_EXTENSIBLE_ATTRIBUTE

Agreements
Funding
Revenue/Invoice
User Defined Attributes (UDA)

For Transactions(cost/hours) migration, there is no APIs to create the expenditures in Oracle. The pa_transaction_interface_all
table needs to be populated with the migration data and once it is populated, the PRC:Transaction Import process with the
Transaction source as parameter needs to be run in Oracle Projects. All invalid records needto be rectified in order to migrate
all the transactions.
The rejected records can be found in the same interface table with the transfer_status_code as R.
Conversion Tips:

Make sure the templates are defined properly and exactly the way it is needed. Once the projects are created using the
templates and the template was wrongly defined, then it takes ages to rectify the converted projects.
Create the conversion program to operate in two modes: Validate, Run. A concurrent process with a parameter called mode
accepting Validate/Run can be created. So the same concurrent program can be used to validate as well as run the actual
migration.
It is a good practice to have source Project id / Project Number as parameter to the projects conversion program. This will
allow us to test the conversion for a single project and validate the data for that project.
The validation process can write the invalid records to the output file. So once validation process completes, the output will
have all the invalid records which needs to be rectified.
Create a separate concurrent program to know the status of the already running migration process. If you want to know where
the migration process is in terms of the number of records migrated, number of records rejected etc. If the volume of the
migration data is huge, then it is likely possible that the conversion programs may run for hours. So in this scenarios this
concurrent program can be helpful in finding the status of that migration process.
For Transactions migration, the custom program written to populate the interface table can kick off the PRC:Transaction
Import process and wait for its completion. Once the transaction import completes, the custom process can print the invalid
records from the interface table to the output file.
There are APIs to publish and baseline the workplans created as a part of projects migration. But these APIs need to be used
with care. There are lot of performance issues and bugs when using these APIs.
Tweet

4 of 5

Like

Share

Mailto

23/05/2015 11:59 PM

Steps for Conversion of Oracle Projects Data into Oracle EBS | Oracle...

0 Comments

http://ebscircle.com/steps-for-conversion-of-oracle-projects-data-into-...

Home

5 of 5

About us

Training

Contact Us

23/05/2015 11:59 PM