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

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.

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

See Also

Understanding PeopleSoft Commitment Control

Setting Up Basic Commitment Control Options

Setting Installation Options for PeopleSoft Applications

Delivered Source Transaction Types for Purchasing

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:

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)

Commitment Control Budget Processor Process in PeopleSoft Purchasing

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.

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 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 purchase order reconciliation workbench (for cancel and close), batch reconciliation processes, 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 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.

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 Pre-Check

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 Set Up Financials/Supply Chain, Install, Installation Options, Commitment Control. 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.

See Also

Checking Budget Journals and Transactions Without Posting

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

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

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 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:

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

2. Save your changes.

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

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.

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.

See Also

Viewing the Activity Log

Closing Requisitions

Closing 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

Commitment Control Budget Processor Process in PeopleSoft Purchasing

Understanding PeopleSoft Enterprise 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.

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 on the purchase order from the original requisition, you should either click the Undo Finalize Line button or the Undo Finalize Entire Document button and save the purchase order. Then, select to budget check the revised purchase order document again. You can declare the purchase order partial, thus liquidating the requisition and freeing the last 50.00 USD for other purposes.

When you finalize the purchase order document on the affected requisition and then perform a budget check on the purchase order again, the Final field is selected and the Budget Line Status value on the Statuses tab is set to Valid on PO Distribution. Also, the Commitment Control Close Flag check box is selected on the Details tab on the Maintain Requisitions – Distribution page.

When you undo finalize on the purchase order document on the affected requisition and then budget check the purchase order again, the Final field is cleared, and the Budget Line Status field value on the Statuses tab is set to Valid on PO Distribution. In this case, the Commitment Control Close check box is deselected on the Details tab on the Maintain Requisitions – Distribution page.

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 Commitment Control Budget Processor process.

• Budget check requisitions using online pages.

Pages Used to Budget Check Requisitions

Budget Checking Requisitions Using the Commitment Control Budget Processor Process

Access the Req Budget Check page (Purchasing, Requisitions, Budget Check, Req Budget Check ).

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 Commitment Control Budget Processor process by remote call.

See Also

Commitment Control 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 Commitment Control Budget Processor process.

• Budget check purchase orders using online pages.

Pages Used to Budget Check Purchase Orders

Budget Checking Purchase Orders Using the Commitment Control Budget Processor Process

Access the Budget Check Request page (Purchasing, Purchase Orders, Budget Check, PO Budget Check Request).

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 Commitment Control Budget Processor process by remote call.

See Also

Commitment Control 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 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 (Purchasing, Procurement Cards, Process Statements, Load Statement).

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 (Purchasing, Procurement Cards, Reconcile, Reconcile Statement, Reconcile Statement - Procurement Card Transactions).

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 Commitment Control 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 reestablish 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 Commitment Control 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

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

• Run the Non Qualified PO Listing 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.

The system places strict requirements on purchase orders and their interdependence with accounts payable, receiving, and commitment control before it makes the purchase orders eligible for rollover. To assist you in reviewing details about why the purchase order is not qualified for rollover and provide you a way to manage exceptions across a large data set, the system provides two options for working with rollover exceptions.

First, you can use the PO Rollover View page to define specific fields that create data sets that you can use to review purchase order rollover information. A search ID value is used to define a data set. As an example of creating a data set, you might want to include only those purchase orders where the Project ChartField is within a range or you might want to exclude purchase orders where the Project ChartField is populated.

When you run the PO_POROLLVW process, the system creates the search ID that you define. You can then use the PO Rollover Workbench to retrieve the search ID with the corresponding rollover details. You can also use the workbench to identify purchase orders that you do not want to rollover. The system filters these purchase orders out for future iterations of the POROLLVW process.

The next rollover exception option enables you to view which purchase orders are not qualified for rollover. To view the purchase orders, you run the POROLLEXP process to create the PO Rollover Exceptions report. You can run the report from within the PO Rollover Workbench, the PO Rollover View page, or the PO Rollover page, or you can use the Non Qualified PO Listing menu option. The report displays the non-qualified purchase orders and their associated documents. To populate the tables to produce the PO Rollover Exceptions report, run the PO Rollover view process to select the disqualified orders.

Note. When a purchase order is over expensed and an associated voucher has been deleted, then the rollover process sets the PO distribution status to Complete.

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 (Purchasing, Purchase Orders, Budget Year End Processing, Request PO Roll View, PO Rollover View).

Note. It is 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.

The PO Rollover View page enables you to limit the information contained in a data set. You use the page to define selection criteria for the PO_POROLLVW process. Along with limiting basic information, such as a business unit, a buyer, or a purchase order, you can limit the data set to ChartField values. For example, you can limit the data set to a specific ChartField or a range of ChartFields.

In addition, you can limit information in data sets using logic operands against a ChartField. These operands include, for example, Begins with, Equal, and Less than. So if you want to include ChartFields for a specific fund affiliate, you would use the In operand. The system displays a General Ledger Business Unit field that you use to select a fund affiliate to include in the data set.

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! When 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.

Exception Report

Use this grid box to indicate that you want to run the PO Rollover Exceptions report and to define the sort method for the report.

Other Information

See Also

Selecting and Qualifying Purchase Orders for Rollover

Running the PO Rollover1 Process

Running the PO Rollover2 Process

Understanding PeopleSoft Enterprise ChartFields

Selecting and Qualifying Purchase Orders for Rollover

Access the PO Rollover page (Purchasing, Purchase Orders, Budget Year End Processing, PO Rollover Workbench, PO Rollover).

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 (Purchasing, Purchase Orders, Budget Year End Processing, Request PO Rollover1, PO Rollover1).

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 Commitment Control 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

Commitment Control 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

Commitment Control Budget Processor Process in PeopleSoft Purchasing

Running the PO Roll Open Encumbrance Process

Access the Roll Open Encum page (Purchasing, Purchase Orders, Budget Year End Processing, Request PO Roll Open Encum).

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.

Running the Non Qualified PO Listing Process

Access the Run Roll Exception page (Purchasing, Purchase Orders, Budget Year End Processing, Non Qualified PO Listing).

Use this page to create the PO Rollover Exceptions report. The report displays the non-qualified purchase orders and their associated documents.

To populate the tables that produce the report, you need to run the PO Rollover View process to create a data set on which to run the report. The report is also available as an XML Publisher report.

You can also access the Run Roll Exception page using the PO Rollover View and PO Rollover 1 pages and by using the PO Rollover Workbench.

Establishing Purchasing ChartField Security

To facilitate ChartField Security functionality, Oracle delivers PeopleSoft Purchasing with components that are already set up for use with ChartField security. You can deactivate the settings, modify the settings, or add security for components. ChartFields are the fields that store charts of accounts and provide the system with the basic structure to segregate and categorize transactional and budget data. PeopleSoft Purchasing enables you to secure specific accounts to prevent unauthorized users from viewing or editing financial information. The ChartField Security feature provides the framework for you to define the ChartField security method and configure and maintain security for specific PeopleSoft Purchasing ChartField fields and records. You can define the security method based on users, roles, and permission lists.

Customers can assign a group of users, roles, or permission lists to a rule in one page using a default effective date. The rule applies to all products. Customers can assign many rules to a user, role, or permission list in one page. Different rules can be assigned to different products for one user.

Chartfields are secured at the distribution level on the purchase order and requisition entry transactions. Values for ChartFields on the Purchase Order Defaults page for the purchase order header are not secured. When you create a transaction, the distribution values may default onto the transaction. When you save the transaction, the ChartField security will validate to ensure that the user can create and maintain documents using those secured ChartField values.

By default, most components in PeopleSoft Purchasing are secured when the product itself is enabled. You can activate or inactivate ChartField security for certain Purchasing components that include transactions, such as data entry for purchase orders and requisitions, search lists, inquiries, and prompts.

The core system for establishing ChartField security is described in the PeopleSoft Application Fundamentals 9.1 PeopleBook. Also, the book provides descriptions of the Purchasing components and pages affected by ChartField security.

See Securing ChartFields.

See Securing ChartFields for PeopleSoft Enterprise Purchasing.