Release 12.1
Part Number E13581-04
Contents
Previous
Next
| Oracle Projects Fundamentals Release 12.1 Part Number E13581-04 | Contents | Previous | Next |
This chapter describes procedures and activities you need to know about to administer data and settings in Oracle Projects.
This chapter covers the following topics:
Oracle Project Resource Management uses deferred workflow processes and administrative processes to manage changes to your data. You must configure and manage the engines for both types of processes in order to handle the volume of changes happening within your system. For more information on these technologies, refer to:
Oracle Workflow Guide
Oracle Application Object Library User Guide
Most of the changes you make to your data automatically update related information within the application. These changes occur without any intervention on your part. However, some changes require the use of administrative processes to ensure that the change is reflected accurately. In particular, two situations require this level of maintenance:
When the automatic processes encounter errors due to missing or invalid setup information, or due to technical failures
In this case, the system notifies an administrative user of the problem, and advises the user to run an administrative process to complete the changes.
When the changed information is not expected to be done frequently enough to warrant an automatic process
For example, if a change is made to a calendar, you must run the Create Calendar Schedules process to reflect the calendar change throughout the system.
Note: Assign at least one user to the seeded application user Projects Application Administrator. This user receives notifications regarding any encountered workflow processing errors. This user should also have the appropriate authority to run the administrative processes which assist in the correction of some of the errors.
You use Oracle Workflow to run a variety of workflow processes. You can run some of these processes manually, while others are completely automated and run in the background. The latter kind of workflow processes are called deferred workflow processes. Deferred workflow processes depend on actions, such as a status change to trigger the steps of the process. You can customize messages and approval workflow using the Oracle Workflow Builder.
Deferred workflow processes automate time-consuming tasks in the background so that users can continue working in the application without waiting for the task to complete online. For example, a deferred workflow process controls the application of team template requirements to a project. When the system completes the task, it sends a notification to the user that initiated the action.
These deferred workflow processes need at least one background engine to monitor background activities in order to ensure consistent processing. This engine is called the Workflow Background Process. You must submit a request to enable a concurrent program for workflow background processing. Only a user with system administrator responsibilities can run the Workflow Background Process.
Related Topics
Integrating with Oracle Workflow: Oracle Projects Implementation Guide
The following item types exist in the Workflow Background Process for Oracle Projects:
PA Project Assignment: This process controls the routing of project assignment approvals.
PA Apply Team Template: This process handles the task of applying a team template to a project.
PA Candidate Notification Process: This process notifies candidates when they are nominated or withdrawn.
PA Mass Assignment Transaction Workflow: This process handles the creation of assignments when a mass assignment request is submitted.
PA Overcommitment Notification Process: This process notifies users when assignments cause overcommitments.
PA HR Related Updates Workflow: This process synchronizes Oracle HRMS data with Project Resource Management data.
PA Mass Assignment Approval: This process handles the routing of approvals for mass assignments.
PA Advertisements Workflow: This process sends out the advertisement notifications and e-mails.
You can schedule all item types in the Workflow Background Process to run in a single request submission, or you can schedule each item type separately in individual requests. To submit all item types in a single request submission, leave the Item Type parameter blank.
Note: When you leave the Item Type parameter blank, the Workflow Background Process runs for all item types across all Oracle applications. Submitting the process for all item types can affect processing performance.
The following table lists the recommended configuration for scheduling the Workflow Background Process for the Project Resource Management item types:
| Parameters | Request 1 | Request 2 | Request 3 |
|---|---|---|---|
| Repeat Every | 10 minutes | 24 hours | 3 days |
| Minimum Threshold | Leave Blank | Leave Blank | Leave Blank |
| Maximum Threshold | Leave Blank | Leave Blank | Leave Blank |
| Process Deferred | Yes | No | No |
| Process Timeout | No | Yes | No |
| Process Stuck | No | No | Yes |
| Apply the Interval | From the completion of the prior run | From the completion of the prior run | From the completion of the prior run |
| Increment Date | Leave Blank | Leave Blank | Leave Blank |
This configuration demonstrates three concurrently scheduled requests of the Workflow Background Process.
Navigate to the Submit Requests form.
Submit the Workflow Background Process concurrent program as a request.
Specify the item type and other parameters as appropriate.
Schedule the process to repeat itself at appropriate intervals.
For more information on submitting and scheduling the workflow processes, see:
Submitting a Request,. Oracle Applications User's Guide.
Setting Up Oracle Workflow, Oracle Workflow Guide.
When you use Oracle Projects to process activity associated with your projects, data accumulates in the database. This data includes transaction information, asset lines, summary data, historical (prior to Release 12) Multiple Reporting Currency transactions, cross charge transactions, and staffing transactions such as assignments and requirements. You can purge (delete) information that you no longer need to access online.
Purging data can lower operating costs and increase efficiency of the application by:
reducing the amount of disk space that you need to maintain
reducing the time required to back up data
You can also choose to archive any project data that you purge. Summary information can then be used for status reporting or transfer to other applications.
You can use the following purge programs to purge project data:
ADM: Purge Project Data: This process purges and archives project information, as specified for each project in the batch. The process purges the project and the specified project data.
For more information, see Purging Process Overview.
ADM: Purge Resources Unassigned Time: This process purges unassigned time for all resources. Unassigned time includes resource capacity, unavailability, and overcommitment. Submit the process ADM: Purge Resources Unassigned Time for a particular Purge Till Date to clear unassigned time data that you no longer require.
ADM: Purge Obsolete Projects Data: This program purges obsolete data across all projects irrespective of the project status. You can use this program to delete the following types of data:
Daily Forecast Information: Historical information about resource availability, project requirements, and project assignments
Reporting Exceptions: Exception information displayed by the PRC: Maintain Project Resources concurrent program
Projects Workflow: Copies of workflows stored in Oracle Projects that have become obsolete
Project Performance Log Data: Debug information stored by project performance summarization processes
Terminated Organization Authority: Organization authority information for all terminated employees or contingent workers
For more information on the purge programs, see Archiving and Purging Processes.
You purge project batches by following these steps:
Create a purge batch. A purge batch is a list of projects whose data you want to purge and/or archive.
Run a validation process that determines whether the projects in the purge batch are eligible for purging.
Release the batch for purging.
Run a process to purge the batch.
For detailed instructions, see Purge Procedures.
Caution: Purging information from Oracle Projects is a powerful function. The system administrator must set up a special responsibility with appropriate security for purging data. For information on assigning the responsibility and other information about applying business rules to the archive and purge feature, see: Purging Safely and Efficiently.
When you create a purge batch, you can also specify that you want to archive certain data. The archive function is available only for project information that you are purging. You cannot archive data without purging it.
Note: The archive function saves information about specific projects. It is not intended to be a general backup system for your database. You cannot use the archive and purge feature to restore projects that have been archived.
There are four categories of data that can be purged and archived.
Actual Data: The detailed expenditure, revenue, and staffing transactions (such as assignments and requirements) that are scheduled on the project being purged. This category also includes cross charge transactions that are charged to the project being purged.
Summary Data: The summarized data used for the Project Status Inquiry feature of Oracle Projects
Capital Data: The asset line details
The data you can archive and purge depends on the Project Type Class and Project Status. The table below shows the combinations of Project Type Class and Project Status that allow purging for each type of data.
| Type of Data | Project Type Class | Project Status |
|---|---|---|
| Summary data | All | Closed |
| Capital data (asset line details) | Capital | Closed |
| Actuals: - Cost distribution lines - Expenditure items and related tables - Cross charge transactions - Staffing transactions | All | Closed |
| Actuals: - Customer invoices - Revenue distribution lines | Contract | Closed |
| Actuals: - Cost distribution lines - Expenditure items and related tables - Cross charge transactions - Staffing transactions Note: For open indirect projects, expenditure items and staffing transactions are purged based on the transaction date. | Indirect | Open |
You cannot query purged records. Purged records are not displayed on standard reports, or in applications that can drill down to project details. For example, you cannot drill down from Oracle Assets to purged asset line details for project assets.
You cannot use the drill down feature for inter-company invoices if the source expenditure items are purged. Adjustments such as cancellation of invoices and write-offs are not allowed.
The archive and purge function does not purge project setup information (such as work breakdown structures), budgets, status reports and team templates.
You can also purge adjusted expenditure items.
If the expenditure item being purged resulted from a transfer, the purge process creates a record in the PA_EXPEND_ITEM_ADJ_ACTIVITIES table for the original expenditure item. This record is flagged to indicate that the new expenditure item has been purged.
If the expenditure item being purged has been transferred (and therefore has a matched negative expenditure item associated with it), the purge process does the following:
purges both the original and the matched negative expenditure items.
creates a record in the PA_EXPEND_ITEM_ADJ_ACTIVITIES table for the new expenditure item that resulted from the transfer. This record is flagged to indicate that the original expenditure item has been purged.
See also: Adjusting Expenditures, Oracle Project Costing User Guide.
There are several steps you can take to purge safely and efficiently:
Back up the database before you start the purge process. For more information, see your Oracle server documentation.
Confirm the integrity of the database backup.
Create database rollback segments that are large, or set the commit size to a smaller number to ensure that the process does not terminate for lack of rollback segment space. See your database administrator for assistance. For more information about the commit size, see: Purge Project Data and PA: Commit Size for Archive and Purge, Oracle Projects Implementation Guide.
Run the purge process when the load on the system is relatively light.
The purge process can take several hours to complete, depending on the number of records to purge and the capacity of your system. You can purge many records more efficiently by submitting several smaller purges. On your first purge, set a Closed-Through Date (for closed projects) or Purge-Through (for open projects) that is far in the past, and gradually increase the date with each purge.
All projects in a purge batch must meet certain prerequisites for the batch to be purged or archived and purged.
All projects in a purge batch must meet the conditions shown in the following table before the batch can be purged or archived and purged. The conditions vary by project type class (indirect, contract, or capital):
| Indirect Project | Contract Project | Capital Project | Condition |
|---|---|---|---|
| yes | yes | yes | All related records in transaction interface tables must be interfaced to Oracle Projects. See: Transaction Import. |
| yes | yes | yes | All related supplier invoices must be interfaced from Payables to Oracle Projects. See: Interface Supplier Costs. |
| yes | yes | yes | The project must not have pending commitments. See: Commitments from External Systems, Oracle Projects Implementation Guide |
| yes | yes | yes | Expenditure item costs must be distributed. See: Distribution Processes. |
| yes | yes | yes | Accounting for costs must be successfully created in Oracle Subledger Accounting. See: Generate Cost Accounting Events and Create Accounting. |
| yes | Events having completion dates must be processed. See: Events, Oracle Project Billing User Guide. | ||
| yes | Accounting for revenue must be successfully created in Oracle Subledger Accounting. See: Generate Revenue Accounting Events and Create Accounting. | ||
| yes | Draft invoices must be interfaced to and accepted in Oracle Receivables. See: Interface Invoices to Receivables, Oracle Project Billing User Guide. | ||
| yes | Unbilled receivables and unearned revenue for the project must be zero. See: Reviewing Revenue, Oracle Project Billing User Guide. | ||
| yes | Project-related Receivables invoices must have a zero balance (that is, the invoice must be paid). Contract projects with invoices that have a balance due amount cannot be purged. See: Oracle Receivables Reference Guide. | ||
| yes | If you have chosen Purge Capital Data in the Purge Batch Details window, all asset lines must be generated and successfully interfaced to Oracle Assets. Also, all project-related assets must be posted in Oracle Assets. See: Generate Asset Lines and Interface Assets. | ||
| yes | yes | yes | AP discount lines must be interfaced to Oracle Projects. See: Interface Supplier Costs. |
| yes | yes | yes | All allocation runs must be in either the Release Success status or the Reversed status for any task of a project that is purged. |
| yes | yes | yes | All project-related supplier invoices in Oracle Payables must be fully paid. |
| yes | Project-related records in Oracle Time & Labor must be interfaced to Oracle Projects. | ||
| yes | The project must not be an Organization Forecast project. See: Organization Forecasting. | ||
| yes | yes | yes | Receipt accrual amounts for project-related purchase items must be interfaced to Oracle Projects. See: Revenue Accruals, Oracle Project Billing User Guide. |
| yes | All retentions must be billed and the retention balance must be zero. See: Customer Billing Retention. | ||
| yes | yes | yes | Project transactions must not be referenced in Oracle Project Contracts, Oracle Property Manager, or Oracle Commitment Administration. |
Note: The summarization and burden cost distribution checks can be part of client extensions. The creation of a summarized burden component can be part of a client extension.
Cross charge transactions must meet the conditions shown in the following table before they can be purged or archived and purged.
| Indirect Project | Contract Project | Capital Project | Condition |
|---|---|---|---|
| yes | yes | yes | Accounting for borrowed and lent transactions must be successfully created in Oracle Subledger Accounting. See: Generate Cross Charge Accounting Events and Create Accounting. |
| yes | yes | Cross charge projects can be purged after intercompany invoices are interfaced to Receivables and tied back to Projects. | |
| yes | Intercompany billing projects cannot be purged. | ||
| yes | If the Reclassify Costs for Cross Charged Transactions option on the Internal Billing tab in Implementation Options is set to either Raw Cost or Burden Cost, then accounting for cross-charged transactions must be successfully created in Oracle Subledger Accounting. See: Generate Cross Charge Accounting Events and Create Accounting. | ||
| yes | For inter-project billing, the provider project must be purged before purging any receiver project. | ||
| yes | For inter-project billing, the provider project can be purged after draft invoices belonging to the provider project are interfaced to Receivables and transferred to Payables as supplier invoice costs for the receiver project. | ||
| yes | yes | For inter-project billing, if the receiver project is an indirect project, then it can be purged multiple times in a time phased manner. |
Staffing transactions must meet the conditions shown in the following table before they can be purged or archived and purged.
| Indirect Project | Contract Project | Capital Project | Condition |
|---|---|---|---|
| yes | For open projects, requirements are not purged if an open requirement exists on the project with an end date earlier than the purge through date. | ||
| yes | yes | yes | For closed projects, the entire project is not purged if an assignment exists on the project with an end date later than the project close date. |
In addition to the default prerequisites listed in the Data That You Can Purge table, you can create additional prerequisites for purging and archiving project data. See: Archive Purge Validation Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
There are three types of statuses that relate to purging or archiving project data:
Project status
Validation status
Purge batch status
These statuses are described in the following sections.
During the purging process, the status of the purged project is updated. The following table lists the default project statuses related to purging.
| Project Status | Meaning |
|---|---|
| Partially Purged | The project actuals have been purged, but the system has retained specified summary information. |
| Pending Purge | The system has marked the project as eligible for purging and has included the project in a purge batch. You cannot modify or enter transactions on a project with Pending Purge status. |
| Purged | The project has been purged. Project setup information (such as project numbers, budgets, and work breakdown structures) remains in the system. |
You can define additional project statuses that map to the Partially Purged or the Purged system statuses. You cannot map statuses to the Pending Purge system status. For more information, see: Project Statuses.
The system assigns the status of the purged project as specified in the Project Verification client extension. For more information, see: Project Verification Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
Open projects return to their original status after being purged. For open projects, the default status changes like this:
original project status-->Pending Purge-->original project status
For closed projects, the default status changes like this:
original project status-->Pending Purge-->Purged or Partially Purged
Projects with a status of Partially Purged can be purged completely at a later time.
As shown in the following table, the validation status indicates where the project is in the validation process. When you submit projects to be validated, this status is updated to indicate whether the project passed the validation. You will find the validation status on the Purge Validation Report and also listed on the Purge Batch Details window that lists the projects included in each purge batch.
| Validation Status | Meaning |
|---|---|
| New | The project has not been processed by the Validate Purge Batch process. |
| Valid | The project has been processed by the Validate Purge Batch process, and has passed the validation criteria. |
| Invalid | The project has been processed by the Validate Purge Batch process, and has failed the validation criteria. You must correct the errors identified by the process or delete the project from the purge batch before the batch can be purged. |
After a project has passed validation and its validation status is set to Valid, you cannot change any of the transactions tied to the project.
A purge batch is a list of projects that you want to purge or that have already been purged. Purge Batch Statuses are associated with purge batches as shown in the following table:
| Purge Batch Status | Meaning |
|---|---|
| Working | The system is creating a batch (validation has not occurred), or the validation process is over. Note: When the validation process is over, the system returns to Working status, even if the system has encountered errors. |
| Validating | The system is validating a batch. |
| Released | The system has released the batch, and the batch is ready to purge. You cannot make any changes to the batch. |
| Purging | The system is running the purge process, or the process has failed due to a system error. If a system error has occurred, you should query the batch again, and then choose the Purge button to restart the process. |
| Completed | The system has run a purge process for the batch. |
Following are descriptions of the steps for purging projects in Oracle Projects.
Create a purge batch, or modify an existing purge batch. A purge batch is a list of projects whose data you want to purge and/or archive.
See: Create a Purge Batch.
To modify an existing purge batch, see Modifying a Purge Batch.
Review and revise the list of projects in the batch. See: Review and Refine the List.
Run the ADM: Validate Purge Batch process to determine whether the projects in the purge batch are eligible for purging. See: Validate the Projects in the Purge Batch.
Release the batch for purging. (You cannot release a batch that contains errors.) See: Release the Purge Batch.
Finally, run the purge process (ADM: Purge Project Data), which purges batches that have passed the validation process. See: Start the Purge Process.
The following steps provide detail instructions for purging (or archiving and purging) in Oracle Projects.
You can populate a purge batch either by providing selection criteria or by selecting specific projects to purge. You can remove projects from the purge batch at any time before you release the batch.
You can define as many purge batches as you want. Each batch can contain either open or closed projects, but not both.
Log in using the Projects System Administrator responsibility. See: Assigning Purge Responsibility.
Navigate to the Purge Batches window. To navigate to the Purge Batches window, log on with the Projects System Administrator responsibility and choose Purge Project Data.
Note: To modify an existing purge batch, see Modifying a purge batch.
Create a purge batch by completing applicable fields (described in the following table) in the Purge Batches window.
| For this field or region | Do this |
|---|---|
| Operating Unit | If you are creating a new purge batch, enter the name of the operating unit to which the batch belongs |
| Batch Name Description | Enter a batch name and description of your choosing. |
| Batch Status | Display only. Both the Batch Status and Purged Date fields are display only. |
| Projects | Choose Open to select open indirect projects or Closed to select closed projects. Note: If you select Open, you can only purge and archive actual data from indirect projects. |
| Administrative Projects | Enable the Administrative Projects check box to purge and/or archive only administrative projects. |
| Purge Options | Choose the types of data that you want to purge or archive by selecting the appropriate options: - Purge Actuals (Default, required for open projects) - Purge Summary Data - Purge Capital Data - Archive Actuals - Archive Summary Data - Archive Capital Data You cannot choose to archive data without also selecting the corresponding purge option for that data. Purge options set here take effect for all the projects in the batch. You can, however, change the purge options at the project level. Important: If you change the purge options here after you generate a batch, the change does not affect the projects in the batch. |
| Purge-Through Date | For open projects, enter the date through which you want to purge and/or archive actuals. |
| Next Purge Status | Select the project status to be assigned to closed projects after the purge process has run. (Open projects are assigned their original status after the purge.) The Next Purge Status is used for closed projects where actual amounts, summary data, and capital data are purged. The Next Partially Purged Status is used for closed projects that retain summary data or capital data. Open projects are assigned their original status after the purge. The default statuses are Purged and Partially Purged. You can change these to any valid user-defined project status that is mapped to a system status of Purged or Partially Purged. See Project Status for Purged Projects. |
Create a list of projects to purge:
If you want to select each project to include in the batch, choose Enter Details. In the Purge Batch Details window, use the list of values in the Project Number or Project Name fields to select each project you want to purge, and then skip to Step 2: Review and Refine the List.
If you want to generate a list of projects based on a set of criteria that you define, choose Generate Details.
In the Generate Details window, set the criteria for the list of projects you want to purge by filling in the fields shown in the following table:
| For this field | Do This |
|---|---|
| Closed - Through Date | Enter a date. The date refers to the date on which the project status was set to Closed. Note: This field is available only if you have selected Closed Projects in the Purge Batches window. |
| Organization | (Optional) Select from the list of values. |
| Project Type | (Optional) Select from the list of values. |
| Project Status | (Optional) Select a status from the poplist. |
If you make a mistake, choose Clear.
Choose Generate to display a list of the projects that meet the criteria. The Purge Batch Details window opens.
After you create the purge batch, review the list of projects to be purged.
Examine the list of projects to purge and further refine the list as shown in the following table.
| To | Do This |
|---|---|
| Delete a project (record) from the list | Select the line containing the project, and then choose Delete Record from the Edit menu. |
| Add a project (record) to the list | Select a blank line or choose New Record from the Edit menu. Then choose a project number or name from the list of values. |
| See more information about the selected projects | Select Project Information from the poplist to display information about the projects to be purged. Add or delete projects as needed. |
| See or alter the archive and purge options for each project | Select Purge Options from the poplist to display the purge options you specified for the batch. Select or deselect the check boxes. For open indirect projects, you can purge (or archive and purge) actuals only. Note: Purge options set on the Purge Batches window take effect for all the projects in the batch when you generate or manually select projects. (You can see the results on the Purge Batch Details window.) Changing the purge options on the Purge Batches window after you generate a batch will not affect the purge options for the projects in the batch. |
If you want to change purge options at the project level, then change the poplist from Project Information to Purge Options. Change the options for each project as appropriate.
Save the list of projects and close the Purge Batch Details window.
After you create purge batches, you validate them by running the ADM: Validate Purge Batch process. The validation process identifies errors in a purge batch. If a purge batch contains errors, you must correct the errors (see: Modifying an Existing Purge Batch), or remove the invalid projects from the list of projects in the purge batch. After you correct the errors, you run the validation process again.
The validation process verifies that the projects to be purged are eligible for purging. All of the projects in a purge batch must be eligible for purging before you can release the batch for purging.
Choose Validate from the Purge Batches window.
The system starts the ADM: Validate Purge Batch process.
You can also validate the batch by running the process from the Submit Requests window. See Validate Purge Batches.
You can view the status of the process by navigating to the Completed Requests window.
When the process is complete, review the Purge Validation Report.
If the Validation Exceptions section lists any errors, return to the Purge Batch Details window and correct the errors. See Correcting Errors.
If the system validates the purge batch, you can release the purge batch. See: Release the Purge Batch.
Note: If you add projects after the system validates the purge batch, you cannot release or purge the batch until you run the Validate Purge Batch process again.
For information about validation requirements, see: Prerequisites for Purging Projects. Your implementation team may define additional rules in the Validation Extension. See: Validation Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
After all the projects in the batch are validated (required), you release the batch for purging. You cannot release a batch that contains errors.
From the Purge Batches window, Choose Release. This sets the batch status to Released.
Note: After a batch is released, you must choose Rework if you want to make any changes in the batch. When you choose Rework, the batch status changes from Released to Working.
When you are ready to purge (or archive and purge) a batch, run the ADM: Purge Project Data process.
From the Purge Batches window, Choose Purge. The ADM: Purge Project Data process starts.
Note: You can also run the purge process from the Submit Requests window.
Following are instructions for modifying an existing purge batch:
Log in using the Projects System Administrator responsibility. See: Assigning Purge Responsibility.
Navigate to the Purge Batches window (from the Projects System Administrator responsibility, choose Purge Project Data).
In the Batch Name field, query the batch name.
To add projects to an existing batch using selection criteria, choose Generate Details. In the Generate Details, set criteria for the list of projects you want to add to the batch, and then choose Generate.
To add or remove individual projects, or change the purge options at the project level, choose Edit Details.
In the Purge Batch Details window, use the poplist to view the alternative areas.
To add or remove a project from the list, choose Project Information.
To change the purge options for a project (if you have permission to change the purge options), choose Purge Options.
Proceed with the review, validation, release, and initiation steps. See: Review and Refine the List.
Following are instructions for modifying a purge batch:
Log in using the Projects System Administrator responsibility. See: Assigning Purge Responsibility.
Navigate to the Purge Batches window (from the Projects System Administrator responsibility, choose Purge Project Data).
In the Batch Name field, query the batch name. Then choose Edit Details to go to the Purge Batch Details window.
For each project in the batch:
Select the project and choose Edit > Delete Record.
After you delete all the projects from the batch, choose File > Save.
Close the Purge Batch Details window to return to the Purge Batches window.
In the Purge Batches window, choose Edit > Delete Record. Then choose File > Save.
You can release a purge batch only if every project in the batch has passed validation. All projects in the batch that do not pass validation must be corrected or removed from the batch.
Projects that have passed validation have a validation status of Valid. Projects that do not pass validation have a status of Invalid. You can view the validation status of the projects in the Purge Batch Details window or the Purge Validation Report, which lists invalid projects and the reasons that the project failed validation.
Navigate to the Purge Batches window.
In the Batch Name field, query the purge batch name and choose Edit Details. The Purge Batch Details window opens.
In the Purge Batch Details window, select a project that failed validation.
For more information about the selected projects, use the Purge Batch Details Window (see: Step Two: Review and Refine the List).
Choose the Errors button to display the errors in the Validation Errors window. You can also view the errors in the Purge Validation Report.
Correct the errors. You can either remove the problem project from the purge batch (Choose Delete Record from the Edit menu) or correct the condition in the project that is causing the error.
For more information about the conditions that must be met before a project can be purged, see: Prerequisites for Purging Projects.
Run the validation process again (see: Validate the Projects in a Purge Batch.)
This section describes steps you can take to manage purged and partially purged projects.
You cannot query purged information. Projects with a status of Purged or Partially Purged are not listed on standard reports.
You cannot query purged projects in applications that drill down to project details. For example, in Oracle Assets, you cannot query purged line details for project assets.
To see what information has been purged from a batch, query the batch in the Purge Batches window and view the purge details.
To view purged information in a printed report, you must write reports using the archive tables that hold the transactions for the purged project.
Projects with a status of Partially Purged can be purged (or archived and purged) at any time.
After you purge a project, you can purge transactions related to the project in other Oracle applications.
In Oracle Payables, you can purge invoices, purchase orders, and requisitions.
In Oracle Receivables, you can purge customer invoices.
Note: You can purge data in Oracle Receivables only if you use accrual based accounting.
There are several processes that you can run to summarize different types of purged projects, including closed projects and open indirect projects. You can also summarize project amounts.
After you purge transactions from a closed project, the summarization processes in Oracle Projects do not calculate the To-Date summary amounts for that project. Running the summarization processes against this project will have no effect.
When you purge an open indirect project, you must decide how you want to calculate the project's summary amounts after the purge. You use two processes to control the summary amounts:
Refresh Project Summary Amounts
Update Project Summary Amounts
If you want the To-Date summary amounts for a project to include only amounts that have not been purged, you must follow these steps:
Run the Refresh Project Summary Amounts Process on the project once after each purge.
After you charge additional transactions to the project, it is only necessary to run the Update Project Summary Amounts Process until the next purge.
If you want the To-Date summary amounts for a project to include all to-date amounts, including amounts that have been purged, you must follow these guidelines:
NEVER run the Refresh Project Summary Amounts Process on the project.
After you charge additional transactions to the project, it is only necessary to run the Update Project Summary Amounts Process.
Important: If you run Refresh Project Summary Amounts, the process recalculates to-date amounts using only the un-purged transactions.
See also: Refresh Project Summary Amounts and Update Project Summary Amounts.
Your database administrator must decide what to do with the data in the archive tables. The database administrator should back up the data, and if necessary, move it to a different location from your production database. By moving the data, you reduce the load on your production system and database.
The implementation team and system administrator can determine some of the functionality of the archive and purge feature, as described in these sections:
If you need to write custom reports using archived data, refer to the following section:
To protect the information in your database, the system administrator must set up a special responsibility for the person who is authorized to purge Oracle Projects data. .
Start Oracle Applications and choose the System Administrator GUI responsibility.
Navigate to the Users window.
Assign the following responsibilities to the new user ID:
Projects System Administrator
Project Billing Super User (if necessary)
Set MO: Operating Unit to the applicable operating unit.
Save your changes.
For more information, see: Managing Oracle Applications Security, Oracle Applications System Administrator's Guide.
Use the profile option PA: Commit Size for Archive and Purge to control the batch size for archive and purge processes. For more information, see: PA: Commit Size for Archive and Purge, Oracle Projects Implementation Guide.
You can use client extensions to extend the functionality of the archive and purge processes. See:
Archive Purge Validation Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference
Purge Custom Tables Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference
The archive purge transaction tables store archive and purge data. Use these tables to:
write custom reports
define alerts against Oracle Applications tables
create views for decision support queries using custom query tools
The archive purge transaction tables are listed below:
PA_PURGE_BATCHES_ALL contains records of all the purge batches held by the operating unit.
PA_PURGE_PROJECTS contains records of all the projects that are purged in a batch. If a project is partially purged and then later is fully purged, it exists in more than one batch.
PA_PURGE_PRJ_DETAILS contains statistics for each table purged for each project in a run. Purge detail records are created by the purge process.
PA_PURGE_PROJECT_ERRORS stores the errors that occur in an archive purge run.
For full table definitions, see the Oracle Projects eTechnical Reference Manual (eTRM).
The purge function deletes data from the major transaction tables. As the system purges the specified data, Oracle Projects creates a parallel table for each purged table and stores the archived data in the parallel tables. An additional attribute in the parallel tables identifies the run in which the data was archived.
The following sections list the tables that are purged and their corresponding archive tables, depending on the purge options that you select.
The following table shows the tables that are purged if you choose the Purge Actuals and Archive Actuals purge options.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_Billing_Messages | PA_Billing_Messages_AR |
| PA_CC_Dist_Lines_All | PA_CC_Dist_Lines_AR |
| PA_Cost_Distribution_Lines_All | PA_Cost_Dist_Lines_AR |
| PA_Cust_Event_RDL_All | PA_Cust_Event_RDL_AR |
| PA_Cust_Rev_Dist_Lines_All | PA_Cust_RDL_AR |
| PA_Distribution_Warnings | PA_Dist_Warnings_AR |
| PA_Draft_Invoice_Items | PA_Draft_Inv_Items_AR |
| PA__Draft_Invoices_All | PA__Draft_Invoices_AR |
| PA_Draft_Revenue_Items | PA_Draft_Rev_Items_AR |
| PA_Draft_Revenues_All | PA_Draft_Revenues_AR |
| PA_EI_DeNorm | PA_EI_DeNorm_AR |
| PA_Events | PA_Events_AR |
| PA_Expend_Item_Adj_Activities | PA_Exp_Item_Adj_Act_AR |
| PA_Expenditure_Comments | PA_Exp_Comments_AR |
| PA_Expenditure_History | PA_Exp_History_AR |
| PA_Expenditure_Items_All | PA_Expenditure_Items_AR |
| PA_Retn_Invoice_Details | PA_Retn_Inv_Details_AR |
| PA_Routings | PA_Routings_AR |
| <Custom Table> | <Custom Table> |
Note: For historical (prior to Release 12) Multiple Reporting Currency transactions, additional tables related are also deleted. See: Multiple Reporting Currencies Tables.
The following table shows the tables that are purged if you choose the Summarized Data purge option.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_Project_Accum_Actuals | PA_Prj_Accum_Actuals_AR |
| PA_Project_Accum_Budgets | PA_Prj_Accum_Budgets_AR |
| PA_Project_Accum_Commitments | PA_Prj_Accum_Commit_AR |
| PA_Project_Accum_Headers | PA_Prj_Accum_Headers_AR |
| PA_Resource_Accum_Details | PA_Res_Accum_Details_AR |
| PA_Txn_Accum | PA_Txn_Accum_AR |
| PA_Txn_Accum_Details | PA_Txn_Accum_Details_AR |
| <Custom Table> | <Custom Table> |
The following table shows the tables that are purged if you choose the Capital purge option.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_Project_Asset_Line_Details | PA_Prj_Asset_Ln_Dets_AR |
| <Custom Table> | <Custom Table> |
The following table shows the tables that are purged for historical (prior to Release 12) Multiple Reporting Currencies transactions.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_MC_CC_Dist_Lines_All | PA_MC_CC_Dist_Lines_AR |
| PA_MC_Cost_Dist_Lines_All | PA_MC_CDL_AR |
| PA_MC_Cust_Event_RDL_All | PA_MC_Cust_Event_RDL_AR |
| PA_MC_Cust_RDL_All | PA_MC_Cust_RDL_AR |
| PA_MC_Draft_Inv_Details_All | PA_MC_Draft_Inv_Dets_AR |
| PA_MC_Draft_Inv_Items | PA_MC_Draft_Inv_Items_AR |
| PA_MC_Draft_Revs_All | PA_MC_Draft_Revs_AR |
| PA_MC_Events | PA_MC_Events_AR |
| PA_MC_Exp_Items_All | PA_MC_Exp_Items_AR |
| PA_MC_Prj_Ast_Line_Dtls | PA_MC_Prj_Ast_Ln_Det_AR |
| PA_MC_Retn_Inv_Details | PA_MC_Retn_Inv_Detls_AR |
| <Custom Table> | <Custom Table> |
The following table shows the tables that are purged if you are using Oracle's cross charge features.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_Draft_Invoice_Details_All | PA_Draft_Inv_Dets_AR |
| <Custom Table> | <Custom Table> |
The following table shows the tables that are purged for staffing transactions.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_Action_Set_Line_Aud | PA_Actn_Setln_Aud_Ar |
| PA_Action_Set_Line_Cond | PA_Actn_Set_Ln_Cond_Ar |
| PA_Action_Set_Lines | PA_Action_Set_Lines_Ar |
| PA_Action_Sets | PA_Action_Sets_Ar |
| PA_Assignment_Conflict_Hist | PA_Asgmt_Cnflt_Hist_Ar |
| PA_Assignments_History | PA_Asgmts_Hstry_Ar |
| PA_Candidate_Reviews | PA_Candidates_Rev_Ar |
| PA_Candidates | PA_Candidates_Ar |
| PA_FI_Amount_Details | PA_FI_Amount_Details_AR |
| PA_Forecast_Item_Details | PA_Frcst_Item_Dtls_Ar |
| PA_Forecast_Items | PA_Frcst_Items_Ar |
| PA_Project_Assignments | PA_Project_Asgmts_Ar |
| PA_Project_Parties | PA_Project_Parties_Ar |
| PA_Schedule_Except_History | PA_Sch_Excpt_Hstry_Ar |
| PA_Schedules | PA_Schedules_Ar |
| PA_Schedules_History | PA_Schedules_Hstry_Ar |
The following table shows the tables that are purged for resource unassigned time.
| Table to be Archived and Purged | Archive Table |
|---|---|
| PA_FI_Amount_Details | PA_FI_Amount_Details_AR |
| PA_Forecast_Item_Details | PA_Frcst_Item_Dtls_Ar |
| PA_Forecast_Items | PA_Frcst_Items_Ar |
Use the Mass Update Batches window to change the organization of multiple projects and tasks. The Mass Update window performs both of the following functions:
Creates a batch for mass update of organization for projects and/or tasks.
Initiates a process that updates the organization on all the projects and tasks specified in the batch. You can optionally mark expenditure items charged to the project or task for recalculation based on the new organization.
You can also run the update as a concurrent program by submitting a request to run the PRC: Process Mass Update Batches program.
Related Topics
You can use the following two methods, alone or in combination, to create a mass update batch:
Generate lines for the batch based on selection criteria you enter.
Enter each project and task.
Navigate to the Mass Update Batches window.
Enter a Batch Name, Description, and Effective Date for the batch.
In the Generate Detail Lines region of the window, enter the selection criteria to select the projects and tasks you want to update. See: Mass Update Batches Window Reference.
Choose Generate Detail Lines to generate the mass update batch lines.
If you want to review and/or revise the mass update batch, choose Details. See: Batch Lines Window Reference.
Navigate to the Mass Update Batches window.
Enter a Batch Name, Description, and Effective Date for the batch.
To enter batch lines in the Batch Lines window, choose Details.
For each batch line, enter a Project Name, Task Name (optional), New Value (new organization to be assigned), and Effective Date, and indicate whether the item should be marked for recalculation. See: Batch Lines Window Reference.
Related Topics
Mass Update Batches Window Reference
Operating Unit. Enter the name of the operating unit for the Mass Update Batch.
Batch Name. Enter a unique name for this Batch.
Description. Enter a unique, descriptive name for this batch.
Status. This field displays the status of the batch. It can have the following values:
Working. The batch can be modified.
Submitted. The batch has been submitted for update. You cannot change the batch.
Rejected. The update process has rejected the batch. You can modify the batch to correct the errors, and resubmit the batch.
Completed. All projects and tasks were updated successfully. You cannot modify the batch.
Processing. The batch is currently being processed. You cannot modify the batch.
Attribute. The project and/or task attribute that you want to update. Currently, this field defaults to Organization and cannot be modified.
Effective Date. The date you enter in this field is used for two purposes:
The date used to select expenditure items for recalculation
The date when the batch will be eligible for processing
Rejection Reason. The reason that the batch was rejected. Following are the possible rejection reasons:
At least one detail line was rejected for this batch.
Batch is not ready for processing due to the effective date.
The batch is not in Submitted status.
Internal SQL Error.
Processed By. This field displays the name of the employee who last submitted the batch for update.
Processed Date. The date when the batch was last processed.
Descriptive Flexfield. Standard descriptive flexfield.
From Project. You can generate lines for a single project or a group of projects, depending on the criteria you enter:
Project Name. A single project will be selected.
Managed By Organization. All projects owned by the organization you enter will be selected.
Task. You can narrow the selection by entering task criteria:
All. All of the tasks for selected projects will be selected.
None. No tasks will be selected.
Same Organization. Tasks owned by the same organization entered under Managed By Organization will be selected.
New Organization. The new organization that will be assigned during the update process. This field is required for processing a mass update batch.
Mark for Recalculation. If this check box is checked, the selected transactions will be marked for recalculation.
Submit. Changes the status of the batch from Working to Submitted. When a batch is in Submitted status, you cannot modify it. You cannot submit a batch unless it contains at least one detail line.
Rework. Returns a submitted batch to Working status.
Update. Runs the Batch Process for Mass Update online. This button is active only if the status of the batch is Submitted.
Details. Displays the Batch Lines window.
Generate Detail Lines. Generates the mass update batch detail lines based on the criteria specified in the Generate Detail Lines region.
The Batch Lines window displays all the detail lines for the batch. Use this window to enter new detail lines, or to modify them after you have entered them or after you have automatically generated them.
If your batch has been rejected, you can use this window to view the rejection reason for each rejected line. You can then correct the data or uncheck the Update check box.
Project Name. The name of the project for which you want to update the organization. Each detail line in the batch must be a unique project/task combination.
Task Name. The name of the task for which you want to update the organization. If you want to update the organization on the project, leave this field blank.
Old Value. This field displays the current organization that owns the project or task.
New Value. The new organization you want to assign to the project or task.
Effective Date. The effective date of the line. This value will default to the Effective Date you entered for the batch. You can override the default value.
Update. This check box indicates if a line will be processed when you run the update process for the batch. You can update this check box only if you have the security to update the specified project.
Mark for Recalculation. This check box indicates if the expenditure lines associated with the project or task will be marked for recalculation. You can update this check box only if you have the security to mark expenditure items for cost and revenue recalculation. See: Security in Oracle Projects.
Rejected. This check box is checked if the line was rejected during the latest update process.
Rejection Reason. For rejected lines, the reason the current line was rejected during the last update process.
Related Topics
Processing a Mass Update Batch
You can process a mass update batch either online or as a concurrent program.
Navigate to the Mass Update Batches window.
Choose Update.
Navigate to the Submit Request window.
Select the PRC: Process Mass Update Batches process.
Select a batch name.
Submit the process.
For each detail line in the batch, the Mass Update Batch process performs the several verifications before processing the line. If a detail line fails any of the verifications, the Rejected check box is checked and a Rejection Reason can be viewed for the record.
Following are the verifications that the Mass Update Batch process performs:
Verify that the Update check box is checked.
Verify that the project status is not Closed.
Verify that the submitter of the process has security to update the project.
Verify that the change specified for the line is allowed. This check includes a call to the Verify Organization Change client extension.
Update the organization of the project or task.
If the Mark for Recalculation check box is checked for the line, the process marks the related expenditure items for recalculation.
After all the batch lines have been processed, if any error has occurred during the processing, none of the updates are processed and the batch status is set to Rejected.
If no error occurs during the process, the updates are processed and the batch status is set to Completed. The Processed By, Processed Date, and Rejection Reason fields of the batch are updated.
The following errors can occur during the Mass Update Batch process:
The batch must have Submitted status in order to be processed.
This error can occur when the batch process is run as a concurrent program. It indicates that the status of the batch changed after the concurrent request was submitted.
Solution: Reset the batch status to Submitted and submit another request to process the batch.
This user is not yet registered as an employee.
The user who is running the batch process does not have an employee record. Contact your System Administrator to create an employee record for this use before continuing.
You do not have permission to update this project.
You do not have permission to update the specified project on a detail line.
The new organization is not allowed to create projects or tasks for the given project type class.
The new organization is invalid for the organization change, because it is not set up to own projects with the specified project's project type class.
Solution: Enter a valid organization for the line, or uncheck the Update check box for the line.
Project/Task Organization cannot be changed due to costed items/revenues/invoices.
The project/task organization of the project specified for the batch line cannot be changed because costed items, revenue, or invoices exist for the project or task.
User-defined error messages.
You can build business rules in the Verify Organization Change Extension to determine whether the organization change is allowed, and to define error messages when the rules are violated.
Related Topics
Verify Organization Change Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference
Oracle Projects supports the merging of customer information through its integration with Oracle Trading Community Architecture.
When you merge customer information, the system merges the customer reference on project customers, agreements, and draft invoices in Oracle Projects. Similarly, when you merge customer addresses, the system updates address references on project customers, tasks, and draft invoices in Oracle Projects.
Certain Oracle Projects entities are affected whenever you perform a customer merge operation. These entities are:
Project Customers (including Contacts and Contribution %)
Agreements
Draft Invoices
Related Topics
AR Merge, Oracle Project Billing User Guide
Oracle Trading Community Architecture User Guide
Copyright © 1994, 2010, Oracle and/or its affiliates. All rights reserved.