Using Commitment Control

This chapter provides an overview of commitment control in PeopleSoft Purchasing and discusses how to:

• Use partial and final liquidations.

• Budget check requisitions.

• Budget check purchase orders.

• Budget check procurement cards.

• Run budget period-end processes.

• Roll over purchase orders at budget period-end.

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. Once your 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:

1. When you generate a requisition, a pre-encumbrance is created in your budget records by the budget-checking process.

2. 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.

3. 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.

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.

See Also

Understanding PeopleSoft Commitment Control

Setting Up Basic Commitment Control Options

Setting Installation Options for PeopleSoft Applications

Comm. Cntrl. Budget Processor Process in PeopleSoft Purchasing

The Comm. Cntrl. Budget Processor (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 Comm. Cntrl. Budget Processor process operates exactly like the budget-check remote call options available on the purchase order and requisition online entry pages, except that it affects a group of transactions rather than one. 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.

See Also

Budget Exceptions

Using Purchase Order Sourcing

Understanding the Budget Checking of Source Transactions

Setting Up Basic Commitment Control Options

Open Period

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 before or after 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 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.

When running budget checking, the system uses the accounting date to determine whether the transaction is in the correct fiscal year and accounting period. The system uses the budget date within the distribution line to check whether the transaction is in the correct budget period.

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 Processing 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 purchase order reconciliation workbench (for cancel and close), and receipt accrual transactions.

See Also

Defining and Updating Open Periods and Adjustment Periods

Liquidation Method

Liquidate method is a document schedule control option that instructs the Comm. Cntrl. 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.

See Also

Setting Installation Options for PeopleSoft Applications

Defining PeopleSoft Purchasing Business Units and Processing Options

Document Tolerances

For information on document tolerances see the discussion on the topic.

See Running Document Tolerances.

Budget Exceptions

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 two different ways that you can 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. Alternatively, you can 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. The worklist contains a complete list of exceptions, stating the exact cause of the error or warning. These two pages enable you to inquire about exceptions and to set overrides. Once the transaction is overridden, the system sends a warning notification.

See Also

Using Workflow

Setting Up and Running Exception Notification

Understanding Viewing and Handling of Budget Transaction Exceptions

Viewing and Handling Budget Transaction Exceptions

Budget Overrides

Various override attributes can affect a budget-checked transaction:

• Only super users (users attached to a super user security role) 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 Comm. Cntrl. 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.

See Also

Viewing and Handling Budget Transaction Exceptions

Setting Up Commitment Control Security

Effects of Changes to Budget-Checked Transactions

Altering a transaction that has been through budget checking results in the deletion of all existing exception rows for the transaction. The Comm. Cntrl. 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 Comm. Cntrl. 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 Comm. Cntrl. Budget Processor process.

Similarly, altering budgets can affect active transactions. The Comm. Cntrl. 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 Comm. Cntrl. 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:

1. Open the source transactions and make the changes to specific transactions.

2. Save your changes.

3. Run the Comm. Cntrl. Budget Processor process again to check the budget.

   The Comm. Cntrl. 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:

This table lists examples of budget changes and their resulting effects:

See Also

Viewing and Handling Budget Transaction Exceptions

Commitment Control and PeopleSoft Purchasing Close Processes

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 vendor 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.

See Also

Closing Requisitions

Reconciling Purchase Orders

Budget Checking Receipt Accruals

This process is used to budget check the expense and encumbrance reclassification transactions. You can budget check either type.

See Also

Performing Budget-Checking for Receipt Accruals

Common Elements Used in This Chapter

See Also

Comm. Cntrl. Budget Processor Process in PeopleSoft Purchasing

Understanding PeopleSoft ChartFields

Setting Up Application-Specific Installation Options

Viewing Budget Details and Transaction Activity

Viewing and Handling Budget Transaction Exceptions

Processing Source Transactions Against Control Budgets

Using Partial and Final Liquidation

If you are using commitment control, you can specify partial or final liquidation of a requisition when it is sourced to a purchase order. When you create or modify a purchase order, you can designate that the purchase order is final, prompting the system to liquidate the preceding requisition. You can make your purchase order the final document to be affected by the preceding requisition, for less money than you originally authorized. You can also reverse the finalization of the document.

In PeopleSoft Purchasing, you can perform partial or final liquidations where the successor transaction references and liquidates its predecessor, including:

• Requisition to purchase order.

• Purchase order to payment voucher.

The system fully liquidates document lines automatically upon completion of the subsequent transaction when you designate the transaction as final. The system then creates the appropriate accounting entries to relieve outstanding pre-encumbrances and encumbrances, performing the reversing entry according to the document type and entry event of the referenced transaction.

Using partial and final liquidation, you can:

• Liquidate requisition or purchase order lines and relieve the outstanding pre-encumbrance and encumbrance from the budget ledger.

• Create the appropriate accounting transactions in the budget to relieve outstanding pre-encumbrances and encumbrances as applicable.

• Perform the correct accounting and available (open) amount calculations for modifications and cancellations of predecessor or successor transactions.

• Process final liquidations at the schedule line level of transactions, that is, orders can have some lines open while others are closed.

  The corresponding voucher lines that reference (liquidate) the lines determine this.

At times, multiple transactions reference the same predecessor. If two payment vouchers for two invoices of 500.00 USD each are associated to the same 1000.00 USD purchase order, only the second payment voucher is considered final. The first 500.00 USD payment voucher is considered partial, because an additional 500.00 USD encumbrance remains outstanding. If the first 500.00 USD actually represents the last expected action against the order, you can designate the voucher as final for less and relieve the entire 1000.00 USD encumbrance.

Partial and Final Liquidation Example

For example, suppose that you create a requisition for 200.00 USD and run budget checking. The system shows an increase of 200.00 USD to the existing pre-encumbrance amount of 40.00 USD.

Then create a purchase order that references this requisition for 165.00 USD. When you run budget checking, the pre-encumbrance decreases and the encumbrance increases by 165.00 USD.

Create another purchase order that references this requisition for 25.00 USD, finalize the purchase order and run budget checking. The total for all purchase orders is 190.00 USD, but the pre-encumbrance is liquidated with the full requisition amount of 200.00 USD. The pre-encumbrance decreases and the encumbrance increases by 25.00 USD.

To liquidate a requisition for an amount lower than the original:

1. Reduce the quantity or price total on the purchase order to the correct amount

2. Click the Finalize Document button for the affected line or lines.

3. Save the purchase order.

4. After approving the revised purchase order, run budget checking to confirm the correction.

Reversing Partial or Final Liquidation

You can also reverse finalization of a purchase order or voucher. The system then restores the original budgetary amount to the preceding documents that had previously been liquidated. If you do not declare a document final (for less), no additional liquidation takes place. The system replicates the partial or final status of a document down to all the document distribution lines associated with the given document schedule, adjusting all ledgers accordingly.

For example, you can process a requisition for 1000.00 USD, then create a purchase order for only 700.00 USD, without expecting to spend the remaining 300.00 USD that the requisition authorizes. You can declare the purchase order final (for less), thereby liquidating the pre-encumbered 300.00 USD from the requisition and freeing that money for other purposes. If you find later that you need to spend another 250.00 USD from the original requisition, you can restore your requisition by changing the purchase order's liquidation status to Partial. Then you can declare the purchase order final (for less) again, thus liquidating the requisition and freeing the last 50.00 USD for other purposes.

To reverse a reduction:

1. Clear the final check box for the affected line or lines, or click the Undo Finalize Entire Document button.

2. Save the purchase order.

3. Run budget checking to confirm the correct amount.

Budget Checking After Partial or Final Liquidation

You must budget check each purchase order after you declare it either final (for less) or partial. During budget checking, the system treats a finalized purchase order as a direct encumbrance, still subject to pre-encumbrance tolerance checking.

Note. If two or more purchase orders are linked to one requisition, none of those purchase orders can be finalized until all of those purchase orders have passed budget checking.

Note. You cannot change a purchase order's liquidation status while its budget-checking status is in Error or once the distribution has been canceled.

Note. You can only indicate that a purchase order is partial after it has successfully completed budget checking.

Running Entry Events After Partial or Final Liquidation

If you're using entry events, you must run them after budget checking. This generates your pro forma accounting entries, adjusted for finalization or partialization.

See Also

Understanding Commitment Control in PeopleSoft Purchasing

Using Entry Events

Budget Checking Requisitions

This section discusses how to:

• Budget check requisitions using the Comm. Cntrl. Budget Processor process.

• Budget check requisitions using online pages.

Pages Used to Budget Check Requisitions

Budget Checking Requisitions Using the Comm. Cntrl. Budget Processor Process

Access the Req Budget Check page.

To budget check requisitions, select REQ_PREENC in the Trans Type field.

Process Options

Budget Checking Requisitions Using Online Pages

When you create online requisitions, you can budget check them in realtime by clicking the Budget Check button on the Maintain Requisitions - Requisition page. This invokes the Comm. Cntrl. Budget Processor process by remote call.

See Also

Comm. Cntrl. Budget Processor Process in PeopleSoft Purchasing

Creating Requisition Header Information

Budget Checking Purchase Orders

This section discusses how to:

• Budget check purchase orders using the Comm. Cntrl. Budget Processor process.

• Budget check purchase orders using online pages.

Pages Used to Budget Check Purchase Orders

Budget Checking Purchase Orders Using the Comm. Cntrl. Budget Processor Process

Access the Budget Check Request page.

To budget check prorated purchase orders, select PO_POENC in the Trans Type field.

To budget check non-prorated purchase orders, select PO_POENCNP in the Trans Type field.

Process Options

Budget Checking Purchase Orders Using Online Pages

When you create online purchase orders, you can budget check them in realtime by clicking the Budget Check button on the Maintain Purchase Order - Purchase Order page. This invokes the Comm. Cntrl. Budget Processor process by remote call.

See Also

Comm. Cntrl. Budget Processor Process in PeopleSoft Purchasing

Creating Purchase Order Headers

Budget Checking Procurement Cards

You can now perform budget check and ChartField edit validations for your procurement card transactions during the Statement Load process and online processing. Use the budget processor to invoke budget check and ChartField edits after staged data is loaded into the Statement Load process and when users use the Reconcile Statement component.

You can use the budget check or the ChartField Edit validation process during:

• The Statement Load process

  If you enable commitment control for procurement cards, the system validates the budget rows. If rows are not budget checked, the budget status is N (not checked). If a row fails the budget check, the budget status is E (error). If rows pass the budget check, the budget status is V (valid).

  If you selected edit combination options on the Purchasing Processing Options page, the system performs ChartField edit combinations based on the ChartField Editing template. The system indicates a status of V (valid for passing rows) or R (recycle for rows that fail).

• Online processing

  If you enable commitment control for procurement cards, the system performs ChartField edits and budget-check validations after the users modify the distribution information and click the Save button on the Reconcile Statement page.

  The system also validates for ChartField combinations on the Distribution Templates page. Once a user modifies and saves information on this page, the system automatically uses the budget processor to check for valid ChartFields.

Note. To budget check procurement cards, first select the procurement card option on the Installation Options page.

Users can access the Budget Check Exceptions page to fix all rows that did not pass budget check. All failed rows must be fixed before successfully passing budget check.

This section discusses how to:

• Budget check procurement cards during the Statement Load process.

• Budget check procurement cards using the Reconcile Statement - Procurement Card Transactions page.

See Also

Setting Installation Options for PeopleSoft Applications

Pages Used to Budget Check Procurement Cards

Budget Checking Procurement Cards During the Statement Load Process

Access the Load Statement page.

See Also

Loading Procurement Card Statements to Application Tables

Budget Checking Procurement Cards Using the Reconcile Statement - Procurement Card Transactions Page

Access the Reconcile Statement - Procurement Card Transactions page.

When you create modify procurement cards using the Reconcile Statement - Procurement Card Transactions page, you can budget check them in realtime when you save the page. This invokes the Comm. Cntrl. Budget Processor process by remote call.

Running Budget Period-End Processes

This section provides an overview of budget period-end processing and discusses how to run budget period-end processes.

Understanding Budget Period-End Processing

Because a budget period can span a calendar or fiscal year, PeopleSoft uses the term period-end universally and applies it to the end of a budget period, the end of a fiscal year, or the end of a calendar year.

The budget period-end processes enable you to continue budgets across budget periods or fiscal years. You may have budgets that stay in force for more than one fiscal period. You may have project budgets that span more than one calendar year. Consequently, you may want to keep budgets in force across these time frames. The commitment control feature in PeopleSoft Purchasing provides you with two options.

You can keep a budget active beyond the end of a fiscal period, allowing purchasing transactions to reference that budget and to remain unaffected by fiscal period-end accounting procedures. This option is useful for project-related budgets that are finite in scope.

You can also close a budget at the end of a budget period and re-establish it in the next period while keeping all outstanding transactions active into the next budget period. This option is useful for ongoing accounts and budgets that you want to infuse with additional funds at regular intervals. You can end one period and start the next one with new amounts in selected budgets. You do not lose your outstanding transactions from the previous budget period, which saves you from having to enter them all over again in the new budget period. PeopleSoft Purchasing enables you to roll these transactions over into the new budget period automatically by using these budget period-end business processes.

Budget period-end processes differ from fiscal period-end processes. Your fiscal period-end closing entries have no effect on the commitment control ledgers. Therefore, fiscal period-end closing entries do not invoke the Comm. Cntrl. Budget Processor process for budget checking.

• The first period-end business processes are the close processes for requisitions and purchase orders that remove outstanding requisitions and purchase orders from your budget.

• The other aspect of these processes involves use of the PO Rollover1 (PO_POROLL1) and PO Rollover2 (PO_POROLL2) Application Engine processes.

  These processes enable you to budget check distribution lines against budgets with expiring periods and then roll funds over to new periods.

See Also

Loading Procurement Card Statements to Application Tables

Reconciling Purchase Orders

Closing Requisitions

Pages Used to Run Budget Period-End Processes

Rolling Over Purchase Orders at Budget Period-End

This section provides an overview of purchase order rollover process and discusses how to:

• Create a data set for retrieval by the purchase order rollover workbench.

• Select and qualify purchase orders for rollover.

• Review purchase order details.

• Run the PO Rollover1 process.

• Run the PO Rollover2 process.

• Run the PO Roll Open Encumbrance process.

Understanding the Purchase Order Rollover Process

If you are using commitment control, you can use purchase order rollover to budget check distribution lines against budgets with expiring budget periods and then roll funds over to new budget periods. PeopleSoft Purchasing enables you to select specific purchase orders to rollover.

Purchase orders that are canceled, fully vouchered, on hold, in process, or have not been successfully budget checked are not qualified for rollover. In addition, distribution lines that are canceled, closed or fully liquidated (that is, the Commitment Control Close Flag (KK_CLOSE_FLAG) is set to Y) do not qualify for rollover.

See Also

Creating Purchase Orders Online

Pages Used to Rollover Purchase Orders

Creating a Data Set for Retrieval by the Purchase Order Rollover Workbench

Access the PO Rollover View page.

Note. It is highly recommended that you create data sets that are no greater than 1000 rows. Any larger and the processing times on the purchase order rollover workbench can be substantial.

Search ID

Enter a search ID for this data set. The search ID is used to retrieve the data set on the PO Rollover page. Note. If the search ID is re-used for different search criteria, the previously selected data will be overwritten. PeopleSoft recommends a unique search ID for each different set of search criteria.

Roll Status

The following rules apply to purchase order selection:

When you select Rolled and None and a purchase order has both statuses, the line becomes available for selection. All distributions with these statuses appear with the appropriate roll error on the More Details tab on the Purchase Order Details page. The rolled distributions are not included in the rollover processes:

• When you select None and a purchase order has distributions that have previously been rolled, only the distributions that have not been rolled appear. The lines are available for selection on the PO Rollover page.

• When you select Rolled, any rolled distributions appear on the PO Rollover page, but they are not available for selection there.

• Once you select a purchase order and it is in Pending or Mid Roll status, it does not appear again unless you select those specific statuses. You cannot select lines that are in Mid Roll status on the PO Rollover page.

Important! Once you select and stage a line for rolling, it is removed from staging if it reappears on the PO Rollover page, is available for selection, and is not selected for staging again. Therefore, successive applications of the filters on this page should be more restrictive.

Other Information

See Also

Selecting and Qualifying Purchase Orders for Rollover

Running the PO Rollover1 Process

Running the PO Rollover2 Process

Understanding PeopleSoft ChartFields

Selecting and Qualifying Purchase Orders for Rollover

Access the PO Rollover page.

Purchase orders that have been received or partially received, but not yet vouchered are available for selection for purchase order rollover processing on the PO Rollover page. To retain the relationship between the purchase order and the receipt, the PO Rollover2 process updates the purchase order distribution number on the receipt distribution to match the new purchase order distribution number.

However, if there is one receipt for the purchase order that has been partially vouchered, the PO Rollover page is unable to maintain the relationship between the associated documents. Therefore, the purchase order is not available for selection for purchase order rollover processing. The Roll Status field is set to Part Vchrd (partially vouchered) and the Roll Error field on the Purchase Order Details page is set to One receipt partially vchrd (one receipt partially vouchered). A receipt is considered partially vouchered if the sum (quantity or amount) of all associated vouchers is less than the amount or quantity on the single receipt.

Purchase orders that you selected on the PO Rollover View page appear if they qualify for rollover. Purchase orders that are canceled, fully vouchered, on hold, in process, or that have not been successfully budget checked do not qualify for rollover and do not appear on this page.

Distribution lines do not appear if they are canceled, closed, or fully liquidated (that is, if the Commitment Control Close Flag is set to Y), because they are not qualified for rollover.

Important! Once you select a line for rolling and set the status to Pending, use the PO Rollover page to reselect it if it appears again on this page and is available for selection. Otherwise, the system removes the line from staging.

Reviewing Purchase Order Details

Access the Purchase Order Details page.

More Details Tab

Select the More Details tab.

Running the PO Rollover1 Process

Access the PO Rollover1 page.

The PO Rollover1 process adjusts amounts and quantities on current distributions to enable the budget processor to liquidate the selected purchase orders. The process then creates new distribution lines with the rolled amounts and quantities. The new distribution lines are held in a staging table until you run the PO Rollover2 process. It also returns outstanding amounts and quantities to the corresponding requisition and modifies various flags and statuses in the PO_HDR, PO_LINE_DISTRIB, and PO_LINE_DIST_NP tables in preparation for the Comm. Cntrl. Budget Processor process.

Note. You must budget check the purchase orders after you run the PO Rollover1 process and before you continue to the PO Rollover2 process.

Note. The PO Rollover1 process acts only on purchase orders when the Keep PY Encumbrances Open check box is clear on the PO Rollover page.

See Also

Comm. Cntrl. Budget Processor Process in PeopleSoft Purchasing

Running the PO Rollover2 Process

Access the PO Rollover2 page.

The PO Rollover2 process breaks the relationship between the rolled purchase order and the prior year's transactions in the commitment control tables and to close all distributions not rolled.

The PO Rollover2 process updates the KK_ROLLED field in the KK_SOURCE_HDR commitment control table to Y for all rolled purchase orders. This update to KK_ROLLED prevents the budget processor from processing and modifying the existing transaction. Instead, the budget processor assigns the purchase order a new transaction ID the next time the rolled purchase order is budget checked. The budget processor bypasses distributions created in prior budget periods.

Once the budget check process is complete, you must run the PO Rollover2 process. The run control page provides the option to complete the rollover process by business unit or by individual purchase orders.

The process closes or cancels the old distribution lines by setting the DISTRIB_LN_STATUS field to C (completed) or X (canceled). Select X only if the entire amount of the distribution was rolled over. The data held in the staging tables is then inserted into the PO_LINE_DISTRIB and PO_LINE_DIST_NP tables.

Note. You must budget check after running the PO Rollover1 process and before continuing to the PO Rollover2 process.

Note. The new distributions must be budget checked.

See Also

Comm. Cntrl. Budget Processor Process in PeopleSoft Purchasing

Running the PO Roll Open Encumbrance Process

Access the Roll Open Encum page.

Note. The process acts only on purchase orders when the Keep PY Encumbrances Open option is selected on the PO Rollover page.

The PO Roll Open Encum process combines PO Rollover1 and PO Rollover2 processing, along with functionality that keeps rolled remaining encumbrances open in the prior budget year. The process makes changes to the rolled distributions that prevent the budget processor from re-validating and liquidating them in the prior budget year. This functionality enables you to track unexpended amounts by individual purchase orders during a budget period without returning unexpended amounts to the budget.

In one step, the process adjusts amounts and quantities down to what has been vouchered on the distribution and creates new distributions for unvouchered amounts. These actions can be completed in one step, because budget checking rolled distributions in the prior budget year is not required, as the intent of the process is to prevent the liquidation of the remaining encumbrances.

Because budget checking of rolled distributions in the prior budget year is not performed when using this process, finalizing associated requisitions is not an option.

Run the budget processor after the PO Roll Open Encum process to budget check newly created distributions and to create their encumbrances in the new budget period.