Understanding Commitment Control in PeopleSoft Purchasing
In PeopleSoft Purchasing, commitment control enables you to track or control commitments, obligations, or expenditures. You can track for encumbrance accounting, as well as check validation against predefined, authorized budgets. Commitment control enables you to automate large portions of the accounting control process.
When you set up your budgets, you designate amounts for those budgets and associate them with the appropriate PeopleSoft General Ledger business unit. After budgets are established, you can track and control all transactions in the procurement life cycle against the overall budget.
From a budgetary perspective, the procurement life cycle includes pre-encumbrances, encumbrances, and expenditures, all of which are tracked against a designated budget. When you use commitment control, the system deducts each type of financial obligation from the budget and tracks it according to obligation type; this enables you to determine how many dollars you have committed in pre-encumbrances, encumbrances, and expenditures. You can liquidate your pre-encumbrance and encumbrance balances by amount or quantity. Depending on the liquidate method that you specify on a document, the budget processor uses that method scheme to calculate the remaining spending authority accordingly.
Here is a high-level overview of the procurement life cycle in commitment control:
When you generate a requisition, a pre-encumbrance is created in your budget records by the budget-checking process.
When a requisition is sourced to a purchase order, commitment control liquidates the pre-encumbrance from the requisition and establishes an encumbrance for the purchase order.
When the purchased goods or services are delivered and the purchase order references a voucher, commitment control liquidates the encumbrance and records an expenditure.
You can set up commitment control to act on transactions that exceed your budget limit. Transactions and future obligations that exceed the budget are exceptions. You can specify the degree of control and corrective action that you want to enable individual users to exercise over exceptions. Commitment control warns you of exceptions if transactions and future obligations exceed your budgeted amounts. You can set this feature to prevent transactions that exceed a designated budget or to warn you about transactions that exceed a budget, and therefore, require corrective action.
Here are some examples of corrective actions:
Increasing approved budgetary amounts.
Requesting competitive bids from alternate suppliers.
Denying requisitions or canceling purchase orders.
Overriding exceptions by authorized users.
Commitment control enables you to receive warnings about activities that may send your budgets over their approved amounts. For example, a transaction that exceeds the budget can trigger a workflow warning to personnel at a higher level, while still going through the system as if the necessary budget existed. The transaction can also be rejected and stopped without approval from a higher authority. In either scenario, you can define options in PeopleSoft General Ledger that provide you with control over how your system handles exceptions for individual budgets and business units.
Commitment control also enables you to determine a budget date default scheme to use when setting up your system for the first time. Use the Installations Options page to define your preferred budget date defaults. You can either automatically change the accounting date to the document's accounting date, or you can copy the budget date from the predecessor document.
You can view summarized budget checking information for affected transactions on the PeopleSoft Purchasing requisition and purchase order inquiry pages.
PeopleSoft Purchasing delivers seven source transaction types for use in PeopleSoft Purchasing. This table illustrates the delivered source transactions types along with their selection criteria (header record field name and field value) that the system uses for selecting source transactions for budget-checking.
Note: You can modify the selection criteria for these source transaction types but special care should be taken when performing the modifications. These modifications are best done by programmers with extensive experience in PeopleSoft application code.
Source Transaction Types
This table illustrates the delivered source transaction types for use with PeopleSoft Purchasing:
|
Source Transaction Type |
Selection Criteria (Field Name and Field Value Pertaining to Header Record) |
Interpretation of Selection Criteria |
|---|---|---|
|
REQ_PREENC (requisition pre-encumbrance) |
REQ_STATUS = A (approved) REQ_STATUS = C (closed) REQ_STATUS = X (canceled) REQ_STATUS = LA (line approved) HOLD_STATUS = N POST_DOC = Y |
Requisitions that meet this criteria will be budget checked: requisitions that are not on hold, requisitions with valid ChartField combinations, and those requisitions with a status of approved, closed, canceled, and line approved. Note: The line approved status is only applicable if you are using the PeopleSoft eProcurement application. If you do not require approval before budget checking, then you could modify the selection criteria and enter a REQ_STATUS = PA (pending approval), and perhaps O (open). |
|
REQ_PRECNP (requisition - non-prorated) |
REQ_STATUS = A (approved) REQ_STATUS = C (closed) REQ_STATUS = X (canceled) REQ_STATUS = LA (line approved) HOLD_STATUS = N POST_DOC = Y BUDGET_STATUS = V (valid) |
Non-prorated value adjustments (REQ_PRECNP) selection criteria should be the same as requisition pre-encumbrance (REQ_PREENC) selection criteria. If you modify the selection criteria for one source transaction type you should also modify the selection criteria for the other source transaction type. |
|
PO_POENC (purchase order - encumbrance) |
PO_STATUS = A (approved) PO_STATUS = C (closed) PO_STATUS = X (canceled) PO_STATUS = D (dispatched) PO_STATUS = PX (pending cancel) HOLD_STATUS = N POST_DOC = Y (ChartField combinations are valid) |
Purchase orders that meet this criteria will be budget checked: purchase orders that are not on hold, purchase orders with valid ChartField combinations, and those purchase orders with a status of approved, closed, canceled, dispatched, and pending cancel. If you do not require approval before budget checking, then you could modify the selection criteria and enter a PO_STATUS = PA (pending approval), and perhaps O (open). |
|
PO_POENCNP (purchase order encumbrance - non-prorate item) |
PO_STATUS = A (approved) PO_STATUS = C (closed) PO_STATUS = X (canceled) PO_STATUS = D (dispatched) PO_STATUS = PX (pending cancel) HOLD_STATUS = N POST_DOC = Y |
Non-prorated value adjustments (PO_POENCNP) selection criteria should be the same as purchase order encumbrance (PO_POENC) selection criteria. If you modify the selection criteria for one source transaction type you should also modify the selection criteria for the other source transaction type. |
Warning! You should not modify the selection criteria for these source transaction types:
PO_PROCARD (procurement card)
PO_RAENC (receipt accruals - encumbrance)
PO_RAEXP (receipt accruals - expense)
The Commitment Control Budget Processor Application Engine process (FS_BP) enables you to budget check your transactions independent of the online budget checking feature or the batch transaction creation processes. You can select process parameters that capture exactly the group of transactions that you want for budget checking. You access this process from the menu for requisitions, purchase orders, and procurement cards.
The Commitment Control Budget Processor process operates the same whether it is initiated in batch mode using the Process Scheduler or when it is initiated from the purchase order and online entry pages. The batch mode affects a group of transactions whereas the online entry pages affect one transaction. The process compares the total amounts on each transaction (distribution) line to the available amounts in the referenced budget. If any line has an amount that exceeds the available budget, allowing for acceptable tolerances, that line fails budget checking and the system generates an exception message.
After you run the process, the transaction statuses and exception messages are on a batch log, which you can view by clicking the Message Log link on the Process Details page.
All lines on a transaction must pass budget checking for the transaction to receive a Valid budget status. Transactions with an Error budget status have one or more budget exceptions, which is a transaction or a transaction line that has failed budget checking. Transactions in Error status must be corrected.
The budget processor records liquidations in the commitment control ledger (LEDGER_KK) as taking place in the fiscal year and accounting period in which the liquidation takes place. For example, when a voucher liquidates a purchase order, the liquidation is recorded using the fiscal year and accounting period of the voucher.
Note: Commitment control is not automatically invoked for requisitions and purchase orders built from batch processes. These transactions must be approved and budget checked using separate processes. If you are using commitment control, a requisition cannot qualify for online sourcing until it has been budget checked and has a Valid budget status.
Open period for receipt accrual transactions is the allowable open date range for accounting entry creation and for budget checking transactions if you are using commitment control. If the accounting date falls within the open period date range, the system posts the accounting entry to the actuals ledger. If the transaction budget date falls before or after the open period date range, the system provides an error or warning message to prevent or warn you from running budget checking.
Open period for requisition or purchase order transactions is the allowable open date range for budget checking transactions when you are using commitment control. If the transaction accounting date falls before or after the open period date range, the system provides an error or warning message to prevent or warn you from running budget checking.
When running budget checking, the system translates the accounting date to a fiscal year and accounting period in the budget ledger.
If you are using commitment control, the system sets open period checking to issue errors as a default. You can activate or override open period checking for PeopleSoft Purchasing on the Purchasing Options page. You enter the open period date range according to general ledger business unit on the Update Open Period page.
The system validates the open period for requisitions, purchase orders, procurement cards, requisition and Buyer's Workbench (for cancel and close), batch reconciliation processes, and receipt accrual transactions.
Liquidate method is a document schedule control option that instructs the Commitment Control Budget Processor process how to accurately calculate and relieve outstanding pre-encumbrance and encumbrance balances from the budget ledger. You can selectively determine how to liquidate an encumbrance or pre-encumbrance at the document schedule level. To enable this functionality, configure your system to liquidate by quantity. Otherwise, all transactions liquidate by amount. Use the Purchasing Definitions - Business Unit Options page to determine whether a purchase order business unit liquidates by quantity and determine the default liquidate method. You can then modify the liquidate method on the requisition or purchase order, and change it to the desired liquidation method. If you choose to distribute by amount, you can not liquidate by quantity.
When liquidating your balances by quantity, the budget processor must adhere to the following rules:
Calculate the unit price by using the amount of the preceding document.
Calculate the liquidate amount by using the predecessors unit price and multiplying it by the standard quantity of the current document.
Use the newly derived amount to relieve the pre-encumbrance and encumbrance of the preceding document.
For information on document tolerances see the discussion on the topic.
When running a budget check only (budget pre-check), the budget processor performs the budget checking and edits that it normally does when a budget or transaction is posted, but it does so without committing changes (postings) to the general ledger records such as the Ledger_KK record. The check only feature is specifically intended to check one document, but does not update the Commitment Control tables (ledger and activity log).
To enable budget pre-checking for Purchasing, select Then, select the Purchasing check box in the Enable Budget Pre-check section. You must also ensure that if the Purchasing check box is selected in the Enable Commitment Control section on the Installation Options - Products page
The Budget Pre-Check button is available for use on these PeopleSoft Purchasing pages:
Requisition
Requester's Workbench
Purchase Order
Express Purchase Order
Buyer's Workbench
When you perform budget pre-check only processing, the statuses of Provisionally Valid or Error on the transaction pages indicate whether a budget is available. If you click the Budget Pre-Check button and if the budget check is valid, then the system sets the budget header status for the requisition to Prov Valid. If the budget check is not valid, then the system sets the budget header status to Error with a link to the Exception page.
When using commitment control with PeopleSoft Purchasing, you track all requisition, purchase order and non-prorated purchase order transactions, procurement cards, and receipt accrual transactions that you submit, even if they cause you to go over budget. If you have a transaction that causes you to go over budget, you can adjust either your transaction or your budget to handle the exception.
Inevitably, some transactions do not pass the budget-checking process and the system identifies them as exceptions. Some of the circumstances that generate errors include:
Insufficient funds for a particular transaction.
Inconsistent ChartField combinations.
Transaction has an offset account.
Budget date for a transaction is out of bounds.
Depending on the configuration of your control budgets, the exact reason that a budget has insufficient funds varies from budget to budget. The budget may be on hold, closed, or simply out of funds. Additionally, you may have set up some budgets to approve transactions even if they go over budget amounts. Because of this, exceptions fall into two categories: warnings and errors.
Error Correction
You can correct errors for transactions by taking one or more of the following actions:
Change the amount on the transaction lines to conform to budget limits.
Change the budget amounts to enable more transactions to pass budget check.
Override the budget for a particular transaction.
Override the entire transaction for all affected budgets.
Only a user with proper authorities can perform this type of correction.
Transactions fail budget checking if they have at least one line that fails budget checking for at least one budget. These transactions are candidates for overrides on either a budget basis or a transaction basis. You are notified of exceptions in two ways: online and through workflow notification.
In an online situation, you receive a message regarding a transaction status when the budget-checking process is complete. The message indicates the type of exception the transaction created and enables you to access the Transaction Exception page, where you can either view the warnings generated or override the errors.
In a batch budget-checking situation, users are notified of exceptions through workflow, based on their individual security profiles in the system. The system generates an appropriate worklist for each user. Your users have access to a list of budgets that caused exceptions or a list of transactions with exceptions. These two options are available through the PeopleSoft menus or through the worklist.
There are a few different methods to access and override exceptions. You can:
Choose a particular budget from a worklist and access the Budget Exceptions page to view a list of all transactions that have failed for that budget.
Choose a particular transaction on a worklist and access the Transaction Exception page to view a list of all budgets that have caused exceptions on that transaction.
Click the Budget Status link on the document that has an error. When you click this link you access the Transaction Exceptions page.
On a document with errors, the budget status field will become a link.
The worklist contains a complete list of exceptions, stating the exact cause of the error or warning. These methods enable you to inquire about exceptions and to set overrides. Once the transaction is overridden, the system sends a warning notification.
Various override attributes can affect a budget-checked transaction:
Only authorized users can perform transaction and budget overrides.
Multiple super users can override different budgets for the same transaction.
A super user need only override a budget for a particular transaction once, unless that transaction changes after the override.
A user can perform an online remote call to the Commitment Control Budget Processor process.
This process budget checks the transactions that the user selected. Transaction lines with overridden budgets receive a warning for every budget that was exceeded. The system refreshes the budget and transaction exception pages to reflect these changes.
The actual process of overriding a budget just requires selecting a check box on the appropriate page. A super user can access either the Budget Exceptions page or the Transaction Exception page to override specific budgets or transactions.
Altering a transaction that has been through budget checking results in the deletion of all existing exception rows for the transaction. The Commitment Control Budget Processor process deletes the exception rows when the altered transaction is budget checked again. This includes the deletion of override marks for any budgets that appear on the altered transactions. A message to this effect appears when the budget is identified for override and you save the page.
Altering a transaction after it has been budget checked forces the Commitment Control Budget Processor process to treat the transaction as if it were new when budget checking is performed again. All previous exceptions are deleted, and any new ones are recorded as the transaction moves through the Commitment Control Budget Processor process.
Similarly, altering budgets can affect active transactions. The Commitment Control Budget Processor process reacts to the most current budget data. Consequently, if you alter your budgets and run a budget check, errors on active transactions can change.
Note: If your transaction fails the Commitment Control Budget Processor process, you must override the budget information using the Budget Exceptions page. Otherwise budget changes can be made by increasing the budget by editing the budget entry.
To make changes to transactions that have been budget checked:
Open the source transactions and make the changes to specific transactions.
Save your changes.
Run the Commitment Control Budget Processor process again to check the budget.
The Commitment Control Budget Processor process removes the original commitment control journal and creates a new one with the changed transactions.
This table lists examples of transaction changes and their resulting effects:
|
Transaction Change |
Effect |
|---|---|
|
Change requisition quantities and requisition item prices. |
Changes final pre-encumbrance amount generated during budget checking. |
|
Change purchase order quantities and item prices. |
Changes final encumbrance amounts generated during budget checking. |
|
Modify ChartFields. |
Sets the budget status to Not Checked. Requires another run of the budget processor. |
|
Cancel, delete, or insert a requisition line. |
Sets budget-header status to Not Checked. Requires another run of the budget processor to release the pre-encumbrance. |
This table lists examples of budget changes and their resulting effects:
|
Budget Change |
Effect |
|---|---|
|
Change arrangement of budgets. Move a detail budget under a new summary budget. Technically, you would be changing the tree or the node level within the same tree that the system uses to translate the relationship between a detail budget and a summary budget. You may be moving a node to a new tree. |
If this change results in a transaction that is no longer controlled by the original budget, you must change all relevant transactions to reference the budget in its new location or to reference a new detail budget. |
|
Increase or decrease budget amounts. |
Generates different exceptions for all affected transactions. Increasing your budget decreases exceptions and decreases your budget increases exceptions. |
|
Adjust tolerances for a particular budget. |
Increasing tolerances generally enables more transactions to pass budget checking within tolerance. Decreasing tolerances generally enables fewer transactions to pass. Although this alteration does not change the total number of exceptions, it does change the proportion of errors and warnings generated for a particular transaction or budget. You receive more warnings and fewer errors. |
|
Alter the status of a budget. |
There are three possible statuses for budgets: Open, Hold, and Closed. If you change the status of a budget, that action affects all referencing transactions captured in the next budget check. |
If you have commitment control enabled, the Close Requisitions (PO_REQRCON) and Close Purchase Orders (PO_PORECON) Application Engine processes consider this functionality.
After you have selected your process parameters and run a close process, the process verifies whether you have enabled commitment control. If it is enabled, the process updates the budget distribution lines and the budget header on all requisitions (for PO_REQRCON) or purchase orders (for PO_PORECON) that meet the close criteria. The status on the distribution line and the header changes from V (valid) to N (not checked).
The close processes set the budget status to Not Checked and the fully liquidated flag to Yes. Run the budget processor to relieve the remaining encumbrance.
For example, you have a purchase order for 100.00 USD, but after discounts, the supplier only invoices you for 98.00 USD. Before running the Close Purchase Orders process, the remaining 2.00 USD still exists as an encumbrance. When you close the purchase order, you must liquidate the remaining encumbrance for 2.00 USD. For this reason, the Close Purchase Orders process set the budget status to Not Checked and fully liquidated flag to Yes. You then run the budget processor to relieve the remaining encumbrance. The running of the budget processor is not an automated step in the close processes.
The commitment control process creates separate closing entries in the PeopleSoft Commitment Control activity log for purchase orders and requisitions. The activity log retains and displays the complete budgetary life cycle of purchase orders and requisitions.
This process is used to budget check the expense and encumbrance reclassification transactions. You can budget check either type.