Oracle Projects Basics PDF
Oracle Projects Basics PDF
In this Blog, I will be giving an introduction on what is Oracle Projects module in the Oracle Apps Ebiz Suite.
Project Costing
Project Billing
Project Foundation
Project 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.
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.
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'.
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.
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
Below are Steps that needs to be followed for successfully creating a Projects Invoice and interfacing it to Oracle
Receivables.
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_PROJECT_PLAYERS - Contains the Key Member Assoications with the Project including the Project managers.
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:
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:
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.
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:
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.
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:
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:
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.
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.
Tech info:
Tables/Views involved:
RA_INTERFACE_LINES_ALL
}[/dropcap]
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
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.
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
Step 2
Create Event Types with classifications 'Realized Gains' and 'Realized Losses' and associated them in
the Project Types window mentioned above.
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-> Assign Rules - > Query for 'Revenue and Invoice Accounts'
and Find.
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
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:
Query to Find the XLA Events for the above expenditure item:
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:
b. To select all event data for Projects related events where the process status code is 'I' (Invalid):
c. To select all event data related to a particular expenditure item with 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:
f. To select all accounting event line data for an expenditure item with 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:
h. To show accounting event headers that indicate they are finally accounted, but cannot be found in General
Ledger (GL):
The main account generator processes that relate to Oracle Projects are:
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 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".
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.
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.
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
How to setup the Oracle Projects module for the conversion/Data Migration.
Scenario:
Company 'XYZ' is using a Project Management and Accounting Software for years long. The Management has
decided to move from their existing system to Oracle Projects module because of its vast functionality and
integration with Other financial modules.
Now the question arises: What data to migrate from the legacy system to Oracle Projects?. Well, it depends
upon the type of projects.
If the Projects are used for Internal Administration and tracking of costs, you may want to migrate the existing
projects, tasks(the work break down structure), Cost Budgets, Cost (Timecards, Employee Expenses, Miscellaneous
Expenses) etc.
If the Projects are used for billing the Clients for the work done (Typical Contract Projects), then you may want to
Revenue, Agreements(Contracts), Revenue budgets and Invoices in addition to the above data.
Once the decision is made to which data to migrate, then the next step would be setting up the Oracle Projects for
the conversion purpose, which we will see in detail sooner. Once the System has been setup, the technical
elements(programs, concurrent processes etc) have to be created in order to migrate the data from Legacy System
to Oracle Projects.
1. The First Stage is to obtain the data from the Legacy System which needs to be migrated to Oracle
Projects.
2. The Second Stage will be most crucial step in the process which is to massage the data according to the
Oracle Projects Conversion Interface(Programs built using AMG APIs). This Step is indeed time consuming, manual
labor intensive to massage and rectify the errors etc. But completing this step successfully pays dividends in the
consecutive processes / Stages.
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.
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.
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.
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'.
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.
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.
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.
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:
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.
<!--[if !supportLists]-->· <!--[endif]-->Validate if the Project Numbering is set to 'Manual' for creating projects with
the predefined project numbers.
<!--[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:
Data Validations:
<!--[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]-->There is no need to create revenue budgets if the 'Baseline funding without
budget' option is checked at the project or project type level. Whenever the funding is created for the contract
project and is baselined, the revenue budget is automatically created and baselined. If that option is not checked, it
is necessary that a revenue budget with the same amount as the funding amount needs to be created and
baselined in order to baseline the funding.
Data Validations:
The cost budget for the project can be from the source system's budgeting system. If there is no budgeting in the
source system, a cost budget with the total cost of the project can be created in Oracle Projects.
For revenue budgets, it has to be equal to the funding amount of the project. If there is no funding amount in the
source system, the sum of the revenue amount can be the funding amount and it is the revenue budget amount as
well.
Data Validations:
<!--[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]-->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.
Data Validations:
Generally for a project, the total revenue is obtained from the source system and is created as a revenue event for
that project. The total invoiced amount is calculated per project and an invoice event is created for each project.
Once these events are created successfully in the system, the Generate Draft Revenue process and Generate Draft
Invoice process needs to be run so that the desired revenue and invoices are generated.
The revenue and invoice automatic approval and release client extensions can be used to automatically release the
revenue when it is generated and approve/release invoices respectively.
If the revenue amounts are already interfaced to General Ledger(GL) through a different interface, then uncheck the
'Interface Revenue to GL' option in the implementation options and run the 'Interface Revenue to GL' process in
Oracle projects. This will turn the flags in the revenue records as accepted in GL, though it is not interfaced. Once
this is done, revert back the implementation option back to its original state.
If the invoice amounts are already interfaced to Accounts Receivables(AR) by different means, it is not desired to
interface the projects invoices to AR again since it will double the invoice amount in AR. In this case, we do not have
an implementation option like we had for Revenue. So a script can be created to update the Invoice's flag to
Accepted State. Alternatively the generated projects invoices can be interfaced to AR, tied back to Oracle and then
the invoices can be deleted in AR.
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:
Agreements PA_AGREEMENT_PUB.CREATE_AGREEMENT
Funding PA_AGREEMENT_PUB.ADD_FUNDING
Revenue/Invoice PA_EVENT_PUB.CREATE_BILLING_EVENT
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'.
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
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
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 non–team 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.
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.
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.
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 system–generated number that is unique across all projects. In addition, each
change document has a number to identify it within the project (see next page).
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.
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.
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.
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.
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.
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.
Specify whether you want to allow entry of only one class code with this class category for a project.
This controls the ability to associate percentages with classification codes. The system requires class code
percentages or the category regardless of the project type.
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.
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.
Important Columns:
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.
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.
(There are different dates for a project each having its own significance, we will see those in a different topic.)
Tasks:
Important Columns:
(WBS - Work Break down Structure indicates the structure of the Project)
Pm_task_reference: uniquely identifies the corresponding task in the source system (used in conversion projects).
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.
To be continued...
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.
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.
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.
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.
For Case1, Interface the un-interfaced Supplier invoice adjustment records in Oracle Projects.
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.
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:
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.
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]--> <!--[if !vml]--><!--[endif]-->
<!--[if !vml]--><!--[endif]-->
<!--[if !vml]--><!--[endif]-->
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.
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.
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.
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;
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.
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.
3. Customize the projects creation page to automatically populate the project number to a prefix + sequence
number corresponding to the OU.
This way we can acheive unique numbering across the OUs and at the same time different sequencing for different
OU
All these can be achieved using Oracle Projects AMG API and private APIs.
Here iam considering the AP invoice integration with Oracle Projects. I will explain about the Expense Reports flow
in another topic.
4. Run the 'Interface Supplier Costs' process in Oracle Projects which interfaces the invoices from AP to PA.
1. Adjust the supplier invoice interfaced to Oracle Projects by either splitting the quantity or transferring an
invoice from one project/task to another.
2. Execute the PRC: Distribute Supplier Invoice Adjustment Costs process in Oracle Projects.
3. Run the PRC: Interface Supplier Invoice Adjustment Costs to Payables process in Oracle Projects.
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:
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.
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
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
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
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.
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.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
Here i will discuss about how to capture extra information in the OTL timecards and transfer it to the Expenditure
items table DFF attributes.
1. Enable the 'Expenditure Items' Descriptive Flexfield in the Application Developer and enter the segments.
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 :
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:
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.
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.
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)
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
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
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.
2. How to setup the Oracle Projects module for the conversion/Data Migration.
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.
7. The First Stage is to obtain the data from the Legacy System which needs to be migrated to Oracle
Projects.
8. 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.
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:
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.
<!--[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.
Data Validations:
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:
Agreements PA_AGREEMENT_PUB.CREATE_AGREEMENT
Funding PA_AGREEMENT_PUB.ADD_FUNDING
Revenue/Invoice PA_EVENT_PUB.CREATE_BILLING_EVENT
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'.
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 .
Steps:
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 pap.project_id = pat.task_id
AND pat.pm_task_reference = txn.task_id
AND hrorg.organization_id = pap.carrying_out_organization_id
AND txn.valid_flag = 'Y'
AND txn.converted_flag = 'N';
Begin
End Loop;
commit;
Exception
When OTHERS then
print_log('Exception in procedure : Populate_Interface_Table: ' || SUBSTR(SQLERRM,1,100));
RAISE;
END;
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