Understanding PeopleSoft Commitment Control

This chapter provides an overview of Oracle's PeopleSoft Commitment Control.

Understanding PeopleSoft Commitment Control

Commitment Control is an optional feature of the PeopleSoft Financials, Enterprise Service Automation, and Supply Chain Management product lines that enables you to control expenditures actively against predefined, authorized budgets. In particular, Commitment Control enables you to:

• Create and maintain control budgets.

• Check actual transactions (such as actual expenditures and revenues) against control budgets.

• Check imminent future financial obligations (pre-encumbrances and encumbrances) against control budgets.

• Check recognized revenue against revenue estimate budgets.

When you set up control budgets, you associate them with a particular General Ledger business unit. You also define the kinds of transactions you are to check against your control budgets. Once your budgets are established, you check these transactions against your budgets, the passing or failing of the transactions depending on the remaining available budget amount and the degree of budgetary control you set up for your budgets.

Depending on how you set up Commitment Control security, users can adjust a transaction that fails budget checking or adjust the budgets that the transaction failed against and budget-check the transaction again. Also, if you grant users the authority, users can override budget checking and allow a transaction to exceed the budget.

In this section, we discuss:

• Commitment accounting.

• The underlying data structure of PeopleSoft Commitment Control.

• The budget-checking process.

• An example of control budget setup and budget checking.

• Accounting examples.

• ChartField security.

Commitment Accounting

Commitment accounting is an integral part of budgetary control. By establishing and tracking commitments to spend and receive amounts—and by checking these amounts against budgets—an organization can readily report on and control future spending and revenue.

In Commitment Control, we provide three expenditure commitment amount types and one revenue commitment amount type:

• Planned: A free-form non-actuals amount.

  Can be used as a memo entry or an entry to estimate future spending. Can also be used to record third-party source transactions that precede pre-encumbrance documents. The latter usage requires defining a new source transaction type.

• Pre-encumbrance: Amount that you expect to spend, but which you have no legal obligation to spend.

  A requisition is a typical pre-encumbrance transaction.

• Encumbrance: Amount that you have a legal obligation to spend in the future.

  Issuance of a purchase order to a vendor is a typical encumbrance transaction.

• Recognized Revenue: Revenue that you have booked and expect to receive.

Except in the case of federal government accounting, your actuals ledger does not store planned, pre-encumbrance, and encumbrance amounts, and it might or might not store recognized revenue amounts. (Federal accounting also records encumbrances in the actuals ledger and treats them as actual transactions.)

The Commitment Control ledgers and activity logs store pre-encumbrance amounts, encumbrance amounts, and recognized revenue amounts.

When you use Commitment Control, you can check both commitments and actual transactions, or expenditures, against control budgets. The following procedure from the procurement life cycle is a typical example of budget checking from commitment through actual transaction:

1. When you generate a requisition, use Commitment Control to check it against the appropriate budgets and post it as a pre-encumbrance in the Commitment Control ledger.

2. When a requisition becomes a purchase order, use Commitment Control to liquidate the pre-encumbrance and post the purchase order amount as an encumbrance (subject to liquidation rules you define).

3. When the purchased goods or services are delivered and the purchase order becomes a voucher, use Commitment Control to liquidate the encumbrance and post the expenditure.

Underlying Data Structure of PeopleSoft Commitment Control

Commitment Control uses the ledger and ledger group structure of General Ledger to store control budgets in the Commitment Control Ledger Data table (LEDGER_KK). Each control budget definition (or set of budgets sharing the same rules) is defined in the system as a Commitment Control ledger group consisting of Commitment Control ledgers, each of which stores a different amount type, such as pre-encumbrance, encumbrance, and expenditure.

A simple organization might have the following budget configuration:

• An expenditure Commitment Control ledger group consisting of a budget ledger, pre-encumbrance ledger, encumbrance ledger, and expenditure ledger.

  That is to say, it consists of a ledger for control budget amounts and a ledgers for each transaction amount type you process against your control budgets as shown in the following table:

  Ledger Group	Budget Ledger	Pre-encumbr Ledger	Encumbr Ledger	Expenditure Ledger
  ORG	ORG_BUD	ORG_PRE	ORG_ENC	ORG_EXP

  Some expenditure ledger groups may also include a planned ledger, which can be used for planned expenditures that have not yet solidified to the point of the need for the issuing of a requisition.

• A revenue Commitment Control ledger group consisting of a revenue estimate budget ledger, a revenue recognized ledger, and a revenue collected ledger,as shown in the following table:

  Ledger Group	Budget Ledger	Recognized Ledger	Collected Ledger
  REVEST	REVEST_BUD	REVEST_REC	REVEST_COL

In other words, within a control budget definition, each amount type has its own bucket, and this structure is reflected in the ledger group and ledger structure.

The way control budget data is actually stored in the Commitment Control Ledger Data table is similar to this example:

Each time a budget-checked transaction updates the Commitment Control Ledger Data table, it updates the posted total amount.

Note. The remaining available budget balance is not a stored amount, but is calculated when you run budget checking.

Using the ledger table structure in General Ledger for Commitment Control setup enables you to take advantage of other General Ledger processes, such as revaluation, ChartField translation, allocations, and summary ledgers. However, be aware that Commitment Control ledgers and ledger groups do not function in all respects as do General Ledger detail ledgers and ledger groups.

Commitment Control documentation often uses synonymously the terms amount type and ledger.

Also, the Commitment Control Ledger Data table at times is referred to as the Commitment Control ledger or budget ledger. It is important to remember these distinctions, as well as the synonymous use of these terms when a particular aspect of Commitment Control budget is being discussed.

Note. Ledgers defined by the Commitment Control ledger template can have different sets of ChartFields than do General Ledger detail ledgers. These can include General Ledger and Projects ChartFields, as well as the Budget Period ChartField.

Budget Checking Process

Commitment Control enables you to check source transactions from many PeopleSoft and third-party applications against your control budgets.

When a transaction exceeds the available budget amount, the system either stops the transaction and issues an error notice or passes the transaction with a warning notice, depending on the processing rules that you set up in your control budget definition, budget attributes, and source transaction type definition.

You can include expenditure budget tolerances and link revenue budgets to increase available spending, or remaining spending authority (RSA), for expenditure budgets. However, in the interest of simplicity, this introductory documentation and examples do not include tolerances and revenue budget linkage, which are discussed in detail in later chapters.

You can also set up Commitment Control to provide early warnings of possible future budget exceptions. Such warnings are triggered when commitments and expenditures reach a predetermined percentage of the total budgeted amount.

The following diagram provides a simplified view of Commitment Control budget-checking of source transactions showing warning and error exception handling through the update of Commitment Control ledgers.

Processing source transactions against control budgets

At the center of Commitment Control is the Budget Processor (FS_BP), an application engine process that performs both budget journal posting and transaction budget-checking.

See Also

Processing Source Transactions Against Control Budgets

Example of Commitment Control Budget Setup and Usage

The following highly simplified example shows how to set up an expenditure budget and budget-check the procurement life cycle of an expense transaction.

Setup and Budget Entry

This example assumes certain processing rules, which we do not discuss here and for the sake of simplicity, it does not include tolerances and revenue budget linkage that increase available spending even when the expenditure budget is exceeded. This scenario can vary, depending on the rules you define for the control budgets and source transaction types.

1. Presupposes that you define a general ledger business unit and ledger group in PeopleSoft General Ledger.

   Business Unit	Ledger Group	ChartFields
   EG004	ACTUALS	ACCOUNT, DEPTID, PRODUCT, AFFILIATE

2. Define an expenditure-type Commitment Control ledger group.

   Commitment Control Ledger Group	Ledgers
   ORG	ORG_BUD
   	ORG_PRE
   	ORG_ENC
   	ORG_EXP

3. Set up a budget period calendar.

   Budget Period	Dates
   Q113	01/01/2013 to 03/31/2013
   Q213	04/01/2013 to 6/30/2013
   Q313	07/01/2013 to 09/30/2013
   Q413	10/01/2013 to 12/31/2013

4. Set up the control budget definition for the Commitment Control ledger group.

   The following are the key ChartFields and the budgetary-level ChartField values.

   ChartField	Values
   ACCOUNT	600000, 640000
   DEPTID	000
   BUDGET_PERIOD	Q113, Q213, Q313, Q413

   You usually set up budget control at a summarized ChartField value level instead of establishing a budget for each detail ChartField value combination. You set up ChartField translation trees to roll detail (transaction level) values up to budgetary-level values.

   Summary Budgetary ChartField Value Level	Detail ChartField Value Level
   Account 600000	Account 601000 rolls up to 600000.
   	Account 602000 rolls up to 600000.
   	Account 603000 rolls up to 600000.
   Account 640000	Account 641200 rolls up to 640000.
   	Account 641500 rolls up to 640000.
   Department ID 000	Department ID 100 rolls up to Department ID 000.
   	Department ID 200 rolls up to Department ID 000.
   	Department ID 400 rolls up to Department ID 000.

5. Associate the Commitment Control ledger group with the general ledger business unit and actual ledger group shown in step 1.

6. Enter budget amounts for each budget.

   Account	DeptID	Budget Period	Budget Amount
   600000	000	Q113	4000
   600000	000	Q213	5000
   600000	000	Q313	5000
   600000	000	Q413	5000
   640000	000	Q113	2000
   640000	000	Q213	2000
   640000	000	Q313	2000
   640000	000	Q413	2000

Budget Checking

The following is an example of simple expenditure cycle.

1. Create a requisition.

   GL BU	Date	Acct	DeptID	Prod	Budget Date	Qnty	Amt
   EG004	06/15/13	601000	100	NB100	06/15/13	5	500

2. Budget-check the requisition.

   In the budget-checking process, the transaction ChartField values are translated to the budgetary values Account 600000 and DeptID 000. The budget date is translated to Budget Period Q213.

   If this is the first transaction, there is 5000 available in the budget for Account 600000, Dept ID 000, and Budget Period Q213, so the requisition passes budget checking. The Budget Processor updates the pre-encumbrance ledger for the budget.

   Budget Amount	Pre-encumbr Amount	Encumbr Amount	Expense Amount	Available Budget Amount
   5000	500	0	0	4500

   Note. This table is laid out for explanatory purposes only and does not reflect the structure of the data stored in the system. Note also that in reality available budget is a calculated amount, not a stored amount.

3. Create a purchase order for this requisition.

   GL BU	Date	Acct	DeptID	Prdt	Budget Date	Qnty	Amnt
   EG004	06/20/13	601000	100	NB100	06/20/13	5	550

4. Budget-check the purchase order.

   The amount for the purchase order is 550, while the amount for the requisition is 500. When the Budget Processor liquidates the pre-encumbrance (requisition), there remains 5000 available in the budget, so the 550 purchase order passes budget checking.

   The Budget Processor liquidates the requisition and updates the pre-encumbrance and encumbrance ledgers for the budget.

   Budget Amount	Pre-encumbr Amount	Encumbr Amount	Expense Amount	Available Budget Amount
   5,000	0	550	0	4450

   Because the purchase order amount exceeds the requisition amount, the system fully reverses the pre-encumbrance, leaving a zero balance. Pre-encumbrances do not become negative when they are liquidated.

   Note. Had the purchase order been equal to or less than the requisition amount, the Budget Processor would have liquidated the pre-encumbrance (requisition) and updated the encumbrance ledger with the purchase order amount without budget checking.

5. Create a payables voucher when you receive the goods from the vendor.

   GL BU	Date	Acct	DeptID	Prdt	Budget Date	Qnty	Amnt
   EG004	06/30/13	601000	100	NB100	06/30/13	5	540

6. Budget-check the voucher.

   The Budget Processor liquidates the encumbrance and updates the expense ledgers for the budget.

   Budget Amount	Pre-encumbrAmount	Encumbr Amount	Expense Amount	Available Budget Amount
   5,000	0	0	540	4460

   You can elect quantity-based or monetary amount-based liquidation. Quantity based liquidation is done through the various applications that feed into Commitment Control. The above example assumes you chose to use quantity based liquidation. Therefore, the Budget Processor reverses the full 550 purchase order amount for the five units, rather than the lower 540 amount indicated on the voucher.

   The example below assumes you had chosen instead to use monetary amount based liquidation, only 540 of the encumbrance would have been reversed, leaving a balance amount of 10 in the encumbrance ledger.

   Budget Amount	Pre-encumbr Amount	Encumbr Amount	Expenditure Amount	Available Budget Amount
   5,000	0	10	540	4450

   When you close your purchase orders, the Budget Processor checks the purchase order again, relieving the 10 encumbrance amount.

   Budget Amount	Pre-encumbr Amount	Encumbr Amount	Expenditure Amount	Available Budget Amount
   5,000	0	0	540	4460

7. You can then use the system within Payables to post the voucher, create its journal entry using Journal Generator, and mark the journal as budget checked so that it is not budget-checked again when you post it to the actuals ledger in General Ledger.

Closing for Purchase Orders and Requisitions

The following example shows the entries generated in the Commitment Control activity log if purchase orders and requisitions are budget checked and closed through the PO Close process.

Example 1: A purchase order is budget checked and closed within accounting period 1.

Example 2: After budget checking a purchase order for 500 USD, a voucher is created for 400 USD relieving the purchase order for the same amount and the balance of the purchase order, 25 USD, is closed all within the same accounting period.

Example 3: In this example the purchase order is dated and budget checked in accounting period 1. The date is changed and the purchase order is reassigned to accounting period 2. The purchase order is later closed in period 2. An unclose in period 2 results in deletion of line 4 that effectively leaves the purchase order open for period 2.

Example 4: In this example a purchase order is budget checked in accounting period 1 and then the date is changed and reestablished in period 2. The purchase order is subsequently closed in period 3 and then unclosed in period 3.

Understanding ChartField Security

PeopleSoft ChartField security provides a flexible, rule-based approach to administer security at a data level. ChartField security is supported in PeopleSoft Commitment Control and across other PeopleSoft Financials and Supply Chain Management (FSCM) applications. The ChartField security feature prevents unauthorized employees and contractors from viewing and editing sensitive financial data by restricting access to data stored with specific ChartField values.

The primary features for ChartField Security are:

• Enforce security rules by user, role, or permission list.

• Enable ChartField security for all products or selectively by product.

• Enable or disable ChartField security selectively by component.

• Define rules to accommodate end-user areas of responsibility.

• Refine access rules by product feature or component.

• Support super user access to minimize setup.

• Define components as exceptions to override security rules.

See Securing ChartFields for PeopleSoft Commitment Control.