Pricing Project Costs

This chapter provides an overview of the various pricing functions in PeopleSoft Project Costing, Variance Pricing, and discusses how to:

• Import transactions into PeopleSoft Project Costing.

• Define rates for employees, job codes, and project roles.

• Define rate set categories, rate sets, and rate plans.

• Define tiered pricing.

• Run the Pricing Application Engine process.

• Run the Variance Pricing process.

• View team rates.

Understanding Pricing Project Costs

This section discusses:

• The pricing process.

• Installation and business unit pricing options.

• Rate sets.

• Rate plans.

• Contract-specific and standard rates.

• Effective-dated rate definitions.

• Transactions eligible for pricing and repricing.

• Tiered pricing.

• Organizational sharing.

• Limits processing.

• Pricing transactions associated with work orders.

• Pricing projects from proposals.

The Pricing Process

The Pricing Application Engine process (PC_PRICING) calculates transaction costs, overhead, and revenue amounts from source rows, which are transactions that are brought into PeopleSoft Project Costing. Source rows can be directly entered into PeopleSoft Project Costing by using the Add Transactions component, or entered into a feeder system, such as PeopleSoft Expenses, and integrated into Project Costing.

Application Engine processes that bring cost transactions into PeopleSoft Project Costing automatically trigger the Pricing process. Adding transactions on the Add Transactions page also triggers the Pricing process. The process matches the costs with rate sets that specify what target rows to create in the Project Transaction table (PROJ_RESOURCE). Target rows are transactions that are created as a result of pricing the source transaction row. The process uses the rate plan to determine which rate sets to run and in what sequence to run them.

You can create revenue rows from cost transactions if you use the Government Contracting feature of PeopleSoft Contracts, and select a Contracts installation option to separate billing and revenue rows. This enables you to run the Pricing process independently for direct and indirect costs, billing, and revenue. If you do not select the PeopleSoft Contracts installation option to separate billing and revenue rows, then you cannot create a rate set to price for revenue nor can you price transaction rows for revenue.

If you use tiered pricing, the system generates billing rows based on the specified rate set or rate plan, and applies the tiered pricing adjustment percentage to the amount on the target row. If you use organizational sharing and define sharing options and rates, the Pricing process creates sharing rows based on the established rates and exceptions.

Transactions are eligible to price for billing when the project and activity are linked to a rate set or rate plan through PeopleSoft Contracts at the contract line level. For example, assume that a voucher is entered in PeopleSoft Payables for 100 USD. When the Payables to Project Costing Application Engine process (PC_AP_TO_PC) runs, it selects the cost row from the Payables Accounting Entries table (VCHR_ACCTG_LINE) and calls the Pricing process, which creates a billing row from the cost row. When the process completes, two rows appear in the Project Transaction table, a row with an analysis type of ACT (actual cost) and a row with an analysis type of BIL (billable amount), as shown in this table:

You can also use the Pricing process to cost project transactions that will not be billed. This is made possible by associating a rate set with an activity on the Activity Definitions - Rates page in PeopleSoft Project Costing. As project-related costs are incurred and sent to PeopleSoft Project Costing, the system can determine transaction costs that are associated with the activity based on the rates in the rate set or rate plan. Instead of linking the project and activity to a contract line and rate set in PeopleSoft Contracts for billing purposes, you can link the project and activity to a rate set in PeopleSoft Project Costing for costing purposes.

Additionally, you can use the Pricing process to price unpriced transaction rows or reprice transaction rows that are in the Project Transaction table. You cannot, however, reprice transactions that are in the process of being billed or sent to the general ledger (GL), or that were generated from the same source transaction as another billable row that is in the process of being billed or sent to GL.

Process Flow

The high-level steps that you follow to create cost, billing, and revenue rows by using the Pricing process are:

1. Determine the elements that contribute to pricing calculations based on your business processes.

   For example, do you use rates by employee, project role, or job code? Do you mark up source transaction amounts to create billing rows, or do you use fixed amounts? Do you associate rate sets with project types, projects, activities, or specific contract lines?

2. Set up installation and business unit options.

3. (Optional) Set up tiered pricing.

4. (Optional) Set up rules and exceptions for organizational sharing.

5. Create rate sets.

6. Create rate plans.

7. Associate projects and activities with rate sets or rate plans and contracts.

8. Price the transactions to create cost, billing, and revenue rows by using feeder systems to automatically trigger the Pricing process.

9. Review the transactions, make changes to rates, and manually run the Pricing process to reprice rows as necessary.

See Also

Tracking Activity Billing and Project Costing Rates

Integrating with PeopleSoft Contracts and PeopleSoft Billing

Defining Accounting Rules

Understanding Accounting Distributions

Installation and Business Unit Pricing Options

During installation, determine if you want to enable organizational sharing for rate-based contract lines. Other pricing options at the installation level are used when the Pricing process is triggered for the business unit by Application Engine processes from feeder systems, or through the Add Transactions functionality in PeopleSoft Project Costing. For example, because the rates that the Pricing process uses are effective-dated, you can specify the date type (transaction or accounting) that the system uses to determine the rate set or rate plan to use for pricing.

Options that you select at the business unit level are also used when the Pricing process is triggered for the business unit by Application Engine processes from feeder systems, or through the Add Transactions functionality in PeopleSoft Project Costing. Select pricing options of Cost, Billing, or both for the system to use to determine which rows to create. If the Separate Billing and Revenue option is enabled on the Installation Options - Contracts page, you can also select a pricing option of Revenue. By using pricing options, you can tell the system to create costs (indirect and direct), billing, and revenue recognition rows separately. The pricing options that you select for the business unit appear by default as the selected pricing options on the Pricing run control page. You can override the business unit default values when you initiate the Pricing process on the Pricing run control page.

Cost and Bill Rate Restrictions in Program Management

If you use PeopleSoft Program Management, at the business unit level you can restrict the rate types that users can select for cost and bill rates for activity resources. The rate types that you enable for the business unit control the rate options that you can select on the Rate Sets - Target page as follows:

• If you enable only the Rates by Employee rate type for the business unit, you cannot select the JBI (Job Code Bill Rate), JCO (Job Code Cost Rate), RBI (Role Bill Rate), or RCO (Role Cost Rate) rate options.

• If you enable only the Rates by Job Code rate type for the business unit, you cannot select the EBI (Employee Bill Rate), ECO (Employee Cost Rate), RBI, or RCO rate options.

• If you enable only the Rates by Role rate type for the business unit, you cannot select the EBI, ECO, JBI, or JCO rate options.

• If you enable only the Custom rate type for the business unit, you cannot select the EBI, ECO, JBI, JCO, RBI, or RCO rate options.

Rate Sets

A rate set enables you to create transaction rows when costing, billing, recognizing revenue, or reporting from incoming or existing transactions in the Project Transaction table. Rate sets have two parts:

• The source criteria that the Pricing process uses to compare against cost transactions coming in from feeder systems.

• The target definition of the cost, billing, or revenue recognition row that the Pricing process creates.

  When an incoming cost transaction matches the source criteria, the Pricing process creates a new transaction row for every target row that is defined on the rate set.

For example, you can use multiple criteria on the source page to create billing rows one way for rows with a source type of MATER (material) and another way for a source type of LABOR. The materials can be billed at cost, while the labor is marked up. The billing rows are defined by the target definition (bill MATER rows at cost, mark up LABOR rows using employee rates) and the project ChartFields.

A one-to-many relationship exists between source criteria and target row definitions. One source row, such as a cost transaction or a billing transaction, can create multiple target rows.

You can attach rate sets or rate plans to:

• Project types

  The system uses the rate set or rate plan that you specify for a project type as the default rate set or rate plan for new projects that you create for that type. You can override the default rate set or rate plan at the project level.

• Products

  If you associate a rate plan with a product, the system uses the product's rate plan for the contract line on the Contracts Related Projects page.

• Contract lines

  Rate sets and rate plans can be defined for general use or for a specific contract. Once defined, you can assign the rate set or rate plan to the rate-based contract using the Related Projects page.

• Projects

  The system uses the rate set or rate plan on the project as the default rate set or rate plan for new activities that you create for that project. You can override the default rate set or rate plan at the activity level.

• Activities

  The actual Pricing process occurs at the activity level. The association of a rate set or rate plan to an activity is effective-dated.

Rate Definition Types

You specify a rate definition type when you create a rate set. By using rate definition types, the Pricing process can create costs (indirect and direct), price transactions for billing, and price transactions for revenue recognition. Rate definition types control the type of rows that the Pricing process creates by restricting the analysis types that you can select for target rows on the rate set.

For example, when you create a rate set with a cost rate definition type, the system restricts the target rows to analysis types that belong to the actual cost analysis group. The default actual cost analysis group is PSCST (Accounting Costs), which is specified on the Installation Options - Project Costing page along with the actual revenue and billing analysis groups. During implementation you can override the default analysis groups for actual cost, revenue, and billing.

This table lists the rate definition types and analysis types that you can select for target rows:

Rate Set Category

Rate set categories are optional. Rate set categories are used to group related rate sets for the Variance Pricing process. If Rate Set Category is selected in the Rate Processing Option field on the Variance Pricing run control page, then all rate sets tat are part of that rate set category and have the Enable Variance check box selected are selected by the Variance Pricing process.

Rate Options

Rate options specify how the Pricing process calculates the rates for the corresponding target rows. For example, you can select a rate option of ECO (Employee Cost Rate) on a target row to use the cost rates that are defined for the employee on the Rates by Employee page. For the ECO rate option, the Pricing process calculates the target amount as the source row transaction quantity × the employee-specific cost rate × the rate set rate amount.

Each rate option is associated with a specific formula that the system uses to calculate the target amount. In the previous example, the source row transaction quantity is the quantity available in the Project Transaction table for the specific row that is being priced. The employee-specific cost rate is the rate that is defined for the employee on the Rates by Employee page. The rate amount on the target row functions as a multiplier for any rate option except the FIX (Fixed Amount) rate option. If you select the FIX rate option, the rate amount functions as the actual rate.

These factors affect the list of rate options that are available for selection:

• Some rate options are available only if you integrate with other PeopleSoft applications.

  For example, if you use PeopleSoft Maintenance Management, you can select the WBI (Work Order Labor Bill Rate) and WCO (Work Order Labor Cost Rate) rate options to use the work order labor bill and cost rates. If you use PeopleSoft Program Management, you can select the ABI (Activity Resource Bill Rate) and ACO (Activity Resource Cost Rate) rate options to use the activity resource labor rates that appear on the PeopleSoft Program Management Resources by Activity page. If you use PeopleSoft Proposal Management, you can select the AML (Mark Up/Down Labor) and AMN (Mark Up/Down Nonlabor) rate options to use the signed percentage amount in the Labor % and Non-Labor % fields on the Project Definitions - Rates page to determine the markup or markdown value.

• If you use PeopleSoft Program Management, the available rate options are also based on the rate types that you specify for the business unit during implementation.

  For example, if you restrict cost and bill rate types at the business unit level to only rates by employee, you cannot select the JBI, JCO, RBI, and RCO rate options.

A complete list of rate options that is available for selection on the Rate Sets - Target page is discussed in the business process section of this chapter.

See Defining Rate Set Categories, Rate Sets, and Rate Plans.

Rate Plans

A rate plan is a collection of rate sets that the system executes in a specified order. Use rate plans to link rate sets so that priced rows from one rate set are used to create additional priced rows from the next rate set. For example, you can add additional expenses, such as administrative costs or overhead, to cost transactions before they are priced for billing or revenue.

The Pricing process uses the rate plan to determine which rate sets to run and in what sequence to run them. When setting up the rate plan, you can assign rate sets in any combination of rate definition types: billing, costing, cost/billing, and revenue. You can assign the same rate set to multiple rate plans.

Rate plans are similar to rate sets in these ways:

• Both can be associated with project types, projects, activities, or contract lines.

• Both are effective-dated.

• If either a rate set or a rate plan is associated with a project type, it is used as the default rate set or plan for new projects that you create for that type.

• If either a rate set or a rate plan is associated with a project, it is used as the default rate set or plan for new activities that you create for that project.

This diagram shows the tables that the system uses to process rate plans:

Tables that the system uses to process rate plans

Source rows that enter PeopleSoft Project Costing from feeder systems are stored in a Project Transaction subrecord (PROJ_RES_TMP) and copied into the PRT_PRICE temporary table.

Basis

A basis is assigned to each rate set in a rate plan and tells the Pricing process what transactions to use to create the target rows for a rate set.

Basis options are:

• Original: The system uses the original source transactions to create target rows for the specified rate set.

• Target: The system uses the target rows that have been created on this rate plan thus far as the basis for creating the target rows for this rate set.

• All: The system uses all of the original sources and all of the previously created target rows on the rate plan to create the target rows for this rate set.

Sequence

When transactions come into PeopleSoft Project Costing from PeopleSoft feeder systems, the Pricing process uses the pricing options that you select for the business unit to tell the system what kind of rows to create from the source transactions. The pricing options correspond to the rate definition types (Billing, Cost, Cost/Billing, or Revenue) that are assigned to rate sets. You can process all rate sets on a rate plan even if the rate sets contain different rate definition types, or you can process a subset of rate sets on a rate plan. When the Pricing process runs for a rate plan, the rate sets are processed for the selected pricing options in the sequence that is defined on the rate plan.

For example, assume that you create a rate plan and attach rate sets to the plan in the order of COST1, BILL1, COST2, BILL2, and REV1. When you run the Pricing process for all three pricing options (Cost, Billing, and Revenue), the system first processes the COST1 rate set, followed by BILL1, COST2, BILL2, and REV1. Because of this processing logic, you should add rate sets to rate plans in the order in which you want them to run.

If you run the Pricing process by using the Pricing run control page, you specify the rate sets to process by selecting pricing options (Cost, Billing, and Revenue) on the run control page. The rate sets are processed in the order that is defined on the rate plan, based on the pricing options that you selected on the run control page.

Example of Using Rate Sets and Rate Plans to Price Transactions

This diagram shows an example of pricing inbound transactions from PeopleSoft Expenses to PeopleSoft Project Costing:

Pricing flow between PeopleSoft Expenses and PeopleSoft Project Costing

As an example of using rate sets on a rate plan to price incoming transactions from time reports in PeopleSoft Expenses, assume that you set up two rate sets. The first rate set has a cost rate definition type and uses incoming time report transactions (rows with a TLX analysis type) to create actual cost transactions (rows with an ACT analysis type) by using the ECO rate option. The ECO rate option multiplies the source row transaction quantity × the employee-specific cost rate × the target row rate amount.

The second rate set has a billing rate definition type and uses the same incoming time report transactions as source rows to create billing transactions (rows with a BIL analysis type) by using the EBI rate option. The EBI rate option multiplies the source row transaction quantity × the employee-specific bill rate × the target row rate amount.

Now set up a rate plan that contains both rate sets. Both rate sets use the original, incoming time report transactions as source rows. After the rate plan processes the rate sets, the Project Transaction table will contain cost transaction rows with an analysis type of ACT, and billing transaction rows with an analysis type of BIL. The transaction amounts on these rows are based on the rate option on the rate set that was current at the time that you ran the Pricing process.

Contract-Specific and Standard Rates

In PeopleSoft Project Costing, you can create rate sets and rate plans that are either contract-specific or standard (general). You can link contract lines to contract-specific or standard rate sets or rate plans. A contract-specific rate plan can contain both standard and contract-specific rate sets. A standard rate plan can contain standard rate sets only.

This table lists the valid combinations of standard and contract-specific rate sets and rate plans that you can attach to activities and contract lines:

You can link an activity that has a rate plan to a contract line. If the contract line is linked to a rate set or contract rates, the system processes the contract line rate set first, followed by the activity rate plan. Thus you can use the resulting target rows from the contract line rate set as source rows for the activity rate plan. Alternatively, you can process the contract line rate set independently of the activity rate plan.

Example of Using Contract-Specific Rate Sets and Activity-Specific Rate Plans

As an example of using a contract line-specific rate set and an activity rate plan, assume that you set up a contract line-specific rate set to create billing rows from time entries for an activity. You also set up an activity rate plan that contains a standard rate set to create indirect labor costs for the project.

The contract line-specific rate set is associated with the contract line on the Related Projects page in PeopleSoft Contracts. This rate set has a billing rate definition type and uses incoming time report transactions to create billing transactions (rows with a BIL analysis type). On the Rate Sets - Target page, the rate option is AMT and the rate set-specific rate amount is 150 USD. The activity is associated with the contract line on the Related Projects page in the PeopleSoft Contracts system. After you enter a time report transaction of 8 work hours for the activity, the Pricing process uses the rate option and rate amount specified on the contract-specific rate set to calculate the target billing transactions (rows with a BIL analysis type) from each incoming time report transaction.

This activity is also associated with a standard rate plan on the Activity Definitions - Rates page. The rate plan contains a standard rate set with a cost rate definition type and a basis of original, which means that the Pricing process uses only the original time entry rows that you import from PeopleSoft Expenses to calculate the target rows. The rate set uses a rate option of ECO, which is the cost rate that is associated with the employee (105 USD in this example), plus a 15 percent markup, to calculate actual overhead cost transactions (rows with an ACT analysis type) from each incoming time report transaction.

This table lists the resulting rows in the Project Transaction table for this example:

Effective-Dated Rate Definitions

You assign an effective date to each rate set and rate plan. This action enables you to not only maintain a set of current rate sets and rate plans, but also to set up rate sets and rate plans for anticipated future use, and adjust transactions by using past-dated rate sets and rate plans.

The Pricing process uses the following date criteria to determine which rows are eligible for pricing:

• The date type (transaction or accounting) that you specify during implementation.

• The effective date of the rate set or plan.

• The effective date of the association of the rate set or plan to the activity.

Date Type

You select the transaction or accounting date option in the Pricing/Funds Distribution group box on the Installation Options - Project Costing Integration page.

If you specify the accounting date type, the Pricing process determines the eligible rows by matching the accounting date for each transaction row to the effective date range of the rate set or plan. Alternatively, you can specify the transaction date type for the Pricing process to select rows with a transaction date that matches the effective date range of the rate set or plan.

Effective Date of the Rate Set or Plan

You can price transactions by using a rate set or plan that is no longer current if the rate set or plan is in an active status. In other words, a rate set or plan can contain more than one active, effective-dated row. You establish the effective date when you set up a rate set on the Rate Sets page or set up a rate plan on the Rate Plans page.

Effective Date of Association of the Rate Set or Plan to the Activity

The association of a rate set or rate plan to an activity is effective-dated. The system will not price a row if the row's specified date type (accounting or transaction) is earlier than the effective date of the association of the rate set or plan to the activity. You establish this effective date on the Activity Definitions - Rates page when you use the page to associate the rate set or plan to the activity.

Example of Using Effective-Dated Rate Sets

Assume that you set up a rate set with two active effective dated rows, as shown in this table:

The rate set has an effective date of January 1, 2004, and uses incoming time report transactions as source rows. The Pricing process multiplies the time report quantities by a target rate of 25.00 USD to create actual cost transactions from source rows that have an accounting date that occurs between January 1 and December 31, 2004. On January 1, 2005, the target rate increases to 50.00 USD.

Assume that you create the following two source transaction rows:

1. The first transaction has a transaction date, accounting date, and currency effective date of April 1, 2004. The transaction quantity is 8, which is measured in work hours (MHR).

2. The second transaction also has a quantity and unit of measure of 8 MHR. The transaction date, accounting date, and currency effective date are June 1, 2005.

Now you run the Pricing process, which uses a target rate of 25.00 USD to calculate the first target row based on the rate set with an effective date of January 1, 2004. The process uses the new target rate of 50.00 USD to calculate the second target row based on the rate set with an effective date of January 1, 2005.

This table lists the target rows that the Pricing process creates for the two source transaction rows:

Transactions Eligible for Pricing and Repricing

The Pricing process uses not only effective date of rate definitions, but also distribution statuses and system sources to identify transactions that are eligible for processing.

Distribution Statuses

These distribution status fields in the Project Transaction table support rate set and rate plan processing:

• Cost distribution status (CST_DISTRIB_STATUS): Indicates if a source row has been priced for costing.

• Billing distribution status (BI_DISTRIB_STATUS): Indicates if a source row has been priced for billing.

• Revenue distribution status (REV_DISTRIB_STATUS): Indicates if a source row has been priced for revenue recognition.

  The revenue distribution status applies only if you use the Government Contracting feature of PeopleSoft Contracts and select a Contracts installation option to separate billing and revenue rows.

• General ledger distribution status (GL_DISTRIB_STATUS): Indicates if a transaction row has been interfaced to the general ledger.

  Repricing cannot occur on a source row if any target transaction rows have been further processed downstream. If a source row results in multiple target rows, and any of the target rows have been sent to PeopleSoft Billing or PeopleSoft General Ledger, neither row can be repriced. For example, assume that a rate plan specifies that an incoming transaction from PeopleSoft Expenses (with a TLX analysis type) is the source row that will create two rows—a cost row (with a CST analysis type) and a bill row (with a BIL analysis type). If the BIL row has already been sent to PeopleSoft Billing, the system cannot reprice the TLX row, which means that the cost cannot be recalculated.

Transaction rows must have a distribution status of N (new or not distributed) to be included in the Pricing process. To process a transaction row for a cost rate definition type, the cost distribution status must be N for the row. To process a row for a billing rate definition type, the billing distribution status must be N. Similarly, to process a row for a revenue rate definition type, the revenue distribution status must be N.

The possible cost, billing, and revenue distribution status values are:

• C: Created (cost and revenue rows only).

• D: Distributed; done.

• G: Generated (cost and revenue rows only).

• I: Ignore; do not process.

• N: New; not distributed.

• P: Priced (billing rows only).

• U: Unbillable/nonbillable (billing rows only).

• W: Worksheet, billing calculations are in the Project Costing Billing Worksheet (billing rows only).

If you select the Separate Billing and Revenue option on the Installation Options - Contracts page, the billing distribution status indicates if a transaction row has been priced for billing, and the revenue distribution status indicates if the row has been priced for revenue. These statuses enable you to separately monitor pricing for billing and revenue.

Note. The Process Project Accounting Application Engine process (PSA_ACCTGGL) assigns the G status value to the GL Distribution Status field (GL_DISTRIB_STATUS) for rows that are associated with contracts revenue. The Contracts Load Update Application Engine process (CA_LOAD_UPD) updates the GL Distribution Status value to D for these rows in the Project Transaction table.

System Sources

The Pricing process uses these system sources, in combination with distribution statuses, to identify transactions that are eligible for processing:

• PRP: Indicates that a transaction is priced for billing.

• PRC: Indicates that a transaction is priced for costing.

• PRR: Indicates that a transaction is priced for revenue.

Repricing

Similar to the Pricing process, the Repricing process considers the pricing options that you select on the Pricing run control page.

You can reprice transactions that:

• Have not been billed or sent to GL.

  A source row is ineligible for repricing if any of its target transaction rows contain a billing distribution status of W or D, or a GL distribution status of D or G.

• Are not linked to an asset.

• Have not been sent to PeopleSoft Asset Management.

• Have not been used for fee calculations (billing and revenue fee worksheets) in PeopleSoft Contracts.

  This rule applies only to government contracts. A transaction with a Contract Fee Status (CA_FEE_STATUS) field value of Generated indicates that it has been used in a fee calculation.

• Are not created by the Variance Pricing Application Engine process (PC_VAR_PRICE).

  Repricing cannot occur on any transaction rows that are created as a result of the Variance Pricing process.

You can view the distribution statuses of the source transaction row on the Transaction Detail page.

See Also

Maintaining Transaction Information

Tiered Pricing

Tiered pricing enables you to adjust the rate that the system applies to cost transactions during the Pricing process based on quantities that accumulate against a contract line. This type of pricing applies to rate-based, contract line processing only.

Tiered pricing requires the use of transaction identifiers, which are similar in concept to using analysis groups. Transaction identifiers provide users with the flexibility to identify and group project ChartField values and eliminate the need to identify the ChartField values each time they define tiered pricing for a new contract line.

Note. To implement tiered pricing, you must install PeopleSoft Contracts. Contracts with a Government classification, or transaction from Variance Pricing, are not eligible for tiered pricing.

See Also

Pricing Contracts

Tiered Pricing

Organizational Sharing

Use organizational sharing to share costs and revenue between the organization that owns the transaction and the organization that owns the project or activity.

If sharing rules are defined and activated, the Pricing process calls the Sharing Application Engine process (PSA_SHARING) to search for rows that are designated for sharing. A row is eligible for the Sharing process if the organization that owns the project or activity differs from the organization that owns the transaction, an applicable sharing rule exists, and the row does not qualify as an exception to the sharing rules.

Note. Contracts with a Government classification are not eligible for organizational sharing.

Limits Processing

When the Pricing process runs as a standalone process, and if you use PeopleSoft Contracts, the Pricing process calls the Apply Limits Application Engine process (CA_LIMIT) for the contract line that is being priced. Use the Pricing run control page to run Pricing as a standalone process. The Pricing process passes run control parameters to the Apply Limits process to create over-the-limit rows for revenue transactions, billing transactions, or both. The revenue option is available only if you select a PeopleSoft Contracts installation option to separate billing and revenue rows.

When the Pricing process is automatically triggered by incoming transactions from feeder systems, the Pricing process also calls the Limits process. The Pricing process uses the selected pricing options (Revenue and Billing) on the Project Costing Options page for the business unit of each row, and it passes those parameters to the Limits process to determine the type of transactions to limit check: revenue, billing, or both.

You can also run the Apply Limits process in PeopleSoft Contracts independently of the Pricing process. Regardless of how the Apply Limits process is called, it evaluates transaction level limits first and then contract line level limits for all pending transactions for each contract line in its scope. Resulting over-the-limit transactions are excluded from revenue recognition and billing, and are not sent to PeopleSoft General Ledger or PeopleSoft Billing, respectively, except for over-the-limit transactions that are created from released retainage, which pass from the billing worksheet directly to the Project Transaction Temporary Billing table (PROJ_RES_TMP_BI) to be inserted into the Project Transaction table.

Because you apply limits at the contract line level, you cannot run the Apply Limits process for specific PeopleSoft Project Costing business units, projects, or activities.

The system limit checks these analysis types:

• BIL (Billable Amount)

• OLT (Over Limit)

• REV (Revenue)

• ROL (Revenue Over Limit)

The system uses these analysis groups to process limits:

• PSLMT (Limit Processing - Billing)

• PSROL (Limit Processing - Revenue)

See Also

Creating and Managing Limits

Creating and Managing Limits

Pricing Transactions Associated with Work Orders

PeopleSoft Project Costing tracks the cost of work that is performed against tasks on a work order if you use PeopleSoft Maintenance Management. Transaction costs flow from PeopleSoft Maintenance Management into various PeopleSoft applications such as PeopleSoft Time and Expense, Inventory, Payables, and Purchasing, and from these systems into PeopleSoft Project Costing. PeopleSoft Project Costing also tracks the cost of tools usage by retrieving the actual time that users record for tools on a work order task, and using the time as a basis to calculate the tools usage cost.

The Project Transaction table stores the work order business unit, work order ID, task ID, work order resource type, and work order resource line number for each transaction row for the work order task.

When you set up rate sets for use with work orders, select the WBI and WCO rate options on the Rate Sets - Target page for the Pricing process to use the work order labor bill and cost rates to calculate target rows. Select the TBI and TCO rate options for the Pricing process to use actual time recorded for tools usage in PeopleSoft Maintenance Management, and the tools cost and bill rates from the Technician Workbench - Tools Usage page to calculate target rows.

The high-level steps to set up work order pricing are:

• Create rate sets in PeopleSoft Project Costing.

• Specify default rate sets for the work order business unit.

• Use the default rate set on the work order or specify an alternate rate set.

  The system updates activities with new rate sets on the work order.

• Run the Pricing process for repricing if you change the default rate set on a work order.

See Also

Integrating with Maintenance Management

Setting Up Rules and Data Related to PeopleSoft Project Costing

Pricing Projects from Proposals

If you use PeopleSoft Proposal Management and PeopleSoft Program Management, Proposal Management uses the bill and cost role rates and hours that are captured in the proposal to populate the Resources page and Resources by Activity page in PeopleSoft Program Management. Unadjusted role rates are treated as Project Role rate types and have the rate that was in effect when the role was added to the proposal. Adjusted role rates are treated as Custom rate types.

Rate sets for labor from proposals can use rate options ABI and ACO for labor source transactions. These rate options tell the Pricing process to use the bill and cost rates on the Resources by Activity page in PeopleSoft Program Management to calculate billing and costing amounts for labor source transactions. Use the Resources by Activity page to modify role rates for projects from proposals.

The system obtains nonlabor pricing information from the rate set, and rate plans from the contract lines in PeopleSoft Contracts.

The Pricing process treats resource classes of Asset, Material, and Other as nonlabor resources. Rate sets for nonlabor from proposals use a rate option of NON (Bill at Cost). After the PM Generate process completes, the Pricing process and the Distribute Costs to Budgets Application Engine process (PGM_SPREAD) do not retrieve any information from the PM proposal.

Markups and Markdowns

On the Project Definitions - Rates page for projects that are created from proposals, you can enter a labor or nonlabor adjustment percentage that the system uses to determine a billing markup or markdown row amount. This field appears for projects that are created from proposals in PeopleSoft Proposal Management.

The labor adjustment percentage is used in conjunction with the AML rate option that you select on the Rate Sets - Target page. The AML rate option tells the system to use the signed percentage amount in the Labor % field on the Project Definitions - Rates page to determine the markup or markdown value. The AMN rate option tells the system to use the signed percentage amount in the Non-Labor % field on the Project Definitions - Rates page to determine the markup or markdown value. The Pricing process creates the target transaction values based on the signed percentage of the source transaction rows.

You can create markup and markdown target billing transactions from labor and nonlabor source transactions. You cannot create markup and markdown target costing transactions from labor and nonlabor source transactions.

Understanding Variance Pricing

This section discusses:

• Variance pricing.

• Variance rates.

• Variance pricing setup requirements.

• Variance pricing process flow.

• Variance pricing statuses.

• Example of using effective-dated rate set in variance pricing.

Variance Pricing

Variance pricing is used to capture and process price variances for a particular set of rates. Variance pricing, or retroactive rate adjustments, are required when contractors retroactively apply new rates to transactions that were previously processed. Transactions that have previously been processed are those that have been billed or sent to the general ledger.

You can apply variance pricing to all contract types and all rate set types. In addition, the Pricing summarization feature can be used, which reduces the number of transaction rows that are processed, in turn reducing the amount of time that it takes to run the Variance Pricing process. The Pricing summarization feature can also be used to reduce the number of transaction rows that result from the Variance Pricing process, which are ultimately posted to the Project Transaction table (PROJ_RESOURCE).

You can enable variance pricing on a standard or contract-specific rate set by selecting the Enable Variance check box. When using this option, you can enter, track, and process variance rates on the Rate Variance History page.

You cannon inactive variance pricing on a rate set if a variance rate exists on one or more target rows in an effective-dated rate set.

Through its integration with Project Costing, Contracts enables you to capture and process any rate changed for indirect costs that are associated with the contract. The rate changes generally impact a certain period of time within the contract. For a transaction to be eligible for variance pricing, at least one of its source or target rows must have been sent to the billing worksheet, passed to PeopleSoft Billing for invoicing, passed to PeopleSoft General Ledger for revenue recognition, sent to Asset Management for capitalization, or have been used for fee calculations.

When rate changes occur, the system verifies whether the transaction rows are eligible to be repriced. If they are, then those transaction rows are repriced by the Pricing engine and are ineligible for variance pricing.

New indirect costs are generated by the system for the difference in the old and new rates, and the new rates are used to calculate indirect costs against any current or future transactions going forward. When a rate change is made to an eligible rate set that is associated with a rate plan, after the new transaction row is created, the system prices the new row using any applicable remaining rate sets contained in the rate plan.

PeopleSoft Project Costing maintains a history of these rate changes for audit and reporting purposes.

Variance Rates

To enable the system to calculate a produce transaction rows for rate changes, you must complete the following tasks:

• Define a rate set with a rate definition type of Cost, Billing, or Cost/Billing.

  Your costing and cost/billing rate sets contain your provisional and forward pricing rates, and enable you to calculate indirect costs. Variance pricing is only applicable to active rates where associated transactions have been billed, recognized as revenue or used for fee calculations for cost-plus contracts lines. Any rate changes that occur are tracked and managed using the rate sets that you define for the contract.

  When rate changes are processed by the Variance Pricing process, the system generates transaction rows for the difference between the old indirect cost row and the new indirect cost row, prices the new row, and assigns a system source of PRV (variance pricing), and the analysis type that was defined for the original target costing row.

• Select an optional Rate Set Category that indicates that the rate set category can be selected on the Variance Pricing run control page.

• Associate the rate set or a rate plan that contains a cost, billing, or cost/billing rate set, to the contract lines.

• When a rate change has occurred, select the Enable Variance check box on the rate set and enter the new target rate amount using the history link.

Variance Pricing Setup Requirements

Before entering retroactive rate changes for your contract lines, you must first complete the following steps required by the variance pricing process:

1. Assign rate-based contract lines to the contract.

2. (Optional) Create a rate set category that is used during the Variance Pricing process.

3. Create a standard or contract-specific rate set or rate plan.

   Optionally assign a rate set category to the rate set.

   Assign the rate set or rate plan to the applicable contract lines.

   Enable Variance check box selected. To bill and recognize revenue for contract-related direct and indirect costs, you must create a billing (if not using the cost/billing) and revenue rate set (if you have selected the Separate Billing and Revenue check box on the Installation Options – Contracts page).

   Because you can assign only one rate set or rate plan to a rate-based contract line at one time, you will most likely combine your cost, billing, and revenue rate sets onto a rate plan in a manner that meets your pricing needs, and assign the rate plan to your rate-based contract lines.

   Note. Rate sets that are eligible for variance pricing cannot have the same field values for analysis type, source type, category, or subcategory for both the source and target definition criteria. At least one value must be different between the source and target row.

4. Assign active projects and activities to your rate-based contract lines.

   Transactions for rate-based contract lines are tracked using projects and activities associated with the contract line, and stored in the PROJ_RESOURCE table.

5. Set the contract to an active processing status and process transactions.

   Transactions that are eligible for variance pricing are project-related transactions associated with rate-based contract lines that are processed through Project Costing. To process transactions for contract and rate-based contract lines you must also define as-incurred billing and revenue plans and assign them to the applicable rate-based contract lines for billing and revenue processing for your transaction.

Variance Pricing Process Flow

After a contract has been activated and transactions have been processed, any rate changes that occur over the life of the contract can be applied using the Variance Pricing feature. This feature enables you to apply rate changes as needed by performing the steps described in this process flow diagram:

Variance Pricing process flow

These steps illustrate a high level example of using variance pricing to distribute transactions at a new rate that you previously distributed at a different rate:

1. Access the active rate set to enter the new rates for the target definition.

   Variance rates are generally applied retroactively, over a specified period of time. When accessing the rate set, you must use Correction mode to open the page for the appropriate effective date. To access the Rate Variance History page, navigate to the Target page and enter the new rates for the target definition. Variance rates are tracked and processed using the Rate Variance History page.

2. Define the variance pricing run control parameters.

   The Variance Pricing process selects the data to process based on the criteria that you specify on the Variance Pricing run control page such as business unit, project ID, activity, ID, accounting or transaction date range, contract information, rate set, rate plan, and rate category.

   The Variance Pricing process applies this logic:

   • Selects rate sets based on the parameters specified on the Variance Pricing run control page.

   • Selects active contracts and projects associated with the rate set specified on the Variance Pricing run control page.

   • Projects associated with the rate set must be active, and contracts associated with the rate set cannot have a closed processing status.

3. Perform variance pricing.

   The Variance Pricing process performs these steps:

   1. Selects the eligible transactions that match the effective date and source criteria for the rate set.

      Eligible transactions include transaction rows that are not eligible for repricing and have a general ledger distribution status (GL_DISTRIB_STATUS) of G (generated) or D (distributed), a billing distribution status (BI_DISTRIB_STATUS) of W (worksheet) or D (distributed), and do not have a system source of PRR (priced for revenue) or PRP (priced for billing). Transactions with an asset management distribution status (AM_DISTRIB_STATUS) of D (distributed) and transactions with a contracts fee status (CA_FEE_STATUS) of 1 (one), where the transaction has been used for billing or revenue fee calculations for cost-plus contract lines, are also eligible for variance pricing, whether or not the actual transaction has been billed or posted to the general ledger for revenue recognition.

   2. Calculates the difference between the old rate and the new rate using this equation:

      Variance Amount = (original source) x (new rate) – (original source) x (old rate). This amount may be positive or negative.

   3. Creates the new transaction rows for the difference and posts them to the Project Transaction table (PROJ_RESOURCE).

      The new transaction rows are assigned the analysis type assigned to the original target row, stamped with a system source of PRV (variance pricing), assigned a cost, revenue, and billing distribution status of N to enable cost stacking, billing, and revenue recognition to occur for the new transactions, and assigned a general ledger distribution status of C. The accounting date is specified on the run control page and the transaction date is stamped with the source transaction date.

4. After the variance pricing process is complete, the system posts the new transaction rows one of two locations:

   1. If the Requires Variance Approval check box is selected on the Variance Pricing run control page, then the new transaction rows are posted to a staging table (PC_VP_REVIEW). You must access the Variance Pricing Review page to approve or delete transaction rows prior to sending the approved rows to the Project Transaction table (PROJ_RESOURCE).

   2. If the Requires Variance Approval check box is not selected on the Variance Pricing run control page, then the new transaction rows are posted to the Project Transaction table (PROJ_RESOUCE).

5. (Optional) Applies standard pricing.

   Based on the run control parameters, the Variance Pricing process calls the Pricing engine (PC_PRICING) to apply the new rate to all transaction rows that have been priced, but have not been billed or booked to the general ledger, or that have not been priced. It also prices any transactions that have not been priced, but are eligible for pricing.

Note. When you run the variance pricing process, the system automatically excludes contracts with a processing status of Closed. Additionally, rows created as part of the variance pricing process are not eligible for repricing.

Variance Pricing Statuses

When entering variance pricing rate changes, each row is assigned a status. The statuses are set and controlled by the system and control the type of action or processing that can occur against the variance rate row. The rate target sequence statuses are:

• Pending: Appears by default when a new variance rate row is added.

  Only one pending rate row may be entered at a time for a target definition. When a variance pricing rate row is in pending status:

  • The rate field is editable.

  • The rate cannot be selected and used for pricing.

  • The rate displays only on the Rate Variance History page and does not appear on the Target page for the rate set.

• Active: After the new variance pricing rate is entered, and the Variance Pricing process is run for the rate set, the system updates the status of the new rate to Active.

  Only one active rate row may exist at a time for a target definition. When a variance pricing rate row is in active status:

  • The rate field is display only and cannot be edited.

  • The new rate is selected and used for pricing by the Variance Pricing and the Pricing processes.

  • The new rate is displayed on the Target page for the rate set and is associated with a sequence number.

• Inactive: After the new variance pricing rate is active, the previous rate row is set to an inactive status by the Variance Pricing process.

  Multiple inactive rate rows can exist for a target definition. When a variance pricing rate row is in an inactive status:

  • The rate field for the inactive row is display only and cannot be edited.

  • The old rate cannot be selected and used for pricing.

  • Inactive rates are displayed only on the Rate Variance History page.

Example of Using Effective-Dated Rate Sets in Variance Pricing

The Understanding Pricing Project Costs, Effective-Dated Rate Definitions section, provided an example of using effective-dated rate sets. The example used a rate set with two active effective-dated rows as shown in this table:

In the example, a source transaction row contained a quantity and unit of measure of 8 MHR, with a transaction date, accounting date, and currency effective date of June 1, 2005. The Pricing process created an actual transaction row in the amount of 400.00 USD by using the rate set named SET1 with an effective date of January 1, 2005, and multiplying 8 MHR by a target rate of 50.00 USD.

Now assume that on July 1, 2005 you want to retroactively apply a new rate of 100.00 USD to existing actual transaction rows that were created after January 1, 2005. The target rate that was previously applied to these actual transactions was 50.00 USD, thus the Variance Pricing process needs to apply the net difference of 50.00 USD. You enter the new rate in a pending status on the Rate Variance History page for the SET1 rate set. When you run the Variance Pricing process, the system inactivates the existing active rate and changes the new rate to an active status, as shown in this table:

To run Variance Pricing on the transaction row that was originally priced at a rate of 50.00 USD, select the SET1 rate set with an effective date of January 1, 2005 on the Variance Pricing run control page. The process creates a new row against the original transaction based on the net difference of 50.00 USD. In this example, you select an accounting date of July 1, 2005 on the run control page that the system applies to the new transaction row, as shown in this table:

The Variance Pricing process ignores transactions that have an accounting date (or specified date type) that are outside of the effective date range of the selected rate set.

Now assume that later you add a new SET1 rate set row with an effective date of July 1, 2006. You discover that you need to calculate pricing variances again on the output rows from the original transaction dated June 1, 2005. Because the system matches the specified date type of the priced costing row to the effective date range of the rate set to determine eligible transactions, you select the rate set effective date of January 1, 2005 for this Variance Pricing run control.

For additional information relating to government contracts and variance pricing, see PeopleSoft Contracts for Government Contracting 9.1 PeopleBook, "Performing Variance Pricing"

See Performing Variance Pricing.

Importing Transactions into PeopleSoft Project Costing

Various PeopleSoft Application Engine processes that are specific to feeder system applications send cost transactions to PeopleSoft Project Costing.

This section lists the pages used to bring cost transactions into PeopleSoft Project Costing.

Pages Used to Bring Process Cost Transactions into PeopleSoft Project Costing

Defining Rates for Employees, Job Codes, and Project Roles

To define rates for employees, job codes, and project roles, use these components:

• Rates by Employee (PC_RATE_EMPL).

• Rates by Job Code (PC_RATE_JOBC).

• Rates by Role (PC_RATE_ROLE).

Use the PC_RATE_EMPL_INTFC component interface to load data into the tables for the PC_RATE_EMPL component.

Use the PC_RATE_JOBC_INTFC component interface to load data into the tables for the PC_RATE_JOBC component.

This section discusses how to define rates by employees, job codes, and project roles.

Pages Used to Define Rates for Employees, Job Codes, and Project Roles

Defining Rates by Project Role

Access the Rates by Role page (Setup Financials/Supply Chain, Product Related, Project Costing, Pricing Structure, Rates by Role, Rates by Role).

Enter the necessary data to define cost and billing rates for a project role.

Regions

Assign one or more rates to a project role based on different regions by using the Regions grid. The Regions grid appears if you use PeopleSoft Program Management and PeopleSoft Resource Management. Use this feature if you want to price labor differently for roles that are performed on projects at different locations.

These two conditions must exist for you to price labor based on different locations:

• In the Bill and Cost tabs in the Resources page and Resources by Activity page in PeopleSoft Program Management, the rate type must be Project Role.

• On the Rate Sets - Target page for the rate set that is associated with the activity, the rate option must be ABI (Activity Resource Bill Rate) or ACO (Activity Resource Cost Rate).

If these conditions exist, the Pricing process creates target transaction rows by using the rate that corresponds to the resource's region in the Regions grid on the Rates by Role page.

If you select the RBI (Role Bill Rate) or RCO (Role Cost Rate) rate option on the Rate Sets - Target page, the Pricing process uses the default project role rate that is defined on the Rates by Role page. The process disregards regional rates when you use the RBI or RCO rate option.

You are not required to associate a region with a project role rate. If the role and region combination is not defined on the Rates by Role page, the system uses the default project role rate.

Defining Rate Set Categories, Rate Sets, and Rate Plans

To define rate set categories, rate sets, and rate plans, use these components:

• Rate Set Category (PC_RATE_CATEGORY)

• Rates Sets (PC_RATE).

• Rate Plans (PC_RATE_PLAN).

Use the PC_RATE_INTFC component interface to load data into the tables for the PC_RATE component.

This section discusses how to:

• Define rate set categories.

• Define standard or contract-specific source rows.

• Define rate set target rows.

• Define standard or contract-specific rate plans.

Pages Used to Define Rate Set Categories, Rate Sets, and Rate Plans

Defining Rate Set Categories

Access the Rate Set Category page (Set Up Financial/Supply Chain, Product Related, Project Costing, Pricing Structure, Rate Set Category).

The rate set category is used on the Variance Pricing run control page, where it can be selected in the Rate Processing Option field. If Rate Set Category is selected in the Rate Processing Option field, then all rate sets that are associated with the rate set category selected in the Rate Category field are selected when the Variance Pricing processes runs.

Defining Standard or Contract-Specific Source Rows

Access the Rate Sets page (Setup Financials/Supply Chain, Product Related, Project Costing, Pricing Structure, Rate Sets, Rate Sets).

Rate Set	Enter a rate set identifier. Rate set identifiers are used to run the Variance Pricing Application Engine process (PC_VAR_PRICE) and as selection criteria when setting up a rate plan. This field is required.
Copy from Rate Set	Click to access the Enter New Rate Set Keys page to enter the business unit and rate set ID of an existing rate set that you want to copy. Click OK on the Enter New Rate Set Keys page to return to the Rate Sets page with fields populated with data from the existing rate set. The Copy from Rate Set button appears only in add mode. Note. You can copy a standard rate set to another standard rate set. You cannot copy contract-specific rate sets.
Rate Definition Type	Select one of the options that determines the type of target rows that the Pricing process will create from this rate set: Billing: Creates billable rows that can be passed to PeopleSoft Billing for invoice generation. Cost: Creates target rows to track and calculate contract, project, and indirect costs. Cost/Billing: Creates cost and billing target rows. Revenue: Creates revenue recognition rows that can be passed to PeopleSoft General Ledger. This option is available if you select the Separate Billing and Revenue option on the Installation Options - Contracts page. Note. The rate definition type can be changed after saving the page. However, the target analysis types must adhere to the selected rate definition type.
Rate Set Category	Select a category to which this rate set belongs. If the Enable Variance check box is selected and the rate set category is selected on the Variance Pricing run control page, then the rate set is selected during the Variance Pricing process.
Enable Variance	Select to indicate that this rate set can contain variance rates. This option enables you to enter a rate variance on the Rate Variance History page for target rows for the rate set and indicate that this rate set is eligible for variance pricing. You can activate or inactivate this option until you enter a variance rate on the Rate Variance History page. You cannot deselect this check box if a variance rate exists on one or more target rows. This option is available for all rate definition types. Variance pricing is available for all contract classifications. For additional information about variance pricing, See Understanding Variance Pricing.

Defining Criteria for Incoming Transactions

To set up a rate set, you define criteria that the system uses to identify the source transactions from feeder systems that are priced using this rate set. At a minimum, you must select an analysis type. All other fields may be identified with a wildcard character (%) to select all transactions that are associated with the specified analysis type. Otherwise, populate the additional fields to identify specific transactions that you want the system to select and price using this rate set.

If you selected the Enable Variance option on the Rate Sets page, the source rows in the Define Criteria for Incoming Transactions grid must contain at least one different value for analysis type, source type, category, or subcategory than the target rows in the Define Target Rows grid. If this condition does not exist, when you click the History link on the Rate Sets - Target page to access the Rate Variance History page, a message will appear stating that the rate set definition is not eligible for variance pricing.

Defining Rate Set Target Rows

Access the Rate Sets - Target page (Setup Financials/Supply Chain, Product Related, Project Costing, Pricing Structure, Rate Sets, Target).

Note. The system supports the use of wildcards (the percent symbol) but does not support the use of partial wildcards (alphanumeric characters in combination with the percent symbol).

The ChartField values that you define for the source row on the Rate Sets page appears on the Rate Sets - Target page for reference.

You can associate each source row with multiple target rows.

Variance Pricing

For variance pricing, on the Rate Sets – Target page you define the target rates that the system uses to calculate indirect costs, and access the Rate Variance History page to enter new rates for the target rows. The rate that is the most current and active rate is used to price the target row. You maintain variance pricing rates on the Rate Variance History page.

The Sequence Number and History columns appear in the Define Target Rows grid when you activate the Enable Variance option on the Rate Sets page.

Defining Standard or Contract-Specific Rate Plans

Access the Rate Plans page (Setup Financials/Supply Chain, Product Related, Project Costing, Pricing Structure, Rate Plans, Rate Plans).

Rate Plan Type	Select the rate plan type for this rate plan. Available values are: Standard: Select to create a rate plan that is generally available for pricing any contract line associated with any contract type. Note. Selecting the standard rate plan type automatically populates the Rate Set Type field as Standard. You cannot overwrite this value. Contract: Select to create a rate plan that is used to price a particular contract line. By selecting the contract rate plan type, you can select standard or contract rate set types on the rate plan and create a rate plan that meets the specific need of your contract line by combining contract-specific and standard pricing rates.
Copy from Rate Plan	Click to access the Enter New Rate Plan Keys page, where you can copy an existing rate plan to create a new rate plan in the same business unit. Note. You can copy a standard rate plan to another standard rate plan. You cannot copy contract-specific rate plans. You can copy rate plans only from within the same business unit.
Rate Set Type	Displays the rate set type (Contract or Standard) from the rate set. For a contract rate plan, enter a rate set type of Contract or Standard for each rate set that you want to add to the rate plan. If you select Contract as the rate set type, you must select a rate set that is associated with the same contract line as the rate plan. For a standard rate plan, the system automatically populates the Rate Set Type field as Standard, and this value cannot be overridden. You can select only standard rate sets for a standard rate plan.
Rate Set	Select the rate set to include in your rate plan. You can select rate sets that are defined and active as of the effective date of the rate plan. Enter rate sets the in the order that you want the Pricing process to price the rows. Rate sets are processed in the order that you enter on this page, and only if they have a rate definition type that corresponds to the pricing options that you select on the Pricing run control page. A rate set can appear only once in a rate plan.
Basis	Select the basis that tells the Pricing process what source transactions to use to create the target rows for the rate set. Available options are: Original: The system uses the original source transactions to create target rows for the specified rate set. Target: The system uses the target rows that have been created on this rate plan thus far as the basis for creating the target rows for this rate set. All: The system uses all of the original source rows and all of the previously created target rows on the rate plan to create target rows for this rate set.
Rate Definition Type	Displays the rate definition type (Billing, Cost, Cost/Billing, or Revenue) from the rate set. The Pricing process can price transactions for costs, billing, revenue, or any combination based on the options that you select on the Pricing run control page.
Review Rate Set	Click the rate set description to access the Rate Sets page and view or modify the rate set.

Creating Price Variances

This section discusses how to:

• Enter price variances.

• Run the Variance Pricing process.

• Review results from the Variance Pricing process.

Pages Used to Create Price Variances

Entering Price Variances

Access the Rate Variance History page (Set Up Financials/Supply Chain, Product Related, Project Costing, Pricing Structure, Rate Sets, Target. Click the History link on the Rate Sets – Target page).

Running the Variance Pricing Process

Access the Variance Pricing page (Project Costing, Utilities, Variance Pricing).

Use this page to run the Variance Pricing process for:

• All rate sets that have Enable Variance selected on the Rate Sets page.

• Target variance rate amounts with a pending status.

• Contracts with an open or pending processing status.

• Contracts, projects, and activities that use the rate definition on this run control page.

Note. To avoid generating duplicate transactions when multiple users are processing Variance Pricing, it is recommended that users select the Requires Variance Approval check box. This allows an opportunity to review the Variance Pricing transactions before sending them to the Project Costing transaction table.

Note. To avoid overlapping processes from running at the same time, only one Variance Pricing process, using the same parameters in these fields, can run at the same time: Business Unit, Project, Activity, and Rate Processing Option.

The Variance Pricing process completes these steps:

1. Updates the target variance rate sequence row to active

2. Updates the rate amount and sequence number on the Rate Sets - Target page with the new active target variance row.

3. Prices rows eligible for Variance Pricing based on the new rate amount.

4. Creates new transaction rows with the system option selected in the Variance Pricing Option field.

5. (Optional) Reprices rows eligible for repricing based on the new rate amount and prices any new, unbilled, or unbooked transactions using the new rate.

Repricing cannot occur on any transaction rows that are created as a result of Variance Pricing.

Reviewing Results from the Variance Pricing Process

Access the Variance Pricing Review page (Project Costing, Utilities, Variance Pricing Review).

Transactions appear on this page if you selected the Requires Variance Approval check box on the Variance Pricing run control page. The transactions are stored in a staging table called PC_VP_REVIEW.

Use this page to approve or delete transaction rows prior to inserting them into the project transaction table (PROJ_RESOURCE).

Selection Parameters

In the Selection Parameters section, the link to the right of the field, such as Activity, Analysis Type, and so on, allow you to select multiple values. The maximum number of values that can be selected for a field is 20.

For Activity, Analysis Type, Source Type, Category, and Subcategory, a single value (selected directly from the Variance Pricing Review page) takes precedence if you also click the link and select multiple values from the Select page.

Variance Pricing Detail

Defining Tiered Pricing

This section discusses how to define transaction identifiers.

Pages Used to Define Tiered Pricing

Defining Transaction Identifiers

Access the Transaction Identifiers page (Set Up Financials/Supply Chain, Product Related, Project Costing, Transaction Options, Transaction Identifiers, Transaction Identifiers).

See Transaction Identifiers.

Running the Pricing Application Engine Process

This section discusses how to price transaction rows by manually initiating the Pricing process.

Page Used to Run the Pricing Application Engine Process

Pricing Transaction Rows

Access the Pricing page (Project Costing, Utilities, Pricing, Pricing).

Transaction Detail

Click to access the Transaction List page to view the transactions.

Application Options

When you use the Pricing page to price or reprice transactions for activities that are associated with fixed fee contract lines, do not enter any contract related information in the Application Options group box. Activities associated with fixed fee contract lines are treated as Project Costing related pricing; therefore, entering contract related information prevents the system from picking up fixed fee data for pricing.

Note. This run control page is used to process transactions from all contract classifications. If you want to initiate the Pricing process for a specific set of contracts, such as government contracts, you must enter search criteria such as project, activity, contract classification, and so on, to identify the transactions to include in this run control.

Viewing Team Rates

The Project Team and Activity Team Rate Sheets provide visibility to the standard rates that are associated with each team member. Project managers can select a view to display standard rates by employee, job code, or role.

Note. When the Pricing process prices cost transactions, the rate set dictates which, if any, of the standard rates are used and whether any markup or adjustment is applied to the standard rate.

This section discusses how to:

• View project team rates.

• View activity team rates.

Pages Used to View Team Rates

See Also

Understanding Pricing Project Costs

Viewing Project Team Rates

Access the Project Team Standard Rate Sheet page (click the Team Rates link on the Project Definitions - Team page).

Project team members appear on this page if you defined a project team role for the member.

See Also

Staffing Project and Activity Teams

Viewing Activity Team Rates

Access the Activity Team Standard Rate Sheet page (click the Activity Team Rates link on the Activity Definitions - Team page).

View Rates by	Select Employee, Job Code, or Role to view different activity team rates.
Cost Rate and Bill Rate	Displays the cost and bill rates associated with the activity team member and the option that you select in the View Rates by field. The system converts these rates as necessary to the currency of the business unit.

See Also

Scheduling and Managing Resources