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 Understanding Entering and Posting Commitment Control Budget Journals.

See Understanding the Budget Checking of Source Transactions.

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.