Effects of Changes to Budget-Checked Transactions
Altering a transaction that has been through budget checking results in the deletion of all existing exception rows for the transaction. The Commitment Control Budget Processor process deletes the exception rows when the altered transaction is budget checked again. This includes the deletion of override marks for any budgets that appear on the altered transactions. A message to this effect appears when the budget is identified for override and you save the page.
Altering a transaction after it has been budget checked forces the Commitment Control Budget Processor process to treat the transaction as if it were new when budget checking is performed again. All previous exceptions are deleted, and any new ones are recorded as the transaction moves through the Commitment Control Budget Processor process.
Similarly, altering budgets can affect active transactions. The Commitment Control Budget Processor process reacts to the most current budget data. Consequently, if you alter your budgets and run a budget check, errors on active transactions can change.
Note:
If your transaction fails the Commitment Control Budget Processor process, you must override the budget information using the Budget Exceptions page. Otherwise budget changes can be made by increasing the budget by editing the budget entry.
To make changes to transactions that have been budget checked:
-
Open the source transactions and make the changes to specific transactions.
-
Save your changes.
-
Run the Commitment Control Budget Processor process again to check the budget.
The Commitment Control Budget Processor process removes the original commitment control journal and creates a new one with the changed transactions.
This table lists examples of transaction changes and their resulting effects:
| Transaction Change | Effect |
|---|---|
|
Change requisition quantities and requisition item prices. |
Changes final pre-encumbrance amount generated during budget checking. |
|
Change purchase order quantities and item prices. |
Changes final encumbrance amounts generated during budget checking. |
|
Modify ChartFields. |
Sets the budget status to Not Checked. Requires another run of the budget processor. |
|
Cancel, delete, or insert a requisition line. |
Sets budget-header status to Not Checked. Requires another run of the budget processor to release the pre-encumbrance. |
This table lists examples of budget changes and their resulting effects:
| Budget Change | Effect |
|---|---|
|
Change arrangement of budgets. Move a detail budget under a new summary budget. Technically, you would be changing the tree or the node level within the same tree that the system uses to translate the relationship between a detail budget and a summary budget. You may be moving a node to a new tree. |
If this change results in a transaction that is no longer controlled by the original budget, you must change all relevant transactions to reference the budget in its new location or to reference a new detail budget. |
|
Increase or decrease budget amounts. |
Generates different exceptions for all affected transactions. Increasing your budget decreases exceptions and decreases your budget increases exceptions. |
|
Adjust tolerances for a particular budget. |
Increasing tolerances generally enables more transactions to pass budget checking within tolerance. Decreasing tolerances generally enables fewer transactions to pass. Although this alteration does not change the total number of exceptions, it does change the proportion of errors and warnings generated for a particular transaction or budget. You receive more warnings and fewer errors. |
|
Alter the status of a budget. |
There are three possible statuses for budgets: Open, Hold, and Closed. If you change the status of a budget, that action affects all referencing transactions captured in the next budget check. |