Limit Processing

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.

Note:

If you rerun the Limits process prior to billing the released OLT row (now BIL row), the row reverts back to an OLT row because the system limit checks it again and the row is still over the limit.

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.

Note:

In the case of contract lines that are associated with value-based billing plans, billed amounts are initiated from the billing plan and not the transaction.

Note:

If the Separate As Incurred Billing and Revenue check box is not selected at contract header level then Limits process should ensure that all the revenue processing details on Limits related records are in-sync with the billing related details.

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.

Note:

If you rerun the Limits process prior to recognizing revenue, the released ROL row (now REV row) reverts back to ROL row because the system limit checks it again and the row is still over the limit.

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

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.