Understanding Project Cost and Revenue Budgets

This table describes terms that are relevant to project budgeting:

This table lists the high level steps to enable and set up project budgeting and provides a link to the documentation that discusses the step:

Project Costing supports top-down project budgeting, bottom-up project budgeting, and the ability to adjust existing project budgets.

This diagram shows the bottom-up and top-down project budgeting process flow in Project Costing:

You can simplify the process of creating budgets by using project templates. For example, you can create a project template that contains the detailed work breakdown structure, budget plan, and budget items that are associated with the project activities. Use the template to populate new projects with the preset budget information. You can modify the project template, or create multiple templates to meet your business needs.

The main steps to create budgets from the top down are:

1. Enter a high-level estimate for the project on the Budget Plan page.

   Use this page to enter budget scenarios for the project. Budget plans provides a high level definition of the total budget for each project budget under consideration.

2. (Optional) Distribute the estimate down to summary activities on the Budget Detail page.

3. Distribute the estimate down the WBS to costing activities on the Budget Detail page.

   Use this page to define a specified project budget at a greater level of detail by using budget items.

4. Adjust budget amounts for budget items on the Project Budget Items - Adjust Budget Items page.

   Use this page to spread the budget amounts to budget items on costing activities.

5. Distribute the estimate across periods on the Project Budget Periods - Adjust Budget Periods page.

   Return to this page to distribute the budget item budget adjustment across budget periods.

6. Choose one cost and one revenue budget plan and finalize the plans.

   Finalizing a budget plan sends the budget data to the Project Transaction Interface staging table (INTFC_PROJ_RES) and initiates a process to determine if the budget transactions go directly to the Project Transaction table (PROJ_RESOURCE). If Commitment Control is active for Project Costing and the GL business unit and ledger group combination, the rows must first go through Commitment Control.

   You can finalize only active plans.

You distribute project-level cost estimates across the WBS for detail activities, budget items, and time periods by using one of the distribution options listed in this table:

You can enter negative percentages and amounts for activities, budget items, and periods.

After you create a detailed WBS and budget plan in Project Costing, you can create budget details by estimating amounts by period for budget items and rolling up the amounts to the activity and project levels.

For example, you can enter revised period budget amounts at the budget item level, which roll up to the activity level. If the sum of the revised budget item amounts is different than the previous activity budget amount, you can override the previous activity budget amount. The sum of the revised activity budget amounts rolls up automatically to the project level.

If you use PeopleSoft Program Management, you can take advantage of a flexible project activity model that supports both a detail WBS for planning, and a cost breakdown structure for accounting. You can use different levels of the WBS for project management and accounting by defining the WBS level at which you want to track project budgets and costs. You can specify a project charging level of WBS level 1, level 2, or level 3, and the system restricts charges to summary and detail activities that are in the specified level. You can also specify a project charging level of all detail activities, in which case you can capture costs on detail activities, but not on summary activities—regardless of an activity's WBS level.

If you use PeopleSoft Project Costing without PeopleSoft Program Management, the project charging level is all detail activities.

See Understanding Project Charging Levels.

Budget items are one of the building blocks of a project budget. Initially, the system uses budget items to establish default ChartField values for budget rows. Later, budget items provide a way of identifying and grouping transactions that the system uses to identify a project activity's budget costs or revenue for a given period.

Project budgeting uses the fields defined on the budget item to match with actual amounts in project transactions. Only those transactions that match the defined ChartField values are counted as actuals for a given budget item.

You can establish cost budget alerts that warn the project manager of potential cost overruns at the project or activity level. The system compares budget amounts with values on the Summary Budget Data table (PC_BUD_SUMMARY), which stores summarized actual costs.

Although budget alerts are not processed at the business unit level, you establish cost budget alerts for the business unit that appear as default values for all project budgets belonging to that business unit. Cost budget alerts that you establish at the project level can be used as default values for project activities. You can override default settings at the project and activity levels.

Budget alerts appear on the Budgets vs Actuals interactive report.

You can define multiple cost budget plans and revenue budget plans for a project, and designate one cost budget plan and one revenue budget plan as active. After you distribute all summary budget amounts to costing activities, budget items, and periods, you can finalize the active plans.

Finalizing a budget plan sends the budget data to the Project Transaction Interface table and initiates the PC_WRAPPER Application Engine program which calls the Load Third-Party Transactions Application Engine process (PC_INTFEDIT). The Load Third-Party Transactions process triggers the Project Costing to Commitment Control Application Engine process (PC_TO_KK), which determines if the budget transactions must go through Commitment Control before they are posted to the Project Transaction table.

If Commitment Control is not required, the process sends the rows directly to the Project Transaction table. You can modify rows on the finalized budget plan and refinalize the plan, which updates the budget amounts on the Project Transaction table. You can also inactivate the previous finalized plan, and activate and finalize a different plan, which replaces the previous budget transactions with new finalized budget transactions on the Project Transaction table.

If Commitment Control is required, the Project Costing to Commitment Control process sends budget rows and cost transactions that require budget-checking to Commitment Control. With Commitment Control you cannot finalize another plan of the same budget type (cost or revenue) and analysis type. You can, however, add new rows on the Budget Detail page and refinalize the budget plan.

Finalizing a budget plan also triggers the Refresh Budget Summary Application Engine process (PC_BUD_SUM) to summarize budget data in the Summary Budget Data table.

After you finalize a budget you can run a Budgets to Costs Review by Period report (PCY1050.RPT) to perform budget versus cost analysis, or use the Budget vs. Actual interactive report to compare budgeted amounts with actual costs.

See Project Costing to Commitment Control Process.

You can retain a historical version of the budget plan transaction rows each time that you finalize a budget. Historical budget plan versions are stored in the Project Transaction table along with the current, finalized budget rows. Each historical budget version is uniquely distinguished by analysis type, and can be used for analysis and reporting. You can control budget plan versions by business unit.

By using budget row versioning, the first time that you finalize a project's budget plan, the system creates a copy of the plan and assigns a unique analysis type to budget rows in the plan copy. The new analysis type distinguishes these rows as historical budget plan version sequence one. The original analysis type remains unchanged on the current, finalized budget rows.

If you modify and refinalize the existing budget plan, or activate and finalize a different plan for the project, the system again creates a copy of the new plan and assigns a unique analysis type to budget rows in the plan copy. The new analysis type distinguishes these rows as historical budget plan version sequence two.

You configure the budget version analysis types, and the sequence in which they are used, by business unit. PeopleSoft delivers the following sequence of analysis types and analysis groups that you can use to distinguish historical cost and revenue budget versions:

You define these sequences at the business unit level, and use them at the project level. Each project independently uses the analysis type sequence for budget plan versions. The last analysis type used in the sequence is stored in the Project Header table (PS_PROJECT).

For example, assume that you finalize a new cost budget plan using the analysis type BUD. The system:

• Saves the budget detail rows with analysis type BUD in the Project Transaction table.

• Creates a copy of the finalized budget detail rows and updates the analysis type to CV1 (Historical Cost Budget Version 1).

• Stores the copy of the budget detail rows with analysis type CV1 in the Project Transaction table.

Next, assume that you refinalize the cost budget plan for the project. The system:

• Deletes the previously finalized budget detail rows with analysis type BUD from the Project Transaction table.

• Saves the new refinalized budget detail rows with analysis type BUD in the Project Transaction table.

• Creates a new copy of the refinalized budget detail rows and updates the analysis type to CV2 (Historical Cost Budget Version 2).

• Stores the copy of the budget detail rows with analysis type CV2 in the Project Transaction table.

The system does not retain a historical budget version in the Project Transaction table if:

• The project is commitment-controlled.

• The Enable Budget Row Versioning check box is not activated for the business unit on the Budget Row Versioning page at the time you finalize the budget.

• No budget analysis type sequence is defined on this page for the business unit.

• All of the analysis types in the budget analysis type sequence have been assigned to a budget version for the business unit.

By using budget row versioning you have the ability to preserve detailed budget rows in the Budgeting tables that match rows in the Project Transaction table. For example, assume that Budget Plan A is the active, finalized cost budget plan. The Project Transaction table contains budget rows with an analysis type of BUD for Budget Plan A, and a copy of Budget Plan A budget rows with an analysis type of CV1. Now you want to modify the budget plan. Instead of modifying and refinalizing Budget Plan A, you inactivate Budget Plan A and activate a new plan—Budget Plan B. When you finalize Budget Plan B, the system deletes the previous BUD rows for Budget Plan A from the Project Transaction table, creates new BUD rows for Budget Plan B, and creates a copy of the new Budget Plan B budget rows with an analysis type of CV2. Then if you want to view the detail rows in the Project Transaction table for analysis type CV1, you simply view Budget Plan A that contains identical rows.

You cannot use budget row versioning if you use Commitment Control.

See Budget Row Versioning Page.