Processing Source Transactions Against Control Budgets

This chapter provides an overview of the budget checking of source transactions and discusses how to:

• Budget check third-party source transactions.

• Budget check Payroll source transactions.

• Optimize budget processor performance.

• Process transactions against expired and closed budgets.

Understanding the Budget Checking of Source Transactions

Commitment Control enables you to budget check transactions from a variety of Oracle's PeopleSoft Enterprise and third-party applications. This section lists those transactions and provides an overview of the functions performed by the PeopleSoft Budget Processor Application Engine process (FS_BP).

Source Transactions Subject to Budget Checking

You can create and budget check source transactions in Oracle's PeopleSoft Enterprise applications listed in this table if you have enabled Commitment Control for the applications in the Installation Options component. In most cases, you can budget check individual transactions when you create them or budget check multiple transactions in batch mode.

We discuss budget checking of third-party source transactions in this chapter. If you create source transactions in third-party applications, you must budget-check them after you interface them to PeopleSoft General Ledger.

We also discuss PeopleSoft Payroll transactions in this chapter. You run the budget processor for Payroll transactions after you send the transactions to General Ledger.

See Also

Budget Checking PeopleSoft Payroll Transactions

Setting Up Commitment Control Source Transaction Types

Budget Processor

The PeopleSoft Commitment Control Budget Processor application engine process (FS_BP) performs these tasks:

• Checks transactions against control budgets.

  • Updates revenue budget and issues a warning when debit transactions are processed if any associated expenditure budgets have negative spending .

  • Updates the expenditure control if there is sufficient spending authority available from the budget and any related tolerance or linked revenue budget.

• Creates an entry in the activity log table.

• Updates the Commitment Control Transaction Log table (KK_TRANS_LOG ) if you have enabled transaction log update for the source transaction type.

If the available budget amount is not sufficient or the transaction receives some other budget-related exception, the budget processor records error exceptions rather than update the control ledgers.

However, it updates the ledgers in some circumstances when the source transaction amount is over the available budget amount, for example if you have selected the Track w/ Budget or Track w/o Budget option for the control budget definition. It also updates the ledgers when the source transaction amount is over the available budget but within the tolerance percentage amount or if there are linked revenue budgets providing sufficient additional spending for the expenditure budget. In these and similar circumstances, the budget processor updates the control ledgers and issues a warning message.

You can override source transactions that produce error exceptions if you have the appropriate authority, in which case the budget processor updates the control ledger and issues a warning exception to notify you of the override.

Run Control IDs Used to Segregate Source Transactions and Products in Batch Budget Processing

Create a unique run control ID for each type of source transaction that is also unique for each PeopleSoft product that you want to budget check independently of other source transactions and products.

You can also choose to use the same run control ID for purchase orders, requisitions, and general ledger journals to processes all purchase orders, requisitions and, journals that exist at the time the run control ID is used to run the budget checking process in batch. For example, if you create a common run control ID of BPO1 for purchasing and general ledger, when you use BP01 to initiate budget checking of purchase orders, the budget processor not only budget checks all existing purchase orders but also budget check all existing journals.

Each source transaction type run control has its own separate criteria. For example, if run control BP01 is defined for purchase orders with the business unit US004 and a separate run control BP01 is defined for journals using the business unit US005, when you run the request from either general ledger or purchasing the system process first one, and then the other run control. The system does not apply one or the other set of criteria across different source transaction types.

However, if you create a different run control ID for purchase orders, requisitions, and journals, the different source transactions are processed independently of each other. For example, creating BPPO1 for purchase orders, BPRQ1 for requisitions, and BPGL1 for journals enables you to budget check these source transactions independently of one another. .

Restart or Rerun the Budget Processor

The Budget Processor (FS_BP) uses the PeopleSoft Application Engine built-in checkpoint and restart capabilities. If an abnormal termination or failure occurs on a step in the budget processor program, you can restart the request from the last successful checkpoint, or the step immediately preceding the step that failed.

When the problem is identified and corrected, you can restart the process from the process monitor.

Restarting the Budget Processor entails:

1. Access the Process Monitor - Process List page and select the Details link for the FS_BP process instance that failed

2. The Details link gives you access to the Process Details page where you select the Restart Request radio button in the Update Process section of the page.

3. Select OK and the process monitor re-queues the process and resumes processing after the last step in the process that issued a commit.

   Warning! Corrupt data could result from restarting a process that was already rerun. Deleting the failed request before rerunning is absolutely necessary.

If possible, restart the process; however, there might be situations where a restart is not feasible. Before rerunning Budget Processor you must reset the KK Process Status field in KK Source Header. Budget Processor locks the KK Source Headers by setting the KK Process Status field to 'I' indicating that document header is processing. This prevents other requests from processing the same document header. If budget process abnormally terminates, the KK process header may still be locked.

Use the Commitment Control Source Header Unlock page to unlock the KK Source Header for a failed request. (Commitment Control Review Budget Check Exceptions Source Header Unlock).

Marked	Select the data to cleanup by selecting this check box.
Unlock	Click this button after you've marked the data you want to cleanup.

The following data cleanup is performed:

• Updates the KK Source Header Process status from I to N.

• Unlocks the run control.

• Unlocks the reserved temporary tables.

• Deletes the State Records data.

• Deletes the data in the temporary table if necessary.

Warning! This user interface is designed to perform all the necessary cleanup in order to rerun the Budget Processor. However, cleanup is not performed on other processes that may invoke the Budget Processor (FS_BP). If Budget Processor is invoked from another process, manual cleanup may be required before rerunning Budget Processor.

Budget Processing Rules

The budget processor uses the rules that you define in budget definitions, rulesets, budget period status, budget attributes , and source transactions pages to determine whether to process a transaction and when to reject a transaction.

The budget processor follows this default and override hierarchy when applying rules. The rules default from the top down through the list and rules override from the bottom up through the list:

• Budget Definition

• Rule Set

• Budget Period Status

• Control ChartField

• Budget Attributes

• Source Transaction Definition

Note. Commitment Control provides many user definable rules that affect how the budget processor handles transactions.

See Understanding Basic Commitment Control Setup.

Balancing Rules

If you select the Entries Must Balance option for a control budget, the budget processor ensures that the Commitment Control activity log entries balance. The process generates offset entries for every source transaction, using the offset Account ChartField values that you specify on the Budget Definitions - Offset page (by source transaction type, with a default). The offset rows inherit all ChartFields flagged as balancing ChartFields on the Ledger Group - Balance page.

See Balancing Entries.

See Establishing Commitment Control Ledger Groups.

Budget Period Liquidation Option for the Successor Transaction

The BP Liquidation Option (budget period liquidation option) is set on the Commitment Control page of the Installation Options component. It determines whether the relief, or liquidation, of the related prior, or referenced, transaction by the current, or successor, transaction is created using the budget period of the referenced prior transaction or the budget period of the related current source transaction.

At installation you must choose one of two options for the BP Liquidation Option:

• If you select Current Document Budget period, you default liquidation to the budget period of the current document being processed.

  For example, the budget period used is that of the successor voucher liquidating the related prior purchase order.

• If you select Prior Document Budget period, you default liquidation to the budget period of the prior document.

  For example, the budget period used is that of the predecessor purchase order and not that of the successor voucher.

This is an installation option that is set at the implementation and it is not changed.

In the following examples budgets exist for 1000 USD in both the 2004 and 2005 budget periods. A requisition is created for 100 USD and is dated December 1, 2004. It is subsequently liquidated and a purchase order is issued for 125 USD on January 1, 2005.

The following example illustrates budget processor behavior using the Current Document Budget period option:

The following shows the summary impact to the remaining spending authority (RSA), or the available spending.

The net result is that the impact to the RSA is reflected in the prior budget period 2004 with the available budget is not impacted, or impacted only to the extent of the difference between the amount of the pre-encumbrance and the amount of the encumbrance in the current budget period 2005.

The second example illustrates budget processor behavior using the Prior Document Budget period option:

The following shows the summary impact to the remaining spending authority (RSA), or the available spending.

The net result is that the impact to the RSA is reflected in the current budget period with the available budget restored in the prior period.

A special scenario is applicable when the ruleset ChartField is changed between the predecessor and the successor document and the BP Liquidation Option is Current. The current budget period may not be correct for the relief entries. In such a case, the Budget Processor uses the predecessor ruleset ChartField to retrieve the ruleset as well as the budget period calendar attached to that ruleset. Based on budget date of the current document and the budget period calendar, a correct budget period is determined for the relief entries, which might be different from both the prior and current budget periods. This scenario is shown n the following example where the predecessor document is a purchase order (PO) of 5 lines, and the successors documents are PO vouchers POV1, POV2, POV3, POV4, and POV5.

The following table shows juxtaposes the budget period of the relief entry for each voucher when using either the budget period liquidation option of prior or current when the ruleset is the same and when the ruleset is changed from that of the predecessor document.

See Setting Budget Date, Reversal Date, and Budget Period Liquidation Options.

Budget Processing Source Transactions That Reference Previous Transactions

When the budget processor processes, a transaction (such as a voucher) that references a prior transaction (such as a purchase order), it can liquidate the referenced transaction either by item quantity or by monetary amount. You can specify the liquidation basis on the prior documents distribution line.

General rules that the budget processor follows when handling referenced transactions include:

• If a source transaction references a previous source transaction (for example a purchase order) that is for the same or a smaller amount, the process liquidates the amount for the previous transaction and updates the control budget with the new transaction amount.

  The process does not validate that sufficient funds exist since the transaction is not attempting to consume additional budgeted funds.

  For example, suppose you budget check a purchase order for 300 USD. When you budget check a 300 USD voucher linked to the purchase order, the process liquidates the original 300 USD encumbrance and updates the 300 USD actual expenditure amount. Because the budget amount is the same, it is not necessary to validate that sufficient funds exist in the budget. However, if the voucher were 350 USD, the process validates for sufficient funding because the transaction is attempting to consume an additional 50 USD.

• Transactions that reference previous transactions never receive budget exceptions for insufficient funds, as long as the transaction is not for a greater amount than its referenced transaction, even if the budget is in overdraft.

• If the control option for the budget is Control Initial Document only, transactions that reference previous transactions never receive error exceptions for insufficient funds, even if they exceed the previous transactions.

  See Setting Budget Date, Reversal Date, and Budget Period Liquidation Options.

  The budget processor issues a warning in such a situation.

• When the budget processor liquidates a referenced document, the liquidation amounts are recorded in the Commitment Control ledger in the fiscal year and accounting period of the current document and in the budget period that you determine by the value you select for the BP Liquidation Option field on the Installation Options — Commitment Control page.

See Setting Budget Date, Reversal Date, and Budget Period Liquidation Options.

The fields that the budget processor uses to identify referenced transactions are defined in the Source Transactions component.

Four fields on the line record for the source transaction affect budget processing:

• If the KK_CLOSE_FLAG is Y, the budget processor sets the open balance to zero on KK_LIQUIDATION for the transaction line being processed.

• If the KK_PROCESS_PRIOR value is N, the budget processor does not liquidate amounts associated with a referenced transaction. However, the budget processor keeps what is already liquidated for re-budget-checking documents associated with a referenced transaction and the KK_PROCESS_PRIOR value at the previous budget checking value of Y (referred to as cancel without restore).

• If the KK_CLOSE_PRIOR value is Y, the budget processor fully liquidates the open balance associated with the referenced transaction line.

• The LIQUIDATE_METHOD on the predecessor determines whether liquidation is by amount or quantity. Values are A for amount and Q for quantity.

See Adding Commitment Control Ledger Groups to a Business Unit.

See Setting Up Commitment Control Source Transaction Types.

Date Option for Previously Budget Checked Transactions

The Reversal Date Option is an installation option set on the Commitment Control page at implementation. The option determines how a rebudget check of a revised document that includes an accounting date change and possibly a change in amount is recorded in the activity log and ledger. It is not an option intended to determine the relief of prior documents that occur in the normal cycle of encumbrance and liquidation. This option does not impact the actual liquidation of a prior document which is always recorded with the fiscal year accounting period of the relieving document.

The budget processor reverses previously budget checked documents using either the Current Date or Prior Date option.

In the tables of examples below, a purchase order goes through several revisions, or incarnations, with the date being changed along the way.

When you use the Prior Date option, each time a document is rebudget checked its old entries are dropped by the system and are no longer visible in the activity log. They are replaced by the new entries generated by budget checking of the new documents.

However, if you select the Current Date option, an audit trail of all the activity is maintained in the activity log and the net change is reflected in the ledger.

The following two examples illustrate separately, for the current and prior date options, the log activity generated by the system for the assumed transactions.

In this first example you select the Current Date (current accounting date) option. The following tables cumulatively illustrate the log entries as the budget processor reverses previously budget checked documents and creates entries for each of the assumed changes and transactions:

Assume a new purchase order is created in the amount of 900 USD for account 640000 with an accounting date of December 15, 2002. Also, assume that the budget date equals the accounting date in the following examples.

Assume the purchase order is changed to 800 USD, the account is changed to 620000, and the new accounting date is January 15, 2003.

Assume the purchase order is changed to 400 USD, the account remains as 620000, and the new accounting date is March 15, 2003.

Assume the purchase order is changed back to 900 USD, the account to 640000, but the accounting date is changed to December 15, 2002.

Assume a voucher is created for the purchase order of 700 USD, for account 620000, and the accounting date is January 15, 2003.

The remaining purchase order amount is closed with the accounting date of March 15, 2003.

In the second example, assume that you select the Prior Date (prior accounting date) option. The budget processor then process the changes and creates log entries as in the following examples:

Assume a new purchase order is created in the amount of 900 USD for account 640000 with an accounting date of December 15, 2002. Italics indicates activity log entries that are deleted from the log (the net effect of the deleted items to the ledger is zero).

Assume the purchase order is changed to 800 USD, the account is changed to 620000, and the new accounting date is January 15, 2003.

Assume the purchase order is changed to 400 USD, the account remains as 620000, and the new accounting date is March 15, 2003.

Assume the purchase order is changed back to 900 USD, the account to 640000, but the accounting date is changed to December 15, 2002.

Assume a voucher is created for the purchase order of 700 USD, for account 620000, and the accounting date is January 15, 2003.

The remaining purchase order amount is closed with the accounting date of March 15, 2003.

See Setting Commitment Control Installation Options.

Budget Processing Source Transactions When Expenditure Budgets Are Associated With Revenue Budgets

If you have associated expenditure and revenue budgets, the budget processor checks the associated budget when the pre-encumbrance, encumbrance, or expense transaction is over the remaining available amount in the budget. In this case, the budget processor checks to see if there is enough revenue in associated revenue budgets to cover the transaction.

See Associated Expenditure and Revenue Budgets.

Revenue Reductions and Negative Remaining Spending Authority (RSA) for Associated Expenditure Budgets

RSA for an expenditure budget is typically calculated by subtracting the total of pre-encumbrances, encumbrances, and expenditures from the posted budget amount. Associated revenue budgets increase the available spending over the remaining spending authority (RSA) for linked expenditure budgets.

Budget processing of any source transaction, which reduces (debits) recognized, collected, or budgeted revenue that is linked to one or more expenditure budgets, results in the budget processor checking to determine if the combined total of the RSA for any related expenditure budgets, their tolerances and their associated revenue budget and associated recognized or collected revenue results in negative spending for any one of the related expenditure budgets.

If a negative RSA is found, a warning (W35 - Assoc Exp Budget Below Zero) is issued by the budget processor and the reduction in revenue is posted.

Note. There is no prior or future period RSA validation when cumulative budgeting is enabled for an associated expenditure budget definition.

If you are budget checking on line and have selected the Pop Up Error/Warning Message check box on the Installation Options – Commitment Control page, the W35 message is automatically displayed if the system detects a negative RSA, or negative spending authority condition. The warning is issued if any associated expenditure budget that is linked to the revenue that is impacted by the reduction has a negative spending condition.

Only reductions in linked revenue in the form of debits to revenue, such as the debit against revenue when a credit is issued to a receivable account, cause the budget processor to check associated expenditure budgets for negative spending authority.

Source transactions that actually reduce revenue (debits to revenue) are typically produced in PeopleSoft Billing, Receivables, and occasionally in General Ledger. However, any source transaction from any product that reduces (debits) revenue that is linked to an associated expenditure budget causes the budget processor to check for negative available spending for all associated expenditure budgets. If any linked expenditure budgets are in a negative spending condition, the processor issues the warning message (W35).

In addition, if further revenue reductions are processed, the warning continues to be issued for any associated expenditure budgets that have continuing negative spending even when not caused by the revenue reduction transaction then being processed.

For example, the system can continue to process sales refunds while there is negative available spending for linked expenditure budgets, but you must increase the expenditure budget, adjust tolerances, or increase revenue to successfully post additional encumbrances or expenditure transactions to the budget having negative spending authority. The warning continues to be issued until sufficient spending is provided for any linked expenditure budgets having a negative spending condition.

The warning message (W35 – Assoc Exp Budget Below Zero) directs you to open the commitment control exception page for your PeopleSoft product and using the Process Status value of Only Warnings Existing, you can find the applicable journal, invoice, or budget exceptions.

When budget checking is run in batch mode, the budget processor provides the number of warnings in addition to the number of lines in error and those that passed budget checking. These statistics are available to all the subsystems that support commitment control and batch mode budget checking.

Most PeopleSoft products provide a warning status for each transaction line. If available for your product, clicking the line status of W provides the revenue ledger group for which the transaction just processed has detected an expense budget row in the negative spending condition. You can use commitment control inquiries to identify the expenditure transactions and budgets needing attention.

See Reviewing and Correcting Journal Entries with Budget Checking Errors.

See Correcting Accounting Entries That Fail Budget Checking.

See Viewing Budget Checking Exceptions for Revenue Estimate Source Transactions.

See Viewing Direct Journal Exceptions.

The following examples illustrates various transaction when expenditure budget CC_ORG is linked to revenue budget CC_REV for budgeted and recognized revenue:

This example becomes much more complicated if you have multiple expenditure budgets associated with one or more revenue budgets or even if you have multiple revenue budgets associated with a single expenditure budget. The budget processor checks all the RSAs for expense budgets that are associated with the impacted revenue budget. This additional processing might cause performance degradation if you have zero based budgets that are associated with revenues and there are multiple associations between expenditures and revenues.

See Setting Up Associated Revenue and Expenditure Budgets.

Budget Processing With Cumulative Budgeting

If you have enabled cumulative budgeting for a source transaction's budget, budget processor checks all of the budget periods in the cumulative range to calculate the available budget amount for the transaction.

See Budget Period Calendars and Cumulative Budgeting.

Budget Processing With Funding Source Control

If you have enabled funding source control for a source transaction's control budget, the budget processor validates that:

• There are funding source allocations for the control budget related to the transaction.

• Any "budgeted" funding source allocation row has a corresponding budget amount entered in the Commitment Control ledger data table (LEDGER_KK).

  The budget processor performs a check for sufficient funds based on the allocations established for the budget. If the sum of the allocated amounts is less than the transaction amount, it fails budget checking.

See Project Costing and Control Budgets with Funding Source.

Budget Processing With Statistical Budgets

The budget processor follows the rules for statistical budgets when the Enable Statistical Budgeting check box is selected on the budget definition just as it does other types of budgets. It bypasses statistical budget checking entirely for source transactions that have no statistics code or statistical amount entered.

When the budget processor relieves budgetary commitments in the procure-to-pay document flow (liquidation), if the successor document has the same statistics code as that of its predecessor, the predecessor's statistical amount is liquidated, just as it is with monetary amount liquidation. However, if the successor does not have statistics code or has statistics code but is different from its predecessor's, the predecessor's statistical amount is not liquidated, because the system cannot determine the statistical amount to liquidate. In such cases, the successor document passes budget checking, but a warning exception W27 (No Stat Liquidate - Diff Code) is logged.

See Statistical Budgeting.

Budget Processing With Related Inter Unit Accounting Entries

If the source transaction has related inter unit accounting entries, the budget processor also checks the inter unit source transactions. If the inter unit transaction fails budget checking, the anchor source transaction also fails budget checking. This occurs when documents have a single header and lines for different business units; however, this is not the case for such things as general ledger journals that generate separate headers for each business unit involved.

Budget Processing for Closed Budgets

If the budget is closed, whether manually or through the Budget Close process (FSPYCLOS), the budget processor issues an error for any source transactions that are checked against that budget.

Budget Processing Deleted Source Transactions

If you run a process to delete the source transaction in an application , the budget processor reverses the old amounts posted to the control ledger and deletes all of the old transaction entries that are in the activity and transaction logs.

Budget Date

You can select one of two budget date default options on the Installation Options — Commitment Control page:

• Accounting Date Default: Select to default the budget date from the document accounting date.

• Predecessor Doc Date Default: Select to default the budget date from the predecessor document.

The budget date initially defaults, but a user with Budget Date override authority can change the date.

See Also

Defining Source Transaction Options

Understanding Exception Handling and Notification

Understanding Basic Commitment Control Setup

Budget-Checking Status

After you run the budget processor online or in batch mode, you can review the results.

Online Budget-Checking Transaction Results

If you run the process online from the Source Transaction page or the Commitment Control page, the Budget Header Status (also labeled Budget Checking Header Status or Budget Status) field is updated with one of these values as soon as the process completes, providing you with immediate feedback:

• Valid: The transaction passed budget checking with no errors or with only warnings. The process updates the control budget.

  If warnings are issued, the system provides a link to the exception page to view the warnings.

• Error: The transaction failed budget checking. The process does not update the control budget. The page also provides a link to the appropriate exceptions page for the transaction to review the exceptions and override them.

Budget Line Status

Budget Processor also updates the Budget Line Status field on the source line table.

• V (Valid Budget Check): The transaction line passed budget checking with no errors.

• W (Warning in Budget Check): The transaction line passed budget checking with warning(s).

• E (Error Budget Check): The transaction line failed budget checking.

• N (Not Budget Checked): The transaction line is not yet budget checked.

• B (Not Subject to Budget Check): The transaction line is not subject to budget checking.

Batch Budget-Checking Process Results

If you run the process in batch mode, you can review the results of the process in the Budget Checking Status component. The process status is one of these values when the process completes:

If the transactions have exceptions, you use the Transaction Exception component for the transaction type to review the exceptions, drill down to the source transactions, and with proper authority override the budget-checking errors.

Workflow Notification of Budget-Checking Results

You can set up workflow to notify you of budgets that have failed budget checking or received errors.

See Also

Managing Budget Exceptions

Budget Checking Third-Party Source Transactions

Commitment Control provides the Budget Check Request/Result IP (Integration Point) to budget check and report budget-checking results for third-party source transactions. After you interface third-party accounting entries to Commitment Control, you run the budget processor from the Request Budget Check page to check the transactions and to update the control budget. You can view or change the transactions on the Generic Transaction Entry page, both before and after running the budget processor.

This section discusses how to:

• View and adjust third-party source transactions.

• Use the Commitment Control page to handle budget checking.

• Run the budget processor for third-party source transactions.

See Also

Loading and Budget Checking Third-Party Transactions

Pages Used to Budget Check Third-Party Source Transactions

Viewing and Adjusting Third-Party Transactions

Access the Generic Transaction Entry page (Commitment Control, Third Party Transactions, Generic Transaction Entry).

Amount Type

Select a Commitment Control amount type. Important! If the transaction contains a line whose account value does not belong in the ledger represented by the amount type that you selected (such as a revenue transaction line when you have selected an amount type of Encumbrance), the budget processor does not process the line and does not update the Commitment Control ledger data table for the line.

See Common Elements Used in This PeopleBook.

Note. Use this page only to review and apply simple transaction updates that have been loaded through the Budget Check / Request Integration Point. This page provides minimal editing and data validation.

Using the Commitment Control Page

Access the Commitment Control page (Click the Budget Check Options button on the Generic Transaction Entry page).

See Also

Viewing and Handling Budget Transaction Exceptions

Viewing the Activity Log

Running the Budget Processor for Generic Transactions

Access the Budget Check Generic Transactions Entry page (Commitment Control, Third Party Transactions, Budget Check Generic Trans, Budget Check Generic Transactions Entry).

Budget Checking Payroll Transactions

This section provides an overview and discusses how to run the budget processor for PeopleSoft Payroll transactions that have been sent to PeopleSoft General Ledger.

Overview of PeopleSoft Payroll and Commitment Control

No budget checking process is available in PeopleSoft Payroll and HR. All budget checking must be done in Commitment Control.

The following is an overview of the integration of PeopleSoft HR, Payroll, Commitment Control and General Ledger. Please refer to the PeopleBooks for PeopleSoft Payroll and HR (human resources) for further information about setting up commitment accounting and the interface with General Ledger and Commitment Control. PeopleSoft Payroll and HR use the following SQRs to manage related general ledger and Commitment Control activities:

• BUD014.sqr is used to create Commitment Control budgets from PeopleSoft HR when commitment accounting is to be used.

• PAYGL01.sqr is used to send accounting transactions to general ledger from North America Payroll when there is to be no commitment accounting and data is limited to Fund, Department and Account ChartFields.

• PAYGL03.sqr is used to establish encumbrance data in HR and publish it to Commitment Control for budget checking (commitment accounting)—applicable to all ChartFields.

• PAYGL02.sqr is used to relieve the previously recorded encumbrances and book the expenditures to general ledger and Commitment Control—applicable to all ChartFields.

The BUD014.sqr process publishes HR department budget data to Commitment Control in the form of budget journals over the message COMMIT_CNTRL_BUDGET_UPDATE. The subscription process creates and automatically initiates the budget processor to post commitment control budget journals to LEDGER_KK.

The Payroll Accounting Transaction message (PAYROLL_ACCTG_TRANSACTION) carries HR transactions from its HR_ACCTG_LINE table. Message subscription PeopleCode is used to populate the HR_ACCTG_LINE table on the Financials database, and updates the HR_KK_HDR table as necessary for budget checking.

The Payroll Accounting Transaction message is sent from HR when you have completed the payroll and are ready to send the ChartField distribution (general ledger accounts) to the financials database using the general ledger interface, PAYGL01.sqr (for non commitment accounting) and PAYGL02.sqr (for commitment accounting).

The PAYGL03.sqr process prepares encumbrance data and send it to Commitment Control over the same Payroll Accounting Transaction message. Before you can post encumbrance data, calculate it using either the Fiscal Year Encumbrances process (PSPENANN) or the Nightly Encumbrances process (PSPENNHT) in HR. Use the Fiscal Year Encumbrances process to calculate encumbrances for the entire fiscal year. Use the Nightly Encumbrances process to update encumbrance data as you make changes to budgets or employees. After running each of these processes, run the Encumbrance GL Interface (PAYGL03.sqr) to post the results to general ledger, and then initiate Budget Processor from the Budget Check HR Payroll page.

The PAYGL02.sqr process prepares actuals transactions to be published to the general ledger over the Payroll Accounting Transaction message. This process also liquidates encumbered amounts to reflect that the actuals for that pay period have been processed. All processed transactions are reflected on the Department Budget Actuals page. After the subscription code populates the HR_ACCTG_LINE, you can run the Journal Generator process against the table to create journals. These journals are marked to bypass budget checking, because budget processor process the payroll transactions directly from the HR_ACCTG_LINE table. A second part of the subscription code populates HR_KK_HDR, which is necessary for running the Budget Processor against the payroll transactions from the Budget Check HR Payroll page.

See Also

Loading Budgets from PeopleSoft Human Resources

Budget Checking PeopleSoft Payroll Transactions

Viewing and Handling Budget Transaction Exceptions

Page Used to Budget Check Payroll Transactions

Running the Budget Processor for PeopleSoft Payroll Transactions

Access the Budget Check HR Payroll page (Commitment Control, Third Party Transactions, Budget Check HR Payroll, Budget Check HR Payroll).

Optimizing Budget Processor Performance

Before running budget processor, there are database properties that we recommend that your database administrator modify and indexes that you should create to improve budget processor performance. The database changes and indexes depend on the source transactions that you feed into budget processor.

This section discusses how to:

• Optimize performance for all source transactions.

• Optimize performance for PeopleSoft Cost Management transactions.

• Optimize performance for PeopleSoft Purchasing.

• Optimize performance for PeopleSoft Vouchers.

• Optimize performance for PeopleSoft General Ledger transactions.

See Also

Optimizing General Ledger Performance

Enterprise PeopleTools PeopleBooks: PeopleSoft Application Designer, "Building SQL Tables and Views," Administering Data, Creating Indexes

Optimizing Performance for All Source Transactions

To optimize budget processor performance for all applications that you have enabled to feed source transactions into budget processor:

1. (Oracle customers only) Set these optimizer parameters to true:

   • COMPLEX_VIEW_MERGING

   • PUSH_JOIN_PREDICATE

   • QUERY_REWRITE_ENABLED

2. (Oracle customers only) Change LARGE_POOL_SIZE to 50 M and SHARED_POOL_SIZE to 250 M.

3. Recompute statistics for these tables when the row count of these tables exceeds 3,000 rows. If the row count is less than 3,000, then delete statistics from the tables.

   1. PS_LEDGER_KK

   2. PS_KK_SOURCE_LN

4. Recompute statistics for the PS_KK_SOURCE_HDR table when the row count exceeds 10,000 rows.

   If the row count is less than 10,000 rows then delete statistics from the table.

5. Recompute statistics on the Product KK_SOURCE_HDR table if the row count exceeds 10,000 rows. . The table name can be found on the Source Transaction page in the KK Source Header Record field as depicted below.

   Note. If the row count is less than 10,000 rows, you can delete statistics from the table.

6. Delete statistics from PS_BP_CF_TAO.

7. Delete statistics from PS_BP_XCF_TAO, and PS_BP_XCF2_TAO.

8. Analyze SYS scheme tables (all system tables) to improve parsing time.

9. Add these indexes:

   Table	Index	Index Fields
   PS_GL_ACCOUNT_TBL	PSFGL_ACCOUNT_TBL	SETID, STATISTICS_ACCOUNT, EFF_STATUS, ACCOUNT_TYPE, ACCOUNT, EFFDT
   PSRECFIELD	PSGPSRECFIELD	RECNAME, SUBRECORD, FIELDNAME, FIELDNUM, CURCTLFIELDNAME, USEEDIT
   PSTREELEVEL	PSBTREELEVEL	SETID, TREE_NAME, TREE_LEVEL, EFFDT, TREE_LEVEL_NUM
   PSTREENODE	PSGTREENODE	(1) TREE_NODE, SETID, TREE_NAME, EFFDT, TREE_NODE_NUM (2) SETID, TREE_NAME, EFFDT, TREE_NODE_NUM, TREE_NODE_NUM_END
   PSTREELEAF	PSCTREELEAF	SETID, TREE_NAME, EFFDT, RANGE_FROM, RANGE_TO, TREE_NODE_NUM

10. Update statistics on these tables: PSTREELEVEL, PSTREENODE, PSTREELEAF.

See Also

Setting Up Commitment Control Source Transaction Types

Enterprise PeopleTools PeopleBooks: PeopleSoft Application Designer

Optimizing Performance for PeopleSoft Cost Management Transactions

Perform this procedure in addition to the performance optimization procedure described in the section, "Optimizing Performance for All Source Transactions."

To optimize budget processor performance for PeopleSoft Cost Management transactions:

1. Access Application Designer and remove the DISTINCT operator from the view text for CM_KK_HDR2VW.

2. Add these indexes:

   Table	Index	Index Fields
   PS_CM_ACCTG_GRP_D	PSCCM_ACCTG_GRP_D	CM_SOURCE_RECORD, TRANSACTION_GROUP
   PS_CM_ACCTG_LINE	PSBCM_ACCTG_LINE	TRANSACTION_GROUP, BUSINESS_UNIT, DT_TIMESTAMP, INV_ITEM_ID, SEQ_NBR, ACCOUNTING_DT, DISTRIB_TYPE, BUDGET_HDR_STATUS, BUDGET_DT, KK_AMOUNT_TYPE, KK_TRAN_OVER_DTTM, KK_TRAN_OVER_FLAG, KK_TRAN_OVER_OPRID
   PS_CM_ACCTG_LINE	PSACM_ACCTG_LINE	BUSINESS_UNIT, INV_ITEM_ID, DT_TIMESTAMP, SEQ_NBR, BUSINESS_UNIT_GL, LEDGER, LEDGER_GROUP, TRANSACTION_GROUP

3. Compute statistics for the table PS_CM_ACCTG_LINE.

Optimizing Performance for PeopleSoft Purchasing

In addition to the optimization procedure described in the section, "Optimizing Performance for All Source Transactions," add this index to support parallel running of the upgrade process for Purchasing:

Optimizing Performance for PeopleSoft Vouchers

In addition to the optimization procedure described in the section, "Optimizing Performance for All Source Transactions," add this index to support parallel run of the upgrade process for VOUCHER data conversion:

Optimizing Performance for PeopleSoft General Ledger Transactions

Follow this procedure to optimize budget processor performance for General Ledger transactions. Perform this procedure in addition to the performance optimization procedure described in the section, "Optimizing Performance for All Source Transactions."

Create this index:

Processing Transactions Against Expired and Closed Budgets

This section provides an overview of the United States federal government accounting requirement for processing source transactions related to expired budgets and discusses how to:

• Define current, expired, and closed budgets.

• Set up authorization to process against expired budgets.

• Use entry events to generate budgetary entries automatically for upward and downward adjustments.

• Set up entry events to process upward and downward adjustments.

Understanding Processing Against Closed Budgets and Expired Budgets With Upward or Downward Adjustments

The United States federal government requires varying accounting treatment for source transactions based on whether the associated budget, or appropriation, is current, expired, or closed. The budget is said to be expired after the current period, or period of availability, has passed. The expired budget remains open to recording, adjusting, and liquidating properly chargeable amounts until the expiration period has ended and the budget is closed (cancelled) based on the end date that you specify. All transaction activity subsequent to the expiration date should be driven by existing obligations recorded during the budget's period of availability. With some exception, no new commitments or obligations are allowed after the budget has expired.

When you choose to use budget expiration functionality, the system does not allow you to process activity against closed budgets, or budgets that exceed their end dates specified on the Expiration ChartField page. After the budget is closed (cancelled), the United States federal government allows payments to be processed against your current year budget if the payment does not exceed 1 percent of the new budget.

See Processing Transactions Against Expired and Closed Budgets.

This section also deals with setting up for processing and automatic generation of budget entries to US SGL accounts that reflect upward or downward adjustments to obligations that are properly chargeable against expired budget authority.

You do processing for expired funding for those transactions that were initially incurred while the related budget was current. Commitment Control provides an error message, which can be overridden, that informs you when you are attempting to process a transaction against expired funding, and the transaction reduces remaining spending authority. The system also determines if you are attempting to process a new obligation to an expired budget. Only approvers that you authorize have the ability to override the resulting error message and process transactions that are in addition to the original obligations incurred or to post the transaction to a new current year.

You receive an error message for expired funding if you are processing an upward adjustment—for example, the voucher is greater than the purchase order. This is because you are spending more than originally designated by the purchase order and this requires approval, or override.

You do not receive an error message if, for example, the vouchers are for the same amount (no adjustment) or less than (downward adjustment) the original purchase order. Downward adjustments denote that the funds set aside previously by a purchase order are not to be utilized and no error message is necessary.

Use Commitment Control budget override functionality to authorize a user to do an override of an upward adjustment error message and to continue processing.

Note. Upward and downward functionality is predicated on liquidation by amount only. If you choose to liquidate by quantity, the accounting results for downward adjustment transactions as specified by the U.S. Treasury are not created.

See Defining Expiration ChartFields.

Defining Current, Expired, and Closed Budgets

Use the Budget Definition - Control Budget Options page to select one of the ChartFields supported in Commitment Control as budget keys to identify the budget that you are controlling for current, expired, and closed status. Processing transactions against expired or closed budgets are predicated on these dates. Budget Period is not available for this purpose.

Use the Budget Definition - Expiration ChartField page to define the values for the Expiration ChartField and the begin date, expiration date, and the end date for an Expiration ChartField value.

See Defining Expiration ChartFields.

Setting Up Authorization to Process Against Expired Budgets

After defining Expiration ChartFields and expiration dates, if you attempt to post previously unrecorded obligations applicable to an expired budget you receive an error message. To override this error you must have security authorization.

Processing against expired budgets is a Budget Override security event. Use the existing functionality in PeopleSoft security to allow an authorized user to override an upward adjustment error and continue processing.

You can establish security for any ChartField that is defined as a key ChartField in the control budget definition. PeopleSoft recommends that you not change this unless you are configuring Commitment Control ChartFields.

See Setting Up Commitment Control Security Events.

Using Entry Events to Generate Accounting Entries Automatically for Upward and Downward Adjustments

Upward and downward adjustments primarily affect Purchasing and Payables.

In Purchasing, when purchase orders are budget checked, the system determines if the obligation is associated with an expired budget. If it is against an expired budget then entry event can be set up to generate upward or downward adjustments.

Accounts Payable is impacted by upward and downward adjustment in two important situations:

• When you create PO Vouchers (purchasing vouchers) that are for more or less than the original purchase order amount, it is considered an adjustment.

  Any upward change related to an expired budget is failed by the Commitment Control budget processor and must be overridden by an authorized user.

• Subsequent adjustments to prepaid PO Vouchers must be done through AP Journal Vouchers (accounts payable vouchers).

  When you create AP Journal Vouchers, care must be taken to select the correct entry event manually.

Commitment Control accumulates voucher activity against the purchase order. The accumulated activity is used by entry event to calculate upward and downward adjustment amounts.

Setting Up Entry Events to Process Upward and Downward Adjustments

The Commitment Control budget processor recognizes a budget as expired when the expired date is attained for that budget. Entry event uses this information to trigger creation of upward or downward adjustments derived from the difference between the accumulated voucher amounts and the applicable purchase order or orders for the expired budgets.

See Upward and Downward Adjustments.

See Using Entry Event Codes for Upward and Downward Adjustments.

Processing Payments Against Closed Budgets

To provide spending limits and to prevent improper payment against closed funding the United States federal government provides for payment of closed obligations against new current budgets to a limit of 1 percent of the new budget.

The Commitment Control budget processor recognizes a budget as closed when the end date is attained for that budget and rejects further payments.

To process payments associated with closed budgets you establish additional budgets as part of the new current year budgeting process for specific spending that is associated with closed-year obligations. For example, you are aware that a closed budget has unpaid obligations. As a part of the new budgeting for the current year you create an adjunct to the new current year budget, or a budget of 1 percent of the new budgeting total amount. Ninety-nine percent of the new budget is placed in its own budget and reserved for new obligations. The 1 percent budget is its own budget having its own budget keys. For example, it can be distinguished as Fund 100X within the overall current budget. Closed budget liquidations cannot exceed the 1 percent limit of current year funding.

These steps illustrate the use of 1 percent budgets and liquidations when you are using Expiration ChartField and dating functionality:

1. If you attempt to post a payment or liquidation against a closed budget (or closed funding), the system does not allow the transaction because the budget is closed and no funds are available to process the liquidation, or payment.

   To accommodate these payments you create a current year 1 percent budget after determining the necessary account, or budget and ChartField keys.

2. Creating the required budgets entails:

   1. Establishing a 1 percent budget covering obligations for budgets that are now closed and subject to the 1 percent rule of Public Law 101-510.

   2. Establishing a revised current year budget representing the normal current funds available for obligations and liquidations.

      This is typically established at a minimum value of 99 percent of the total funds available for the current year.

3. When processing liquidations subject to Public Law 101-510, record the expenditures against the 1 percent budget.

   Current budget processing validates that the user does not exceed the 1 percent budget. However, no new purchase orders or obligations should be allowed against the 1 percent budget. The account (budget) should only be used for liquidations against obligations established in the funding year where the budget is now closed.

   This example illustrates the process:

   • A single year appropriation ABC1996 expired on September 30, 1996.

     The funds were still available for processing liquidations against previously established purchase orders for a period of five years, ending on September 30, 2001. At that time, the appropriation was closed with an unliquidated balance of 100 USD that was cancelled.

   • In May 2002, you receive a 10 USD voucher against an existing purchase order associated with account ABC1996.

     You attempt to post the voucher against ABC1996 and receives a failure warning indicating that the budget is closed.

   • To post this voucher to current year account, the ChartField combination should be revised on the transaction to post against the current year 1 percent budget.

     This is accomplished by taking the current year Appropriation ABC2002 for a total of 5000 USD available and establishing two sub-budgets. One is the 1 percent of the current ABC2002 budget (50 USD) and the remainder of 4550 USD is recorded to a second budget.

   • You post any subsequent vouchers for the same purchase order against the 1 percent current year budget, which is subject to normal budget checks for funds availability within the 1 percent budget.

Checking Budget Journals and Transactions Without Posting

This section provides an overview of checking budget journals and transactions without posting and discusses how to:

• Enable budget check only.

• Run budget check only.

Understanding Budget Check Only (Budget Pre-Check)

Just as the Commitment Control Posting process (FS_BP) can be run to check and post budget journals and transactions to the control budget ledgers, it can also be run as a check only processing option referred to as, Budget Check Only.

When running a budget check only, 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 Ledger_KK, and other such records.

See Enabling Budget Pre-Check for Commitment Control.

See Entering and Posting Commitment Control Budget Journals.

See Processing Source Transactions Against Control Budgets.

A check only of budget entries is useful while you are in the work-in-progress stage of your budget development or implementing budget changes. Transactions can also be run through the Check Only process. However, budget status for a budget entry or transaction might only be valid for a short time if others have concurrent access to affect the budget and process transactions. For example, if two individuals do a budget check only on a transaction for 1000 USD and there is a budget of 1000 USD, both transactions will pass because there is no commitment or posting in the Check Only process that reserves the budget for either amount. Also, if another individual posts a commitment to the budget ledgers shortly after you have run the Check Only process, the results of your check only will no longer be valid. Check Only can be run online or in a batch process. Errors that might have been made can be resolved before you commit transactions or post your final budgets to the ledgers. If errors (exceptions) are encountered in the Check Only process, you may access the error through Commitment Control inquiries as errors are written to exception tables. After errors are resolved, you may run Check Only again, or, post to ledgers.

Note. The check only feature is specifically intended to check one document, but does not update the Commitment Control tables (ledger and activity log). For example, in PeopleSoft Purchasing, the purchase order is one document and the non-prorated charges are submitted as a separate document with a separate source transaction definition. So, the non-prorated charges and purchase order is submitted as separate (or first and second) requests to the BP. The second request is created by the system and not normally visible. Therefore when purchase order is checked, and passes, the funds are NOT reserved or committed in the ledger. When the non-prorated charges are budget checked, they pass as well even though when these docs would fail when processed together. This should not normally be an issue because the ChartField combinations used for the non-prorated charges should not be the same ChartFields used for the expenses.

Enabling Budget Check Only

Access the Commitment Control page (Set Up Financials/Supply Chain, Install, Installation Options, Commitment Control. By selecting a check box in the Enable Check Only Cmtmnt Ctrl section, you make the Budget Check Only feature available to any PeopleSoft Enterprise application.

Running Budget Check Only

Access the Budget Lines page (Commitment Control, Budget Journals, Enter Budget Journals) or (Commitment Control, Budget Journals, Enter Budget Transfer).

You can run Budget Check Only from the Process button on the Journal Lines or Budget Journal Line page in PeopleSoft Enterprise General Ledger and Commitment Control. You can run Check Only online using:

• Budget Journal Entry page (using the Check Only option).

• Regular Journal Entry page (using the Check Only option).

• Commitment Control Process (using Budget Journal Check Only).

• Commitment Control Process (using Document Check Only).

A successful Check Only budget entry will have a Budget Hdr Status of P to indicate a valid Budget Check Only. The value P is equivalent to N (not checked). Subsequently, after full processing, a successful budget check is indicated by the Budget Hdr Status V (valid), which indicates a successful budget check and posting to the Ledger_KK record.

A Check Only that results in errors being logged updates the Budget Hdr Status to E (errors) and the applications links an access to the exception table functions as with normal budget checking and posting. Lines with errors are updated to an E (error) status. Those that are valid remain with an N (not checked) status.

Note. If a budget transaction line is not subject to budget checking for any Commitment Control ledger groups assigned to the General Ledger business unit, the Budget processor sets the budget line status to B. If the budget transaction line is subject to budget checking, the budget line status has a V.