Oracle PeopleSoft Enterprise Financial Management 9.1 Implementation — Save 50%
An exhaustive book and ebook resource for PeopleSoft Financials application practitioners to understand core concepts, configurations, and business processes
Commitment Control is an optional feature of PeopleSoft used for enforcing budget control over an organization's spending. It enables an organization to perform what is known as "encumbrance accounting", or commitment accounting. Using this feature, organizations can define budgets for various categories of their spending and track each spending transaction against available budget amounts. Although commitment control configurations are part of the General Ledger module, it spans many more modules such as Purchasing, Accounts Payable, Expenses, Billing, Accounts Receivable, and so on, which are responsible for creating transactions for spending as well as generating revenue.
In this article by Ranjeet Yadav, author of Oracle PeopleSoft Enterprise Financial Management 9.1 Implementation, we'll cover the following important topics:
- Understanding commitment control
- Commitment control configurations
|Read more about this book|
(For more resources on Oracle, see here.)
Understanding commitment control
Before we proceed further, let's take some time to understand the basic concepts of commitment control.
Commitment control can be used to track expenses against pre-defined control budgets as well as to track recognized revenue against revenue estimate budgets. In this article, we'll concentrate more on the expense side of commitment control, as it is more widely used.
Defining control budgets
An organization may draw budgets for different countries in which it operates or for its various departments. Going further, it may then define budget amounts for different areas of spending, such as IT hardware, construction of buildings, and so on. Finally, it will also need to specify the time periods for which the budget applies, such as a month, a quarter, six months, or a year.
In other words, a budget needs the following components:
- Account, to specify expense areas such as hardware expenses, construction expense, and so on
- One or more chartfields to specify the level of budget such as Operating unit, Department, Product, and so on
- Time period to specify if the budgeted amount applies to a month quarter or year, and so on
Let's take a simple example to understand how control budgets are defined. An organization defines budgets for each of its departments. Budgets are defined for different expense categories, such as the purchase of computers and purchase of office supplies such as notepads, pens, and so on. It sets up budgets for each month of the year.
Assume that following chartfield values are used by the organization:
Now, the budgets are defined for each period and a combination of chartfields as follows:
Thus, $100,000 has been allocated for hardware purchases for the Sales department for January 2012. Purchases will be allowed until this budget is exhausted. If a purchase exceeds the available amount, it will be prevented from taking place.
Tracking expense transactions
Commitment control spending transactions are classified into Pre-encumbrance, Encumbrance, and Expenditure categories. To understand this, we'll consider a simple procurement example. This involves the PeopleSoft Purchasing and Accounts Payable modules. In an organization, a department manager may decide that he/she needs three new computers for the newly recruited staff. A purchase requisition may be created by the manager to request purchase of these computers. Once it is approved by the appropriate authority, it is passed on to the procurement group. This group may refer to the procurement policies, inquire with various vendors about prices, and decide to buy these computers from a particular vendor. The procurement group then creates a purchase order containing the quantity, configuration, price, and so on and sends it to the vendor. Once the vendor delivers the computers, the organization receives the invoice and creates a voucher to process the vendor payment. Voucher creation takes place in the Accounts Payable module, while creation of requisition and purchase order takes place in the Purchasing module.
In commitment control terms, Pre-encumbrance is the amount that may be spent in future, but there is no obligation to spend it. In the previous example, the requisition constitutes the pre-encumbrance amount. Note that the requisition is an internal document which may or may not get approved, thus there is no obligation to spend the money to purchase computers.
Encumbrance is the amount for which there is a legal obligation to spend in future. In the previous example, the purchase order sent to the vendor constitutes the encumbrance amount, as we have asked the vendor to deliver the goods.
Finally, when a voucher is created, it indicates the Expenditure amount that is actually being spent. A voucher indicates that we have already received the goods and, in accounting terms, the expense has been recognized.
To understand how PeopleSoft handles this, think of four different buckets: Budget amount, Pre-encumbrance amount, Encumbrance amount, and Expenditure amount.
Budget definition is the first step in commitment control. Let's say that an organization has budgeted $50,000 for purchase of IT hardware at the beginning of the year 2011. At that time, these buckets will show the amounts as follows:
|Budget||Pre-encumbrance||Encumbrance||Expenditure||Available budget amount|
Available budget amount is calculated using the following formula:
Available budget amount = Budget amount – (Pre-encumbrance + Encumbrance + Expenditure)
Now when the requisition for three computers (costing a total of $3,000) is created, it is checked against the available budget. It will be approved, as the entire $50,000 budget amount is available. After getting approved, the requisition amount of $3,000 is recorded as pre-encumbrance and the available budget is accordingly reduced. Thus, the budget amounts are updated as shown next:
|Budget||Pre-encumbrance||Encumbrance||Expenditure||Available budget amount|
A purchase order can be created only after a requisition is successfully budget checked. When the purchase order i created (again for $3,000), it is once again checked against the available budget and will pass due to sufficient available budget. Thus, once approved, the purchase order amount of $3,000 is recorded as encumbrance, while the pre-encumbrance is eliminated. In other words, the pre-encumbrance amount is converted into an encumbrance amount, as now there is a legal obligation to spend it. A purchase order can be sent to the vendor only after it is successfully budget checked. Now, the amounts are updated as shown next:
|Pre-encumbrance||Encumbrance||Expenditure||Available budget amount|
When the voucher gets created (for $3,000), it is once again checked against the available budget and will pass, as the available budget is sufficient. Once approved, the voucher amount of $3,000 is recorded as expenditure, while the encumbrance is eliminated. In other words, the encumbrance amount is converted into actual expenditure amount. Now, the amounts are updated as shown next:
|Budget||Pre-encumbrance||Encumbrance||Expenditure||Available budget amount|
The process of eliminating the previous encumbrance or pre-encumbrance amount is known as liquidation. Thus, whenever a document (purchase order or voucher) is budget checked, the amount for the previous document is liquidated.
Thus, a transaction will move successively through these three stages with the system checking if available budget is sufficient to process it. Whenever the transaction encounters insufficient budget, it is flagged as an exception.
So, now the obvious question is how do we implement this in PeopleSoft? To put it simply, we need the following building blocks at the minimum:
- Ledgers to record budget, pre-encumbrance, encumbrance, and expenditure amounts
- Batch processes to budget check various transactions
Of course, there are other configurations involved as well. We'll discuss them in the upcoming section.
Commitment control configurations
In this section, we'll go through the following important configurations needed to use the commitment control feature:
- Enabling commitment control
- Setting up the system-level commitment control options
- Defining the commitment control ledgers and ledger groups
- Defining the budget period calendar
- Configuring the control budget definition
- Linking the commitment control ledger group with the actual transaction ledger group
- Defining commitment control transactions
Enabling commitment control
Before using the commitment control feature for a PeopleSoft module, it needs to be enabled on the Installation Options page.
Follow this navigation to enable or disable commitment control for an individual module:
Setup Financials / Supply Chain | Install | Installation Options | Products
The following screenshot shows the Installation Options – Products page:
This page allows a system administrator to activate any installed PeopleSoft modules as well as to enable commitment control feature for a PeopleSoft module.
The PeopleSoft Products section lists all PeopleSoft modules. Select the checkbox next to a module that is implemented by the organization.
The Enable Commitment Control section shows the PeopleSoft modules for which commitment control can be enabled. Select the checkbox next to a module to activate commitment control and validate transactions in it against defined budgets.
Setting up system-level commitment control options
After enabling commitment control for desired modules, we need to set up some processing options at the system level.
Follow this navigation to set up these system level options:
Setup Financials / Supply Chain | Install | Installation Options | Commitment Control
The following screenshot shows the Installation Options – Commitment Control page:
- Default Budget Date: This field specifies the default budget date that is populated on the requisitions, purchase orders and vouchers. The available options are Accounting Date Default (to use the document accounting date as the budget date) and Predecessor Doc Date Default (to use the budget date from the predecessor document). For example, the purchase order inherits requisition's budget date, and the voucher inherits the purchase order's budget date.
- Reversal Date Option: There are situations when changes are made to an already budget-checked transaction. Whenever this happens, the document needs to be budget checked again. This field determines how the changed transactions are posted. Consider a case where a requisition for $1,000 is created and successfully budget checked in January. In February, the requisition has to be increased to $1,200. It will need to be budget checked again. The available options are Prior Date (this option completely reverses pre-encumbrance entries for January for $1,000 and creates new entries for $1,200 in February) and Current Date (this option creates additional entries for $200 for February, while leaving $1,000 entries for January unchanged).
- BP Liquidation Option: We already saw that system liquidates the pre-encumbrance and encumbrance amounts while budget checking purchase orders and vouchers. This field determines the period when the previous amount is liquidated, if the transactions occur in different periods. The available options are Current Document Budget period (liquidate the amounts in the current period) and Prior Document Budget period (liquidate the amounts in the period when the source document was created).
- Enable Budget Pre-Check: This is a useful option to test the expense transactions without actually committing the amounts (pre-encumbrance, encumbrance, and expenditure) in respective ledgers. We may budget check a transaction and find that it fails the validation. Rather than budget checking and then handling the exception, it is much more efficient to simply do a budget pre-check. The system shows all the potential error messages which can help us in correcting the transaction data appropriately. Select the checkbox next to a module to enable this feature.
eBook Price: $32.99
Book Price: $54.99
|Read more about this book|
(For more resources on Oracle, see here.)
Defining commitment control ledgers and ledger groups
The ledgers are used to record actual accounting transactions. We also need additional ledgers to record commitment control transactions similar to the illustrative example we saw previously.
We briefly mentioned that dedicated ledgers are needed to record amounts from each bucket (that is, Budget, Pre-encumbrance, Encumbrance, and Expenditure). Thus, in order to use commitment control, we need at least one ledger group containing four commitment control ledgers. A sample ledger group may be configured as shown next:
As you can see, the CC_COMB_BD ledger will store the budget amounts, the CC_COMB_PR ledger will store any pre-encumbrance amounts, and the CC_COMB_EN ledger will record encumbrance amounts, while the CC_COMB_EX ledger stores the expenditure amounts.
Select the ledger value and its purpose in the Ledger and Commitment Control Ledger Type fields respectively.
Ensure that the commitment control ledger group contains four ledgers with the types as shown. The Ledger Group Type field value must be Commitment Control Expense or Commitment Control Revenue as the need may be. The Ledger template used must be the one specifically used for commitment control.
Defining commitment control budget calendars
Note that calendars are created irrespective of whether an organization uses commitment control or not. They are mandatory for any PeopleSoft financial system. However, PeopleSoft uses different pages to build budget calendars. Depending on how an organization creates its budgets (monthly, bi-monthly, quarterly, and so on, we need to create appropriate budget calendars. There are various ways in which an organization may define its budgets.
For example, an organization may define its budget of $1,000,000 for IT hardware procurement for an entire year with no restriction on when this amount should be spent. Or it may decide to budget $250,000 for each quarter of the year. Thus, in the first case, it may spend up to $1,000,000 in the first month of the year itself. On the other hand, in the second case, it can spend only up to $250,000 in the three months of a quarter.
Follow these navigations to create new budget calendars:
Set Up Financials/Supply Chain | Common Definitions | Calendars/Schedules | Budget Period Calendar
Set Up Financials/Supply Chain | Common Definitions | Calendars/Schedules | Budget Period Calendar Builder
Set Up Financials/Supply Chain | Common Definitions | Calendars/Schedules | Summary BP Calendar
The following screenshot shows a sample quarterly budget calendar:
As you can see, we can specify the number of periods in a year, type of calendar (Month, Bimonth, Quarter, and so on, and Begin Date and End Date for each budget period. You can probably appreciate the fact that there will be 12 budget periods in a year if monthly budgets are defined, four budget periods in a year if quarterly budgets are defined, and so on.
Configuring tree definitions
Usually when budgets are set up, they are set up at a higher (summarized) level. For example, when an organization decides to set up budgets on the basis of departments, it may not establish budgets for each department. Instead, it may set them up for a group of departments. This will need a hierarchical structure of a desired chartfield known as Tree.
Note that Department is just an example how budgets are defined. An organization may decide to use any other chartfield or a combination of chartfields to define its budgets.
Follow this navigation to create a tree:
Tree Manager | Tree Manager
The following screenshot shows a sample tree created for grouping Department chartfield values:
As you can see, the tree has four levels of Department values. Thus, we can specify budgets for the Administration, School of Medicine, Sales Admin, and Manufacturing Support groups of departments. This approach greatly reduces the manual configuration effort by summarizing the budget amounts at a higher level.
When we budget check a transaction for department 15000, the system refers to this tree definition and checks the available budget for its rolled-up value (that is, Department group 14000) to decide if the transaction should go through or fail.
Configuring control budget definitions
This is one of the most crucial configurations for commitment control which sets up various processing options for a commitment control ledger group. Before discussing this configuration, we'll take some time to understand a few concepts.
- Ruleset: Budget definitions usually have multiple processing rules for different scenarios. For example, in our sample budget determined by Department value, we may have different processing rules for different groups of departments. For example, budgets for Sales and Manufacturing departments should be tracked by an additional parameter (Product) which may not be needed for other groups. Thus, any transaction with Sales and Manufacturing departments must have the Product chartfield value as well, while it is optional for other departments. These subsets of processing rules are known as Rulesets. The chartfield whose value determines which processing options, or, in other words, which ruleset, should be used is known as Ruleset Chartfield. In this example, Department will be the Ruleset chartfield.
- Controlling options: PeopleSoft offers the following options to decide how the expense transactions should be processed by the budget processor:
- Control: This option validates each transaction amount (such as requisitions, purchase orders, vouchers, and so on) against budgeted amounts. If transaction amount exceeds the budgeted amount, it is flagged as an exception.
- Control Initial Document: This option validates only the initial document against budgeted amounts. If the amount of the initial document exceeds the budgeted amount, error messages are issued. If an initial document successfully passes the budget check, all subsequent documents automatically pass the budget check. Thus, if a requisition passes budget check, the resulting purchase order and voucher will pass the budget check even if sufficient budget is not available at that time.
- Track with Budget: This option keeps track of all expense transactions; however, it does not issue any error messages like the previous option. All transactions for which a budget exists (even for a zero amount) are passed. If the transaction amounts exceed the budgeted amount, only warnings are issued but the transaction can proceed. Note that the presence of a budget is necessary.
- Track without Budget: This option tracks transactions even if no budget exists. If a budget exists and the transaction amount exceeds the budgeted amount, warnings are issued. If no budget exists, no warning is issued.
If necessary, we can specify that all transactions for some specific departments (or any other chartfield) should have an option of 'Control', while transactions from other departments should have an option of 'Control Initial Document'. A chartfield whose values control how the transactions are processed is known as a Controlling Chartfield.
Follow this navigation to create or modify a control budget definition:
Commitment Control | Define Control Budgets | Budget Definitions | Control Budget Options
The following screenshot shows a sample budget definition:
As mentioned previously, we are essentially setting up the processing options for the CC_COMBO commitment control ledger group in this configuration.
- Budget Type: The system automatically displays a value Expense or Revenue, depending on the Ledger Group Type selected for this ledger group.
- Associated Expenditure Budget: If we are configuring a revenue budget, it can be linked to an expenditure budget in this field.
- Tolerance Percent: This field is used to specify a percentage by which transaction amounts can exceed the budget amounts without triggering an error message.
- Ruleset CF: This option specifies the ruleset chartfield as discussed earlier. The value of this chartfield will determine which processing rules are to be used.
- Tree Name, Level Name: This specifies the hierarchy tree details for the ruleset chartfield that we discussed previously.
- Control CF: This specifies the control chartfield as discussed earlier. The value of this chartfield will determine how transactions with specified chartfield values will be processed.
- Commitment Control Options - Control Option: This specifies the processing option for this budget ledger. The available options are the same as we discussed previously: Control, Control Initial Document, Track with Budget, and Track without Budget.
The following screenshot shows the Ruleset Chartfield tab:
This tab is used to define one or more processing rules (rulesets) for different ranges of values of the Ruleset Chartfield. As we specified Department as the ruleset chartfield in the previous tab, we can specify various ranges of Department values to define different processing options for them. As you can see, we have defined two rulesets based on department values. Note that only one ruleset can be designated as the default.
In the next tabs, we'll define options to decide how we can process transactions differently for these two groups.
The following screenshot shows the Keys and Translations tab:
This is the tab where we can specify various processing options for the different rulesets. As you can see, the page shows two different sets of options for RULESET1 and RULESET2 that we defined on previous tab. Note that all of the options discussed next can be set up differently for different rulesets.
- Enable Cumulative Budgeting: Let's say we use a budget calendar with 12 periods, one corresponding to each month. Thus we define budget amounts for each period. Normally a transaction will be checked against budget amount defined for the month in which it was created. However, PeopleSoft offers an option to use cumulative periods using cumulative calendars to determine budget amounts. Thus, if each month's budget amount is $1,000, and we enable cumulative budgeting with a quarterly calendar, transactions will be checked against the cumulative budget of $3,000 (for three months). As a result, irrespective of the monthly budget amount, a transaction is validated against the available budget for a quarter and not an individual month. This is known as cumulative budgeting. Select this checkbox to use this feature.
- Cumulative Calendar: Specify a cumulative calendar if cumulative budgeting is used. This is a calendar with period larger than the regular calendar. For example, if regular budget calendar is monthly, we can use quarterly, semi-annual, or any other calendar with period larger than a month.
- Calendar ID: Specify the regular budget period calendar that we discussed earlier.
- Keys and Translation: This section lists the chartfield keys that are needed to track budget amounts. Thus, if we need to track Sales and Manufacturing department transactions by product, add the Product chartfield as the additional key to the appropriate ruleset. If a budget is defined at a higher level for a chartfield, specify the details in Tree Name and Level Name fields.
The following screenshot shows a part of the Control Chartfield tab:
Earlier, we discussed how budget control options work. In the first tab, Department was specified as the control chartfield. Thus, this tab allows various ranges of Department values to be defined and corresponding control options specified. As shown in the given screenshot, we can specify different control options for different ranges of the Department value.
We'll not discuss the remaining tabs (Offsets and Excluded Account Types) in detail but quickly get an overview of their purpose.
The Offsets tab is used to specify the offset accounts for budget entry. Budget amount entry is done through online budget journals, which we'll see in a short while. This tab also records the offset account to be used for each source transaction that is budget checked.
The Excluded Account Types tab is used to specify which account types or specific account values should be excluded from budget check. Recall that PeopleSoft delivers the account types Assets, Liabilities, Equity, Revenue, and Expense. If we are using commitment control for tracking expense transactions, we can specify Assets, Liabilities, Equity, and Revenue account types for exclusion. If required, we can also specify individual account values that need to be excluded from budget checking.
Defining commitment control transactions
During our discussion so far, we have already seen that a requisition, purchase order, or voucher are examples of commitment control transactions that get validated against budgets. PeopleSoft delivers a group of transactions which are recognized by the budget processor.
Follow this navigation to view/ modify the source transactions:
Commitment Control | Define Control Budgets | Source Transactions
The following screenshot shows a sample delivered transaction – Purchase order:
The following table lists various commitment control transactions delivered by PeopleSoft:
|Source transaction name||Description|
|AP_ACCT_LN||Voucher (gain, loss, close)|
|AP_ACCTDSE||Voucher (discount earned)|
|AP_VCHR_NP||Voucher (non-prorated item)|
|AR_MISCPAY||Direct Journal Payments|
|CM_TRNXTN||Cost Management Transaction|
|EX_EXCLOSE||Close Expense Reports|
|GL_BD_JRNL||General Ledger Budget Entry|
|GL_JOURNAL||General Ledger Journal|
|GM_FA||Facilities and Administration|
|GM_FA_UPG||Facilities and Administration (for Upgrade Budget Processor only)|
|PO_POENCNP||PO (non-prorated item)|
|PO_RAENC||Receipt Accruals - Encumbrance|
|PO_RAEXP||Receipt Accruals - Expense|
|REQ_PRECNP||Purchase Requisition - Non-prorated|
It is very rare that we would need to change the delivered definitions of commitment control transactions. For most of the requirements, the source transactions can be used as delivered.
Commitment control is a useful optional feature used by organizations to enforce budget controls. PeopleSoft offers the ability to define budgets and track transactions against these budgets. Budgets can be defined for both expense and revenue amounts. Dedicated commitment control ledgers are used to track the various types of commitment control transactions.
Budget, Pre-encumbrance, Encumbrance, and Expenditure ledgers are required in a commitment control ledger group. Commitment control budget definition determines the processing options for a ledger group. Rulesets specify processing rules for various groups of designated chartfields. A commitment control ledger group is linked to an actual ledger group for a business unit so that an association is made between the actual transactions and their corresponding budgets.
Budget amounts for necessary chartfield combinations are entered using budget journals. These journals are then posted to the appropriate commitment control ledger group. The budget processor batch process is used to validate transactions from various modules against defined budgets.
Based on user preferences, a user can be given the ability to override commitment control exceptions. Otherwise, the system prevents these transactions from proceeding. Organizations can decide whether to use this feature or not. If it is used, it can be enabled for select modules.
- Oracle WebCenter 11g: Portlets [Article]
- An Overview of Oracle Advanced Pricing [Article]
- Oracle Business Intelligence: Drilling Data Up and Down [Article]
- Integrating Discussions, Wiki, and Blog with Oracle WebCenter [Article]
eBook Price: $32.99
Book Price: $54.99
About the Author :
Ranjeet Yadav has been working in the IT industry for more than 10 years. He possesses professional experience of more than 8 years as a functional consultant with PeopleSoft finance and supply chain applications. He has worked on PeopleSoft implementations for many world class organizations and performed various roles such as PeopleSoft consultant, Module lead, Finance track lead and Project manager. Although his entry into the PeopleSoft world was rather accidental, he was quickly impressed by the deep impact such an ERP product can have on an organization's functioning. He finds the challenge of designing solutions for organizations' critical business problems quite exciting.
Ranjeet holds an Electronics Engineering degree and a Post Graduate Diploma in Management with specialization in Information Systems from Indian Institute of Management,Lucknow. He is currently working with IBM India as a PeopleSoft consultant and Project manager.