You are on page 1of 62

Oracle Projects Basics

In this Blog, I will be giving an introduction on what is Oracle Projects module in the Oracle Apps Ebiz Suite.
Oracle Projects is suite of modules which combines
Project Costing
Project Billing
Project Foundation
Project Management
Project Resource Management
and Project Portfolio Management
Oracle Projects is very useful for any Project Based Organizations. In today's world i can say all he organizations are
based on Projects for ease of maintenance and tracking.

What is Project Costing ?


To put it in a simpler manner, module to calculate the cost and account it. In any organization there should be an
application which keeps track of the costs of the projects and categorize the costs. I can say Project Costing is
similar to one of the applications, but not limited to calculating and accounting. I will explain in detail in the coming
posts, how cost is calculated and accounted in Oracle Projects Costing.
What is Project Billing ?
Lets take an example of Services Company. Any Services company has customers whom they serve and inturn bill
the clients for the service offered. In such scenarios Project Billing is handful in billing the customer. Not only that
you can calculate revenue for the projects, which is very important. In detail explanation will be in my future posts.
What is Project Foundation ? Project Foundation provides the basic infrastructure and components for the Costing
and Billing to work. So what it means ? For Costing and Billing to work we need basic infrastructure /components
like Projects, Tasks, WBS(Work Break Down Structure) etc, Cost Rate Schedules, Bill Rate Schedules. These
structures are created using Project Foundation APIs and hence the name 'Foundation'.
What is Project Management ?
Offcourse the name itself explains that it is to manage the projects. The functions involve Project Tracking,
Performance Tracking and other standard project management functions.
What is Project Resource Management ?
This is for manging the resources of the project. Functions involve assigning resources, moving resources
/deallocating resources, competency management , creation of vacancies, advertising the vacancies, evaluating the
skills of the resources etc.
For more info: see the Oracle Projects Fundamentals User guide

1. Draft Invoice Set Ups


This article gives a basic understanding of the Oracle Projects Invoice Flow:
Oracle Projects Invoice Flow:
Below are Steps that needs to be followed for successfully creating a Projects Invoice and interfacing it to Oracle
Receivables.
1. Creation of Contract Project (Mandatory)

2. Assign a Customer for the Project (Mandatory)


3. Create an Agreement with the Customer (Mandatory)
4. Fund the Project through the Customer Agreement (Mandatory)
5. Create an Approved Revenue Budget for the Project (optional).
6. Baseline the Funding (Mandatory).
7. Generate Draft Revenue (Optional).
8. Generate Draft Invoice (Mandatory).
9. Approve and Release the Draft Invoice (Mandatory).
10. Interface Draft Invoices to Oracle Receivables. (Mandatory)
11. Tieback invoices back to Oracle Projects. (Mandatory).

1. Creation of Contract Project:


Create a Project of 'Contract' Project Type. Only Contract Projects can be associated with a Customer. Create WBS
Structure for the Project. Identify the Project Manager. Assign Team members if needed.
Tech info:
Tables/Views involved:
PA_PROJECTS_ALL - Projects Table
PA_PROJECT_TYPES - Project Types Information
PA_TASKS - Tasks Associated with the Projects (WBS Information)
PA_PROJECT_PLAYERS - Contains the Key Member Assoications with the Project including the Project managers.

2. Assign a Customer for the Project:


Assign a Customer to the Project and the 'Bill to ' Address for the customer, so that the customer can be billed. Also
you can assign Billing and Shipping Contacts for the Customer in the Customers Options in the Projects Form.
Tech info:
Tables/Views involved:
PA_PROJECT_CUSTOMERS - Projects-Customers Association
3. Create an Agreement for the Customer:
A Funding Agreement needs to be created for the Customer with the Terms and the Agreement Amount. This can be
done using the Agreements Form.
Here you can specify the 'Hard Limts' . If the Hard Limit is set for Revenue, Revenue cannot be generated past the
funded amount for the project. Similarly if the Hard Limit is set for the invoice, the customer cannot be billed past
the funded amount in the agreement for that project.
Tech info:
Tables/Views involved:
PA_AGREEMENTS_ALL - Agreement Header Information.
4. Fund the Project through the Customer Agreement:
Fund the Project using the Customer agreement created in Step 4. This can be done using the Fundings Section in
the Agreement Form. If a customer agreement already exists for this customer, you can use the same agreement to
fund this project.
Tech info:
Tables/Views involved:

PA_SUMMARY_PROJECT_FUNDINGS - Project Funding Information.


5. Create an Approved Revenue Budget for the Project:
This Step is optional, if the 'Baseline Funding without Budget' option is set at the Project level. If this option is
not set, then an approved revenue budget for the project has to be created with the funding amount. Baselining this
budget, baselines the funding automatically.
Tech info:
Tables/Views involved:
PA_BUDGET_VERSIONS - Budget header info
PA_BUDGET_LINES : Budget Line level info
6. Baseline the Funding:
If 'Baseline Funding without Budget' is set then the funding can be baselined without the Approved Revenue
Budget. Oracle Projects creates an internal Approved Revenue Budget with the budget amount equal to the Funding
amount and baselines both the Budget and Funding.
7. Generate Draft Revenue:
This step is optional depending on the Distribution Rule for the invoice. If the invoice distribution rule is WORK, this
step is mandatory. The process "PRC: Generate Draft Revenue for a single Project" is run for the Project. If revenue
needs to be generated for multiple projects, run the "PRC: Generate Draft Revenue for range of Projects" process
giving the Project Number ranges.
Tech info:
Tables/Views involved:
PA_DRAFT_REVENUES_ALL - Revenue Header info
PA_DRAFT_REVENUE_ITEMS - Line level details.
PA_CUST_REV_DIST_LINES_ALL - Revenue distribution lines for the Expenditure items
PA_CUST_EVENT_RDL_ALL - Revenue distribution lines for the events
8. Generate Draft Invoice:
Run the Process "PRC:Generate Draft Invoice for a single Project", giving the Project number as parameter. This will
generate draft invoices only for that project. If you want to generate invoices for multiple projects, run "PRC:
Generate Draft Invoice for a range of Projects" giving the Project number ranges.
Tech info:
Tables/Views involved:
PA_DRAFT_INVOICES_ALL - Draft invoice header information
PA_DRAFT_INVOICE_ITEMS - Item level information
9. Approve and Release the Draft Invoice:
The invoices needs to be approved and released in order to interface them to AR. This can be done in the Invoice
Review Form. Alternatively the Automatic Approval and release client extension can be used to automatically
approve and release the invoices. But it all depends on the business scenario. Generally an invoice accountant will
review the invoice, approve and release it.
The approval workflow can also be customized to have a multi-level approval mechanism.
10. Interface Draft Invoices to Oracle Receivables
Run the "PRC: Interface invoices to Receivables" process in order to interface the released projects invoices to AR.
This process will populate the AR interface table. Once this process is run, in AR, the " Autoinvoice import"process
need to be run so that it will create AR invoices from the interface records.
[dropcap color={color} cap={cap}]{
Tech info:
Tables/Views involved:

RA_INTERFACE_LINES_ALL
}[/dropcap]
11. Tieback invoices back to Oracle Projects
Once the Autoinvoice import is successfully run, the "PRC: Tieback Invoices from Receivables" process is run to
update the status of the invoice import in AR to the Projects Invoices

Funding Revaluation in Oracle Projects Billing


Forex Loss/Gain in a Nutshell:
Revaluation is the process of revaluing accounts that have transactions denominated in foreign currency. This is
done for the account balance, not individual transactions. Revaluation can be done on any account, but typically,
this is done for balance sheet accounts, whose balance is made up of open transactions (ie. Accounts Payable,
Accounts Receivable). Revaluation reflects the change in conversion rates between the date of the transaction
and the date of the balance sheet.
When revaluation is run, a journal entry is created that either increases or decreases the functional currency
amount for that account, based on the
fluctuation of the exchange rate. The offset for this journal is a predefined Unrealized Gain/Loss Account.
All well said, the above is the scenario in AR/ AP. How do projects come in to picture here ? yes in projects we have
funding, revenue and invoices which an be affected due to the forex fluctuations since we can have multi currency
billing projects.
This article does not explain you the concepts, but the setup to be done in the Projects side to enable the Realized
Loss or gain to be captured for the funding and revenue.
Here are the Steps:
1. Enable the 'Revaluate Funding' and 'Funding Revaluation includes Project Gains and Losses' options at
the project type and project level.
2. Enter the Event types for the Realized Gains and Losses in the Billing Tab of the Project Types window.
3. Setup the Function Transactions for the Realized Gain and Loss accounts for the auto accounting functions
'Revenue and Invoice accounts'.
Step1:
Enable 'Funding Revaluation Includes Gains and Losses' in the Projects Implementation Options.

At Project Type level, Enable 'Revaluate Funding' and 'Funding Revaluation includes Gain and Loss'.
Associate the Gain and loss event types .

Query the existing project and setup the Funding revaluation options.

Navigation: Project -> Project Options -> Billing Setup

Project - Billing Setup


Step 2
Create Event Types with classifications 'Realized Gains' and 'Realized Losses' and associated them in
the Project Types window mentioned above.
Navigation: Projects -> Setup-> Billing -> Event Types

Event Types Setup


Step 3
Now we need to setup the Realized Gain and Loss Rules in Auto accounting and assign them to the
existing auto accounting function 'Revenue and Invoice Accounts'.
To do this, first create rules for 'Realized Loss and Realized Gain' . This rule determines which company account
segment the gains/loss should go.
Note: These accounts should be the same as the GL Gain and Loss account setup in Receivables.
Navigation: Projects -> Setup -> Auto accounting -> Rules.

In this example the company account segment to which Realized Gains will go is 0343, alternatively you can setup
SQL as well to dynamically find the Realized Gain account, but in general there will a single account, so generally
constant type is used.

Auto accounting - Realized Gain Rule Setup

Auto accounting - Loss Rule setup

Now that we have created the Loss and Gain rules, we need to assign these rules to the 'Revenue and Invoice'
Function. For this we need to query this Function in the auto accounting setup and assign the already created rules
to the Realized Gains account and Realized Losses account.
Navigation : Projects-> Setup -> Auto accounting-> Assign Rules - > Query for 'Revenue and Invoice Accounts'
and Find.
Then assign the rules as said above.

Assign Rules - Realized Gains Account

Assign Rules - Realized Losses Account


When funding revaluation process is run, the funding adjustment line.The revenue Loss/Gain events
are created if there are any cash payments to the projects invoices in AR.

2. What do the various AutoAccounting errors mean?


MESSAGE NAME

MESSAGE TEXT

PA_AA_AA_ERROR

Error occurred during AutoAccounting

PA_AA_ABORTING

Process &PROCESS terminating with error

PA_AA_BAD_APPLICATION

Bad application id passed to AutoAccounting

PA_AA_ENTER_CONSTANT_VALUE

Please enter a constant value

PA_AA_ENTER_FF_STRUCTURE

Please enter a flexfield structure

PA_AA_ENTER_PARAMETER_NAME

Please enter a parameter name

PA_AA_ENTER_SQL_STATEMENT

Please enter a SQL Select Statement

PA_AA_ERROR

Error in AutoAccounting Set Processing error


function

PA_AA_FIELD_NOT_COPIED

Function '&FUNCTION' could not update the field


'&FIELD'

PA_AA_FIRING_RULE

Firing rule '&RULE' ...

PA_AA_FUNC_UNINIT

Function '&FUNCTION' is not initialized

PA_AA_FV_ERROR

Error occurred during flexfield validation

PA_AA_INVALID_MODE

You have called '&FUNCTION' with an invalid mode

PA_AA_INVLD_KEY_SRC

Key source for rule '&RULE' is invalid

PA_AA_INVLD_RULE_TYP

Rule type for rule '&RULE' is invalid

PA_AA_INVLD_SQL_PARAM

AutoAccounting rule '&RULE' refers to a


nonexistent SQL parameter

PA_AA_LESS_PARAMS

Not enough parameters passed into function


'&FUNCTION'

PA_AA_LOOKUP_SET_INTEGRITY

This lookup set is already in use by another rule

PA_AA_MISSING_TOKEN

The '&TOKEN' token is missing

PA_AA_MULT_ROWS

Rule '&RULE' selects multiple rows which is not


currently supported

PA_AA_NOT_ENF_ARGS

&MODULE: Not enough arguments

PA_AA_NO_DB_CNCT

Unable to connect to database

PA_AA_NO_DESCRP

Unable to allocate a descriptor

PA_AA_NO_DETAIL_POST

Detail posting disabled for code combination &CCID

PA_AA_NO_LOOKUP

No segment value lookup in AutoAccounting lookup


set '&LOOKUPSET'

PA_AA_NO_MEMORY

&MODULE is out of memory

PA_AA_NO_PARAMS

No parameters exist for function '&FUNCTION'

PA_AA_NO_ROWS

SQL Select Statement for rule '&RULE' did not


return any rows

PA_AA_NO_RULE_PARAM

Rule 'RULE' refers to a parameter not connected to


its parent function

PA_AA_NO_SUCH_FNCT

AutoAccounting function '&FUNCTION' does not


exist

PA_AA_NO_SUCH_TKN

The token '&TOKEN' does not exist

PA_AA_NO_SUCH_TRANS

The function transaction code &FTCODE does not


exist

PA_AA_NO_TRANS

No transactions exist for function '&FUNCTION'.

PA_AA_NULL_SELECTED

SQL Statement for rule '&RULE' has selected a row


with a NULL value

PA_AA_OUT_OF_MEMORY

Memory could not be allocated for '&OBJECT' in


'&FUNCTION'.

PA_AA_PAXTAU_ARG_PROTOPA_AA_PAXTAU_ARG_PR Usage: PAXTAU Account/password 0 Y ApplicationOTO


Name AA-Function Function-Transaction StructureID Parameter1 Parameter2 ...
PA_AA_READING

Reading &ENTITY ...

PA_AA_RULE_INTEGRITY

This rue has been assigned to a segment. Delete


assignment first

PA_AA_SEG_ORDER_LBL

AutoAccounting qualifiers by segment order

PA_AA_SUMMARY_ALLOWED

Summary allowed for code combination &CCID

PA_AA_TOO_MANY_PARMS

AutoAccounting function '&FUNCTION' has


exceeded the maximum number of parameters
allowed

PA_AA_TOO_MANY_QULFRS

SQL statement for rule '&RULE' selects more than


the maximum number of qualifiers allowed

PA_AA_TOO_MANY_ROWS

SQL Select Statement for Rule '&RULE' has selected


more rows than the maximum number allowed

PA_AA_TOO_MANY_RULES

AutoAccounting function '&FUNCTION' uses more


than the maximum number of rules allowed

PA_AA_TOO_MANY_SQL_PARAMS

AutoAccounting rule '&RULE' uses more than the


maximum number of SQL parameters allowed

PA_AA_TOO_MANY_TOKNS

SQL Select Statement for rule '&RULE' selects more


than the maximum number of tokens allowed

PA_AA_TOO_MANY_TRANS

Too many transactions exist for function


'&FUNCTION'

PA_AA_TOO_MANY_TRIGS

AutoAccounting transaction '&TRANSACTION' has


more than the maximum number of triggers
allowed

PA_AA_TRANS_UNKNOWN

Transaction '&TRANSACTION' is not defined

PA_AA_VALUE_MATCH_NOT_UNIQUE

Intermediate Values must be unique

PA_AA_VALUE_TOO_LARGE

Value '&VALUE' is too large for its segment

PA_AA_WARNING

Warning in Auto Accounting for line '&LINE'

PA_AA_WRONG_FF

The passed template uses a different flexfield


structure from the one used by function
'&FUNCTION'

PA_AA_WRONG_KEY_SRC_TYPE

Reference to a non-existent key source type in rule


'&RULE'

PA_AA_WRONG_N_CLMS

SQL Select Statement for rule '&RULE' does not


select the correct number of columns

PA_AA_WRONG_PARAM

SQL Statement for rule '&RULE' uses incorrect


number of parameters

PA_AA_WRONG_RULE_TYPE

Rule '&RULE' uses an invalid rule type

3. Project and Subledger Links


In this Article we will look at how to link the data between Oracle Projects with the SLA module.
After Generate Accounting Events is run the acct_event_id in the pa_cost_distribution_lines_all table will be
populated with the accounting event id in the SLA. So using this acct_event_id column we can easily get to the XLA
Tables.
For the Cost Distribution lines, we can link the acct_event_id directly to the Xla_events table.
Example:
Lets say my expenditure item id is 123456.

Query to Find the XLA Events for the above expenditure item:

SELECT * FROM xla_events


WHERE event_id in (
SELECT DISTINCT acct_event_id
FROM pa_cost_distribution_lines_all
WHERE expenditure_item_id = 123456);

To select cost distribution line data where the process status on the associated accounting event is 'I'
(Invalid). Other process statuses that might be of interest: E=Error, U=Unprocessed, R=Related Event
in Error:
a.

To select cost distribution line data where the process status on the associated accounting event is 'I'
(Invalid). Other process statuses that might be of interest: E=Error, U=Unprocessed, R=Related Event in Error:
SELECT * FROM pa_cost_distribution_lines_all pa
WHERE acct_event_id in (
SELECT event_id FROM xla_events
WHERE process_status_code = 'I'
AND application_id = 275)
ORDER BY expenditure_item_id,line_num;

b.

To select all event data for Projects related events where the process status code is 'I' (Invalid):
SELECT * FROM xla_events
WHERE process_status_code = 'I'
AND application_id = 275;

c.

To select all event data related to a particular expenditure item with id 123456:
SELECT * FROM xla_events
WHERE event_id in (
SELECT DISTINCT acct_event_id FROM pa_cost_distribution_lines_all
WHERE expenditure_item_id = 123456);

d.

To view accounting errors associated with a particular expenditure item with id 123456:

SELECT * FROM xla_accounting_errors


WHERE event_id in (
SELECT acct_event_id FROM pa_cost_distribution_lines_all
WHERE expenditure_item_id = 123456);

e.

To select all accounting event header data for an expenditure item with id 123456:
SELECT * FROM xla_ae_headers
WHERE application_id = 275
AND event_id IN (
SELECT acct_event_id FROM pa_cost_distribution_lines_all
WHERE expenditure_item_id = 123456);

f.

To select all accounting event line data for an expenditure item with id 123456:
SELECT * FROM xla_ae_lines
WHERE application_id = 275
AND ae_header_id IN (
SELECT ae_header_id FROM xla_ae_headers
WHERE application_id = 275
AND event_id IN (
SELECT acct_event_id FROM pa_cost_distribution_lines_all
WHERE expenditure_item_id = 123456));

g.

To select all distribution link data, which provides direct links between accounting event, event header, and
event line details and the associated transactions in the source subledger, you can use:
SELECT * FROM xla_distribution_links
WHERE application_id = 275
AND ae_header_id in (
SELECT ae_header_id FROM xla_ae_headers
WHERE application_id = 275
AND event_id IN (
SELECT acct_event_id FROM pa_cost_distribution_lines_all
WHERE expenditure_item_id = 123456));

h.

To show accounting event headers that indicate they are finally accounted, but cannot be found in General
Ledger (GL):
SELECT DISTINCT hdr.ae_header_id , hdr.event_id, hdr.event_type_code, hdr.je_category_name
FROM xla_ae_lines lines, xla_ae_headers hdr
WHERE hdr.ae_header_id = lines.ae_header_id
AND hdr.accounting_entry_status_code = 'F'
AND lines.gl_sl_link_id IS NOT NULL
AND NOT EXISTS (
SELECT gl_sl_link_id FROM gl_import_references gir
WHERE lines.gl_sl_link_id = gir.gl_sl_link_id)

i.

Projects:

You can also use a query like the one below to query all events for a particular type of transaction in

SELECT * FROM xla_events


WHERE application_id = 275
AND event_type_code = upper('&event_type_code');

4. Funds Check Result Codes


This article lists all the valid funds check result codes as a result of funds check in oracle projects module.

RESULT_CODE

DESCRIPTION

RESULT

F01

Funds Check failed because of invalid budgeted task

Fail

F02

Funds Check failed because of invalid parent resource member

Fail

F03

Funds Check failed because of invalid top task

Fail

F04

Funds Check failed due to invalid award number

Fail

F05

Funds Check failed during budget period derivation

Fail

F06

Funds Check failed during burden calculation

Fail

F07

Funds Check failed during burden posting

Fail

F08

Adjusted transaction has not been funds checked

Fail

F09

Funds Check failed due to incomplete transfer of data

Fail

F10

Transaction failed funds check at Award level

Fail

F100

Insufficient funds

Fail

F101

No budget exists at the resource level

Fail

F102

No budget exists at the resource group level

Fail

F103

No budget exists at the task level

Fail

F104

No budget exists at the top task level

Fail

F105

No budget exists at the project level

Fail

F106

No budget exists at the project account level

Fail

F107

The transaction account and the budget account are different

Fail

F108

The transaction failed funds check at the resource level

Fail

F109

The transaction failed funds check at the resource group level

Fail

F110

The transaction failed funds check at the task level

Fail

F111

The transaction failed funds check at the top task level

Fail

F112

The transaction failed funds check at the project level

Fail

F113

The transaction failed funds check at project account level

Fail

F114

The transaction failed to populate burden cost

Fail

F115

Funds check failed because of insufficient funds to cover burden cost

Fail

F116

Funds check failed because of insufficient funds to cover raw cost

Fail

F117

The transaction failed because of errors in one or more cost distribution lines

Fail

F118

Funds check failed because of invalid budget versions

Fail

F119

Failed because year end rollover process is in progress

Fail

F120

Funds check failed during setup and summarization

Fail

F121

The resource list is invalid or null

Fail

F122

The amount type or boundary code is invalid

Fail

F123

The amount type or boundary code is invalid for no time phase

Fail

F124

The boundary code for amount type ''Project to date'' is invalid

Fail

F125

Invalid boundary code for amount type ''Year to date''

Fail

F127

Invalid boundary code for amount type ''Period to date''

Fail

F128

Funds check failed because of invalid resource list member

Fail

F129

Start date or end date is null for the specified date range

Fail

F130

Not able to derive PA date

Fail

F131

Invalid budget entry method or missing baseline version

Fail

F132

Could not map to a budget line while deriving budget account

Fail

F134

Not able to derive GL date

Fail

F135

The encumbrance type is null or invalid

Fail

F136

Funds check failed while calculating start date or end date

Fail

F137

No matching requisition was found for this purchase order

Fail

F138

No matching purchase order was found for this invoice

Fail

F140

Funds check failed due to fatal error while inserting burden cost

Fail

F141

Could not acquire lock: funds checks are running concurrently

Fail

F142

Funds check failed because of unexpected error

Fail

F143

Funds check failed because budget baselining is in progress

Fail

F144

Funds check failed for the unreserve mode

Fail

F145

Funds check failed for the baseline mode

Fail

F146

Funds check failed for the reserve mode

Fail

F150

The GL funds check failed for the check funds mode

Fail

F151

The GL funds check encountered fatal errors

Fail

F152

The CBC funds check failed for the check funds mode

Fail

F153

The CBC funds check encountered fatal errors

Fail

F155

The GL funds check failed for the full mode

Fail

F156

The GL funds check failed for the partial mode

Fail

F157

The CBC funds check failed for the full mode

Fail

F158

The CBC funds check failed for the partial mode

Fail

F160

Funds check failed to generate the return code

Fail

F161

Funds check failed to create encumbrance liquidation

Fail

F162

Funds check failed to update budget account balances

Fail

F163

Funds check failed while posting burden cost to GL

Fail

F164

Funds check failed while posting burden cost to CBC

Fail

F165

No budget account on raw line

Fail

F166

No baselined budget version exists for this project

Fail

P101

Transaction passed funds check at the project account level

Pass

P102

Transaction passed funds check at project account level in advisory mode

Pass

P103

Transaction passed funds check at project level

Pass

P104

Transaction passed funds check at project level in advisory mode

Pass

P105

Transaction passed funds check at top task level

Pass

P106

Transaction passed funds check at top task level in advisory mode

Pass

P107

Transaction passed funds check at task level

Pass

P108

Transaction passed funds check at task level in advisory mode

Pass

P109

Transaction passed funds check at resource group level

Pass

P110

Funds check passed at resource group level in advisory mode

Pass

P111

Transaction passed funds check at resource level

Pass

P112

Transaction passed funds check at resource level in advisory mode

Pass

P113

Increase in funds does not require funds check

Pass

P114

Invoice interfaced from projects does not require funds check

Pass

P115

Expense report from projects requires no funds check

Pass

P116

Transaction passed funds check in force pass mode

Pass

5. Oracle Projects Account generators


The main account generator processes that relate to Oracle Projects are:
PAAPINVW -- Project Supplier Invoice Account Generation
PAAPWEBX -- Project Expense Report Account Generator
POWFPOAG -- PO Account Generator
POWFRQAG -- PO Requisition Account Generator
The first two are called from Oracle Payables when creating project related supplier invoices and expense reports,
and the second two are called from Oracle Purchasing when entering projects related requisitions and purchase
orders.
For transactions created within Oracle Projects, CCIDs are generated using the autoaccounting setup.
Project Supplier Invoice Account Generator
Project Supplier Invoice by default: The default process Generate default account contains nothing more than
a dummy
procedure (PA_ACC_GEN_WF_PKG.AP_INV_ACC_UNDEFINED_RULES) which generates the following message
and aborts:
"The default workflow for the Oracle Payables account function Project Supplier Invoice charge Account has not
been customised.Please replace the dummy function in the default process for account generation by your own
account generation method".
Expense Report Account Generator
The default Expense Report Account Generator works as follows:
The vendor on an expense report must be associated with an employee. Employees can be assigned a default
expense account in the employee setup in Oracle Human Resources:
People->Enter and Maintain->Assignment->Purchase Order Information
The account generator will use this default expense account. If it is not defined you will get an error when you try to
save your expense report.
PO/Requisition Account Generator
The PO and Requisition account generators actually generate a series of Accounts. Each has procedures to generate
the charge/expense account, the
accrual account, the budget account and the variance account. Within the default account generator there is a
separate process to generate each of these accounts for project related purchase orders and requisitions.
PO Project-Related?
The default PO and Requisition Account Generator processes contain a procedure to determine if the PO or
requisition is project-related or not.

This procedure (PO_WF_PO_CHARGE_ACC.IS_PO_PROJECT_RELATED) as defined is a dummy procedure that always


returns false.
In order to generate specific accounts for project-related purchase orders and requisitions, this process must be
modified, or the activity replaced with another that accurately determines whether the object is projects-related.
A common technique to accomplish this is to replace the function activity with a Compare Number function
(available in the list of standard functions). This function allows you to compare the value of the Test value (which
you set to be the item attribute Project id) and the Reference value (which you set to be the constant 0). The
results of this function are Greater Than, Less Than, Equal or Null. It will return null if the test value is null.
Therefore branching off of this comparison you will have two transitions. One linked to the Null return value which
leads to the non project-related process, and one which is the <Default> encompassing all the other return values
which leads to the project-related process. In this way, if the project_id is not null, it will branch to the project
related process.
Build Expense Project Accounts
There are four subprocesses of the default workflow which are called if the above process determines that the item
is project related. They are all named Build Expense Project XXXX Account, where XXXX could be Budget, Accrual,
Variance or Charge. Like the Supplier Invoice process, there is no
default logic associated with any of these processes, and if there is a business need to enter project information and
to generate different accounts based on that, they must be customize

6. Oracle Projects Migration/ Data Conversion


In this article I will be explaining the general steps involved in any Conversion/Data Migration of Oracle Projects
module.
At the end of this article, you would have learned:

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 Loads).

Oracle Projects AMG APIs needed to perform the Conversion.

Testing the Conversion Process.

Verifying the Conversion Process.

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.
How to deal with it ?
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.
Stages in Oracle Projects Conversion
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.

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.

1.

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.
Oracle Projects Setup For Conversion
<!--[if !supportLists]-->

<!--[endif]-->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 !supportLists]-->

<!--[endif]-->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 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 to create the budgets for the migrated projects.

<!--[if !supportLists]-->

<!--[endif]-->Implementation Option Setup:

Project Numbering: This implementation option is by default set to 'Automatic' which


means when creating projects in Oracle Projects, the project number is automatically derived and
users are not required to provide any project 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
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'.

<!--[if !supportLists]-->

<!--[endif]-->Setup Transaction Source:

The Transaction Source needs to be setup in Oracle Projects in the Transaction Sources
form in Oracle Projects 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 API's what is the source system and how the data is handled when it is imported to
Oracle Projects.

<!--[if !supportLists]-->

<!--[endif]-->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.

<!--[if !supportLists]-->

<!--[endif]-->Setup Employee Cost Rates:

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.
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 timecards.

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.

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 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.

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

Contract

Contract_Template

Template

Indirect

Indirect_Template

Expenditure Type

Hours

Labor

Expenditure Type

Expenses

Employee_Expense

Transaction

Transaction Source

Legacy1

Product Code

Product code

LEGACY1

Project

Publish Workplan

Yes

Project

Baseline Workplan

Yes

Cost Budget

Baseline

Yes

Revenue Budget

Baseline

Yes

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.

Project/Task - Setup Validations:

<!--[if !supportLists]--> <!--[endif]-->Validate the Product code is setup.


<!--[if !supportLists]--> <!--[endif]-->Validate if the required Project Templates are setup.
<!--[if !supportLists]--> <!--[endif]-->Validate if the Project Numbering is set to 'Manual' for creating projects with
the predefined project numbers.
Project/Task Data Validations:
<!--[if !supportLists]--> <!--[endif]-->Validate if the project name is unique. Project with the same name should not
exist in Oracle Projects.
<!--[if !supportLists]--> <!--[endif]-->Validate if the project number is unique. Project with the same number should
not exist in Oracle Projects.
<!--[if !supportLists]--> <!--[endif]-->Validate if the project long name is unique. Project with the same long name
should not exist in Oracle.
<!--[if !supportLists]--> <!--[endif]-->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)
<!--[if !supportLists]--> <!--[endif]-->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.
<!--[if !supportLists]--> <!--[endif]-->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.
<!--[if !supportLists]--> <!--[endif]-->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.
<!--[if !supportLists]--> <!--[endif]-->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:
<!--[if !supportLists]-->

<!--[endif]-->Validate if the Transaction source is setup.

<!--[if !supportLists]-->

<!--[endif]-->Validate if the Expenditure type is setup.

Data Validations:
<!--[if !supportLists]-->

<!--[endif]-->Check if the hours value is greater than zero.

<!--[if !supportLists]-->
date.

<!--[endif]-->Check if the employee number is valid in HR and is active on the timecard

<!--[if !supportLists]-->
<!--[endif]-->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:

<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->

<!--[endif]-->Budget amount has to be greater than zero.

<!--[if !supportLists]-->
<!--[endif]-->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.

Agreements and Funding Validation


Data Validations:
<!--[if !supportLists]-->

<!--[endif]-->Agreement type should be valid.

<!--[if !supportLists]-->

<!--[endif]-->Agreement Amount should be greater than zero.

<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->

<!--[endif]-->Funding amount has to be within the Agreement amount.

<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
Revenue and Invoice Validations:
Data Validations:
<!--[if !supportLists]-->

<!--[endif]-->Project / Task should already been converted to Oracle.

<!--[if !supportLists]-->

<!--[endif]-->Event amount should be non zero.

<!--[if !supportLists]-->

<!--[endif]-->For revenue event revenue amount should be populated.

<!--[if !supportLists]-->

<!--[endif]-->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 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.

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

PA_PROJECT_PUB.CREATE_PROJECT

Budgets Conversion

PA_BUDGET_PU B.CREATE_DRAFT_BUDGET,
PA_BUDGET_PUB.BASELINE_BUDGET

Agreements

PA_AGREEMENT_PUB.CREATE_AGREEMENT

Funding

PA_AGREEMENT_PUB.ADD_FUNDING

Revenue/Invoice

PA_EVENT_PUB.CREATE_BILLING_EVENT

User Defined Attributes (UDA)

PA_PROJECT_PUB.LOAD_EXTENSIBLE_ATTRIBUTE

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 need to 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'.
For code samples: http://www.projectsaccounting.com/code-snippets
Conversion Tips:
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.

<!--[if !supportLists]-->
<!--[endif]-->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

Change Management -An Overview


A change is an event, action, or condition that affects the scope, value, or duration of a project or task. All change
documents must be associated with a project or project/task combination. Change management is the process of
creating, managing, resolving, implementing, and communicating changes. Change management encompasses
both change requests and change order.
Change requests enable you to document potential changes to the scope of a project and to facilitate the approval
process.
Change orders enable you to track and implement the impacts of changes to a project.
You can merge the impacts of multiple change requests into a single change order. Once approved, you can
implement the impact of a change order.
Change requests and change orders are sometimes referred to collectively in Oracle Projects as change documents.

Change Management

The change management process consists of the following stages:


Create change documents
When you identify a change for a project or task, you can record the change details using Oracle Project
Management and assign ownership of the resulting change document. The owner creates and assigns actions in an
effort to resolve the change document, and defines the change document impacts. You can also create a change
document by copying an existing issue or change document.
Manage change documents
You can view change documents for one or more projects for which you are responsible for resolving. These lists
provide information to help you determine which change documents need immediate attention. You can also update
the progress being made to resolve change documents.

Resolve change documents


After change document impacts have been defined and all actions have been closed, the change document owner
is required to submit it for approval.
If a resolution is required for a change document, you must enter it before you can submit the change document for
approval.
Approve change documents
Approval of a change document indicates that the approver has reviewed the change document and agrees with
the defined impacts and the resolution. By default, the approver for your change documents is the project manager,
but you may define the approver differently during implementation.
If the approver rejects the change document resolution, the status is changed to Rejected and the change
document must be reworked in order to be resubmitted it for approval. A change document with open actions
cannot be submitted for approval.

Implement and close change documents


Once approved, you can include change requests in a change order. Once a change order has been approved, you

can implement the financial impact in the approved budget for the project. You can also implement and track the
supplier impact in purchase orders, and track the implementation details for workplan, contract, staffing, and other
impacts.
After a change document is approved and implemented, you can close it. Change requests must be included in a
change order before they can be closed. Once approved, you can implement the impacts of a change order and
close the change order.

Change Document Participation


Both project team members and nonteam members can participate in the resolution and implementation of a
change document. These participants can have different levels of access to the change document and related
actions based on both the status of the change document and the type of assigned actions. Possible participants
include:

Creator: A change document creator is a project team member who creates the change document and designates
the owner. Only the creator and users with proper project security access such as super users, users with project
authority for an organization, and project managers have access to a change document while it is in Draft status.

Owner: A change document owner is a project team member who has been assigned the responsibility of
overseeing the progress, resolution, implementation, and closure of a change document. This person creates and
assigns actions to both team members and nonteam members, as appropriate. In addition, users who have proper
project security access can change the status and ownership of items. The owner of the change document can be
changed only while the change document is in either Draft or Working status.

Assignee: An assignee is a person who has been assigned an action. The assignee can respond, close, or reassign
the action.

Approver: An approver reviews and approves a change document. Project managers are the default change
document approvers. If the person that submits the change document for approval is the project manager, the
change document is automatically approved once it is submitted.

Creating Change Documents

Each change document is based on a predefined change request type or change order type. The change document
type determines who can create a change document of that type and the general behavior of a change document
such as how the change documents are numbered and if a resolution is required. Change document types are
associated with project types. This association determines the list of change document types available for a given
project.
Points to keep in mind when creating change documents:
If you are not ready for the project team to begin working on the change document and assigned action, then you
must change the status to Draft before you save the change document for the first time. You cannot change the
status of a working change document back to Draft once it has been saved.
If the change document status was originally set to Draft, change the status to Working when you are ready for the
project team members and other action assignees to begin working on their actions and the resolution of the
change document.
Each change document has a log tracking the interaction between team members and action assignees. All
comments and responses to actions are recorded in this log and can be viewed through the Interaction History
page.

Change Document Attributes


When you create a change document, the information you provide assists in its tracking and resolution. All change

documents must be associated with a project. This section describes the key attributes of a change document. The
change document attributes include:
Summary and Description
You can provide both a textual summary and a description of the change document. The summary appears on all
predefined views of change document lists.

Classification
You must select a classification for each change document. This classification provides further categorization of the
change document.
For example, you have defined classifications of Resource, Knowledge Gap, and Dependencies. You can create a
personalized view of all the Resource change documents. The classification enables you to categorize your change
documents into meaningful groups for identifying high problem areas.
Priority
You can select a value to indicate the level of priority of the change document.

Reason
You must select the reason for the change document.
For example, you may have reasons such as Enhancement Request, Error in Initial Scope, or Insufficient Materials.
The reasons can assist you later in categorizing and analyzing the causes of your change documents for one or
more projects.

Required by Date
You can specify a date by which the change document should be resolved and implemented. This attribute is used
to calculate the value for Days Until Due, which indicates to team members the urgency of the change document by
showing how much time is left to resolve and close a change document.

Owner
You must assign ownership either to yourself or another project team member. Ownership defaults to the person
creating the change document.
Level of Effort
You can select a value to indicate the estimated level of effort required to resolve the change document.

Status
When you create a change document, you must select a status of Draft or Working. Once the change document is
saved in Working status, you cannot change it back to Draft.

Price and Currency


You can enter the estimated price of the change document resolution, if known, and specify the currency of the
price.

Task
You can associate the change document to a particular task on either the currently published workplan or financial
structure.

Source
If source information is enabled for the change document type, you can specify the originating source of the change
document and its related information.

Action
You can assign an initial action for the change document. If you want to create additional actions, you must create
them from the Actions page.

System Number and Change Document Number


Each change document is assigned a systemgenerated number that is unique across all projects. In addition, each
change document has a number to identify it within the project (see next page).
Defining Change Document Impacts

The types of impacts that are available for you to define for a specific change request or change order are based on
the impacts that are enabled for the change document type.
You define workplan, staffing, contract, and other impacts by entering descriptive text. When you define a supplier
impact, you can enter descriptive text, as well as an impact amount by purchase order. You can use the supplier
impact amount information to manually update purchase orders at any time.

When you define financial impact for a change document, you can enter descriptive text, estimate amounts, and
detail plan lines. Amounts can include quantities, cost amounts, and revenue amounts, as appropriate, based on the
planning options defined in the approved budget plan type for a project.

Oracle Project Management uses the plan setup for the approved budget plan type for a project to determine
whether you can enter cost impacts only, revenue impacts only, or both cost and revenue impacts.
Before you can enter financial impact amounts for a change document, a current working plan version must exist
for the approved budget plan type for the project. In addition, once a financial impact has been defined for a
change document, you must have at least one current working plan version for the approved budget plan type.

When the Baseline Funding Without Budget option is enabled for a project, Oracle Projects automatically creates an
approved revenue budget when you create the project funding baseline. When defining the financial impact of a
change order on a project with this option enabled, you must select the agreement name from which the project
funding was created. If you want to increase the total amount for the agreement by the amount of the change order
financial impact, select the Update Agreement Amount option on the Impact Details page.

Editing Planning Options for Financial Impact in Change Documents


Planning options control the level, currencies, time phase, and planning elements (tasks and resources), for which
financial amounts can be planned. Oracle Projects defines default planning options for the financial impact of a
change document based on the planning options for the current working plan version of the approved budget plan
type. You can optionally edit the default planning options of a change document from the pages used to edit the
cost and revenue amounts.
Creating and Assigning Actions to Change Documents
An action is an assigned question or unit of work related to the change document. The action consists of the request
and related information, and all responses to the request. Actions enable project team members and other
interested parties to collaborate on a change document, and can help in the resolution of the change document.
You can create actions for a change document that is in either Draft or Working status, and assign these actions to
any person. These actions are visible to the assignees only when the change document is in working status. You can
create two types of actions: Review or Update. A review action allows the assignee to review the change document
and enter a response. An update action allows the assignee to update the change document for as long as the
action is open. Only the change document owner or project manager can create update actions. Persons assigned
to open review and update actions can create new review actions for other people.
When you define an action, you can specify a due date for the response in the Required by Date field. This date
assists the change document owner in managing outstanding actions on the change document. You can also
request sign off from the action assignee in order to confirm the action response. The change document owner can
submit the change document for approval only after all the actions are closed.

Including and Viewing Change Documents


You can automatically implement the financial impact of an approved change order in a current working plan
version that is designated as an approved cost budget or an approved revenue budget.
You can include the financial impact of a change document of any status in any plan version that is not designated
as an approved cost budget or an approved revenue budget. You can include the financial impact of a change
document in a plan version only once.

Manually Including the Impact of a Change Document


Oracle Projects cannot automatically include the financial impact of a change document in a plan version if any of
the following conditions are true:
The planning level of the plan version is at a more detailed level than the planning level of the change document.
The time phase of the plan version and the change document differ, and the time phase of the plan version is not
None.
The resource list of the plan version and the change document differ, and the resource list of the plan version is not
None.
When the system cannot automatically include the financial impact of a change document in a plan version, the
system will display the View Plan page for the change document. To manually include the financial impact of the
change document, choose Printable Page on the View Plan page to print the document information and use the
information to manually update the plan version.
If you manually update a plan version to include the financial impact of a change document, then use the Mark as
Included option on the View Plan page. This prevents the change document from being included in a plan version
more than once, and enables the change document to be displayed in the View Included Change Documents page
for a plan version.

Viewing Included Change Documents


To view a list of change documents that are included in a plan version, navigate to the View Included Change
Documents page

Oracle Projects New Features in Release 12.1.3


So lets look at some of the new/enhanced features of oracle projects in R12.1.3
1.

Enhanced Project List Page wherein users can create/edit/delete their own report views. Save search as a
report.

2.

One of the major improvements in this release is the improvement in the project performance reporting
processes. Now the PPR processes comes with a parameter 'project status' which the users can select while
submitting the processes. Am sure this will help in improving the long running PPR processes.

3.

Now Non-shared Task Based Mapping Structures and Partially Shared Structures are supported for MSP
integrations ( I would say better integration than before) in Release 12.1.3

4.

Enhanced Retention Invoice Processing: Now you can process the project deductions before the releasing
the retention and hence making sure that the deductions are processed before the invoice is processed. Any
unapproved deductions if exist, the retention invoice will be put on hold.

5.

Cost Issue Planning now can consider the estimated changes in direct or supplier costs. Consolidate
multiple change requests into a change order to impact the budget.

6.

Improved Oracle Projects Diagnostics

Project Statuses
(N): Projects Implementation Super User Resp -> Setup -> System -> Statuses

When you implement Oracle Projects, your system is seeded with predefined statuses. You can also modify the
default status controls for existing user statuses. You define additional project statuses to meet your business
needs. You can create new user statuses based on the available system statuses.
Every project must have a valid status. The predefined Project Statuses are: Unapproved, Submitted, Approved,
Rejected, Pending Closed, and Closed.
Each project status must be associated with a system status. The predefined system statuses for project statuses
are: Unapproved, Submitted, Approved, Pending Close, Closed, Pending Purge, Partially Purged, and Purged.
You can optionally include project status as a level of security in which you create separate menus for each project
status value and then associate the menu set to a role. This additional security layer enables you to use the status
of the project as another way of determining access to specific functions related to that project. For example, you
can give project managers the ability to update assignment rate information for projects while they are in the sales
pipeline with a "submitted" status, and then prevent them from updating that information after those projects are
approved.

Defining Project Status Workflow

Use the workflow tab to enable workflow for a status and to associate the status with a workflow item type and
process.
If a status is enabled for workflow, and the project type for the project is enabled for the use workflow for
project status changes, when you update a project to that status the system will initiate the associated workflow
process.
When you enable a status for workflow, you will then enter information for the following fields:
Item Type
Process
Success Status
Failure Status
Oracle Projects provides a default project workflow process to use in association with project statuses.
The process is named the PA Project Workflow. If you enable a status for workflow and then associate the default
process with the status, the default process will route the approval of a project status change to the immediate
supervisor of the person who submitted the status change. Using the Oracle Workflow Builder, you may customize
the process or create new one.
Defining Status Controls
You use the Status Controls region of the Statuses window to define actions that are allowed or restricted for
each project status. If you want to change the status controls from the default settings, you can select or clear the
Allow box.
The status controls for project statuses are:
Create New Transactions
Project Status Report Notifications
Adjust Transactions
Generate Revenue
Generate Invoice
Capitalize Assets
Include in Status Reports
Change Project Probability
Allow Confirmed Assignments
Allow Provisional Assignments
Include Project in Organization Forecasts
Defining the Next Allowable Status
Defining the next allowable statuses determines the process flow for your objects. For example, you can specify
that a project with the user status of Submitted can have its status changed to the user statuses of either
Approved or Rejected. With this setup, you have just determined two possible process flows:

Submitted -> Approved


Submitted -> Rejected
Four option buttons control the next allowable statuses you can enter:
All: The current status can be changed to any status. This is the default value.
None: The current status cannot be changed.
System Status: The Next Allowable Statuses are all system statuses.
Status: The Next Allowable Statuses are all user-defined statuses.

Oracle Projects Classifications


Project Classifications Project classifications are used to group the projects.

A project classification includes a class category and a class code.Class categories and codes are shared across
operating units. For example, if you want to know the Product to which a project belongs, you can define a class
category with a name such as Industry Sector.
You can define class codes for this category such as Hi-Tech,Professional Services, Federal,E&C etc.Classifications
can be used for querying projects, reporting, and AutoAccounting.

A classification can be marked as mandatory for all projects or for projects with a particular project type.The
following options are available when you define Project Classifications:
Mandatory Classifications
You can specify whether a class category is mandatory for every project you define. Select this option if all projects
must have a code assigned to this class category.Classifications and Project TypesOn the Project Types tab, you can
select each project type that you would like to associate with this class category. Enable the Mandatory check box
for a project type if you want the system to require all projects of the project type to be associated with the
selected class category.
AutoAccounting
If this option is checked, you can use the class category in the auto accounting rules.
Allow 1 code only
Specify whether you want to allow entry of only one class code with this class category for a project.
Allow percent entry
This controls the ability to associate percentages with classification codes. The system requires class code
percentages or the category regardless of the project type.
Total percent equal 100
If this option is checked, the sum of all class code percentages should be equal to 100 for the selected class
category. This option can be disabled at anytime.

Oracle Projects Data Model


This topic covers the Oracle Projects Data model.
Projects are created from the Projects Templates / other Projects .

Base Table: PA_IMPLEMENTATIONS_ALL


This table contains a row for each projects implementation, i.e one per operating unit. This table contains the setup
information specific to the operating unit.
The table data corresponds to the front end: Projects implementation super user resp -> Setup->System>Implementation options.
Base Table: PA_PROJECTS_ALL
Important Columns:
Project ID: uniquely identifies a project
Name: Name of the Project
Segment1: Project Number
This project number can be automatic/ Manual depending upon the System Implementation Option Setups, i.e., if
the setting is automatic, there is no need of giving a project number when creating a project. If it is manual, then a
project number should be provided while creating the project.
Carrying_out_organization_id : This is the project owning organization.
Pm_product_code: This identifies the source of the project, generally used whenever a project is created from a
third party product.
Project_Status_code: Indicates the project status whether active, approved, closed, rejected etc.
Start_Date : Transaction start date of the Project.
Completion_Date: Transaction End Date of the project.
(There are different dates for a project each having its own significance, we will see those in a different topic.)
Tasks:
Base Table: PA_TASKS
Important Columns:
Task_id : uniquely identifies a task.
Project_id : - From the pa_projects_all table .
Carrying_out_organization_id : This is the task owning organization.
(Task owning organization can be different from Project owning organization).
Start_date : Transaction Start Date of the Task
Completion_Date: Transaction End Date of the Task
Wbs_level :Indicates the level of the Task in the WBS hierarchy.
(WBS - Work Break down Structure indicates the structure of the Project)
Parent_Task_id : uniquely identifies the Parent Task
Top_Task_id : uniquely identifies the Top Task.
Pm_product_code : Indicates the source of the task(used in conversion projects).
Pm_task_reference: uniquely identifies the corresponding task in the source system (used in conversion projects).
Base Table: PA_AGREEMENTS_ALL

This is the table which stores the Agreement information.


Agreement_id : uniquely identifies the agreement.
Customer_id : Agreements customer id.
Agreement_num : Agreement Number
Expiration_Date : Expiration Date of the Agreement
Revenue_Limit_Flag: Flag which indicates whether the revenue can exceed the allocated funding amount.
Invoice_Limit_Flag: Flag which indicates whether invoice can exceed the allocated funding amount.
Amount: Agreement Amount.
Base Table: PA_PROJECT_FUNDINGS
Project_Funding_id : uniquely identifies the Funding
Project_id : id of Project to which the funding is allocated
Task_id : id of Top Task to which the funding is allocated
Budget_type_code : Status of the budget whether baselined or not.
Allocated_amount: the amount of funding allocated to the project or top task.
To be continued...

Reconciling PA and other modules - Part I


The most challenging part is reconciling the cost and revenue in PA with other modules.Below is a flow chart
showing the data flow between the modules PA, AP, PO and GL.

Here in this Part1 iam giving you the basic queries that will be helpful to reconcile the cost between these modules.
In Part2 I will be giving the basic queries for revenue reconciliation. In Part3, i will be giving the UBR and UER
reconcilation.

NOTE: These queries are just prototypes, you may have to modify it according to your accounting
setup. All the queries are for a particular period since we are concerned about reconciling
cost/revenue for that particular period only.
Q1: Cost interfaced from the modules PA,AP,PO,AR to GL in JUN-08.
SELECT SUM(nvl(entered_dr,0) - nvl(entered_cr,0)) amt , glcc.segment1, glcc.segment2, glh.je_source
FROM apps.gl_je_headers glh,
apps.gl_je_lines gll,
apps.gl_code_combinations glcc
WHERE glh.je_header_id = gll.je_header_id
AND gll.code_combination_id = glcc.code_combination_id
AND glcc.segment2 in ('10903','10953','10814') -- specific accounts
AND actual_flag = 'A'
AND summary_flag = 'N'
AND gll.period_name in ('JUN-08') -- Period
AND glh.je_source in ('Project Accounting', 'Purchasing', 'Payables', 'Receivables') GROUP BY
glcc.segment1, glcc.segment2, glh.je_source , gll.period_name
Now we can check the total cost in projects that are interfaced to GL :
Q2: Total Cost in Projects by Transaction source and Segment1 and Segment2 for JUN-08.
You can add more segments here according to your needs.
SELECT transaction_source, glcc.segment1, glcc.segment2, SUM(cdl.burdened_cost) JUN08_Cost,
ei.system_linkage_function
FROM
apps.pa_cost_distribution_lines_all cdl,
apps.pa_expenditure_items_all ei,
apps.pa_projects_all ppa,
apps.hr_all_organization_units hou,
apps.gl_code_combinations glcc
WHERE ppa.carrying_out_organization_id = hou.organization_id
AND ppa.project_id = cdl.project_id
AND cdl.gl_period_name = 'JUN-08'
AND cdl.expenditure_item_id = ei.expenditure_item_id
AND cdl.dr_code_combination_id = glcc.code_combination_id
GROUP BY ei.transaction_source, glcc.segment1, glcc.segment2, ei.system_linkage_function
Now you have to tie the cost amounts from various sources such as 'Payables', 'PO Receipt' and other modules to
the Cost returned in the Query1 for these sources.
The Costs from AP are directly sent to GL. The Costs from PO/Receiving are directly sent to GL.
Q3: Costs that are interfaced from AP to PA in JUN-08
SELECT
NVL(sum(nvl(amount,0)),0) amt, glcc.segment1, glcc.segment2 , inv_dist.pa_addition_flag,
inv_dist.je_batch_id, inv_dist.accrual_posted_flag,
inv_dist.project_id, inv_dist.expenditure_type
FROM apps.ap_invoice_distributions_all inv_dist
,apps.ap_invoices_all i
,apps.gl_code_combinations glcc
WHERE inv_dist.invoice_id = i.invoice_id
AND inv_dist.dist_code_combination_id = glcc.code_combination_id
AND glcc.segment2 in ('10903','10953','10814') -- specific accounts
AND inv_dist.posted_flag = 'Y'
AND inv_dist.accounting_date between '01-JUN-08' and '30-JUN-08'
AND inv_dist.period_name = 'JUN-08'
GROUP BY glcc.segment1, glcc.segment2, inv_dist.pa_addition_flag, inv_dist.je_batch_id,
inv_dist.ACCRUAL_POSTED_FLAG,inv_dist.project_id, inv_dist.expenditure_type

The above query will give you the cost that is interfaced from AP to PA for JUN08 period. The Cost in Query Q2 for
the transaction source 'Payables' should match the cost in Q3.If these two are not matching then it might be that
Cost is adjusted in Projects/Payables but posted to the other module.
Case1: Invoice from AP is adjusted in PA.
Case2: Invoice is adjusted in AP after it is interfaced to PA.
For Case1, Interface the un-interfaced Supplier invoice adjustment records in Oracle Projects.
For Case2:Interface the Adjusted AP invoice to Oracle Projects.
Then re-run the queries Q2 and Q3 and check.
Q4: Costs that are interfaced from PO to PA in JUN-08
SELECT
NVL(sum(nvl(rcv.accounted_dr,0)),0) - NVL(sum(nvl(accounted_cr,0)),0) amt,
glcc.segment1, glcc.segment2, rcv.pa_addition_flag FROM apps.rcv_transactions t
,apps.RCV_RECEIVING_SUB_LEDGER rcv
,apps.gl_code_combinations glcc
WHERE rcv.code_combination_id = glcc.code_combination_id
AND rcv.rcv_transaction_id = t.transaction_id
AND glcc.segment2 in ('10903','10953','10814') -- specific accounts
AND rcv.actual_flag = 'A'
AND rcv.accounting_date between '01-JUN-08' and '30-JUN-08'
GROUP BY glcc.segment1, glcc.segment2, rcv.pa_addition_flag
Now we have to look at the output of all the queries to reconcile. If PA and AP does not match then we need to find
out the uninterfaced transactions in both the modules and interface them. Similarly for the PO and PA.
In the next part i will be explaining about the Revenue reconciliation

How to Capture Extra Information in Projects?


In this article i will explain the powerful facility that Oracle projects has provided to capture extra information for
any projects without having to write a single line of code.
UDA : User Defined Attributes
UDA is a powerful mechanism wherein similar to the Descriptive flex fields in forms. Here we have to create an
Attribute Group which is similar to the Desc Flex and the Attribute items similar to the segments in the flex field.
In the Projects Super user responsibility, we have set of menu functions for creating a UDA page.
The example scenario here is I want to capture the Cost Center information of a Project. If UDA concept is not there,
i need to write a custom OA Page for this.
Steps involved:
1.

Create an Attribute Group (XX_Cost_Center).

2.

Add Attribute item (cost_center) to the attribute group.

3.

Add Attribute Context - This is to associate the attribute group to the context of the project. The context
can be Class Category, Project Type, Task Type. For example if i add an attribute context
of type 'Project Type' with the value 'Construction'. Then all the projects which are of type 'Construction' are eligible
for collecting the cost center information.

4.

Add Page region - This is to Create a Region to associate the Attribute Group. There can be more than one
Attribute group that can be associated to a page region.

5.

Create the database view for the Attribute Group created.


<!--[if !vml]-->
<!--[endif]-->

<!--[if !vml]-->
<!--[endif]-->

<!--[if !vml]-->
<!--[endif]-->

<!--[if !vml]--><!--[endif]--> <!--[if !vml]--><!--[endif]-->

<!--[if !vml]--><!--[endif]-->

<!--[if !vml]--><!--[endif]-->
Search for a Construction Project:

Navigate to the Setup of the Project. We can see the Cost Center Information Link at the bottom of the Page.

Navigate to the Cost Center Information Page, we can see the Attribute item we have created. We can fill in the
value of the cost center here and it is stored in the PA_PROJECTS_ERP_EXT_B and PA_PROJECTS_ERP_EXT_TL
Tables.

Role Based Costing in Oracle Projects


One of the scenario that i came across is client wanted to have the cost rates assigned at the role level. With the
standard functionality this is not possible.
So we decided to create a form to assign the rates to the project roles. But i would prefer enabling the flexfield in
the Project Roles definition form and then assigning rates in one of the segments.
The first step here is enabling the flexfield in the Project Roles forms.
1. Enable DFF segments for the Project Role Type DFF.

2. Add the Cost Rate Segment - Which maps to the Attribute1 of the PA_PROJECT_ROLE_TYPES_B
table.

3. In the PA Implementation SU resp, Setup->Projects-> Roles,assign the cost rate to the respective
roles.

4. Now we have to modify the Labor costing client extension provided by Oracle . Below is an example of how to
obtain the cost rate and calculate the cost.
Labor Costing Extension Package: PA_Client_Extn_Costing
under patch/115/PAXCCECB.pls
procedure Calc_Raw_Cost(
x_transaction_type
in varchar2 default 'ACTUAL',
x_expenditure_item_id in number,
x_sys_linkage_function in varchar2,
x_denom_raw_cost
in out number,
x_status
in out number )
is
l_cost_rate Number;
l_quantity Number;
begin
-- Reset the output parameters.
x_denom_raw_cost := NULL;
x_status := 0;
if ( x_transaction_type = 'ACTUAL') then
if (x_sys_linkage_function = 'ST') then
begin
select to_number(roltyp.attribute1)
into l_cost_rate, l_quantity
from pa_project_role_types_vl roltyp,pa_expenditure_items_all ei,
pa_project_players ppp, pa_expenditures_all exp
where roltyp.project_role_type = ppp.project_role_type
and ppp.project_id = ei.project_id
and ei.expenditure_id = exp.expenditure_id
and ppp.person_id = exp.incurred_by_person_id
and ei.expenditure_item_id = x_expenditure_item_id;
x_denom_raw_cost := l_cost_rate * l_quantity;
Exception
When no_data_found then
Null;
End;

null;
else

-- Add your calculation of overtime expenditure item.


null;
end if;
elsif ( x_transaction_type = 'FORECAST') then
-- Add your calculation for forecast
null;
end if;
exception
when others then
-- Add your exception handler here.
-- To raise an application error, assign a positive number to x_status.
-- To raise an ORACLE error, assign SQLCODE to x_status.
null;
end Calc_Raw_Cost;
Assumption: Here we are assuming that all employees who enter expenditures for the project are assigned Roles.

Custom Project Numbering in Oracle Projects


Some of the companies they want to customize the way automatic project numbering is working in projects. One
such requirement is to have different project number sequences for different OUs.
Since the projects numbering is based on a sequence if the automatic project numbering is on and is common for
all the OUs, there is not a way to have a different sequence for different OU.
Here is a way where you can customize it:
Using customization we can achieve it.
1. Set the project numbering to be manual.
2. Create one sequence for each OU.
3. Customize the projects creation page to automatically populate the project number to a prefix + sequence
number corresponding to the OU.
Lets say the prefix: ABC for OU ABC Inc
then the project number is ABC1
and prefix : XYZ for XYZ inc
then the project number is XYZ1.
This way we can acheive unique numbering across the OUs and at the same time different sequencing for different
OU

Enhancements in Oracle Projects


Some of the enhancements to Projects can be :
1. Adding/Updating a single Task Across multiple project.
2. Adding multiple tasks to multiple projects at a time.
3. Adding /Updating a key member across a project.
4. Publishing Multiple Projects at a time.
These enhancements will save more time to any organization.
All these can be achieved using Oracle Projects AMG API and private APIs.
We will see how we can achieve this in the coming articles

Oracle Projects- Accounts Payables Integration


PA - AP Flow:
Here iam considering the AP invoice integration with Oracle Projects. I will explain about the Expense Reports flow
in another topic.
This integration involves 2 sub processes given below:

Interfacing Supplier Invoice From Oracle Payables To Oracle Projects

Interfacing Supplier Invoice Adjustments From Oracle Projects To Oracle Payables


Interfacing Supplier Invoice From Oracle Payables To Oracle Projects:
This process involves :

1.

Creating the invoice.

2.

Approve the invoice.

3.

Account for the invoice in payables.

4.

Run the 'Interface Supplier Costs' process in Oracle Projects which interfaces the invoices from AP to PA.
Interfacing Supplier Invoice Adjustments From Oracle Projects To Oracle Payables:
This process involves:

1.

2.
3.

Adjust the supplier invoice interfaced to Oracle Projects by either splitting the quantity or transferring an
invoice from one project/task to another.
Execute the PRC: Distribute Supplier Invoice Adjustment Costs process in Oracle Projects.
Run the PRC: Interface Supplier Invoice Adjustment Costs to Payables process in Oracle Projects.
Important Project Related Fields in AP:

Project Name - Project Name to which the Invoice is accounted in Payables.

Task Number - Task Number of the Project to which the invoice is accounted. Note: If the Task is not
chargeable, the system displays the following error message: APP-PA-19270 The Task is Not Chargeable. The same
error will be received if the Chargeable Flag is not checked while defining Tasks in Projects Setup or if the task is a
Parent Task. Expenditures cannot be created at the Parent Task level.

Expenditure Types - Expenditure Type of the invoice. This is based on the projects expenditure types
(pa_expenditure_types table)

Expenditure Item Date - The date of the invoice expenditure item to be created in Projects.

Expenditure Organization - Active Project Expenditure/Event Organization against which the invoice has
to be mapped.
The Expenditure Org can be find in PA_ALL_Organizations table with pa_org_use_type = 'EXPENDITURES'. For any
organization to be a Expenditure Organization, it has to be classified in HR as 'Expenditure/Event Organization'.

Quantity - Based on the Expenditure Type definition, quantity is verified by checking the PA_QUANTITY
column in the AP_INVOICE_DISTRIBUTIONS_ALL. If the COST_RATE_FLAG column in PA_EXPENDITURE_TYPES table is
set to Y, then the quantity field in the Payables Invoice Workbench needs to be filled in.

Once all the requisite information has been entered and the invoice distribution saved, the system checks whether
the values given in the Project, Task, Expenditure Type and Expenditure Organization fields are active as of the
Expenditure Item Date.
The following columns in the AP_INVOICE_DISTRIBUTIONS_ALL table are relevant for project-related supplier
invoices:

1.

PROJECT_ACCOUNTING_CONTEXT - This column is set to Yes if the Project ID column is filled.

1.

ASSET_ADDITION_FLAG - If the project-related invoice distribution is charged to a Capital Project, then


the ASSET_ADDITION_FLAG is set to P when the PA_ADDITION_FLAG is set to Y, Z or T.

To avoid the same invoice distribution being interfaced to both Projects and Fixed Assets, you must interface any
project-related invoice distribution to Oracle Projects before you interface it to Oracle Assets.

1.

PA_ADDITION_FLAG - The PA_ADDITION_FLAG tracks the status of project-related supplier invoice


distribution lines and expense report distribution lines. For supplier invoice distributions entered via Oracle
Payables, the PA_ADDITION_FLAG is set to N if the distribution is project-related, otherwise it is set to E and it is
updated by Oracle Projects when the distribution is processed by the Oracle Projects Interface Supplier Invoice
process. Oracle Projects sets the PA_ADDITION_FLAG to Y or Z after the item is successfully processed, or may be
set to a rejection code if the line is rejected during transfer to Projects. For supplier invoice adjustment lines
interfaced from Projects to Payables (which must net to zero with another line), the value for the
PA_ADDITION_FLAG is set to T. Listed below are the Quick Codes available for the PA_ADDITION_FLAG:

B No open PA period
C Task does not allow charges
D Outside project dates
E Non-project related invoice distributions
I Outside task dates
J Project level transaction controls violated
K Task level transaction controls violated
M Invalid project/task combination
N New line not yet processed by Oracle Projects
P Project is closed
Q Transaction control extension violated
S Temporary status used during processing
T Adjustment line transferred from Oracle Projects
V Invalid data (catch-all error)
X Burdening error
Y Transferred to Oracle Projects
Z Net zero adjustment line. Never transferred to PA

If an item is rejected, you must correct the rejection reason and re-run the interface process.
Once the Invoice is interfaced to Projects, the following tables are populated with appropriate values:

PA_EXPENDITURE_GROUPS_ALL

PA_EXPEDITURES_ALL

PA_EXPENDITURE_ITEMS_ALL

PA_COST_DISTRIBUTION_LINES_ALL
The interrelationship between the relevant Payables and Projects tables are as follows:

AP_INVOICES_ALL

PA_EXPENDITURES_ALL

PA_COST_DISTRIBUTION_LINES_ALL

INVOICE_NUM

ORIG_USER_EXP_TXN_REFERENCE

INVOICE_ID

ORIG_EXP_TXN_REFERENCE1

SYSTEM_REFERENCE2

VENDOR_ID

VENDOR_ID

SYSTEM_REFERENCE1

ORG_ID

ORG_ID

ORG_ID

AP_INVOICE_DISTRIBUTIONS_ALL PA_EXPENDITURE_ITEMS_ALL

PA_COST_DISTRIBUTION_LINES_ALL

DISTRIBUTION_LINE_NUMBER

SYSTEM_REFERENCE3

DIST_CODE_COMBINATION_ID

DR_CODE_COMBINATION_ID

INVOICE_ID

SYSTEM_REFERENCE2

EXPENDITURE_TYPE

EXPENDITURE_TYPE

EXPENDITURE_ORGANIZATION_ID

EXPENDITURE_ORGANIZATION_ID

PROJECT_ID

PROJECT_ID

PROJECT_ID

TASK_ID

TASK_ID

TASK_ID

EXPENDITURE_ITEM_DATE

EXPENDITURE_ITEM_DATE

GL_DATE

ORG_ID

ORG_ID

ORG_ID

PA_QUANTITY

QUANTITY

QUANTITY

AMOUNT

RAW_COST

AMOUNT

It is possible to map between the TRANSFER_STATUS_CODE column in the PA_COST_DISTRIBUTION_LINES_ALL table


and the PA_ADDITION_FLAG column in the AP_INVOICE_DISTRIBUTIONS_ALL table. TRANSFER_STATUS_CODEs
available in the PA_COST_DISTRIBUTION_LINES_ALL table for supplier invoices are:

V- Interface from Oracle Payables - Upon creation set to Received

P - Pending - Upon execution of Distribute Cost Process after Supplier Invoice Adjustments

G - If payables rules do not allow adjustments to the invoice (example: if the invoice is cancelled), then
distribute supplier invoice adjustments program would create the CDL and set the value to (G), these lines will
always reside in Oracle Projects and will not be transferred to Oracle Payables

A - Transfer Costs - If successfully transferred to Oracle Payables, set to Accepted

X - Rejected in transfer to Oracle Payables, set to Rejected in Transfer

How to capture the Project information in AP Expense


Reports?
Here is a different requirement:
Customer wanted to use the AP expense report form to enter expense reports to Projects as well though you can
enter expense reports directly in AP invoice entry form / Projects Expenditure entry.
This can be achieved by customization.
Here are the steps:

1. In the flexfield 'AP Expense Report Line' add the following segments:
1. Segment: Project Number, Valueset : PA_SRS_Project_ID
2. Segment: Task Number , Valueset: PA_SRS_Task_ID
3. Segment: Expenditure_Type,Valuset: PA_SRS_Expenditure_Type
4. Segment: Expenditure_Organization,Valueset: PA_SRS_Expenditure_Organization
So whenever an AP expense report is entered, these fields are captured in the 'AP_Expense_Reports_lines'
attributes.
Now the expense report is converted into AP invoices using 'AP invoice import process'. These invoices anyway will
not have the projects information. So we need to look back into the attributes captured in the Expense report lines
and update the ap_invoice_distributions_all table.
So write a concurrent program for acheiving the same. The update statement should update the below fields:
ap_invoice_d istributions_all.project_id
ap_invoice_distributions_all.task_id
ap_invoice_distributions_all.expenditure_type
ap_invoice_distributions_all.expenditure_item_Date
ap_invoice_distributions_all.expenditure_organization_id
ap_invoice_distributions_all.project_accounting_context -> this should be set to 'Yes' to interface the invoices to
Projects.
ap_invoice_distributions_all.pa_addition_flag -> this should be set to 'N' to set the lines eligible for interface to
Projects.
Once the above update is done, the invoice can be interfaced to projects by running the 'PRC:Interface Supplier
Costs' process from PA

Oracle Projects information in OTL


How to capture extra information in Project related Timecards in OTL ?
Here i will discuss about how to capture extra information in the OTL timecards and transfer it to the Expenditure
items table DFF attributes.
Here are the steps.

1. Enable the 'Expenditure Items' Descriptive Flexfield in the Application Developer and enter the segments.
Unfreeze the flexfield first and then make the changes.
in the 'Global Data Elements' context. You can enter more than one segment depending on how many fields you
want to capture in OTL.

Note: Please make sure you have enabled the segment and make it visible. Also the required check
box should be OFF , unless you want to make this segment mandatory.
2. Enable the DFF context 'Global Data Elements' and then Freeze the flexfield and compile.

3. In OTL Application Developer Responsibility, run the 'Generate Flexfield and Mapping Process' with the
parameters :
Effective Date : can be given sysdate or any date before.
Include Expenditure Items Flexfield : Yes

4. In Application Developer responsiblity, query for the 'OTL Information Types' flexfield and then query for the
'PAEXPITDFF-GLOBAL' context value.
Then unfreeze the DFF and enable the PAEXPITDFF-GLOBAL Context and then compile. Also you can verify that this
DFF has pulled in the segments from the Expenditure Items DFF after the 'Generate Mapping' process is run.
This Context PAEXPIT-DFF is automatically generated pulling any of the DFF segments in the Expenditure items DFF.
Now we have defined a new DFF segment called 'Work type' in Expenditure Items DFF and this will be available in
PAEXPITDFF-GLOBAL.

5. Now goto Selfservice time responsibility and enter a timecard and click on Details. You will now see the DFF
segment 'Work Type' being shown for each day entry.
You can even attach an Valueset to the segment in the Expenditure Items DFF and you will see an LOV here.

Also Note: Any change to the DFF has to be made in Expenditure Items DFF and then the Generate
mapping process will pull the changes into PAEXPITDFF-GLOBAL. You cannot manually do the changes
in segments in the PAEXPITDFF-GLOBAL context.

Oracle Projects - Fixed Assets Integration


In this article, i will explain the steps involved in the interface of Capital Projects Assets to Fixed Assets.
1. Enter the cost that you want to capitalize either in the Pre-approved expenditure entry or through transaction
import or from Payables or other modules.
2. Run the distribute process for the type of cost that you are dealing with. (i.e labor, usage, and miscellaneous
cost. )
3. If the item is from Payables, you need to run the 'PRC: Interface Supplier Costs' process.
4. Interface Raw Cost and Burden Cost to GL. You may need to run the suitable process from the list below:
PRC:
PRC:
PRC:
PRC:

Interface
Interface
Interface
Interface

Labor cost to GL
Total Burdened Cost to GL
Usage and Miscellaneous Cost to GL
Supplier Invoice Adjustments to AP(if item is from payables).

5. Define Assets under Projects

6. Assign Assets to a Task/Project in Oracle Projects.

7. Place the Assets in service.


8. Run the 'PRC: Update Project Summary Amounts' to update the Cost buckets.
9. Run the 'PRC:Generate Asset Lines' process to generate Asset Lines in PA.
10. Run 'PRC: Interface Assets' process to interface Asset Lines to FA.
11. In Fixed Assets post the Asset Lines you have interfaced from PA to FA.
Things you may have to check before generating asset lines:
1. Check all the costs have been cost distributed( You need to run the appropriate cost distribution process
labor, expense, miscellaneous etc depending upon your expenditure type).
2. Check the project type for the project. In the capitalization information, alternate region it indicates whether raw
or burden costs are being capitalized. If burden costs are used, then nothing will get picked up unless Distribute
total Burden costs has been run.
3. Make sure that the assets have an in-service date and that the report parameter Date Placed In Service Through
includes this date.
4. Check the PA Date Through parameter used. Note that this must be at least the last day of the period which
includes the PA Date of the cost distribution lines of the expenditure.
If this date is not the last day of a period, the process will select the first date which is a last day of a period prior to
the date entered.
Lets say your PA periods are like below:
JAN-09 01-JAN-09 to 31-JAN-09 FEB-09 01-FEB-09 to 28-FEB-09
If you have CDL's with a PA date of 15-FEB-09, and you enter a PA date through 25-FEB-09, these CDL's will not be
picked up because the process will not actually use the date 25-FEB-09, but rather the first period ending date prior
to that date, or 31-JAN-09.
5. Check the project status. In Setup-Projects-Status, make sure that the project's current status has the Capitalize
Assets action allowed.

Cost Collector Troubleshooting


In case the transactions are not interfaced from Project Inventory to Oracle Projects. You need to make sure the
following setups.
1. Check the Project references box.When you check this box, the organization is Project References enabled.
Project number and, optionally, task numbers can be associated with the transactions.

2. Select a Common Project. Selecting a common project enables you to track the cost of manufacturing
transactions that have not been associated with a specific project. You can set up a different common project for
each inventory organization.
3. Under Project, setup, PJM parameters, Cost Group option set value to "By Project". If the cost group option
"Inventory" is chosen, cost collection is only supported for capital project transactions, and transactions will not be
cost collected.
3. Cost Collection enabled. The cost collector can run in these organizations and post transactions into Projects
interface for transactions belonging to this organization. INV-->Setup-->Organizations-->Parameters-->Costing
Information
4. Associate Expenditure Types with Cost elements.A expenditure type for IN and another one for OUT has to be
defined.
In expenditure types are used to cost the value of transfers into a project. Out expenditure types are used to cost
the value of transfers out of a project. (Cost -> Setup -> Expenditure Types for Cost Elements form)
IF the value of profile "INV: Project Miscellaneous Transaction Expenditure Type"? if it has been set to User Entered,
then check the Cost Element- Expenditure type association form, need to set the IN and OUT expenditure types for
ALL cost elements.
If they have not then once again only Project Miscellaneous transactions will
be cost collected and all other transaction families will only be marked as "not applicable"
5. Define project cost groups and associate WIP accounting classes with each project cost group. For each project
cost group, you must define five elemental subinventory valuation accounts, an average cost variance account, and
an encumbrance account. You can use different accounts or the same account for all five elemental accounts. The
Cost Collector collects costs by project, task, and expenditure type. Associating expenditure types with cost
subelements ensures that project manufacturing costs can be collected and transferred to Oracle Projects.
6. Set profile option: INV: Project Miscellaneous Transaction Expenditure Type to User Entry
Note: If the value of this profile option is set to System Defined, the process is not going to work as the system will
be looking for a link between all cost elements and expenditure types, even though there is only material cost
element and it is impossible to create other cost elements and link them to expenditure types. This is probably
possible if Project Manufacturing is installed.
INV_PROJ_MISC_TXN_EXP_TYPE
INV: Project Miscellaneous Transaction Expenditure Type (0:System defined, 1:User entered)
If the profile option 'INV: Project Miscellaneous Transaction Expenditure Type'
is set to : "User entered" , not defining expenditure types for all cost elements could cause
reported issue since only project miscelaneous transaction (transaction types with type_class = 1) will be cost
collected, and Project Transfer is NOT a project miscelaneous transaction.
7. Run cost collection manager (SRS)
Path: INV--> Costs-->Accounting close cycle-->Project cost transfers
Parameters: Number of days to leave costs uncollected: 0
Note: You can choose here the number of whole days that you want to use as transfer time fence. For example if
you choose 1 then the transactions of today will not be interfaced; if you choose 2 the transactions of yesterday and
today will not be interfaced and so on.
The request will start the Cost Collection Manager and if it finds any costed material transactions with correct
project information, it will start the Material Cost Collection Worker processes to insert records into the
PA_TRANSACTION_INTERFACE_ALL.
The Cost collection manager will spawn the material cost collection worker if it finds any elegible material
transaction to be cost collected
8. Run Transaction Import in Project Accounting
Path: Projects-->Control-->Transaction Import-->Project Transaction Import -->Import Transactions
Parameters: Transaction Source: Inventory Misc, Batch: empty
9. Review imported or failed records
Path: Projects ->Control ->Transaction Import ->Project Transaction Import -> Review Transactions (form), if the
records have been rejected, correct and re-import on line.
10. Check mtl_material_transactions table for PM_COST_COLLECTED FIELD and PM_COST_COLLECTOR_GROUP_ID
fields to not null .

11. Is the item an Asset Item. Is the Subinventory an asset subinventory.


Except for some transactions in PO family, only asset subinventories and asset items are transferred
other scenarios are not supported, check the user's guide for eligibility, there is a section on that.

13. Oracle Project Manufacturing's Cost Collector allows you to transfer manufacturing costs to Oracle
Project. However, the manufacturing cost here means the cost of Work Order, inventory transactions and labor
cost related to the WO.
Sales Order is not considering as manufacturing cost, it goes to GL directly through Oracle Project.
Please review Metalink Note 434704.1- Unable to Create Project Material Cost Transactions From Sales
Order Shipment and Note 238695.1- Internal Sales Order Not Interfacing To Projects
14. If the transaction has not crossed projects or at least cross tasks it is not eligible for cost collection, this is in
the User's Guide, chapter 8. Check fields source_project_id, source_task_id, and project_id and task_id in MMT, if
they are the same then it is not eligible to be transferred since there is no net change in the project.
15. Sales order issue and Internal Order issue transactions are not cost collected
Sales Order Pick transaction is cost collected
This is documented in Cost Management User's Guide section 7-21:
"Transactions that are not cost collected include:
Sales order issues
Work in Process component issues from the same project/task as the project/task on the WIP job
Assembly completions
Average and standard cost updates
Job close and average cost variances
Scrap transactions"

16 . For "Project transfer" transaction


NAV:Inventory, Transactions, Borrow Payback transactions, Project Transfer
The transaction that should be cost collect is the one with the negative quantity, it will create entries for both
Project and TO Project, or a single entry if this is from non project to project or vice versa.

There are two transactions created for project transfer transaction. The distributions are all done against the issue
transaction and the cost collector collects the issue transaction. Hence the issue transaction shows "Yes" in the
"Transfer to Projects" field and the receipt shows "Not applicable" in the receipt transaction.
Set profile option: INV: Project Miscellaneous transaction to System Defined

Oracle Projects Migration/ Data Conversion


In this article I will be explaining the general steps involved in any Conversion/Data Migration of Oracle Projects
module.
At the end of this article, you would have learned:
1.

Stages in Oracle Projects Conversion.

2.

How to setup the Oracle Projects module for the conversion/Data Migration.

3.

Options for the Load (flat file, csv, or direct Loads).

4.

Oracle Projects AMG APIs needed to perform the Conversion.

5.

Testing the Conversion Process.

6.

Verifying the Conversion Process.


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.
How to deal with it ?
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.
Stages in Oracle Projects Conversion
7.

8.

Projects.

The First Stage is to obtain the data from the Legacy System which needs to be migrated to Oracle

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.
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.

1.

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.
Oracle Projects Setup For Conversion
<!--[if !supportLists]-->
<!--[endif]-->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 !supportLists]-->
<!--[endif]-->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 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 to
create the budgets for the migrated projects.
<!--[if !supportLists]-->
<!--[endif]-->Implementation Option Setup:
Project Numbering: This implementation option is by default set to 'Automatic' which means when creating
projects in Oracle Projects, the project number is automatically derived and users are not required to provide any
project 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 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'.
<!--[if !supportLists]-->
<!--[endif]-->Setup Transaction Source:
The Transaction Source needs to be setup in Oracle Projects in the Transaction Sources form in Oracle Projects
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 API's what is the source system and how the data is
handled when it is imported to Oracle Projects.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->Setup Employee Cost Rates:
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.
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 timecards.
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.
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 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.
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

Contract

Contract_Templ
ate

Template

Indirect

Indirect_Templa
te

Expenditure
Type

Hours

Labor

Expenditure
Type

Expenses

Employee_Expe
nse

Transaction

Transaction
Source

Legacy1

Product Code

Product code

LEGACY1

Project

Publish
Workplan

Yes

Project

Baseline
Workplan

Yes

Cost Budget

Baseline

Yes

Revenue
Budget

Baseline

Yes

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.
Project/Task - Setup Validations:
<!--[if !supportLists]--> <!--[endif]-->Validate the Product code is setup.
<!--[if !supportLists]--> <!--[endif]-->Validate if the required Project Templates are setup.
<!--[if !supportLists]--> <!--[endif]-->Validate if the Project Numbering is set to 'Manual' for creating projects with
the predefined project numbers.
Project/Task Data Validations:
<!--[if !supportLists]--> <!--[endif]-->Validate if the project name is unique. Project with the same name should not
exist in Oracle Projects.
<!--[if !supportLists]--> <!--[endif]-->Validate if the project number is unique. Project with the same number should
not exist in Oracle Projects.
<!--[if !supportLists]--> <!--[endif]-->Validate if the project long name is unique. Project with the same long name
should not exist in Oracle.
<!--[if !supportLists]--> <!--[endif]-->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)
<!--[if !supportLists]--> <!--[endif]-->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.
<!--[if !supportLists]--> <!--[endif]-->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.
<!--[if !supportLists]--> <!--[endif]-->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.
<!--[if !supportLists]--> <!--[endif]-->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:
<!--[if !supportLists]-->
<!--[endif]-->Validate if the Transaction source is setup.
<!--[if !supportLists]-->
<!--[endif]-->Validate if the Expenditure type is setup.
Data Validations:
<!--[if !supportLists]-->
<!--[endif]-->Check if the hours value is greater than zero.
<!--[if !supportLists]-->
<!--[endif]-->Check if the employee number is valid in HR and is active on the timecard
date.
<!--[if !supportLists]-->
<!--[endif]-->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:
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->Budget amount has to be greater than zero.
<!--[if !supportLists]-->
<!--[endif]-->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.
Agreements and Funding Validation
Data Validations:
<!--[if !supportLists]-->
<!--[endif]-->Agreement type should be valid.
<!--[if !supportLists]-->
<!--[endif]-->Agreement Amount should be greater than zero.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->Funding amount has to be within the Agreement amount.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
Revenue and Invoice Validations:
Data Validations:
<!--[if !supportLists]-->
<!--[endif]-->Project / Task should already been converted to Oracle.
<!--[if !supportLists]-->
<!--[endif]-->Event amount should be non zero.
<!--[if !supportLists]-->
<!--[endif]-->For revenue event revenue amount should be populated.
<!--[if !supportLists]-->
<!--[endif]-->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 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.
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

PA_PROJECT_PUB.CREATE_PROJECT

Budgets Conversion

PA_BUDGET_PU B.CREATE_DRAFT_BUDGET,
PA_BUDGET_PUB.BASELINE_BUDGET

Agreements

PA_AGREEMENT_PUB.CREATE_AGREEMENT

Funding

PA_AGREEMENT_PUB.ADD_FUNDING

Revenue/Invoice

PA_EVENT_PUB.CREATE_BILLING_EVENT

User Defined Attributes (UDA)

PA_PROJECT_PUB.LOAD_EXTENSIBLE_ATTRIBUTE

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 need to 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'.
For code samples: http://www.projectsaccounting.com/code-snippets
Conversion Tips:
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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.

<!--[if !supportLists]-->
<!--[endif]-->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.
<!--[if !supportLists]-->
<!--[endif]-->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 .

Import legacy Timesheets to Oracle Projects


This article gives you a brief understanding and sample code snippet of how to import legacy timesheets into oracle
projects.
Steps:
1. Populate the transaction interface table pa_transaction_interface_all.
2. Run the PRC: Transaction Import process for the Transaction Source/ batch name.
3. Run the Distribute Labor Costs process if the transactions are not costed.
Populating the Transaction Interface Table:
Below is a code snippet of how to populate the interface table:
NOTE:This code populates the interface table with the uncosted transactions, so there is no need of populating the
cost columns.
If you are importing costed transactions, then you have to supply the denom_raw_cost,
acct_raw_cost,burdened_cost, denom_currency_code and other burden cost columns if you are importing the
burden amounts as well.
Also if you are importing the GL accounted transactions, then you have to provide the Debit and Credit CCIDs.

Procedure Populate_Interface_Table
Is
CURSOR Txn_Cur IS --Cursor for the transactions that belong to 2007 and beyond
SELECT 'ABC' transaction_source, /** Transaction Source should have been defined ***/
'ABC-BATCH' batch_name,
hrorg.NAME organization_name,
pa_utils.getweekending (expenditure_item_date) expenditure_ending_date,
expenditure_item_date,
pap.segment1 project_number,
pat.task_number,
'Internal Labor' Expenditure_Type,
txn.total_hours,
employee_role,
'Hours From ABC' expenditure_comment, 'P' transaction_status_code,
txn.txn_reference,
'Y' unmatched_negative_txn_flag,
'N' billable_flag,
pap.org_id,
txn.employee_number,
fnd_global.login_id created_by,
SYSDATE creation_date,
fnd_global.login_id modified_by,
SYSDATE modified_date
FROM ABC_Legacy_Timesheets txn,
pa_projects_all pap,
pa_tasks pat,
hr_all_organization_units hrorg
WHERE txn.project_id = TO_NUMBER (pap.pm_project_reference)

AND
AND
AND
AND
AND

pap.project_id = pat.task_id
pat.pm_task_reference = txn.task_id
hrorg.organization_id = pap.carrying_out_organization_id
txn.valid_flag = 'Y'
txn.converted_flag = 'N';

Begin
For txn_rec in txn_cur Loop
Insert into pa_transaction_interface
(
transaction_source
,
batch_name
,
expenditure_ending_date
,
organization_name
,
expenditure_item_date
,
project_number
,
task_number
,
expenditure_type
,
quantity
,
expenditure_comment
,
transaction_status_code
,
orig_transaction_reference
,
unmatched_negative_txn_flag
,
billable_flag
,
org_id
,
employee_number
,
attribute_category
,
attribute1
,
created_by
,
creation_date
,
last_updated_by
,
last_update_date
)
VALUES
(
txn_rec.transaction_source,
txn_rec.batch_name,
txn_rec.expenditure_ending_date,
txn_rec.organization_name,
txn_rec.expenditure_item_date,
txn_rec.project_number,
txn_rec.task_number,
txn_rec.expenditure_type,
txn_rec.total_hours,
txn_rec.expenditure_comment,
txn_rec.transaction_status_code,
txn_rec.txn_reference,
txn_rec.unmatched_negative_txn_flag,
txn_rec.billable_flag,
txn_rec.org_id,
txn_rec.employee_number,
'Global Data Elements', /** Attribute category ***/
txn_rec.employee_role, /** this is attribute1 of the expenditure item **/
txn_rec.created_by,
txn_rec.creation_date,
txn_rec.modified_by,
txn_rec.modified_date
);
End Loop;
commit;
Exception
When OTHERS then
print_log('Exception in procedure : Populate_Interface_Table: ' || SUBSTR(SQLERRM,1,100));

END;

RAISE;

2. Run the PRC: Transaction Import Process , for the source 'ABC' and batch name 'ABC-BATCH'.
3. Run the Distribute Labor Costs since these transactions are not costed

You might also like