Scenario 1 - GLS.20XX and ENC.20XX do not match (and GLS.20xx is not zero)

If these two numbers do not match, determine where the difference is occurring (which PO(s) or BPO(s) are causing the imbalance). 

Find where the issue exists using either of these methods:

1. Run LGLA for the GL account in question

• On the LGLA screen, enter the appropriate year for Fiscal Year
• Select (E) for Encumbrances
• Enter the 11 digit GL Account in the Include GL Accounts field
• Click Save
• Select H (Hold) for Output Device, click Save, click Update
• When report is displayed, click Save As and then Download
• Click on the file and open with NotePad
• Click File / Save As...
• Open Excel and then open the file
• Choose Fixed Width Import
• Set the column widths according to detail on report
• Sort by PO/BPO column and then sub-total
• Find where there are difference between the credits and debits columns, those are the PO(s)/BPO(s) than need to be fixed

OR refer to new report (tbd) to identify the variances between the General Ledger and Encumbrance balances in Colleague

2. Once discrepancies are determined , create a GLIM file to post EP one-sided transactions; Debit or Credit as appropriate

3. Post the GLIM file(s); now the GLS.20XX and ENC.20XX numbers should match. 

Scenario 2 - If GLS.20XX is zero and ENC.20XX is not

This step is currently handled by IT - to update the ENC table so that it matches the GLS table If Blanket is closed then go to EDRC​

Scenario 3 - Encumbrance Transactions listed with subsidiary total equal zero

Either have the Business Office create a GLEE transaction for each (if it is a BPO definitely use this method)

OR

IT ? for Purchase Orders, run POEV, POEU, RPOE

• ​POEV - Enter the Fiscal Year 20XX in Ledger ID, enter PO #s (as ...P0XXXXX) either individually or using a Saved List - need to confirm SLED format for POs), Type 'Y' to Proceed with Verification.
• POEU - uses report from previous step - Type a 'Y' in Update Files and View Report
• RPOE - use 06/30/20XX date from same fiscal year​​, Type 'Y' to Correct Encumbrance Data

Scenario 4 - GL# Not Listed

Summary: The GL account verified is not found in the subsidiary record(s)

Details: For the subsidiary referenced, the GL# being reported is not found. This could be caused by a change to the existing number in an unexpected manner. Typically, if a line item's account number is changed, the associated encumbered amount is relieved from the original expense account and debited to the second.

Do not need to fix this error, will get adjusted with year-end close process.

If Business Office wants to fix it, create GLEE transaction.

Scenario 5 - Enc found in 20XX (next fiscal year)

Summary: Outstanding encumbrance and related relief cross fiscal years

Details: This condition usually occurs when the purchase order was created in the fiscal year being closed, then paid in the next fiscal year. The date paid would be the transaction date of the relieving transaction. When the current fiscal year is closed, the outstanding amount will be carried forward and when summed with the relief, the net result will be correct. This message is informational only and will not affect year-end processing.

Do not need to fix this error, will get adjusted with the year-end close process

If Business Office wants to fix it, create 2 GLEE transactions, one for each fiscal year (credit for current year and debit for next year)

Scenario 6 - Not on File

Summary: Subsidiary document cannot be found

Details: 'Not on File' indicates that the subsidiary document (requisition, purchase order, blanket purchase order, or recurring voucher) cannot be found. In both pages above, which appear to be affected similarly, the subsidiary document 'not on file' is a requisition, which means that from an end user perspective, you would not be able to find the requisition using Colleague forms such as REQM, RINQ. This is because Colleague cannot find a record in the REQUISITIONS file which contains a value of '0019696' in the field REQ.NO, typically indicating that the entire record is not found, possibly due to it being purged. In addition, when a requisition is purged, a reversing amount is posted to both GL.ACCTS and ENC depend on the transaction date entered.

Do not need to fix this error, will get adjusted with the year-end close process.

If Business Office wants to fix it, create 2 GLEE transactions, one for each fiscal year (credit for the current year and debit for next year).

Scenario 7 - Status not defined​

Summary: No status was found in the subsidiary document

Need IT to resolve missing status from the ENC table

Scenario 8 - Date Problem

Summary: ENC/Subsidiary transaction dates cross fiscal years.

Details: 'Date Problem' is a message as opposed to an error, which will not prevent you from closing the fiscal year. This indicates that either the encumbrance held in ENC does not have the correct transaction date according to the outstanding line item(s) contained in the purchase order, or that the outstanding encumbrance may have been adjusted with an encumbrance adjustment entry using GLEE, when according to the items in the purchase order, the encumbrance should have rolled forward from the prior year as opposed to being created in the current year. The way the report determines this is whether the prefix 'EOB - 'exists in front of the associated multivalued field, ENC.PO.VENDOR.

Resolution: No action needs to be taken concerning this message.

Scenario 9 - Undefined

Summary: Encumbrance activity has been found with no link back to the subsidiary.

Details: In this particular case, the document referenced is an invalid encumbrance adjustment, determined by the 'E' reference number (E000747). These adjustments have been found not to roll forward, and truly should be addressed prior to beginning your fiscal year-end close. Although they may not cause a stoppage in the year-end close, since they don't roll forward, you'll have problems reconciling your open balance of the new year with your closing balance of the previous year.

Resolution: Create a reversing encumbrance adjustment using GLEE containing a transaction date that falls in the fiscal year being closed. To offset the existing encumbrance, if the amount seen in ENC.YYYY is positive (+), then a CREDIT would be applied against it; if negative (-), a DEBIT would be applied. 

Once the encumbrance adjustment has been created and the resulting GL.POSTINGS record posted, the invalid entry will be offset, resolving the issue for the GL account in question.

Scenario 10 - Blank page for account

A page is presented with an account number but no message , amount or issue listed

Ellucian guidance pending; frozen accounts seem to be an issue

1.  Confirm all 11 months are closed in GLME
2. Run GPES and capture all EP Errors; send screenshots to IT/ Ellucian Support
3. Run YFBV and capture screenshot from VBS/VBSD showing any error messages; send to IT/Ellucian support