Understanding the Budget Checking of Source Transactions

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 > Reset KK Source Status.

This example illustrates the fields and controls on the Commitment Control Source Header Unlock page. You can find definitions for the fields and controls later on this page.

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.

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

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

See Installation Options - Commitment Control Page.

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 Installation Options - Commitment Control Page.

  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 Installation Options - Commitment Control Page.

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 Understanding Source Transaction Type Setup.

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:

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:

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.

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 Revenue Estimate Exceptions Page.

See Miscellaneous Payment Exceptions Page.

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.

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