Understanding the Pricing Process
This topic 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 Application Engine process (PC_PRICING) calculates transaction costs, overhead, and billing amounts from source rows, which are transactions that are brought into PeopleSoft Project Costing. On some projects, billing transactions will also be used for revenue. However, you can create revenue rows separate from billing rows using rate sets with a rate definition type of revenue. This enables you to run the Pricing process independently for direct and indirect costs, billing, and revenue. 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.
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 and revenue 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:
|
Description |
Source |
Analysis Type |
Amount |
|---|---|---|---|
|
Materials |
Payables |
ACT |
100 USD |
|
Markup 25 percent |
Pricing process |
BIL |
125 USD |
In this example, analysis type BIL is used for both billing and revenue. If billing and revenue were separated on the related contract, then an additional row with analysis type REV would be created using the markup defined for revenue rather than the markup used for billing.
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.
Creating Cost, Billing, and Revenue Transactions Using the Pricing Process
The high-level steps that you follow to create cost, billing, and revenue transactions by using the Pricing process are:
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?
Set up installation and business unit options.
(Optional) Set up tiered pricing.
(Optional) Set up rules and exceptions for organizational sharing.
(Optional) Define and populate custom rates.
Create rate sets.
Create rate plans.
Associate projects and activities with rate sets or rate plans and contracts.
Price the transactions to create cost, billing, and revenue rows by using feeder systems to automatically trigger the Pricing process.
Review the transactions, make changes to rates, and manually run the Pricing process to reprice rows as necessary.
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, andRevenue for the system to use to determine which rows to create. 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), RCO (Role Cost Rate), CRB (Custom Bill Rate). or CRC (Custom 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, RCO, CRB, or CRC rate options.
If you enable only the Rates by Role rate type for the business unit, you cannot select the EBI, ECO, JBI, JCO, CRB, or CRC rate options.
If you enable only the Override rate type for the business unit, you cannot select the EBI, ECO, JBI, JCO, RBI, RCO, CRB, or CRC 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.
Rates for revenue may be entered into the rate set as a percentage of one of the options listed above or directly into the rate setup amount field.
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. Additionally, revenue can be recognized using different markups than those used for billing.
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 Definition Type |
Target Row Analysis Types |
|---|---|
|
Billing |
For target rows, you can select analysis types that belong to the PSWKS (Billing Worksheet Grouping) analysis group. |
|
Cost |
For target rows, you can select analysis types that belong to the analysis group that is specified in the Actual Cost field on the Installation Options - Project Costing page. The default analysis group is PSCST (Accounting Costs). Note: You can enable variance pricing on rate sets with a cost or cost/billing rate definition type. |
|
Cost/Billing |
For target rows, you can select analysis types that belong to either:
Note: You can enable variance pricing on rate sets with a cost or cost/billing rate definition type. |
|
Revenue |
For target rows, you can select analysis types that belong to the PSRV2 analysis group. |
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 are available for selection on the Rate Sets - Target Page.
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:
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:
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.
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:
|
Attach at the Activity Level |
Attach at the Contract Line Level |
|---|---|
|
Standard rate set |
If you attach a standard rate plan to an activity, you cannot attach this activity to a contract line. |
|
Standard rate plan |
Contract-specific rate set. |
|
Nothing |
Standard rate set. |
|
Nothing |
Standard rate plan. |
|
Nothing |
Contract-specific rate set. |
|
Nothing |
Contract-specific rate plan. |
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:
|
Description |
Source |
Quantity |
Analysis Type |
Rate Amount |
Transaction Amount |
|---|---|---|---|---|---|
|
Original transaction. |
Time report transaction |
8 work hours |
TLX |
Not applicable |
Not applicable |
|
Target billing row based on the contract line rate set. |
Pricing process |
8 work hours |
BIL |
150 USD |
1,200 USD (calculated as 8 hours × 150 USD) |
|
Target cost row based on the activity rate plan. |
Pricing process |
8 work hours |
ACT |
1.15 |
966 USD (calculated as 8 work hours × 1.15 rate amount × 105 USD employee cost rate) |
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:
|
Effective Date |
Source Analysis Type |
Target Rate Option |
Target Rate Amount |
Target Analysis Type |
|---|---|---|---|---|
|
January 1, 2004 |
TLX (incoming time report) |
AMT (quantity × target rate) |
25.00 USD |
ACT (actual cost transaction) |
|
January 1, 2005 |
TLX |
AMT |
50.00 USD |
ACT |
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:
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).
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:
|
Accounting Date |
Project |
Activity |
Quantity |
Rate Amount |
Analysis Type |
Transaction Amount |
|---|---|---|---|---|---|---|
|
April 1, 2004 |
PROJ1 |
ACT1 |
8 MHR |
|
TLX |
|
|
April 1, 2004 |
PROJ1 |
ACT1 |
8 MHR |
25.00 USD |
ACT |
200.00 USD |
|
June 1, 2005 |
PROJ1 |
ACT1 |
8 MHR |
|
TLX |
|
|
June 1, 2005 |
PROJ1 |
ACT1 |
8 MHR |
50.00 USD |
ACT |
400.00 USD |
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.
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).
For projects assigned to contracts that separate billing and revenue, 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.
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 and transactions created from Variance Pricing are not eligible for tiered pricing.
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.
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.
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)
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.
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 Override 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 Proposal Management Generate process completes, the Pricing process and the Distribute Costs to Budgets Application Engine process (PGM_SPREAD) do not retrieve any information from the proposal Management 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.