Oracle Projects Basics
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.
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
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.
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.
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.
MESSAGE TEXT
PA_AA_AA_ERROR
PA_AA_ABORTING
PA_AA_BAD_APPLICATION
PA_AA_ENTER_CONSTANT_VALUE
PA_AA_ENTER_FF_STRUCTURE
PA_AA_ENTER_PARAMETER_NAME
PA_AA_ENTER_SQL_STATEMENT
PA_AA_ERROR
PA_AA_FIELD_NOT_COPIED
PA_AA_FIRING_RULE
PA_AA_FUNC_UNINIT
PA_AA_FV_ERROR
PA_AA_INVALID_MODE
PA_AA_INVLD_KEY_SRC
PA_AA_INVLD_RULE_TYP
PA_AA_INVLD_SQL_PARAM
PA_AA_LESS_PARAMS
PA_AA_LOOKUP_SET_INTEGRITY
PA_AA_MISSING_TOKEN
PA_AA_MULT_ROWS
PA_AA_NOT_ENF_ARGS
PA_AA_NO_DB_CNCT
PA_AA_NO_DESCRP
PA_AA_NO_DETAIL_POST
PA_AA_NO_LOOKUP
PA_AA_NO_MEMORY
PA_AA_NO_PARAMS
PA_AA_NO_ROWS
PA_AA_NO_RULE_PARAM
PA_AA_NO_SUCH_FNCT
PA_AA_NO_SUCH_TKN
PA_AA_NO_SUCH_TRANS
PA_AA_NO_TRANS
PA_AA_NULL_SELECTED
PA_AA_OUT_OF_MEMORY
PA_AA_RULE_INTEGRITY
PA_AA_SEG_ORDER_LBL
PA_AA_SUMMARY_ALLOWED
PA_AA_TOO_MANY_PARMS
PA_AA_TOO_MANY_QULFRS
PA_AA_TOO_MANY_ROWS
PA_AA_TOO_MANY_RULES
PA_AA_TOO_MANY_SQL_PARAMS
PA_AA_TOO_MANY_TOKNS
PA_AA_TOO_MANY_TRANS
PA_AA_TOO_MANY_TRIGS
PA_AA_TRANS_UNKNOWN
PA_AA_VALUE_MATCH_NOT_UNIQUE
PA_AA_VALUE_TOO_LARGE
PA_AA_WARNING
PA_AA_WRONG_FF
PA_AA_WRONG_KEY_SRC_TYPE
PA_AA_WRONG_N_CLMS
PA_AA_WRONG_PARAM
PA_AA_WRONG_RULE_TYPE
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:
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:
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
RESULT_CODE
DESCRIPTION
RESULT
F01
Fail
F02
Fail
F03
Fail
F04
Fail
F05
Fail
F06
Fail
F07
Fail
F08
Fail
F09
Fail
F10
Fail
F100
Insufficient funds
Fail
F101
Fail
F102
Fail
F103
Fail
F104
Fail
F105
Fail
F106
Fail
F107
Fail
F108
Fail
F109
Fail
F110
Fail
F111
Fail
F112
Fail
F113
Fail
F114
Fail
F115
Fail
F116
Fail
F117
The transaction failed because of errors in one or more cost distribution lines
Fail
F118
Fail
F119
Fail
F120
Fail
F121
Fail
F122
Fail
F123
Fail
F124
Fail
F125
Fail
F127
Fail
F128
Fail
F129
Start date or end date is null for the specified date range
Fail
F130
Fail
F131
Fail
F132
Fail
F134
Fail
F135
Fail
F136
Fail
F137
Fail
F138
Fail
F140
Funds check failed due to fatal error while inserting burden cost
Fail
F141
Fail
F142
Fail
F143
Fail
F144
Fail
F145
Fail
F146
Fail
F150
Fail
F151
Fail
F152
The CBC funds check failed for the check funds mode
Fail
F153
Fail
F155
Fail
F156
Fail
F157
Fail
F158
Fail
F160
Fail
F161
Fail
F162
Fail
F163
Fail
F164
Fail
F165
Fail
F166
Fail
P101
Pass
P102
Pass
P103
Pass
P104
Pass
P105
Pass
P106
Pass
P107
Pass
P108
Pass
P109
Pass
P110
Pass
P111
Pass
P112
Pass
P113
Pass
P114
Pass
P115
Pass
P116
Pass
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.
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]-->
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]-->
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]-->
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]-->
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]-->
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:
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.
<!--[if !supportLists]-->
Data Validations:
<!--[if !supportLists]-->
<!--[if !supportLists]-->
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]-->
<!--[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.
<!--[if !supportLists]-->
<!--[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]-->
<!--[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]-->
<!--[if !supportLists]-->
<!--[if !supportLists]-->
<!--[if !supportLists]-->
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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
2.
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.
<!--[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.
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
1.
2.
3.
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:
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.
1.
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.
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
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
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
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.
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).
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 .
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"
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
2.
How to setup the Oracle Projects module for the conversion/Data Migration.
3.
4.
5.
6.
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
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 .
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