all about oracle projects workflow

Skip Headers

This chapter describes the Oracle Workflow processes that are used in the Oracle Projects solution.

This chapter covers the following topics:

Integrating with Oracle Workflow Oracle Project Costing Workflows

Oracle Project Foundation Workflows Oracle Project Management Workflows Oracle Project Portfolio Analysis Workflow

Oracle Project Resource Management Workflows

Integrating with Oracle Workflow

Oracle Projects provides the ability to integrate with Oracle Workflow to automate some activities.

Using the powerful abilities of Oracle Workflow, you can create, view, and modify business processes that

determine the workflows. Workflow automatically routes approvals and notifies appropriate users of current approval status. The approval process updates statuses as approvals are obtained or denied.

You decide what is the approval chain and what business rules must be met before a transaction can be

approved.

Oracle Projects provides default processes for each workflow. You can modify the default processes and create additional processes to accommodate the needs of your business, using the Oracle Workflow Builder.

Workflows in Oracle Projects

Oracle Projects provides the following workflows that you can customize for your business needs. Some of the

workflows are for internal purposes and cannot be modified.

The workflows are organized in this chapter by product:

Oracle Project Costing

PA Step Down Allocations

Oracle Project Foundation

PA: Mass Pipeline Projects Update Workflow

PA: Oracle Projects Library Workflow

PA: Project Workflow

Oracle Project Management

PA: Budget Workflow

Oracle Projects Implementation Guide Release 12.1

Part Number E13582-04

Contents

Previous

Next

Workflow Processes

Page 1 of 112Oracle Projects Implementation Guide

30-05-2012http://docs.oracle.com/cd/E18727_01/doc.121/e13582/T188672T324950.htm

PA: Budget Integration Workflow

PA: Change Request Workflow

PA: Deduction Workflow

PA: Issue and Change Workflow

PA: Issue and Change Action Workflow

Project Budget Account Generation Workflow

PA: Project Execution Workflow

PA: Performance Notification Workflow

PA: Status Report Workflow

PA: Task Approval Workflow

PA: Workplan Workflow

Oracle Project Portfolio Analysis

Project Portfolio Analysis Workflow

Oracle Project Resource Management

PA: Advertisements Workflow

PA: Apply Team Template Workflow

PA: Candidate Notification Process

PA: CRM Workaround Workflow

PA: HR Related Updates Workflow

PA: Mass Assignment Approval Workflow

PA: Mass Assignment Transaction Workflow

PA: Overcommitment Notification Process Workflow

PA: Project Assignments Workflow

Customizing Workflow Messages

When you customize a workflow, we recommend that you customize the workflow item processes and the loop

counters, but not the messages. Instead of modifying a workflow message, you should create a new message. The reasons are explained below:

When you create a process definition, Oracle Workflow Builder assigns a new version number to an activity if you make changes to it. It saves the new version of the activity to the database without overwriting older versions of the activity. In Oracle Workflow, activities also have effective dates so that at any time, only

one version of the activity is in effect.



If a process is running, Oracle Workflow uses the version of the activity that was in effect when the process was initiated. It does not switch versions of the activity midway through the process. Since a

process itself is an activity, a process definition always remains constant until the process instance completes.

Oracle Workflow Builder does not maintain version information for objects such as item types, item type

attributes, messages, and lookup types. For these objects, their latest definition always applies, so you must consider whether a change to any of these objects is backwards compatible. If the modification

affects existing processes, you should create a new object rather than edit the existing object.

Related Topics

Oracle Workflow User's Guide

Oracle Workflow Administrator's Guide

Oracle Workflow Developer's Guide

Oracle Project Costing Workflows

Oracle Project Costing provides several workflows to automate and manage allocations and allocated costs. In addition, Oracle Project Costing provides a workflow to enable control of supplier payments.

Overview of Oracle Project Costing Workflows

Oracle Project Costing provides the following workflows.

PA: Step Down Allocations Workflow

You use the Step-Down Allocations workflow to automate AutoAllocations.

The PA Step Down Allocations workflow (item type) automates the execution of step-down autoallocation sets to do the following:

Create allocation runs

Generate the allocation transactions

Release the allocation transactions (if the rule is set up to release automatically) or require approval from a

specific person before the process proceeds

Distribute costs

Update the project summary amounts

Workflow Name Description

PA: Step Down Allocations Workflow

Automates AutoAllocations and includes processes that generate and release allocations, distribute and summarize allocated costs, and customize these processes for reporting

Send AR

Notification workflow

Notifies project manager when a receipt is applied to a project invoice in Oracle

Receivables. For customer invoices linked to supplier invoices on pay when paid payment holds, the notification enables project managers to review and release holds on supplier invoices.



The filename of this workflow is paauto.wft.

You can use AutoAllocations in a standalone installation of Oracle Projects. If you want to include both Oracle

Projects rules and Oracle General Ledger batches in the same autoallocation set, Oracle General Ledger must be integrated with Oracle Projects.

Implementing the PA: Step Down Allocations Workflow

Note: Do not customize any aspect of the workflow other than the ones listed here. Oracle does not support any other customizations.

You can customize the following processes:

PA Customizable Allocation Process

PA Customizable Distribute Cost Process

PA Customizable Summarization Process

Customize the PA_AUTO_ALLOC_WF_PKG (defined in the files PAPAALCB.pls and PAPAALCS.pls). This package contains the PL/SQL template of procedures and functions that you modify to customize the GL AutoAllocation

Process.

The customizable processes return the result types shown in the following table:

You can also customize the timeout attribute to set the amount of time that a user has to respond to a notification. See: Timeout attribute.

For information on opening and modifying Oracle Workflow processes, see: Oracle Workflow Developers Guide.

Unsupported Processes

The following processes in the PA Step Down Allocations workflow are unsupported:

PA Allocation Rollback Process

PA Distribute Cost Rollback Process

PA Update Projects Summary Rollback Process

PA: Step Down Allocations Processes

This workflow applies only to step-down allocations, not parallel allocations. The PA Step Down Allocation workflow (item type) directs the flow of autoallocations through the system.

In Oracle Workflow Builder, the processes are listed in alphabetical order. In this section, however, the

processes are grouped by purpose and flow.

The PA Auto Allocation Process is the primary process for Projects AutoAllocations. This process calls the PA Step Down Allocation Process.

Result Type The process

COMPLETE.PASS Is complete

COMPLETE.FAIL Has failed and has been terminated



The PA Step Down Allocation Process manages the Oracle Projects allocations run. The PA Step Down Allocations workflow includes the following processes:

PA Allocation Process

PA Allocation Generation Process

PA Allocation Release Process


PA Cost Process

PA Distribute Cost Process


PA Summarization Process

PA Update Projects Summary Process


PA Auto Allocation Process

This is the main process for AutoAllocations. This process calls the process PA Step Down Allocation Process,

In the diagram shown below, the process activity nodes are numbered for reference in the descriptions that

follow. The numbered circles are not part of the process diagram.

PA Auto Allocation Activities

The following information describes each activity in the PA Auto Allocation process, listed by function name:

Start (Node 1): This is a standard activity that marks the start of the process.

PA Step Down Allocation Process (Node 2)This is the main process for Oracle Projects step-down

allocations.



If the process is successful, it branches to node 4.

If the process fails, it branches to node 5.

Set Projects Auto Allocations Status (Rollback) (Node 3): This process is for allocation rollbacks (not supported in this release).

Set Projects Auto Allocations Status (Pass) (Node 4): This process sets the status of the auto allocations

set to Pass.

Set Projects Auto Allocations Status (Fail) (Node 5): This process sets the status of the auto allocations set to Fail.

End (Pass) (Node 6)This activity terminates the process and returns the result Pass.

PA Step Down Allocation Process

This is the main process for step-down allocations.



PA Step Down Allocation Activities



The following information describes each activity in the PA Step Down Allocation process, listed by function name


End (Rollback) (Nodes 2, 5, and 8): This is for allocation rollbacks (not supported in this release).

PA Allocation Process (Node 3): This process manages the allocations run.



PA Cost Process (Node 6): This node calls the PA Cost process.



PA Summarization Process (Node 9): This node calls the PA Summarization process.



End (Fail) (Nodes 4, 7, and 10): This activity terminates the process and returns the result Fail.

End (Pass) (Node 11): This activity terminates the process and returns the result Pass.

PA Allocation Process

This process manages the allocations run.





PA Allocation Activities

The following information describes each activity in the PA Allocation process, listed by function name:


PA Allocation Generation Process (Node 2): This activity submits the PA Allocation Generation Process.



PA Allocation Release Process (Node 3): This activity submits the PA Allocation Release Process.



PA Customizable Allocation Process (Node 4): This activity submits the PA Customizable Allocation Process.






End (Rollback) (Nodes 6, 7, and 8): This is for allocation rollbacks (not supported in this release).

End (Fail) (Nodes 9, 10, 11): This activity terminates the process and returns the result Fail.

PA Allocation Generation Process

This process submits an allocation run.

In the diagram shown below, the process activity nodes are numbered for reference in the descriptions that follow. The numbered circles are not part of the process diagram.

PA Allocation Generation Activities

The following information describes each activity in the PA Allocation Generation process, listed by function

name:


Submit Allocation Run Process (Node 2): This activity submits the allocation run. Based on the defer

thread, this activity branches to node 4, Check Concurrent Program Status.

Check Concurrent Program Status (Node 4): This activity checks the status of the concurrent program



Submit Allocation Run Generation.

If the allocation has completed, the process branches to node 5.

If the release has not completed, the process branches to node 12.

Check Allocation Run for Exceptions (Node 5): This activity checks the completed allocation run for any exceptions.

If there are exceptions, the process branches to node 9.

If there are no exceptions, the process branches to node 6.

Notify (Node 9): This activity sends a notification that the concurrent program has not completed.

If a restart response is received, the process branches back to node 2.

If a rollback response is received, the process branches to node 7.

If the notification times out, the process branches to node 11.

If a terminate response is received, the process branches to node 8.

Notify - No Rollback (Node 12): This activity sends a notification that the allocation run had exceptions.




End (Rollback) (Node 7): This is for allocation rollbacks (not supported in this release).

End (Fail) (Nodes 8, 11, 14, and 15): This activity terminates the process and returns the result Fail.

PA Allocation Release Process

This process releases an unreleased allocation run.





PA Allocation Release Activities

The following information describes each activity in the PA Allocation Release process, listed by function name:


Is Allocation Run Released? (Node 2): This process tests whether the allocation run has been released.

If the run has been released, the process branches to node 12.

If the run has not been released (is in draft form), the process branches to node 3.

Release Confirmation Notification (Node 3): This process sends a notification asking for confirmation of the release.

If the release is confirmed, the process branches to node 5.

If the release is not confirmed, the process branches to node 4.

Submit Allocation Run Release Process (Node 5): This activity submits the allocation run release. Based

on the defer thread, this activity branches to node 9.


Submit Allocation Run Release.











Check Allocation Run for Exceptions (Node 13): This activity checks the completed allocation run for any exceptions.



Notify (Node 14): This activity sends a notification that the allocation run had exceptions.




End (Fail) (Nodes 4, 7, 11, 16, and 18): This activity terminates the process and returns the result Fail.

End (Rollback) (Nodes 15 and 19): This is for allocation rollbacks (not supported in this release).


You can customize this process for reporting, checking data, or similar tasks.





PA Customizable Allocation Activities

The following information describes each activity in the PA Customizable Allocation process, listed by function

name:


Customizable Allocation (Node 2): This is a customizable node.


End (Fail) (Node 4): This activity terminates the process and returns the result Fail.


PA Cost Process

This process distributes allocated costs by calling two subprocesses, PA Distribute Cost Process and PA Customizable Distribute Cost Process. The PA Customizable Distribute Cost Process can restart the PA Distribute Cost Process.




PA Cost Activities

The following information describes each activity in the PA Cost process, listed by function name:


PA Distribute Cost Process (Node 3):

If this process is successful, it branches to node 6.


PA Customizable Distribute Cost Process (Node 6): This node calls the PA Customizable Distribute Cost process.

If this process is successful, it branches to node 8.



End (Fail) (Nodes 4 and 7): This activity terminates the process and returns the result Fail.


PA Distribute Cost Process

This process distributes the costs for the expenditures generated by the allocation run.





PA Distribute Cost Activities

The following information describes each activity in the PA Distribute Cost process, listed by function name:


Is There Any Expenditure Group to Cost? (Node 2): This process tests whether there is an expenditure group that needs to be costed.

If there is no expenditure group to cost, the process branches to node 3.

If there is an expenditure group to cost, the process branches to node 9


Notify (Nodes 7): This activity sends a notification that the concurrent program has not completed.







Submit Distribute Cost Process (Node 9): This activity submits the distribute cost process. Based on the defer thread, this activity branches to node 11.

Check Concurrent Program Status (Node 11): This activity checks the status of the concurrent program Submit Distribute Cost Process.











You can customize this process for tasks such as the following:

Reporting

Checking data

Running the process PRC: Generate Cost Accounting Events

Running the process PRC: Create Accounting to create accounting in Oracle Subledger Accounting, transfer subledger journal entries from Oracle Subledger Accounting to Oracle General Ledger, and post journal entries in Oracle General Ledger

Restarting the PA Distribute Costs Process




PA Customizable Distribute Cost Activities

The following information describes each activity in the PA Customizable Distribute Cost process, listed by

function name:


Customizable Distribute Cost: This is a customizable node.




PA Summarization Process

This process summarizes allocated costs by calling two subprocesses, PA Update Projects Summary Process and PA Customizable Summarization Process. The PA Customizable Summarization Process can restart the PA Update Projects Summary Process.




PA Summarization Activities

The following information describes each activity in the PA Summarization process, listed by function name:


PA Update Projects Summary Process (Node 3)



PA Customizable Summarization Process (Node 6): This node calls the PA Customizable Summarization process.




End (Fail) (Nodes 4 and 7): This activity terminates the process and returns the result Fail.


PA Update Projects Summary Process

This process summarizes the costs for the expenditures generated by the allocation run.




PA Update Projects Summary Activities

The following information describes each activity in the PA Update Projects Summary process, listed by function

name:


Submit Update Projects Summary Process (Node 2): This activity submits the summary process. Based on

the defer thread, this activity branches to node 4.


Submit Update Projects Summary Process.



Check Summarization Process for Exceptions (Node 5): This activity checks the completed summarization process for any exceptions.



















You can customize this process for reporting, restarting the PA Update Projects Summary Process, checking the data, or similar tasks.


PA Customizable Summarization Activities

The following information describes each activity in the PA Customizable Summarization process, listed by function name:




Customizable Summarization (Node 2): This is a customizable node.




Timeout Attribute

The timeout attribute sets the amount of time that a user has to respond to a notification. The default value is

1440 minutes (24 hours). The workflow timeout attribute executes three times. (For example, if the timeout value is 1440 minutes, the actual time that elapses before the step-down autoallocation stops is 4320 minutes, equivalent to 72 hours.)

If the person notified by the workflow does not respond after the attribute executes three times, the step-down autoallocation stops.

For information on backing up and modifying the Timeout attribute, see: Oracle Workflow Guide.

Related Topics

AutoAllocations, Oracle Projects Costing User Guide, Oracle Project Costing User Guide

Setting Up Step-Down AutoAllocation, Oracle General Ledger Implementation Guide

Case Study of Incremental Allocations

Send AR Notification Workflow

If your project is Pay When Paid enabled and you choose to receive pay when paid notifications, the Send AR Notification workflow informs project managers every time a receipt is applied in Oracle Receivables to an Oracle Projects customer invoice. You can enable the AR Receipt Notification check box either for a project type or as

part of revenue and billing information when setting up your project.

The notification contains information on the projects invoice in Oracle Receivables for which payment is received, the payment amount, the project for this customer invoice, and linked supplier invoices that are on pay when

paid hold. From the notification, you can click on the Open Supplier Summary link to access the Supplier Summary page for the project. The filename of this workflow is PAPWPARN.wft.

This workflow contains the following functions

Start. This is a standard activity that marks the start of the process.

Select Project Manager. This activity selects the manager for the project by calling the Select Project

Manager procedure in the Send AR Notification Workflow client extension (pa_ce_ar_notify_wf.Select_Project_Manager). You can customize this client extension to enter a recipient other than the default recipient of project manager. If a project manager is found, the process moves to

the next function, or it moves to the last function of End

Send AR Notification Subprocess. This activity sends a workflow notification by email to the selected project manager about receipts applied in Oracle Receivables on project invoices.

End. This activity terminates the process.



The following diagram illustrates the Send AR Notification subprocess described above.

Related Topics

Oracle Workflow Developers Guide

Project Types Window Reference

Revenue and Billing Information, Oracle Projects Fundamentals

Oracle Project Foundation Workflows

Oracle Project Foundation provides workflows to integrate with Oracle Sales, enhance existing workflows, and

for status change approvals.

Overview of Oracle Project Foundation Workflows

Oracle Project Foundation provides the following workflows:


The PA: Mass Pipeline Projects Update workflow is used for integration of Oracle Projects with Oracle Sales. The workflow sends notifications to project managers and staffing owners of any change in status of sales

opportunities. The filename of this workflow is PAYPRJNT.wft.

PA: Mass Pipeline Projects Update Processes



Integrates Oracle Projects with Oracle Sales

PA: Oracle Projects Library Workflow Contains common functions that can be used to enhance other workflows

PA: Project Workflow Routes project status changes to one or more destinations for

approval



This workflow includes the PA: Mass Pipeline Projects Update process.

PA: Mass Pipeline Projects Update

This process informs the project manager and the staffing owner about change in status of a sales opportunity.



PA: Mass Pipeline Projects Update Activities

The following information describes each activity in the PA: Mass Pipeline Projects Update process, listed by function name:


Mass Pipeline Projects Update Success Notification (Node 2): This activity sends a notification to the project managers and the staffing owners informing them that the status of an opportunity has changed.

End (Node 3): This activity terminates the process.

Related Topics

Integrating with Oracle Sales, Oracle Projects Fundamentals

PA: Oracle Projects Library Workflow

The PA: Oracle Projects Library workflow is a library of common functions that you can use to modify or enhance other provided workflows. The filename of this workflow is PAPROJWF.wft.

PA: Project Workflow

You use the PA: Project Workflow to route project status changes to one or more destinations for approval. The filename for this workflow is PAPROJWF.wft.

The following diagram shows a typical flow of status changes for a project:



The project statuses names are user-defined, and the statuses you create for your business may be different

from those given in the diagram above. You may have some projects that require several status changes, while other projects (those with a short duration, for example) may have fewer status changes, and may not require

approval. Oracle Projects enables you to implement the status flow you require for each project, and to use the PA: Project workflow to automate the approvals and processes involved with each status.

Implementing the PA: Project Workflow

To make this workflow active, you must do the following:

For project status, select the Enable Workflow check box. For each of these project statuses, specify the Success Project Status and Failure Project Status.

For project type, select the Use Workflow for Project Status Changes check box. For more information, see Project Types, Oracle Projects Implementation Guide.

If required, you can modify the project workflow process to perform the routing, notifications, and

processes that you require for each status change.

You can optionally use the Project Workflow client extension to further customize project workflow rules. See: Project Workflow Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

PA: Project Workflow Processes

The workflow includes the following processes:

Project

Project Approval Subprocess

Project Process

Oracle Projects provides a default project workflow process, called PA: Project Workflow.

The default process routes approval of a project status change to the supervisor of the status change submitter. The default project workflow process does not need to be modified in order to run without error. You may customize the process or create a new one, using the Oracle Workflow Builder. For more information on how to

use the Oracle Workflow Builder, see the Oracle Workflow Guide.




Project Workflow Activities

The following information describes each activity in the Project workflow process, listed by function name:


Select Project Approver (Node 2): This activity selects the approver for the project by calling the Select Project Approver procedure in the Project Workflow client extension

(PA_CLIENT_EXTN_PROJECT_WF.SELECT_PROJECT_APPROVER). The approver in the default procedure is the supervisor of the submitter of the workflow.

This activity has two possible outcomes.

If a project approver is found, the process branches to Node 10.

If a project approver is not found, the process branches to Node 3.

Notify Project Approver Not Found (Node 3): This activity notifies the submitter of the project that no

project approver was found. The submitter can optionally resubmit the project or terminate the submission.

If the project is resubmitted, the process branches to Node 6.

If the submission is terminated, the process branches to Node 4.

Set Failure Status (Nodes 4, 8, and 12): This activity sets the project status to the Failure Status indicated in the Project Statuses window. The process branches to an End (Failure) node.



End (Failure) (Nodes 5, 9, 13, and 16): This activity terminates the process and returns the result Failure.

Verify Project Rules (Node 6): This activity verifies that the project satisfies the requirements for approval by

calling the Verify Project Status Change procedure in the Project Workflow client extension (PA_CLIENT_EXTN_PROJ_STATUS.VERIFY_PROJECT_STATUS_CHANGE).

If the verification rules are satisfied, the process branches to Node 2.

If the verification rules are not satisfied, the process branches to Node 7.

Notify: Project Failed Verification Rules (Node 7): This activity notifies the submitter that the project failed the verification rules. The submitter may resubmit the project for approval or terminate the submission.

If the project is resubmitted, the process branches to Node 6.


Project Approval Subprocess (Node 10): This activity runs the Project Approval Subprocess. See: Project

Approval Subprocess.

If the Project Approval Subprocess succeeds, the process branches to Node 14.

If the Project Approval Subprocess fails, the process branches to Node 11.

Notify: Project Rejected (Node 11): This activity notifies the submitter that the status change for the project was rejected.

If the submitter chooses to resubmit the project, the process branches to Node 6.

If the submitter terminates the submission, the process branches to Node 12.

Set Success Status (Node 14): This activity sets the project status to the Success Status indicated in the Project Statuses window.

If the project status is successfully changed, the process branches to Node 17.

If the status change is unsuccessful, the process branches to Node 15.

Notify: Project Status Change Failed (Node 15): This activity notifies the submitter that the project status change failed. The status change can fail if the project was changed after it was approved, so that it no longer complies with the project verification rules. An Oracle database error can also cause the failure.

Notify: Project Approved and Status Changed (Node 17): This activity notifies the submitter that the project was approved and the project status was changed.

End (Success) (Node 18): This activity terminates the process and returns the result Success.

Project Approval Subprocess

The Project Approval Subprocess is called by the default PA: Project Workflow process.




Project Approval Subprocess Activities

The following information describes each activity in the Project Approval Subprocess, listed by function name:

Start (Node 1): The following information describes each activity in the Project Approval Subprocess, listed by function name:

Notify: Project Approval Required (Node 2): This activity notifies the project approver that approval is

required for the project status change.

If the project approver approves the project, the subprocess branches to Node 5.

If the project approver rejects the project, the subprocess branches to Node 6.

If the activity times out, the subprocess branches to Node 3. The default time for the activity to time out is two days. You can use the Oracle Workflow Builder to change the timeout value to suit your business

needs.

Notify: Reminder, Project Approval Required (Node 3): This activity sends a reminder notification to the project approver.

If the project approver approves the project, the subprocess branches to Node 5.

If the project approver rejects the project, the subprocess branches to Node 6.

If the activity times out, the subprocess branches to the Loop Counter (Node 4).



Loop Counter (Node 4): This activity counts the number of times the subprocess has branched to this node.

If the count has reached the Loop Limit (a constant that is set in this node), the subprocess branches to

Node 6.

If the count has not reached the Loop Limit, the subprocess returns to Node 3.

The loop counter defaults to a limit of 1. (You can change the default value of the loop counter.)

After the activity reaches the Loop Limit, the process sends one more reminder. If there is no response, the loop counter stops counting and branches to node 6.

End (Approved) (Node 5): This activity ends the subprocess and returns the result Approved.

End (Rejected) (Node 6): This activity ends the subprocess and returns the result Rejected.

Project Workflow Example

The following diagram illustrates project status flow where the project workflow is used for three status changes during the lifecycle of a project:

A user manually sets the status to Submitted for Approval. This initiates the workflow process is, which if successful, the status is updated to Approved.

A user manually sets the status to Pending Close. This initiates the workflow process, which if successful, the status is updated to Closed.

Oracle Project Management Workflows

Oracle Project Management provides workflows to manage and transmit information about budgets, issues, change orders, project execution, and status reporting.

Overview of Oracle Project Management Workflows

Oracle Project Management provides the following workflows:


PA: Budget Manages budget approvals



PA: Budget Workflow

Budget statuses progress in the following order:

1. Working

2. Submitted

3. In Process

Workflow

PA: Budget

Integration Workflow

For bottom-up integrated budgets: Validates the submitted budget version, creates baseline version, generates accounting events, creates accounting in final mode in Oracle Subledger Accounting, and validates budget amounts against the Oracle General Ledger budget. For top-down integrated budgets: Validates the submitted budget version, creates baseline version, validates existing approved transaction amounts (at resource, resource group, task, top task and project levels) against the project budget, generates accounting events, creates accounting in final mode in Oracle Subledger Accounting, validates budget amounts

against the General Ledger Funding Budget, and validates existing approved transaction amounts (at account level) against the project budget. For non-integrated budgets with budgetary controls: Validates the submitted budget version, creates baseline version, and validates existing approved transaction amounts against the project budget.

PA: Change Request Approval

Routes change request approval


Routes deduction approval workflow

PA: Issue and

Change Workflow

Routes control items approvals

PA: Issue and

Change Action Workflow

Sends issue and change action notifications

Project Budget Account

Generation Workflow

Automates account generation and assignment process

PA: Project Execution Workflow

Coordinates the Task Execution Workflows that you create to perform tasks

PA: Performance

Notification Workflow

Sends performance notifications

PA: Status Report Workflow

Routes status report approvals

PA: Task Approval

Workflow

Routes approval of tasks created in a change document.

PA: Workplan

Workflow

Sends workplan status notifications



4. Baselined

When you submit the draft budget for approval, the PA: Budget workflow is initiated. The filename of this

workflow is PABUDGWF.wft.

Implementing the PA: Budget Workflow

To use the workflow for approving budgets and approving forecasts, you must perform the following steps:

For budget types, enable the "Use Workflow for Budget Status Change" check box. For more information, see: Budget Types.

For financial plan type, enable the "Use Workflow for Status Changes" check box. For more information, see: Financial Plan Types.

For project type, enable the "Use Workflow for Project Status Change" check box.

Modify the Budget Workflow process to perform the routing, notifications, and processes that you require for each status change.

You can optionally use the Budget Workflow client extension to further customize the PA: Budget Workflow. See:

Budget Workflow Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Oracle Projects also supplies a budget verification extension. PA Budget Workflow calls this extension before it:

Initiates the budget approval process

Changes the budget status

This ensures that the verification rules for the status change are met, even if changes have been made to the budget during the approval process.

PA: Budget Workflow Processes

The workflow includes the following processes:

Budget

Budget Approval Subprocess

Budget Process

Oracle Projects provides a default budget workflow process, called the PA Budget workflow.

You can alter, delete, or move any of the activities in the default budget workflow process to obtain the desired results for your installation. You may customize the process or create a new one, using the Oracle Workflow Builder. For more information on how to use the Oracle Workflow Builder, see the Oracle Workflow Guide.




Budget Workflow Activities

The following information describes each activity in the PA: Budget Workflow process, listed by function name:


Select Budget Approver (Node 2): This activity selects the approver for the budget by calling the Select Budget Approver procedure in the Budget workflow client extension

(PA_CLIENT_EXTN_BUDGET_WF.SELECT_BUDGET_APPROVER). The approver in the default procedure is the immediate supervisor of the person who submitted the budget. This activity has the following two possible outcomes:

If a budget approver is found, the process branches to Node 10.

If a budget approver is not found, the process branches to Node 3.

Notify Budget Approver Not Found (Node 3): This activity notifies the submitter of the budget that no

budget approver was found. The submitter can optionally resubmit the budget or terminate the submission.

If the budget is resubmitted, the process branches to Node 6.


Reset Budget Status to Rejected (Nodes 4, 8, and 12): This activity sets the budget status to Rejected. The process branches to an End (Not Baselined) node.

End (Not Baselined) (Nodes 5, 9, 13, and 18): This activity terminates the process and returns the result



Not Baselined.

Verify Budget Rules (Node 6): This activity verifies that the budget satisfies the requirements for approval by

calling the Verify Budget Rules procedure in the Budget workflow client extension (PA_CLIENT_EXTN_BUDGET_WF.VERIFY_BUDGET_RULES). The default procedure does not include any requirements.

If the verification rules are satisfied, the process branches to Node 2.

If the verification rules are not satisfied, the process branches to Node 7.

Notify: Budget Failed Verification Rules (Node 7): This activity notifies the submitter that the budget failed

the verification rules. The submitter may resubmit the budget for approval or terminate the submission.

If the budget is resubmitted, the process branches to Node 6.


Budget Approval Subprocess (Node 10): This activity runs the Budget Approval Subprocess. See: Budget Approval Subprocess.

If the Budget Approval Subprocess succeeds, the process branches to Node 14.

If the Budget Approval Subprocess fails, the process branches to Node 11.

Notify: Budget Rejected (Node 11): This activity notifies the submitter that the budget was rejected.

If the submitter chooses to resubmit the budget, the process branches to Node 6.

If the submitter terminates the submission, the process branches to Node 12.

Baseline Approved Budget (Node 14): This activity sets the budget status to Baseline.

If the budget baseline is successful, the process branches to Node 19.

If the budget baseline is unsuccessful, the process branches to Node 15.

Notify: Budget Baseline Failed (Node 15): This activity notifies the submitter that the budget baseline

failed. The baseline can fail if the budget was changed after it was approved, so that it no longer complies with the budget verification rules. An Oracle database error can also cause the failure.

Is Federal Enabled And Notify Interface Status is False? (Node 16): This activity checks whether the

profile option FV: Federal Enabled is set to Yes at the site level. If yes, the activity calls the Federal Integration client extension to insert the budget lines into the open interface tables FV_BE_INTERFACE_CONTROL and FV_BE_INTERFACE.

If the extension fails, then the process branches to Node 17.

If the extension executes with no errors, or if the profile option FV: Federal Enabled is not set to Yes at the site level, then the process branches to Node 18.

Notify: Budget Baseline and Interface Failed (Node 17): This activity notifies the submitter that the budget baseline failed because the Federal Integration client extension returned an error status.

Notify: Budget Approved and Baselined (Node 19): This activity notifies the submitter that the budget was

approved and a baseline budget is created.



Is Federal Enabled And Notify Status is True? (Node 20): This activity checks if the value of the profile option FV: Federal Enabled is set to Yes at the site level. If it is it set to Yes, the process branches to node 21.

Otherwise, the process branches to node 22.

Notify: Budget Approved and Baselined (Node 21): This activity notifies the budget approver that the budget baseline was successfully created.

End (Baselined) (Node 22): This activity terminates the process and returns the result Baseline.

Budget Approval Subprocess

The Budget Approval subprocess is called by the default PA Budget Workflow process.



Budget Approval Subprocess Activities

The following information describes each activity in the Budget Approval subprocess, listed by function name:


Notify: Budget Approval Required (Node 2): This activity notifies the budget approver that approval is required for the budget status change.

If the budget approver approves the budget, the subprocess branches to Node 5.



If the budget approver rejects the budget, the subprocess branches to Node 6.

If the activity times out, the subprocess branches to Node 3.

Notify: Reminder, Budget Approval Required (Node 3): This activity sends a reminder notification to the budget approver.

If the budget approver approves the budget, the subprocess branches to Node 5.

If the budget approver rejects the budget, the subprocess branches to Node 6.

If the activity times out, the subprocess branches to the Loop Counter (Node 4).

Loop Counter (Node 4): This activity counts the number of times the subprocess has branched to this node.

If the count has reached the Loop Limit (a constant that is set in this node), the subprocess branches to Node 6.

If the count has not reached the Loop Limit, the subprocess returns to Node 3.

The loop counter defaults to a limit of 1. (You can change the default value of the loop counter.)

After the activity reaches the Loop Limit, the process sends one more reminder. If there is no response, the loop counter stops counting and branches to node 6.

End (Approved) (Node 5): This activity ends the subprocess and returns the result Approved.

End (Rejected) (Node 6): This activity ends the subprocess and returns the result Rejected.

Related Topics

Submitting a Draft, Oracle Project Management User Guide

Budget Workflow Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference

Budget Verification Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference

PA: Budget Integration Workflow

When a project uses budgetary controls, the budget baseline process launches the PA: Budget Integration workflow.

The PA: Budget Integration workflow performs the following tasks:

For bottom-up integrated budgets:

1. Validates the submitted budget version and changes the budget version status to In Progress

2. Creates baseline version

3. Generates accounting events

4. Creates accounting in final mode for the accounting events in Oracle Subledger Accounting

5. Validates budget amounts against an Oracle General Ledger budget



Note: If the budget fails funds validation, then the workflow removes the accounting entries it created form Oracle Subledger Accounting and updates the submitted budget version to Rejected status.

6. Sends a workflow notification to the user when the baseline process is complete

For top-down integrated budgets:

1. Validates the submitted budget version and changes the budget version status to In Progress


3. Validates existing approved transaction amounts (at resource, resource group, task, top task and

project levels) against the project budget

4. Generates accounting events

5. Creates accounting in final mode for the accounting events in Oracle Subledger Accounting

6. Validates budget amounts against the General Ledger Funding Budget

7. Validates existing approved transaction amounts (at account level) against the project budget

Note: If the budget fails either funds validation, then the workflow removes the accounting entries it

created from Oracle Subledger Accounting and updates the submitted budget version to Rejected status.

8. Sends a workflow notification to the user when the baseline process is complete

For non-integrated budgets with budgetary controls:

1. Validates the submitted budget version


3. Validates existing approved transaction amounts against the project budget

Note: The PA: Budget Integration workflow generates and processes accounting events only for top-down and

bottom-up integrated budgets. It does not generate and process accounting events for non-integrated budgets.

Note: You run the process PRC: Transfer Journal Entries to GL to transfer the journal entries to Oracle General Ledger. When you submit the process PRC: Transfer Journal Entries to GL, you can optionally choose to have the

process post the journal entries. Otherwise, you can manually post the journal entries in Oracle General Ledger.

The baseline process updates funds balances in Oracle General Ledger. The process PRC: Transfer Journal Entries to GL does not affect funds balances.

For additional information, see: Transfer Journal Entries to GL, Oracle Projects Fundamentals

The filename of this workflow is PAWFBUI.wft.

Important: This is a system-defined workflow that cannot be modified.

Implementing the PA: Budget Integration Workflow




Enable budgetary controls for the project

Ensure that the workflow background process is running to process the submitted deferred workflow

PA: Budget Integration Workflow Processes

The workflow includes the PA Budget Integration process.

PA: Budget Integration Process

This workflow process enables you to create baseline budgets when budget integration is used.


PA: Budget Integration Process Activities

The following information describes each activity in the PA: Budget Integration process, listed by function name:


PA Notify Project Resource Administrator (Node 3): This activity sends a notification to the PASYSADMIN

that the budget integration has not been processed successfully.

PA Process Budget Integration (Node 4): This activity performs edits and calls the funds checking processes for integrated budgets.

If the budget passes the funds check, the process branches to Node 3.



If the budget does not pass the funds check, the process branches to Node 5.

PA Notify Requestor (Node 5): This activity sends a notification to the person who started the workflow that

the budget integration has been processed successfully.

End (Nodes 2 and 6): This activity terminates the process.

PA: Change Request Approval Workflow

The PA: Change Request Approval Workflow is the approval of change request. Whenever you submit a change request for approval, this workflow sends an email notification to the approver of the change request. Based on

this notification, the approver can either approve or reject the change request.

In the diagram, the process activity nodes are numbered for reference in the descriptions that follow.

The following information describes each activity in the PA: Change Request Approval workflow process.

Start (Node 1): This is a standard activity that marks the start of the workflow process.

Are All Tasks Approved (Node 2): This activity check if all the tasks in the change request are in approved status or not.

If all the tasks are approved, then the process branches to Node 3.

If there are tasks that are not approved, then the process branches to Node 11.

Is Approver Same as Submitter (Node 3): This activity checks if the approver is the same person who has

requested for approval.

If the approver is same person who has requested for approval, then the process branches to Node 7.

If the approver is different from the person who has requested for approval, then the process branches to



Node 4.

Set CI Approver (Node 4): This activity sets the approver of the change request.

Approval Request (Node 5): This activity send and FYI notification to the approver to approve the change request.

If the approver rejects the approval, then process branches to Node 9.

FORWARD_POST_NOTIFICATION (Node 6): This is invoked if the receiver of the notification chooses to forward it to another user.

Request Approved (Node 7): This activity approves the change request.

Approval Request Approved (Node 8): This activity sends a notification to the person who has requested for approval of the change request that it has been approved.

Request Rejected (Node 9): This activity rejects the approval request.

Approval Request Rejected (Node 10): This activity sends an e-mail notification to the person who has submitted the approval request that the change order has been rejected.

Mark Change Document Status (Node 11): This activity updates the status of the change document to

Submitted.

Set CI Approver (Node 12): This activity identifies the approver of the Control Item, task, the approval of

which is pending.

Pending for Task Approval (Node 13 and Node 14): This activity sends an e-mail notification to the person who has submitted the task for approval and the approver of the change document that the approval of the

change document is pending approval of the task.

End (Node 15): This activity terminates the workflow process.


The PA: Deduction workflow is a deduction approval workflow. Whenever you submit a deduction for approval this workflow sends and email notification to the approver.




The following information describes each activity in the PA: Deduction workflow.

Start (Node 1): This is a standard activity that marks the start of the workflow process.

Select Project Manager (Node 2): This activity stores the project manager that user has selected. The

project manager acts as the approving authority for the deduction.

If the user has selected a project manager, then the process branches to Node 3.

If project manager is not available, then the process branches to Node 5.

Send Deduction Approval Notification (Node 3): This activity sends a notification to the project manager that the deduction has been approved.

Notify: Notification to Manager Failed (Node 4): The notification has failed.

Notify: Project Manager Not Available (Node 5): This activity sends a notification, to the requestor, that the project manager is not available, and the workflow terminates.

End (Node 6): This activity terminates the workflow process.

Send Deduction Approval Notification Process

If notification is successfully sent, then the process branches to Node 6.

If there is an exception, then the process branches to Node 4 and a notification is sent to the project

manager.



PA: Issue and Change Workflow

The PA: Issue and Change workflow is an approval workflow for control items. Whenever ownership of a control item changes, this workflow sends an FYI notification to the new owner. The filename of this workflow is PAWFCISC.wft.

Implementing the PA Issue and Change Workflow


Enable this workflow for a control item status

Enter the workflow name (PA: Issue and Change Workflow) and the process name (PA: Control Item Process Approval)

You can optionally use the Issue and Change Workflow client extension to further customize the PA Issue and Change workflow. See: Issue and Change Workflow Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

PA Issue and Change Workflow Processes

This workflow includes the following processes:

PA: Control Item Owner Change FYI

PA: Control Item Process Approval

PA: Control Item Owner Change FYI

When the owner of a control item is changed, this process sends an FYI notification to the new owner.


PA: Control Item Owner Change FYI Activities

The following information describes each activity in the PA: Control Item Owner Change FYI process, listed by

function name:


Owner Change FYI (Node 2): This activity sends an FYI notification of the change of ownership to the new



owner of the control item.


PA: Control Item Process Approval

This process checks for the approver of a submitted control item in the following ways:

If the approver is the same person who submitted the control item, this process approves the control item and sends an FYI notification to the approver.

If the approver is not the same person who submitted the control item, this process uses the Set Control

Item Approver procedure in the Issue and Change Workflow client extension to determine the approver, and sends a notification to the approver.

The approver can approve, reject, or forward the notification.

Note: The process PA: Control Item Process Approval is launched only if the workflow is enabled for the control item status.


PA: Control Item Process Approval Activities

The following information describes each activity in the PA: Control Item Approval process, listed by function

name:


Is Approver Same as the Submitter (Node 2): This activity determines if the submitter of the control item



approval process is also the approver.

If the approver is the same person as the submitter, the process branches to Node 6.

If the approver is not the same person as the submitter, the process branches to Node 3.

Set CI Approver (Node 3): This activity calls the Set Control Item Approver procedure in the Issue and Change Workflow client extension (PA_CONTROL_ITEMS_WF_CLIENT.SET_CI_APPROVER) to determine the

approver of the control item. The default approver is the Project Manager.

Approval Request (Node 4): This activity sends a notification to the approver requesting approval of the control item.

If the approver approves the control item, the process branches to Node 5.

If the approver rejects the control item, the process branches to Node 7.

Forward Post Notification (Node 5): This activity is called when an approval notification is forwarded to an

approver who is not the submitter. It checks to see if the approver is a valid user. If the approver is a valid user, the notification is sent to the approver. If not, the request is rejected.

Request Approved (Node 6): This activity changes the status of the control item to Approved.

Request Rejected (Node 7): This activity changes the status of the control item to Rejected.

Approval Request Approved (Node 8): This activity sends a Control Item Approved FYI notification to the

control item owner.

Approval Request Rejected (Node 10): This activity sends a Control Item Rejected FYI notification to the control item owner.


PA: Issue and Change Action Workflow

You can use the PA: Issue and Change Action workflow to generate e-mail notifications for all user actions. The filename of this workflow is PAWFCIAC.wft.

The e-mail notification contains details regarding project information, change orders, and actions. From the

notification, you can select View Issue/Change Order to view a read-only version of the issue or change document. The Request region shows comments entered by the person who initiated the notification.

To assign an action to another user, the user selects Take Action and logs in.

PA: Issue and Change Action Workflow Processes

This workflow includes the following processes:

PA: Action Assignment with Signoff

PA: Action Assignment without Signoff

PA: Action Close FYI

The first two processes request the user to take one of the following actions as relevant to the process:



Close the issue or change action (while closing the action a user can signoff the action if the action requires a signoff)

Keep the issue or change action open and update with any information included with the response

Reassign the issue or change action

If the user responds from the Take Action page, the notification is closed and no further action can be taken

directly from it.

PA: Action Assignment with Signoff

This process is called when an action is created that requires a signoff. The process sends a response-required notification to the assignee.


PA: Action Assignment with Signoff Activities

The following information describes each activity in the PA: Action Assignment with Signoff process, listed by

function name:


Action Assigned with Signoff (Node 2): This activity sends a notification to the action assignee that the

action is assigned with a signoff. The user can respond by selecting Keep Open or Close.

If the action assignee selects Keep Open, the process branches to Node 3.

If the action assignee selects Close, the process branches to Node 4.

Keep Open Function (Node 3): This activity is called when user selects Keep Open. It records any user comments.

Close Action (Node 4): This activity is called when the user selects Close Action. It records any user



comments and changes the status of the action to Closed.


PA: Action Assignment without Signoff

This process is called when an action is created that does not require a signoff. It sends a response-required

notification to the assignee.


PA: Action Assignment Without Signoff Activities

The following information describes each activity in the PA: Action Assignment Without Signoff process, listed by function name:


Action Assigned without Signoff (Node 2): This activity sends an Action Assigned Without Signoff notification to the action assignee.

If the action assignee selects Keep Open, the process branches to Node 3.

If the action assignee selects Close, the process branches to Node 4.

Keep Open Function (Node 3): This activity is called when user selects Keep Open. It records user any

comments.

Close Action (Node 4): This activity is called when user selects Close Action. It records any user comments and changes the status of the action to Closed.


PA: Action Closed FYI

This process sends an FYI notification to the owner of an action when the action is closed. If the action was reassigned at any time, the notification is also sent to all previous owners.




PA: Action Closed FYI Activities

The following information describes each activity in the PA: Action Closed FYI process, listed by function name:


Action Closed FYI (Node 2): This activity sends an FYI notification that the action has been closed.


Project Budget Account Generation Workflow

The Project Budget Account Generation workflow enables you to automate the account generation and assignment process. The filename of this workflow is PABDACWF.wft.

You can use the Budget Account Details window to review and optionally override the accounts generated by the Project Budget Account Generation workflow. For more information, see: Reviewing and Overriding Budget Account Details for Integrated Budgets, Oracle Project Management User Guide, Oracle Project Management User Guide.

Implementing the Project Budget Account Generation Workflow

This workflow runs when one of the following occurs:

A user manually selects the Generate Budget Accounting option from the Tools menu of the Budgets window.

A user submits an integrated budget and it creates a baseline version.

A user runs the year-end rollover process for a top-down integrated budget to carry forward the unspent project budget encumbrance amount from the year that is ending into the next year.

When you activate the workflow from the Tools menu, an account is generated or regenerated for all the defined budget lines. When the workflow is activated during budget submission, accounts are only generated for budget lines that do not already have an assigned account.

Note: Do not update the account for the budget line if the budget line is associated with transactions. Updating the account causes the baseline process to fail.

You must customize the Project Budget Account Generation workflow to generate accounts based on your



business needs. Oracle Projects provides predefined parameters to simplify the customization process. You can use the predefined parameters to derive accounts based on project organizations, expenditure organizations,

and tasks, or based on the resource groups and resources used for budget entry. For a complete list of the parameters, see: Project Budget Account Generation Workflow Parameters.

For more information about customizing Account Generator workflows, see: Using the Account Generator in

Oracle Projects, and the Oracle Applications Flexfields Guide.

Account Generation for Top-Down Budget Integration and Oracle Subledger Accounting

For top-down budget integration, the Project Budget Account Generation workflow generates the default

encumbrance account.

When you create a budget baseline or run the process PRC: Year End Budget Rollover, Oracle Projects generates

accounting events and creates accounting for the events in Oracle Subledger Accounting. Oracle Projects predefines setup in Oracle Subledger Accounting to accept default encumbrance accounts from Oracle Projects and transfer them to Oracle General Ledger without change. If you define your own detailed accounting rules in

Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Projects derives using the Project Budget Account Generation Workflow.

Important: You must define the Reserve for Encumbrance Account that Oracle Subledger Accounting uses to create balancing encumbrance recovery accounting entries. You use the Accounting Setup Manager in Oracle General Ledger to specify the Reserve for Encumbrance Account for your ledger. For more information, see the discussions about the Accounting Setup Manager in the Oracle Financials Implementation Guide and the Oracle General Ledger Implementation Guide.

Important: If you update account derivation rules for budgets in Oracle Subledger Accounting, then you must carefully consider the affect of the updates on existing integrated budgets. The baseline process fails if a revised

account derivation rule overwrites accounts for budget lines that are associated with transactions.

Account Generation for Bottom-Up Budget Integration and Oracle Subledger Accounting

For bottom-up budget integration, the Project Budget Account Generation workflow generates the default cost or

revenue budget account.

When you create a budget baseline, Oracle Projects generates accounting events and creates accounting for the

events in Oracle Subledger Accounting. Oracle Projects predefines setup in Oracle Subledger Accounting to accept default budget accounts from Oracle Projects and transfer them to Oracle General Ledger without change. If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger

Accounting overwrites default accounts, or individual segments of accounts, that Oracle Projects derives using the Project Budget Account Generation Workflow.

Important: If you update account derivation rules for budgets in Oracle Subledger Accounting, then you must

carefully consider the affect of the updates on existing integrated budgets. The baseline process fails if a revised account derivation rule overwrites accounts for budget lines that are associated with transactions.

Project Budget Account Generation Workflow Process

This workflow includes the Generate Default Account process.

Generate Default Account Process

You use the process to generate accounts.




Generate Default Account Process Activities

The following information describes each activity in the Generate Default Account process, listed by function

name:

Start Generating Code Combination (Node 1): This is a standard activity that marks the start of the process.

Dummy Default Account Generator (Node 2): This activity can be replaced by your defined procedure for account generation.

If the account generation succeeds, your procedure should branch to Node 4.

If the account generation fails, your procedure should branch to Node 3.

Abort Generating Code Combination (Node 3): This activity ends the process as an error if a code combination was not generated.

Validate Code Combination (Node 4): This activity checks to see if the generated code combination is valid.

End Generating Code Combination (Node 5): This activity terminates the process.

Account Generation Example

The following example uses Fremont Corporation to show a sample strategy for customizing the Project Budget Account workflow. This strategy reduces the maintenance required for customization.

Fremont Corporation: Background

Fremont Corporation uses bottom-up budgeting for revenue reporting and top-down budgeting for controlling costs. They define their organization-level budgets in Oracle General Ledger and use Oracle Projects budget

integration to integrate their project budgets with the defined GL budgets.

In this example, Fremont uses a four-segment accounting flexfield to represent their chart of accounts. The segments are: Company, Cost Center, Account, and Future Use.

Account Generation Business Rules

To generate accounts for integrated project budget lines, Fremont Corporation uses the following business rules:

Company: Project owning organizations are used to derive the company segment.



Cost Center

Cost: Project budget expenditure organizations are used to derive the cost center segment

Revenue: Project budget revenue organizations are used to derive the cost center segment

Account

Cost: Project budget expenditure categories are used to derive the account segment

Revenue: Project budget revenue categories are used to derive the account segment

Future Use: The future use segment is always assigned a value of 000.

Note: Fremont Corporation enters budget amounts using a two-level resource list. Budget amounts are entered

by organization and expenditure/revenue category.

Business Rule Implementation

To implement their business rules, Fremont Corporation defines the AutoAccounting lookup sets listed below.

They customize the Project Budget Account Generation workflow to use the lookup sets to assign values to each account segment. This approach reduces the effort required to customize the Project Budget Accou

all about oracle projects workflow

Documents

oracle workflow processes

oracle workflow builder

change workflow pa

advertisements workflow

deduction workflow pa

workflow processespage

project execution workflow

task approval workflow