Transaction Limits

The funded and revenue limit amounts defined for a government contract line represent the maximum amounts that can be billed and recognized as revenue for that line. In addition, limits can be defined for a subset of transactions on the contract line such as travel, labor, or materials. PeopleSoft Contracts enables you to set up transaction-level limits, in addition to overall funded and revenue limits. Transaction limits enable you to apply limit amounts to one or multiple subsets of transactions on a contract line.

Transaction limits consist of the following main elements:

  • Transaction identifiers.

  • Transaction limit amounts and sequence numbers.

Transaction Identifiers

Transaction identifiers can be configured 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 funded and revenue limit. Transactions not meeting the criteria for a transaction identifier are included in the contract line funded 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 considers transaction level limits first, and then funded 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 funded 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.

Transaction Limit Processing Examples

Transaction limits enable you to define a limit on one or more subsets of transactions on single rate-based contract line. The following example describes the steps and processing for a multilimit overlapping scenario using a transaction limit for overall travel and a second transaction limit on air travel.

Note:

This example assumes that the Split to Match Limit Exactly check box is selected and the Separate As Incurred Billing and Revenue check box is deselected (so that no revenue limits exist) on the Contract.

Similar processing will happen for revenue (REV) rows if Separate As Incurred Billing and revenue check box is selected on the Contract.

  1. Define transaction identifiers to include limits for airfare and travel:

    Transaction Identifier Source Type Category Subcategory

    AIRFARE

    TRAVL

    AIR

    %

    TRAVEL

    TRAVL

    %

    %

  2. Define two transaction limits for the rate-based contract line:

    Transaction Identifier Description Limit Amount Use Sequence

    AIRFARE

    AIRFARE

    10,000 USD

    1

    TRAVEL

    TRAVEL

    15,000 USD

    2

  3. An expense transaction for airfare is submitted against the contract line, and contains the following details:

    Source Type Category Amount

    TRAVL

    AIR

    16,000 USD

  4. When the transaction is priced, the Limits process (CA_LIMIT) is called.

    The Limits process applies the transaction to the first transaction limit amount with Use Sequence number 1, splits the transaction into two, one for 10,000 USD that passes the first limit and a second for 6,000 USD that is over the limit, and passes the over-the-limit transaction to PeopleSoft Project Costing:

    Transaction Identifier Analysis Type Source Type Category Quantity Unit of Measure Source Amount Source Currency

    AIRFARE

    OLT

    TRAVL

    AIR

    1

    EA

    6,000

    USD

  5. The system applies the passed transaction to the second transaction limit amount with Use Sequence number 2, and passes the following results to PeopleSoft Project Costing:

    Transaction Identifier Analysis Type Source Type Category Quantity Unit of Measure Source Amount Source Currency

    AIRFARE

    BIL

    TRAVL

    AIR

    1

    EA

    10,000

    USD

  6. The billable (BIL) row is passed to PeopleSoft Billing, and the over-the-limit (OLT) row remains in PeopleSoft Project Costing for reporting and analysis.

    If the Airfare travel limit amount is subsequently increased, the OLT transaction row can be reprocessed and a BIL row is created for it if the limit is sufficient to pass the transaction.

Because the system processes transaction limits in the order specified by the Use Sequence, the system produces different results if the Use Sequence of the transaction limits were reversed. In this example, if the Travel transaction limit is set to the first Use Sequence, and the Airfare transaction limit is set to the second Use Sequence, then when the 16,000 USD airfare expense is processed, the system produces the following results:

Transaction Identifier Analysis Type Source Type Category Quantity Unit of Measure Source Amount Source Currency

TRAVEL

OLT

TRAVL

  

1

EA

1,000

USD

AIRFARE

OLT

TRAVL

AIR

1

EA

5,000

USD

AIRFARE

BIL

TRAVL

AIR

1

EA

10,000

USD

Because the Travel limit is specified as the first limit, the system applies the 16,000 USD transaction to that limit, which results in the system creating a 15,000 USD BIL row and a 1,000 USD OLT row for the transaction identifier of Travel. Then, the system applies the 15,000 USD BIL transaction that passed the first limit to the Airfare limit, resulting in another OLT row for 5,000 USD for the transaction identifier of Airfare, and a final 10,000 USD billable row.

The system applies the transaction to both the Travel and Airfare limits because the transaction contains the PeopleSoft Project Costing ChartField values that match the limit definitions.