Budget Control Establishment Strategies

When setting up custom controls there are several points to remember in addition to those mentioned in the previous discussions of the configuration pages:

Insert constraints on Budget Level Control for the lowest required budget level of a structure that should control spending and not upper levels as those levels will only issue duplicate errors. This guidance assumes you have guidelines in place to prevent more budget authority to be given at lower levels than at the parent upper levels.
Do not place parent to child amount guidelines on the lowest budget level as there is no level below that one for the system to accurately calculate the guideline so that the system will always issue the guideline error.
Ensure that control ID #13, #14 or #29 is inserted on Budget Level Controls for the each level in a reimbursement budget structure with a default violation of Reject with none of the Allow flags checked. This control ID on Budget Level Controls should be the same one that is the Application Parameter for Reimbursement Budget Availability (REIM_BUD_AVAIL).
Give security access to the Load Constrains action in a very restricted fashion for better budget control.
Where possible, build with calculated amounts instead of stand alone amounts for performance reasons.
Do not change delivered controls unless you will track the change and reapply with an upgrade, or when upgrading you will not be taking delivered controls. The recommended approach is to copy the constraint you want to change and create a new one with an ID that is four-digits.
Do not include the same budget amount twice within a side or in the left and right sides simultaneously, unless intended. This may sound simplistic if only stand alone amounts are used, but calculated amounts may cause this mistake if the full calculation formula is not evaluated.
Avoid recursive formulas where the application will get caught in a loop trying to calculate a control. This problem can occur within the LHS or RHS definitions or be inherited from faulty Budget Formula setup. To create an example, the following letters were used to denote budget amount fields. The following example shows a recursive problem as A has to be calculated from an amount (F) that already includes A.

LHS: A (calculated amount)

Operator: >=

RHS: 0

Formula for A = B (calculated amount) - C - D - E (C, D, & E are stand alone)

Formula for B = F (calculated Amount) - G

Formula for F = A + H

When determining the settings for the Include Pending Increases and Decreases flags on Budget Tracking Amount, remember that most transactions perform a liquidation of another. If the pending increases for the referencing transaction and not the pending decreases for the referenced transaction are checked, a budget error could be issued in the situation where the liquidation is needed to cover the liquidating entry.

More InfoMore Info

Budget Control Severity of WARNING
Transaction Control Submit Phase of FINAL
Workflow Rule	Pending Included	Over Pending Phase	Validate	Submit	Final Approval
n/a	Yes	n/a	Warning	Final with Warning	n/a
n/a	No	n/a	Warning	Final with Warning	n/a
Transaction Control Submit Phase of PENDING
Workflow Rule	Pending Included	Over Pending Phase	Validate	Submit	Final Approval
Met	Yes	n/a	Warning	Pending with Warning	Final with Warning
Met	No	n/a	No Warning	Pending with Warning	Final with Warning
Not Met	Yes	n/a	Warning	Final with Warning	n/a
Not Met	No	n/a	No Warning	Final with Warning	n/a
Budget Control Severity of REQUIRE OVERRIDE
Transaction Control Submit Phase of FINAL
Workflow Rule	Pending Included	Over Pending Phase	Validate	Submit	Final Approval
n/a	Yes	n/a	Overrideable Error	Final with Warning	n/a
n/a	No	n/a	Overrideable Error	Final with Warning	n/a

Transaction Control Submit Phase of PENDING
Workflow Rule	Pending Included	Over Pending Phase	Validate	Submit¹	Final Approval
Met	Yes	Required Before	Overrideable Error	Pending with Warning¹	Final with Warning
Met	No	Required Before	No Error	Pending with No Errors	Rejects²
Not Met	Yes	Required Before	Overrideable Error	Final with Warning¹	n/a
Not Met	No	Required Before	No Error	Final with Warning3	n/a
Met	Yes	Allowed Only After	Overrideable	Pending with Warning⁴	Final with Warning
Met	No	Allowed Only After	No Error	Pending with No Errors	Rejects⁵
Not Met	Yes	Allowed Only After	Overrideable Error	Fails⁶	n/a
Not Met	No	Allowed Only After	No Error	Fails⁶	n/a
Budget Control Severity of REJECT
Transaction Control Submit Phase of FINAL
Workflow Rule	Pending Included	Over Pending Phase	Validate	Submit	Final Approval
n/a	Yes	n/a	Reject Error	Reject Error	n/a
n/a	No	n/a	Reject Error	Reject Error	n/a
Transaction Control Submit Phase of PENDING
Workflow Rule	Pending Included	Over Pending Phase	Validate	Submit	Final Approval
Met	Yes	n/a	Reject Error	Reject Error
Met	No	n/a	No Error	Reject Error
Not Met	Yes	n/a	Reject Error	Reject Error	n/a
Not Met	No	n/a	No Error	Reject Error	n/a

Note 1: Overrides were applied when issued after the validate action before the first submit.

Note 2: Upon final approval, an overrideable error will be issued and the transaction rejects back to draft as this is the first time the transaction has updated an accepted budget amount instead of a pending amount. Overrides can be applied and the transaction sent back into workflow, but it will continue to reject until there is budget authority sufficient for the transaction to accept or the Violation Action is relaxed for that budget control on that budget line. Another alternative is to have a user with security rights to use the Bypass Approvals action on the transaction to force the transaction to final.

Note 3: Overrides were applied before the second submit action when not issued from validate but from first submit.

Note 4: Overrides were applied after reaching pending status but before final approval.

Note 5: Upon final approval, an overrideable error will be issued and the transaction rejects back to draft as this is the first time the transaction has updated an accepted budget amount instead of a pending amount. Overrides cannot be applied given the setting of Allow only after reaching. The error goes away upon the next validate or submit, but will continue to return upon final approval until there is budget authority sufficient for the transaction to accept or the Violation Action is relaxed for that budget control on that budget line.

Note 6: Overrides cannot be applied given the setting of Allow only after reaching. Thus a submit to final is not possible and the transaction remains with the overrideable error. Such a combination should not exist where workflow rule(s) established for a transaction’s code will not always be met, the choice of Allowed before or after reaching option should be selected.