Understanding Limits

For as-incurred and value-based billing methods on rate-based contract lines, PeopleSoft Contracts enable you to set a maximum amount that can be billed and recognized for revenue. This is referred to as a billing limit and revenue limit. You establish a line limit for billing and revenue on the Billing Allocation and Revenue Allocation pages respectively.

Line limit amounts are visible on the contract summary and online, and can also be viewed and managed using the Limits Review online inquiry page. Any changes made to the limits over the life of the contract must be performed at the contract line level.

Transaction limits enable you to apply limits to one or more subsets of transactions for a specific contract line. Transaction limits are only visible and must be managed at the contract line level.

Transaction limits consist of the following main elements:

• Transaction identifiers.

• Transaction limit amounts and sequence numbers.

Transaction Identifiers

Transaction identifiers are configurable and allow you to identify a subset of transactions by applying specific criteria to one or more PeopleSoft Project Costing ChartField values (source type, category, and subcategory).

You associate the transaction identifier with a contract line and then establish the limit for that transaction identifier on the line. Multiple contract lines can use the same transaction identifier, but the limit is always specific to the contract line. Transaction Limits are applied when the PeopleSoft Project Costing ChartField values on the billing or revenue transaction match the criteria defined for the transaction identifier. Billing and revenue transactions must first pass the transaction limit before they can be checked against the contract line billing and revenue limits. Transactions not meeting the criteria for a transaction identifier are included in the contract line billing and revenue limits only. These amounts are entered on the Billing and Revenue Allocation pages.

Warning! After a transaction identifier is defined and associated with a transaction limit, it should not be modified, because data conflicts may occur for any transactions already processed using the transaction identifier.

Transaction Limit Amounts and Sequence Numbers

After you have defined transaction identifiers, you assign them to the contract line. A contract line can have multiple transaction limits, each with its own transaction identifier and limit enabling you to limit revenue and billing on multiple subsets of transactions. For more complex limit processing scenarios, you can create multiple transaction limits based on the types of transactions associated with the contract line and you can set up your transaction limits to overlap one another.

When assigning multiple transaction limits to one contract line, the system uses sequence numbers to determine the order in which a limit amount is applied to a transaction. These sequence numbers are defined by you and must be unique to the contract line. In the event that you set up overlapping limits, the system uses the sequence numbers to identify which transaction limit should be processed first.

Limits processing always consider transaction level limits first, and then billing and revenue limits defined at the contract line level, when determining whether a transaction can pass limit checking. Only transactions that pass transaction limits, or transactions for which transaction limits are not applicable, are checked against overall billing and revenue limits. Depending on your limit setup, when a transaction is processed, a portion of the transaction could be determined to be over-the-limit for the transaction level limit, even though it might have been within the available overall funded and revenue limit amount.

Note: When assigning multiple transaction limits to a contract line, sequencing defines the order in which limits are applied to transactions. Because the over-the-limit transactions generated can vary depending on the order of the transaction limits, you need to carefully consider your setup and any potentially negative results from overlapping limits.

The Limits (CA_LIMIT) Application Engine process applies transaction level and overall line level limits to your rate-based contract lines. The Limits process can be run using the following options:

• Manually run the Limits process, or schedule it to run automatically, as a standalone process.

  When you run the Limits process as a standalone process, you can select specific run control criteria to apply limits for specific business units, contracts, or other criteria.

• Manually run the Limits process for a specific contract line.

  When you are managing limits for a specific contract line, you can manually run the limit process by clicking the Perform Limit Checking button on the Amount Allocation pages for Billing and Revenue or from the Transaction Limits pages when limits have been changed in amendment mode and the amendment has been processed.

• Automatically run the Limits process when performing pricing or repricing.

  When the Pricing (PC_PRICING) process is run using the Pricing run control page, the Limits (CA_LIMITS) process also runs.

• Automatically run the Limits process when processing transactions from feeder systems.

  Cost transactions for your contract lines will generally originate from within other PeopleSoft applications, such as PeopleSoft Expenses or PeopleSoft Payables. When transactions are sent from these feeder systems to PeopleSoft Project Costing, the Pricing (PC_PRICING) engine is automatically run, which also runs the Limits (CA_LIMITS) process.

• Automatically run the Limits process when processing billing.

  When the Contracts Billing Interface (CA_BI_INTFC) process is run, the Limits (CA_LIMITS) process also runs.

No matter the location from where the Limits (CA_LIMITS) process is run, once initiated, the system evaluates any transaction-level limits first, then line-level limits, using the criteria that you have defined for limit processing.

If a contract does not Separate As Incurred Billing and Revenue then the Limits process will Limit check as follows:

Limit processing examines each PROJ_RESOURCE row that represents a contract line for which you have specified billing limits. If the amount on the row falls below the limit less the amount previously billed or set to be billed in this process, the row is marked BIL. If the amount on the row exceeds the limit less the amount previously billed or set to be billed, the row is marked OLT (over-the-limit).

The OLT transaction rows will not be billed nor recognized as revenue. The over-the-limit rows are excluded from billing and revenue processing until you release the OLT transaction or increase the limit and rerun the Limits process. Once you release the OLT transaction on the Limit Details page, the system converts the OLT row back to a BIL so it can be sent to billing and booked to revenue the next time that the billing and revenue processes are run.

If a discount is specified for a rate-based contract line, the amount on the BIL resource row is decreased by the discount amount prior to comparing it against the limit. In addition, you can choose to retain a portion of the billable amount as a retainage. If so, the amount on the BIL resource row is decreased by an estimate of the retainage amount prior to comparing it against the limit, if the Reduce by retainage first option in the Limit Processing Management Options group box on the Installation Options - Contracts page is selected.

For rate-based lines, when the row is billed and fed back to PeopleSoft Project Costing, the analysis type is updated from OLT to BLD.

If additional funding is received later in the contract life cycle, you can use amendment processing to increase the limit amount and process the appropriate over-the-limit rows through to PeopleSoft Billing and PeopleSoft General Ledger.

If Separate As Incurred Billing and Revenue is selected for a contract then the Limits process will Limit check as follows:

If the contract separates as incurred billing and revenue then based on your Rate Plan/Rate Set the Pricing process will generate Revenue (REV) rows. In this scenario, REV rows identify revenue to be integrated to general ledger. In contrast, if the contract does not separate as incurred billing and revenue, then BIL rows will be used for both billing and for revenue integration to General Ledger.

The Limits process will limit check Revenue (REV) rows if Process Revenue check box is checked on the Standalone Limits process Run Control Page or Process Revenue is checked on the Project Costing Business Unit option.

Limit processing examines each PROJ_RESOURCE row that represents a contract line for which you have specified revenue limits. If the amount on the row falls below the limit less the amount previously recognized or set to be recognized as revenue in this process, the row is marked REV. If the amount on the row exceeds the limit less the amount previously recognized or set to be recognized for revenue, the row is marked ROL (Revenue over-the-limit).

The ROL transaction rows will not be recognized as revenue. The Revenue over-the-limit rows are excluded from revenue processing by the Contracts revenue process (PSA_ACCTGGL) until you release the ROL transaction or increase the revenue limit and rerun the Limits process. Once you release the ROL transaction on the Limit Details page, the system converts the ROL row back to a REV so that it can be used by the revenue process to book revenue the next time the revenue process runs.

Splitting Over-the-Limit Rows

You have the option to split OLT/ROL transactions so that the portion under the limit amount can continue with billing and revenue processing. The option to split transactions is configurable on the Installation Options - Contracts page by selecting the Split to Match Limit Exactly option. When this option is selected, the system splits a BIL row into one BIL row and one OLT row. Similarly, the system splits a revenue row (REV) into one REV and one ROL row. This enables you to reach the exact limit amount with the BIL/REV rows, and the system places the remaining transaction amount onto an OLT/ROL row.

Note: With retainages, the Contracts Billing Interface optionally checks for limits when retainages are released, depending on the value of the Apply retainage upon release Contracts Installation option. If the row is over-the-limit, it is returned to PeopleSoft Project Costing as OLT rather than RRT. With the Split to Match Limit Exactly option selected, the RRT is split into an RRT and an OLT, if there is some available limit left, but not enough for the release to fully pass limit checking.

When splitting OLT/ROL rows, the system prorates the quantity across the two new transactions. For example, if a 100.00 USD BIL/REV, with a quantity of 10.00, was split into a 60.00 USD BIL/REV and a 40.00 USD OLT/ROL, the BIL/REV receives a quantity of 6.00 and the OLT/ROL receives a quantity of 4.00. The quantity is rounded to two decimal places.

The system handles OLT/ROL rows differently depending on whether revenue and billing processing has occurred:

• When no billing or revenue processing has occurred, both parts of a split transaction are eligible for repricing.

  If the transaction is no longer over the limit, the split rows are deleted and replaced with a single BIL/REV row.

• When billing and revenue processing has occurred (processed by either the Contracts Billing Interface or the Contracts Revenue process) for the BIL/REV half of a split transaction, the system cannot reprice the corresponding OLT/ROL row.

  However, that OLT/ROL row is still eligible for consideration against the limit. If the limit amount is increased or other activity occurs that makes a remaining limit amount available, and the OLT/ROL becomes under limit, the system converts it to a BIL/REV row.

The Limits process (CA_LIMITS) processes transactions based on the RESOURCE_ID_FROM and RESOURCE_ID field values. The values for these fields are created in the Project Costing Transaction table, PROJ_RESOURCE and are inserted into temporary tables for processing by the Limits process. During limit checking, transactions having numeric values in the RESOURCE_ID_FROM and RESOURCE_ID fields are processed before transactions with concatenated values. Concatenated values originate from sub-systems other than Project Costing and are stored in the PROJ_RESOURCE table. The system applies limit checking to transactions that have a numeric value prior to applying limit checking to transactions that have a concatenated value, as it processes the transactions first by RESOURCE_ID_FROM field and then RESOURCE_ID field. This occurs irrespective of the order in which the transactions are added from feeder systems such as General Ledger or transactions added from non feeder systems such as Project Costing.

For example, this table shows transactions in the Project Resource table that is from feeder and non-feeder applications for a contract with a limit amount of 2000$. The Order column shows the order in which the Limits process applies limit checking:

This table shows additional data being inserted into the Project Resource table. The Order column shows the order in which the Limits process applies limit checking.

In this example, when new transactions with numeric resource ID values are inserted into the Project Resource table, they are processed prior to the transactions with concatenated resource ID values. As a result, transactions having numeric resource ID values get limit checked first irrespective of their limit or the transaction being marked as OLT (over-the-limit) once the limit checking is complete.

If Separate As Incurred Billing and Revenue is selected for the contract then similar processing happens for REV/ROL rows.

Limit Processing Using Processing Order Template

A Processing Order Template can be defined and used during the Limits process. A Processing Order Template enables you to define a processing order and priority of processing for each transaction, matching specific criterion. You can select one or more fields from the given drop-down list as a criterion for sorting the transactions. This list is a subset of fields available in PROJ_RESOURCE table. The selected fields can be specified as an ascending or descending ordered field when transactions are being processed for limit checking. Also within each field you can specify additional conditions (sub-order) for prioritizing the processing of transactions based on matching criteria of the field values.

For example, consider TRANSACTION_DATE, RESOURCE_AMOUNT, TRANS_CODE, and TRANS_TYPE fields to be used as criteria for limit checking. A new Processing Order Template can be created as follows:

Field	Sort Order	Order	Sub-Order	Value to Match
RESOURCE_AMOUNT	Descending	1	-	-
TRANS_DT	Ascending	2	-	-
PROJ_TRANS_CODE	Ascending	3	-	-
PROJ_TRANS_TYPE	Ascending	4	1	C%
PROJ_TRANS_TYPE	Ascending	4	2	A%

In this example, the Resource Amount field takes precedence over the other fields because it is listed first. Similarly Transaction Date field takes precedence over Transaction Code and Transaction Type fields. For Transaction Type field, values beginning with “C” take precedence over field values beginning with “A”.

In case if RESOURCE_ID field is not selected in the processing order template, the system by default will use RESOURCE_ID as the last ordering field. This is done to ensure that the uniqueness and consistency in processing, when the fields are selected or process order specified does not result in unique values. For example, in the above illustration the final processing order that the system will use would be:

1. RESOURCE_AMOUNT

2. TRANS_DT

3. PROJ_TRANS_CODE

4. PROJ_TRANS_TYPE having values starting with C

5. PROJ_TRANS_TYPE having values starting with A

6. PROJ_TRANS_TYPE having values other than #4 and #5

7. RESOURCE_ID

The resulting process ordering from #1 to #6 may not result in unique rows. As a result the transactions falling out of this order list may get processed inconsistently. Hence by default the system would use RESOURCE_ID as the last ordering field.

If you select RESOURCE_ID as one of the columns in the processing order template then the system will not append RESOURCE_ID field at the end of processing order list.

When using processing order templates, the transactions are processed based on the processing order defined by the templates and not on predefined values of RESOURCE_ID_FROM and RESOURCE_ID.

Note: Processing Order Templates are optional. If Processing Order Template is not used then by default transactions are processed based on RESOURCE_ID_FROM and RESOURCE_ID field values.