Understanding Basic Commitment Control Setup

Enabling Commitment Control for Third-Party Applications

You enable or disable budget checking for the journals that are generated from third-party (non-PeopleSoft) applications on the Accounting Entry Definition page in General Ledger. If you select Skip Commitment Control In GL, the Budget Processor skips journals that are generated through the Journal Generator (FS_JGEN) from outside source transactions. If you select the Skip Commitment Control In GL check box, journals that are generated from outside source transactions have to be budget-checked in General Ledger before the journals can be posted.

Configuring ChartFields for Commitment Control

If the delivered ChartFields do not meet your requirements, you can configure Commitment Control ChartFields for your specific organizational practices.

Budget Reference ChartField

Commitment Control provides a budget reference ChartField that uniquely identifies a budget. The budget reference ChartField enables you to perform comprehensive reporting on budgets that span multiple years and that overlap other multiyear budgets.

See Budget Reference ChartField.

Budgetary-Only ChartField Values

When you define a ChartField value and select this option, the ChartField value can be used for budget purposes only and is not available for recording actual transactional entries. With the exception of the affiliate ChartFields, the Budgetary Only option is available for ChartFields supported by Commitment Control.

You usually establish budget control using summary Budgetary Only ChartField values instead of establishing a budget for each detail transactional ChartField value. You then set up ChartField translation trees to roll up the detail transactional-level ChartField values to the summary budgetary ChartField level values.

For example, if Account is a key ChartField, and you budget at a translated level, you designate your budget level accounts as budgetary-only when you define them in the Account component. Budgetary-only accounts are then available for budgeting but unavailable for use at the source transaction level. This prevents users from using high-level roll up accounts in detail transactions.

See Account Page.

Commitment Control Override for Account

When you define an Account ChartField value and select this option on the Account page, the Account value is not subject to budget controls and receives an automatic override. Transactions containing account values with the override option will pass budget checking regardless of the control ChartField value and the budget processor issues warnings instead of errors for all exceptions that can be overridden.

See Understanding Exception Handling and Notification.

See Account Page.

Key ChartFields

When you set up control budget definitions, you specify budget keys, which are the ChartFields that you require for budget journals and source transactions to identify budgets for budget checking. .

Budget journals and source transactions that do not have values for budget key ChartFields will fail posting and budget checking unless you select one of two other Value Required options. You can instruct the budget processor to bypass transaction lines if key ChartFields other than Account are set to Not Required. Setting the Value Required option to Optional allows you to maintain budget rows with blank values for the same budget key structure that was not possible in prior releases.

The Control ChartField and the Ruleset ChartField are always required as keys for all Rulesets. Each ruleset in a budget definition can have its own set of additional budget keys.

See Budget Definition - Ruleset ChartField Page.

Translation Trees

Most enterprise budgets are at a level above the level of their detail source transaction ChartField values. For example, while you might record source transactions to separate accounts for outside copy service and use another account for copier paper stock and supplies, for your budgets you would probably group transactions for both these accounts and track them at a summary level in an account called Office Supplies. To be included in budgetary control and tracking, the copy services and inhouse copy supplies accounts that you enter on transactions require translation to the budgetary Office Supplies account.

By translating source transactions to Commitment Control budgets, translation trees provide a convenient way to budget at a high level while using detail-level ChartFields in transactions. Using trees, you set up a hierarchy of ChartField values, such as accounts, with all of the budgetary-level values at the same level or even at more than one budgetary level, for example, if you have parent and child budgets that budget at different levels. When you set up budget definitions, you enter the tree name and appropriate budgetary level for each key ChartField. The Commitment Control Posting process can then determine which ChartField values are valid for budget journals, and how to roll source transaction ChartField values up to those budgetary ChartField values for budget checking against the appropriate budget.

You must have a tree for each ChartField that you use as a budget key and that you want to translate.

The budget processor references the version of the tree that has the greatest effective date that is before or equal to the budget definition's effective date that is used to process a particular transaction. The budget definition's effective date is based on the budget date that is specified on each source transaction line.

Accounts Tree Example

The following example illustrates how tree levels translate data.

Sample Translation Tree

The sample translation tree contains the following levels, beginning with the level 1 node:

• Level 1: Node 000000

• Level 2: 999901 and 682000

• Level 3: 999902−999907, 600010−600020, 610000, and 616200−621000

• Level 4: 614000−617000

When you define a control budget definition, you enter the tree level at which you want to define budgets for each key ChartField. Suppose that you want to budget at account ChartField level 3 for the sample translation tree. You enter tree level 3 for account on the Keys and Translations page. All account values found at level 3 and levels 2 and 1 above it are then valid for budget journals, and all source transaction account values below level 3 roll up for budget checking to the budgets that you define at that level. Budget Journal processing validates against the translation rules that you established in your budget definition in the tree to ensure that you selected the correct value for the budget account.

On the Control ChartField page, you can also choose whether to include all control ChartField values at your budgeting level or to exclude some. These are the results that depend on your choices:

• If you select the All Values option, then all control ChartField values at or above the tree level that you entered on the Keys and Translations page are valid for budgeting and budget-checking.

  Source transactions with any value for the control ChartField are budget checked.

• If you deselect the All Values check box, you must enter each value that you want to be valid for budgeting on the ChartField Values grid.

  Only source transactions with values that translate to the values in the list are budget checked.

For example, assume that you are budgeting at level 3. You deselect the All Values check box and enter the values 999901 and 610000 onto the ChartField Values grid. The following results occur:

• If a purchase order has the level-4 account 614000, then the Budget Processor translates the account to 610000 by using the tree and level information that you entered on the Keys and Translations page.

  The Budget Processor checks account 610000.

• If a second purchase order has the level-3 account 616200, the Budget Processor translates the account to itself.

  Because 616200 is not one of the level-3 accounts that you entered as valid for budget checking, the Budget Processor does not budget check this transaction.

Winter Trees and Spring Trees

Commitment Control can use either winter trees or spring trees to translate budget keys.

A winter tree uses the detail value table for nodes and has no leaves. That is, each node is a valid detail ChartField value. The previous section, Accounts Tree Example, shows a winter tree.

A spring tree is a hybrid between a node-only winter tree and a summer tree. A summer tree uses the PS_TREE_NODE table for nodes and a detail value table for leaves. A spring tree uses a detail value table for the nodes as well as the leaves:

Spring Tree

In this spring tree, the 4001 account is a budget-level node, whereas accounts 4002 - 4982 are detail-level leaves that roll up to the 4001 node. Note that you can define leaves in spring trees as ranges of detail values.

Spring trees reduce tree maintenance by allowing you to add ChartField values to the system without having to update trees, as long as new values are within a detail-value range already defined for the tree.

Whether you use spring or winter trees, each node must be a valid ChartField value. You must therefore assign the detail table name as the tree node table in the tree structure.

Using the Budget Date to Determine the Budget Period

The Budget Processor uses the budget date on a source transaction, with the budget period calendar defined for the Commitment Control budgets, to determine the budget period of the Commitment Control budget against which the transaction is to be processed.

The budget date is supplied automatically depending on the default budget date option that you select on the Installation Options - Commitment Control page, but you can also override it for some source transactions, depending on your Commitment Control security access.

Budgeting Without Budget Period Calendars

You do not need to use budget period calendars with all budget definitions. For example, you can define a project budget with no budget periods. If you do not specify the budget period calendar when you set up your budget definition, the system uses a blank budget period instead of performing a lookup against the budget period calendar. Use the Begin Date and End Date fields on the Control ChartField page or Budget Attributes component to define the time span of the budget.

Using Begin and End Dates with Budget Period Calendars

You can enter begin and end dates on the Control ChartField page and the Budget Attributes component to restrict budget journal entries to budget periods, for which the dates are at least partially within the specified spending range. Entering begin and end dates also restricts source transactions to those for which transaction dates fall within these dates. The setting of begin and end dates on the Control ChartField page establishes a higher-level default. You might want to use budget attributes to enter exceptions to the defaults by setting individual begin and end dates for detail budgets.

Cumulative Budgeting

You can set up your budgets to allow spending against the available balances in a defined range of budget periods when a transaction would otherwise exceed the balance in the current period.

For example, you budget check a transaction in the amount of 150 that affects budget period 20X1Q3. You set up cumulative budgeting such that the Budget Processor searches for available balances in all budget periods for 20X1. As the following table shows, the available balance for 20X1Q3 is 100 and is not enough to cover the transaction. However, the cumulative available balance for 20X1Q3 is 300. Therefore, the transaction passes budget checking. If you do not set up cumulative budgeting, the transaction fails.

In the following table, italicized values are derived calculations.

You can set up cumulative budgeting in two ways:

• You can use a budget period calendar as a cumulative calendar.

  Although you should define the cumulative calendar as a detail budget calendar rather than a summary budget calendar, the cumulative calendar must summarize the detail budget periods that are defined for the budget. Thus, each cumulative budget period defines the range of detail budget periods whose balances are available for spending.

  For example, your budget uses a monthly budget period calendar (calendar ID MN). The cumulative calendar that you assign is a budget period calendar that summarizes the monthly detail budget period calendar into quarters (calendar ID QR):

  Budget Periods for Calendar MN	Budget Periods for Calendar QR
  20X1M01 (01/01/X1 to 01/31/X1) 20X1M02 (02/01/X1 to 02/28/X1) 20X1M03 (03/01/X1 to 03/31/X1)	20X1Q1 (01/01/X1 to 03/31/X1)
  20X1M04 (04/01/X1 to 04/30/X1) 20X1M05 (05/01/X1 to 05/31/X1) 20X1M06 (06/01/X1 to 06/30/X1)	20X1Q2 (04/01/X1 to 06/30/X1)

  When you budget check a transaction whose budget date falls in budget period 20X1M05, the available balances from both periods 20X1M04 and 20X1M05 add up to the cumulative available balance.

  You can enable cumulative budgeting at the ruleset and assign cumulative calendars at the ruleset, control ChartField, and budget attributes levels.

  See Hierarchy of Control Budget Attributes.

• You can define a date range for cumulative budgeting by using begin and end dates instead of the cumulative calendar.

  Available balances for all of the budget periods included within the date range are then potentially available for spending. (That is, all current and prior budget periods within the date range are available for any given transaction.)

  In the following example, when you budget check a transaction whose budget date falls in budget period 20X1M02, the available balances from both periods 20X1M01 and 20X1M02 add up to the cumulative available balance.

  Budget Periods for Calendar MN	Date Range for Cumulative Budgeting
  20X1M01 (01/01/X1 to 01/31/X1) 20X1M02 (02/01/X1 to 02/28/X1) 20X1M03 (03/01/X1 to 03/31/X1)	01/01/X1 to 03/31/X1

You can select the date range option at the ruleset, control ChartField, and budget attributes levels. You specify the dates at the budget attributes or at budget journal entry.

Cumulative budgeting looks at all periods in the cumulative range to ensure that future transactions have not already spent current funds.

Entering Budget Journals and Budget Transfer Journals

Sharing a Control Budget Definition Across Business Units with Different ChartField SetIDs

Suppose that you have a budget definition for an organization with three business units (US001, US002, and FRA01) and three SetIDs (SHARE, NA000, and EU000):

In the example, one budget definition, with SetID SHARE and ledger group CC_ORG, is shared by all three business units of an organization.

The key ChartFields are the same for all three business units of the organization, but in the Ruleset Keys grid on the Ruleset ChartField page, each Ruleset established requires three rows: one for SetIDs SHARE and NA000, and one for EU000.

If the control ChartField is designated as DeptID, then the ChartField Values grid on the Control ChartField page requires two sets of data: one for SetID SHARE, to be shared by business units US001 and US002, and a second set of data for SetID EU000 to be used by business unit FRA01. If, instead, you designate the control ChartField as Account, you would need to have three sets of data in the ChartField Values grid, one for each of the three SetIDs.

You also perform the same setup in the Budget Entry Offsets and Source Transaction Offsets scroll areas on the Offsets page and the SetIDs for Excluded Account Types and SetIDs for Excluded Accounts scroll areas on the Excluded Accounts page.

Sharing a Control Budget Definition Across Business Units with Different SetIDs for Ledger Groups

If you have business units with different SetIDs for ledger groups, then you must define identical Commitment Control ledger groups for each SetID in order to share a control budget definition.

Suppose that business units US001, US002, and FRA01 are sharing SHARE for their Commitment Control SetID, but each uses its own SetID for GL ledger groups. For example, business unit US001 uses SHARE for GL ledger groups, US002 uses NA000, and FRA01 uses EU000. The business units can still share the control budget definition (because all three use SHARE for Commitment Control), as long as you define three different Commitment Control ledger groups, one for each, sharing the same ledger group name and template but having different SetIDs. They do not need to share the exact same ledgers—one ledger group can dispense with the pre-encumbrance ledger, for example, whereas the others include it. In the following example, the ledger group names are all the same, as are the budget, expense, encumbrance, and pre-encumbrance ledger names:

Setting Up Parents and Children

To create the parent-child relationship:

1. Include the ChartField values for the parents and the children on the same budget key translation trees.

   The ChartField values of the parent budget must be at a level that is the same as or higher than the child's to ensure that each child budget is translated to its parent budget.

2. Define the parent budget definition.

3. Define the child budget definition.

   When you indicate the parent budget definition on the Control Budget Options page, the system automatically copies the parent's control ChartField, control ChartField values, Ruleset ChartField, Ruleset ChartField values, and key ChartFields into the child budget definition. You can add more key ChartFields to the child, but it must contain all of the parent key ChartFields and trees. The translation levels for the key ChartFields in the child budget definition can be lower than that of the parent.

Automatic Generation of Parent Budget Level Activity from Child Budget and Budget Adjustment Journals

After you have set up your parent child budgets, Commitment Control provides the option for automatic generation of parent budget-level activity to streamline the entry, adjustment, and transfer functions for multilevel budgeting with complex budget hierarchies. When you use the parent budget automatic generation feature, the budgeting impact associated with child-level budget journal entries can be automatically reflected at all levels above the specified originating child budget entry level. This functionality can save a significant amount of time because budget maintenance can be done at the lowest child level and the system automatically handles the budget impacts associated with each of the higher parent budget levels. This is sometimes referred to as bottom-up budgeting.

See Generate Parent Budgets, Budget Adjustments, and Budget Transfers Automatically.

Setting Up Project Budgets with Funding Source Control

To set up project budgets with funding source control, you define your funding sources, set up associated expenditure and revenue budgets, and allocate the funding sources to each project. Use the following setup procedure:

1. Establish Commitment Control ledgers and ledger groups for a project expenditure budget definition and a project revenue budget definition in the Detail Ledger and Ledger Groups components.

2. Define funding sources on the Funding Source Definition page.

   You enter funding source amounts and adjustments on the Funding Source Transaction Logs grid, and also descriptive information about the funding source. The page calculates the total funding source amount by aggregating the amounts that you enter on the grid.

3. Define a project expenditure budget definition in the Budget Definitions component:

   • Select the Enable Funding Source check box on the Control Budget Options page.

     By entering the revenue ledger group that you created in step 1 in the Revenue Track field on the same page, and after saving the expenditure budget definition, the system automatically creates the related revenue budget definition with the same parameters as the expenditure budget, except for the Commitment Control option, which is Track w/o Budget, and the excluded account types, which you must define. You can also add a second key ChartField to the revenue budget definition to further refine your identification of revenue sources.

   • Do not assign a budget period calendar.

   • You must enter the valid project ID values on the Control ChartField page and select or deselect the Funding Source Required check box for each.

     This alerts the system about whether a project is funding source-controlled. You can also enter the budget begin and end dates for the project.

4. On the Funding Source Allocation page, enter the overall amount approved for the project and then allocate funding sources and amounts for each project ID that requires funding source tracking.

   Each row on the Funding Source Allocation Details grid must have a unique funding source, even if the spend option is different.

   You can specify this allocation as a percentage or priority method. For the percentage allocation method, you can define funding source amounts as a percentage of the overall spending amount for the project or as a flat spending cap amount. For the priority method, assign each funding source a unique nonzero priority number. The system still saves the allocation with a zero priority number, but the Budget Processor cannot use this allocation because a funding source error is in effect for such cases. You also define whether a funding source amount can be spent immediately (budgeted), upon revenue being recognized or upon revenue being collected. For the recognized and collected revenue spending options, you define the percentage of revenue that can apply toward your project expenditure budget, up to the spending cap. The same revenue cannot be assigned to different funding sources. If more than two revenue rows exist, the secondary key identified in the revenue budget definition can be used to distinguish the revenue amounts.

   The following example presents funding source allocations for a project. Italicized values represent system-calculated amounts:

   Project ID	Funding Source	Spend Option	Spending Cap	% of Revenue	% of Overall Amount
   PROJ23	NIH0014	Budgeted	5000	NA	25
   PROJ23	UNIV17	Recognized	10000	75	50
   PROJ23	PRAT01	Budgeted	5000	NA	25

   In this example, the total spending amount for project ID PROJ23 is 20000, although the available spending amount at any given moment depends on the amount of revenue recognized from funding source UNIV17. The project can use up to 75 percent of the recognized revenue from funding source UNIV17, up to the 10000 spending cap. Fifty percent of the overall expenditure budget for the project comes from funding source UNIV17, 25 percent from NIH0014, and 25 percent from PRAT01.

   You can allocate funding sources to as many projects and business units as you prefer. The system validates that you do not over allocate a funding source.

5. Enter budget journals for budgeted funding source allocation rows.

   The Commitment Control Posting Process (FS_BP) Application Engine process validates that the funding source allocation is already defined and that the sum of the budget journal amount for one funding source does not exceed the spending cap defined on the Funding Source Allocation page.

Multiyear Overlapping Budgets

Budget reference primarily enables unique identification of multiyear overlapping budgets with shared ChartFields. Typically, these are appropriations that are made every year but last a number of years. For example, your organization receives an appropriation each fiscal year. You can use these appropriations to fund spending for three years so that the appropriation granted in 2008 is eligible to fund spending from July 1, 2007 to June 30, 2010 (budget periods 2008, 2009, and 2010), and the 2009 appropriation can fund spending from July 1, 2008 to June 30, 2011 (budget periods 2009, 2010, and 2011), and so on:

If these appropriations budgets share the same ChartField combination, the system cannot distinguish the appropriations with overlapping budget periods unless a unique identifier exists for each appropriation. To report your spending by both fiscal year and appropriation grant, you must identify both the fiscal year and the appropriation for each spending transaction. In this example, each budget period represents a fiscal year, but you need a budget reference to identify each appropriation.

To set up the budget reference ChartField to distinguish multiyear overlapping budgets such as those in the preceding example:

1. Define budget reference ChartField values for each appropriation budget by using the Budget Reference page.

   You may want the budget reference to refer to the resolution that created the appropriation, or a time associated value. In this scenario, budget references RES2008, RES2009, and RES2010 are defined.

   See Budget Reference Page.

2. (Optional) Define a budget period calendar with periods by which you must report.

   In this example, budget periods that mimic fiscal years are set up, starting on July 1 and ending on June 30.

3. Set up a control budget definition that includes budget reference as a key ChartField.

   If your budget definition uses a budget period calendar, multiyear overlapping appropriations require cumulative budgeting. Do not select Derive Dates or assign a cumulative calendar on the Keys and Translations page. Instead, you should enter the begin and end dates for the multiyear appropriation when you enter the budget journal.

   If your budget definition does not use a budget period calendar, you can enter the date range for the appropriation at the control ChartField, at the budget attributes, or at budget journal entry.

   In this scenario, the budget definition is called CC_MY.

   See Budget Period Calendars and Cumulative Budgeting.

4. Enter and post a budget journal for the multiyear appropriation.

   Enter the budget reference just as you would any ChartField value. Enter the begin and end dates for the appropriation, and click Generate Budget Period Lines to generate journal lines for each budget period covered by the appropriation.

   Ledger Group	Acct	Fund	Bud Ref	Bud Period	Amnt	Begin Date	End Date
   CC_MY	50000	100	RES2008	2008	3000000	July 1, 2007	June 30, 2010
   CC_MY	50000	100	RES2008	2009	0	July 1, 2007	June 30, 2010
   CC_MY	50000	100	RES2008	2010	0	July 1, 2007	June 30, 2010

   You can enter either the entire amount of the budget on the first line and zero on the remaining lines, as in the preceding table, or an amount on each line.

   See Entering Budget Journals and Budget Transfer Journals.

Each time you create a source transaction for this appropriation budget definition, you enter the budget reference of the appropriation that you want to spend against, just as you would any ChartField value. As long as a sufficient cumulative available balance exists across all of the budget periods included in the appropriation, the transaction will pass. When it comes time to report on spending against the appropriation, you can easily identify all of the transactions that hit the appropriation in a budget period, fiscal year, or accounting period.

If you do not use a budget period calendar, then cumulative budgeting is not an issue. The Budget Processor treats the spending range of the budget as a single budget period.