Budget Checking Related Issues

Issue Source: Atlas Helpdesk, Training/Workshops, BOM Units

Affected Parties: Country Offices, Headquarters

Categorization: Efficiency – Lack of System Capabilities

There are a large number of issues regarding budget checking and the budget checking batch process, described below.

1. Closed POs with Budget Exceptions that Cannot Be Overridden

Certain POs have exceptions that cannot be overridden. These are typically “No Budget Exists” exceptions when a budget does not exist for the ChartFields specified on the document. Once the PO is closed, ChartFields cannot be changed via the front-end application, thus requiring back end update. Generally, POs should not be allowed closed if they have a budget exception. The exception should be cleared first.

Additional patches from the vendor are intended to address this problem, although we cannot be certain that this will cover every case. These patches are in the process of being applied and tested. The PO should not be closed or cancelled if there is a budget exception. The exception should be cleared first.

As an interim solution a script has been developed to change the account on any closed PO distributions with a “no budget exists” exception to account 21020, which is excluded from budget checking. The script should be run periodically until a suitable alternative is available.

The impact of this issue is that encumbrance for closed and cancelled purchase orders may not be reversed even though it should be reversed. This can impact funds available for spending in Commitment Control, and can distort Commitment Control reporting. (Note that while no budget may exist, the transaction may have previously affected other budgets, hence the need for the budget checking to run successfully.)

Someone needs to be designated to own and actively manage budget checking of cancelled and closed POs. The update script should be run regularly after budget checking has completed as it will update accounts and reset status for those distributions with a “no budget exists” exception.

Users cannot budget check cancelled and closed purchase orders by themselves since the budget check icon is not available on the inquiry pages used to view closed transactions. Therefore, the budget check can only be done via the batch process. Currently, only one individual is managing this process, but only informally as time permits.

2. Close Flag Not Set Properly on Cancelled/Closed POs and Requisitions

An issue with the Reconciliation Workbench for POs and Requisitions results in POs and Requisitions that do not have the Commitment Control Close flag set properly.

SQL scripts have been developed to periodically set flags of Requisitions and Purchase Orders affected. The script sets the KK close flag on the distribution level and also resets budget statuses. This script should be run periodically until the problem is fully resolved.

Additional patches from PeopleSoft are intended to address problem. The impact of the problem is that Commitment Control not properly updated to reverse encumbrance (or pre-encumbrance), impacting available budget. This also distorts Commitment Control reporting. Someone needs to be designated to own and actively manage budget checking of cancelled and closed POs. The update script for both POs and Requisitions with the close flag not properly set should be run regularly before running budget check.

Users cannot budget check cancelled and closed purchase orders by themselves, since the budget check icon is not available on the inquiry pages used to view closed transactions. Therefore, the budget check can only be done via the batch process. Currently, only one individual is informally managing this issue on an interim basis, but only as time permits.

3. Problems with Budget Checking of Voucher Gains, Losses, and Closures

RSA (Rounding Suspense Account) accounting lines for vouchers applied to pre-paids have null, or blank, budget dates. This bug causes the budget check of voucher gains/losses/closures to fail. Budget checking must be scheduled for voucher gains/losses/closures as there is no equivalent online budget check. As a workaround, a script was written which updates the budget date with the accounting date. This script must be run prior to the run of the budget checking batch process for voucher gains, losses, and closures. Due to the manual script requirement, the budget checking is run manually and the scheduled process has been disabled. A scheduled process would simply error each time unless the script is run immediately prior.

This issue must be raised with PeopleSoft as patches have not been found to address the problem. The result of the problem is that Vouchers that have been closed are still reflected as an expense in Commitment Control, leading to unnecessary budget errors and distorting reporting. In addition, gains and losses on exchange rates would not be reflected in Commitment Control. Currently, only one individual is informally managing the budget check of AP accounting transactions, but only on an informal basis as time permits.

4. Override of Voucher Gain, Loss, and Closure exceptions

Budget checking of Accounts Payable Accounting activity (gains, losses, and closures) is set up to “Track w/o Budget”, so that tolerance issues do not present a problem. This will allow most transactions to pass budget check automatically, since the user no longer has any control over these transactions. However, occasionally there are exceptions flagged because of the end date of the project. These exceptions need to be overridden periodically so that they properly update Commitment Control. The volume here is very low. If the overrides are not done, Commitment Control will not be updated and the budget checking process will attempt to budget check the transaction every time it runs, eventually slowing down the process. Currently, there is no one formally handling this process.

5. Budget Checking Batch Process Instability

Since go-live, the budget checking batch process has been highly unstable and cannot be relied upon to run automatically. The process encounters numerous problems when running for sets of transactions and eventually fails. While the status of the process typically indicates Success, investigation into the message log shows the details of the failure. When the process fails, it rolls back most of the previous work it has completed. For this reason, most of the scheduled budget checking batch processes are disabled until they are stabilized. This primarily affects procure-to-pay budget check transactions, including Requisitions, Purchasing, Vouchers, and Voucher Accounting.

Unfortunately it has been very difficult to trace the exact details of the problem. Several cases with the vendor have been created and patches applied. It now appears that the latest GL patches from PepoleSoft might finally solve this problem. We have been able to run a full budget check for these modules in a test environment which includes these latest bundles.

6. Budget Checking Batch Performance

The batch processes for budget checking need to be reviewed for possible performance improvements at the database level. The amount of time it is taking to budget check larger numbers of transactions has been steadily increasing as the amount of data in the system has grown. While there process went through earlier tuning two years ago, additional improvements can likely be made, such as new indexes on larger tables. The poor performance partially contributes to the inability to schedule. Improved performance, along with along with resolution of the budget check batch process stability issues, will allow to budget checking processes to again be scheduled regularly and will cut down on the manual intervention required of users and the help desk.

7. Override of Tolerance Exceptions for Closed Purchase Orders

The budget checking process often flags closed purchased orders with budget exceptions if there is no budget available for the appropriate ChartFields. This occurs despite a closure inherently putting money back into available budget. A case was created earlier with PeopleSoft on this subject but they could not re-create the issue. Further investigation between UNDP and PeopleSoft/Oracle is required. In the interim, we override budget exceptions associated with cancelled and closed purchase orders. This is not straightforward process, however, and is generally not left to users to complete. Instead, over the past two years, selected individuals from OIST and the Management Support Centre have selective performed overrides. However, the individuals from OIST are no longer present (or have moved onto non-Atlas related initiatives), and there is a need for some responsibility to be taken for this issue going forward.

The risk of leaving these budget exceptions outstanding includes inaccurate figures in Commitment Control. Further, the exception will be repeatedly budget checked impacting performance, until cleared. Currently, there is no formal process in place to ensure this process is done regular. One individual is currently assisting with this process but only as time permits on an informal basis.