Pricing Project Costs

This chapter provides overviews of the various pricing functions in Project Costing and discusses how to:

• Import transactions into Project Costing.

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

• Define rate sets and plans.

• Define tiered pricing.

• Run the Pricing Application Engine process.

• View team rates.

Understanding Pricing Project Costs

This section discusses:

• The pricing process.

• Transactions eligible for pricing.

• Installation and business unit pricing options.

• Tiered pricing.

• Organizational sharing.

• Rate sets.

• Rate plans.

• Example of using rate sets and rate plans to price transactions.

• Distribution statuses.

• Variance pricing.

• Limits processing.

• Pricing transactions associated with a work order.

• 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 Project Costing. Source rows can be directly entered into Project Costing by using the Add Transactions component, or entered into a feeder system, such as Expenses, and integrated into Project Costing.

Application Engine processes that bring cost transactions into 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. 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 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 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 Contracts at the contract line level. For example, assume that a voucher is entered in PeopleSoft Enterprise 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 Voucher Accounting Line table and calls the Pricing process, which creates a billing row from the cost row. When the process completes there are two rows 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 Project Costing. As project-related costs are incurred and sent to 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 Contracts for billing purposes, you can link the project and activity to a rate set in 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 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 Contracts and Billing

Defining Accounting Rules

Understanding Accounting Distributions

Transactions Eligible for Pricing

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.

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. This enables you to separately monitor pricing for billing and 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 Asset Management.

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

  This 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

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 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 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 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 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.

All rate options are available for selection when you set up revenue recognition target rows.

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 Contracts. Contracts with a Government classification are not eligible for tiered pricing.

See Also

Pricing Contracts

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.

Rate Sets

Rate sets enable you to create transaction rows for use in costing, billing, revenue recognition, 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 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.

There is a one-to-many relationship 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.

• 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 sets and rate plans are effective-dated, which enables you to maintain a set of current rate sets and rate plans, and set up rate sets and rate plans for anticipated future use. The effective date also enables you to adjust prior transactions, if necessary.

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 on the rate set for target rows. 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 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 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 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 Maintenance Management, you can select the WBI and WCO rate options to use the work order labor bill and cost rates. If you use Program Management, you can select the ABI and ACO rate options to use the activity resource labor rates that appear on the Program Management Resources by Activity page. If you use Proposal Management, you can select the AML and AMN 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 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 are available for selection on the Rate Sets - Target page is discussed in the business process section of this chapter.

See Defining Rate Sets and Plans.

Contract-Specific and Standard Rate Sets

In 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 defaulted from the project type or project 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.

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—cost, billing, and revenue. You can assign the same rate set to multiple rate plans.

Rate plans are similar to rate sets in these areas:

• 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 are 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 are 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 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 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—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 Expenses to Project Costing:

Pricing flow between Expenses and Project Costing

As an example of using rate sets on a rate plan to price incoming transactions from time reports in Expenses, assume that you set up two rate sets. Rate Set ABC 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.

Rate Set DEF 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 GHI that contains Rate Set ABC and Rate Set DEF. Both rate sets use the original, incoming time report transactions as source rows. After Rate Plan GHI 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.

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 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 Billing or General Ledger, neither row can be repriced. For example, assume that a rate plan specifies that an incoming transaction from 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 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 (not distributed or new) 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 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: Not distributed; new.

• 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).

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.

Variance Pricing

If you use the Government Contracting feature of Contracts, you can capture variance pricing for cost rate definition types. Variance pricing, or retroactive rate adjustments, are required when government contractors retroactively apply new rates to previously processed transactions. You can enable variance pricing on a standard or contract-specific rate set. By using this option you can enter, track, and process variance rates on the Rate Variance History page.

The Enable Variance option appears on the Rate Sets page if you select a cost rate definition type. To use variance pricing, you must associate the rate set with a contract that has a classification of government. You cannot inactivate variance pricing on a rate set if a variance rate exists on one or more target rows in an effective-dated rate set.

See Also

Performing Variance Pricing

Limits Processing

When the Pricing process runs as a standalone process, and if you use 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 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 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 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 General Ledger or 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 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)

The Variance Pricing Application Engine process (PC_VAR_PRICE) writes new rows to the Project Transaction table for the difference in the new and old rates. The Limits process treats these transactions as new rows.

See Also

Creating and Managing Limits

Creating and Managing Limits

Pricing Transactions Associated with a Work Order

Project Costing tracks the cost of work that is performed against tasks on a work order if you use Maintenance Management. Transaction costs flow from Maintenance Management into various PeopleSoft applications such as Time and Expense, Inventory, Payables, and Purchasing, and from these systems into Project Costing. 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 designate projects as work order managed, it tells the system that these projects are managed with work orders in Maintenance Management, instead of by a project manager in Project Costing. For work order-managed projects, the Pricing process retrieves cost and billing rates from the work order labor rate to calculate the resource amount.

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

• Create rate sets in 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.

When you set up rate sets for use with work orders, select the WBI and WCO rate options on the Rate Sets - Target page to use the work order labor bill and cost rates. Administrators use the Default Rate Set field in the Project Costing group box in the WO Business Unit - Integration Options page (BUS_UNIT_TBL_WM2) in Maintenance Management to specify the rate set that the system uses as a default for chargebacks for work order-managed projects. The default rate set on the work order business unit overrides the default project rate set or plan on the project.

Project Costing Application Engine processes that collect costs from feeder systems assign a value of H (on hold) to the GL distribution status field for transactions on open work order tasks. This prevents the Process Project Accounting process from processing transactions for open work order tasks. When a work order task closes, the system updates the value of the GL distribution field for the transactions to C (costed). The Process Project Accounting process uses the WBI and WCO rates from the Work Task Labor Schedules table (WM_WO_SCHED_LBR) to process the transactions on closed work order tasks that are associated with work order managed projects.

See Also

Integrating with Maintenance Management

Setting Up Rules and Data Related to Project Costing

Pricing Projects from Proposals

If you use Proposal Management and Program Management, Proposal Management uses the bill and cost role rates and hours that are captured in the proposal to populate the Resources page (PC_PRL) and Resources by Activity page (PC_ARL) in 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 (Activity Resource Bill Rate) and ACO (Activity Resource Cost Rate) 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 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 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 PGM_SPREAD process 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 Proposal Management.

The labor adjustment percentage is used in conjunction with the AML (Mark Up/Down Labor) 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 (Mark Up/Down Nonlabor) 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.

Importing Transactions into Project Costing

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

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

Pages Used to Bring Process Cost Transactions into 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.

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 Program Management and Resource Management. Use this feature if you need to cost or price labor differently for roles that are performed on projects at different locations.

In the Bill and Cost tabs in the Resources page and Resources by Activity page in Program Management, if the rate type is Project Role, the system uses the rate that corresponds to the value in the Region field on that page. 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 rate.

There is an exception to regions processing when you select a rate option of RBI (Role Bill Rate) or RCO (Role Cost Rate) on the Rate Sets - Target page. To calculate rates by using the role rate options of RBI or RCO, the Pricing process uses only the project role rates that are defined on the Rates by Role page. Regional rates are not considered when you use the RBI or RCO rate option.

Defining Rate Sets and Plans

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

• 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 standard or contract-specific source rows.

• Define rate set target rows.

• Define standard or contract-specific rate plans.

Pages Used to Define Rate Sets and Plans

Defining Standard or Contract-Specific Source Rows

Access the Rate Sets page.

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 is a required field.
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 following options that determines the type of target rows that the Pricing process will create from this rate set: Cost: Creates target rows to track and calculate contract, project, and indirect costs. Billing: Creates billable rows that can be passed to Billing for invoice generation. Revenue: Creates revenue recognition rows that can be passed to General Ledger. This option is available if you select the Separate Billing and Revenue option on the Installation Options - Contracts page. You cannot modify the rate definition type after you save the page. To modify a rate definition type on a rate set, create a new rate set and assign the appropriate rate definition type.
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 Sets - Target page. You cannot clear this check box if a variance rate exists on one or more target rows. This option appears only if you select a cost rate definition type for the rate set variance. You can use variance pricing only for contracts with a government classification. See Performing 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.

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.

Defining Standard or Contract-Specific Rate Plans

Access the Rate Plans page.

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 and cannot be overridden. 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 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 (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.

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.

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.

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 contracts-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 there is any markup or adjustment 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.

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.

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