Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Sathish
1/1/2009
www.projectsaccounting.com
In this article I will be explaining the general steps involved in any Conversion/Data Migration
of Oracle Projects module.
Scenario:
Company 'XYZ' is using a Project Management and Accounting Software for years long. The
Management has decided to move from their existing system to Oracle Projects module because
of its vast functionality and integration with Other financial modules.
Now the question arises: What data to migrate from the legacy system to Oracle Projects?.
Well, it depends upon the type 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.
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.
Once the decision is made to which data to migrate, then the next step would be setting up the
Oracle Projects for the 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.
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 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.
www.projectsaccounting.com
3. The Third Stage is uploading the data obtained from legacy systems into the Staging
Area(Staging Tables created to hold 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.
The Second Stage and Third Stages are repetitive until you get the Valid data from the
legacy system which can be migrated into Oracle Projects without any errors or issues.
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.
Before going through the stages, we will look at some of the basic setups that needs to be
done in Oracle Projects.
Product Code:
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.
If you are migrating Cost and Revenue Budgets, then the Plan Types need to be
attached to the templates in order to create the budgets for the migrated projects.
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 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'.
You can setup job rate schedule, employee level rate schedule or employee level
overrides. Alternatively, the costing 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.
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 recommended since comma
separated files behave strange when there is a comma in the data itself.
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 preferred as it is more
performance intensive when it comes to selecting large data over the network.
www.projectsaccounting.com
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:
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
www.projectsaccounting.com
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.
Validate if 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:
www.projectsaccounting.com
Data Validations:
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 system's 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.
Data Validations:
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 the funding amounts.
Records which fail the above validations have to be rectified before doing the actual migration.
Data Validations:
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 Invoice's 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.
www.projectsaccounting.com
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 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
www.projectsaccounting.com
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.
Conclusion:
I hope this article would have provided you an insight of Oracle Projects Data Migration.
For more information or if you need any other information related to Projects migration, you are
welcome to create a topic in my forum http://www.projectsaccounting.com/projects-forum.html .