Troubleshooting GL Issues

GL50 Out of Balance

GL50 reads GLAF as the driving file for this report. It reads the last period closed and adds Collector file (GLCF) records up to the report "as of" date to arrive at the account’s ending balance. If there are any XYZ accounts in GLCF that do NOT have a corresponding master file record in GLAF (which could be the case if it is a newly generated XYZ account code) then the GLCF records for that account will not be picked up. Debits will not equal Credits on GL50. To eliminate this as the reason (because you may not realize that this condition exists), you should run GL81-Preliminary. If that program finds a GLCF record without a corresponding record in GLAF then it will automatically set up the GLAF record. Then rerun GL50; the previously unreported XYZ account will be reported and chances are GL50 will be in balance.

GL70 – Diagnostic on GL Collector File

GL70 checks that DR = CR for all GL transactions in file GLCF. It does this check for each posting date. If everything is fine, then this program reports Total=0.00. But if DR<>CR for any day, the system that the imbalance occurred in and the date that it occurred on will be reported. The applicable register(s) for that date should be retrieved and the GL distribution reviewed (for example, if system IN reported an out of balance, then pull the IN44 registers for the date reported and use GL45 to confirm that all the GL distribution records actually exist GLCF. This would happen if a record is missing or has a bad/missing posting date. Pointforce needs to fix this problem because the user cannot post a one-sided journal entry. Before you start to close a fiscal period, GL70 should be run. GL81 will not close a fiscal period if there is an out of balance in GLCF for the period being closed.

GL81 says "Previous Period Out of Balance"

This prints at the end of GL81 if the Company Total of the Balance Forward column (which represents the last period closed) does not equal zero.
To diagnose manually, compare the Balance Forward on the GL81 report just printed to the Closing Balance on last month’s GL81 report looking for an account where they are not equal. That will identify the account with the problem and you can assess from there.
To diagnose electronically, run a pass to compare sum of (LYRBAL12 + all GLYH transactions for the account) to the BAL field for the last period closed. They should be equal. Note: This will only work if Retain History flag = Y.

GL81 "Weird" sequence of accounts

Check for key/data mismatch in GLCF, i.e. record rekeyed but GLACCT not changed.

GL81-Final (for any period) exited/aborted before completion.

Although it is OK to rerun a Preliminary GL81

Final cannot simply be rerun because updates to GLAF happen on the fly

Recovery is to reset the GL such that it thinks only the Preliminary for that period has been run

Check the SUUD:GL*FISCAL settings and set them to what they would look like after a Preliminary GL81. GL*FISCAL:11 (STATUS$) should = P and Current/Next Month fields should reflect period being closed.

Note: If GLCF has not changed, then you would be OK to re-run GL81-Final.

There are a few clues to determine how far GL81 got. As GL81-Final is running, it is updating the period end balance in GLAF and also updates field 44, Last Period Closed (LASPER). After the acceptance codes are entered, then the GLCF transaction records that were reported are moved to GLYH.

Check the first record in GLAF and see if field 44 has been updated (ie, set to the period you are closing). If not, then nothing has happened yet to GLAF. Rerun GL81-Final.
Check field 44 for the last account in GLAF to see if field 44 has been updated (ie, set to the period you are closing). If not, then GL81 died somewhere in the GLAF update phase of the program.
If field 44 has been updated for the last account in GLAF, then the program got past the GLAF update phase. This is where you would be if the user bailed out of the acceptance codes.
In either case, reset GLAF:44 to the last period closed (if the last period closed was 12, then set this field = 00) and clear GLAF:03, GLAF:04 and the GLAF:BAL field for the period being closed.
Also check if there are any records for the period being closed already in GLYH (just in case GL81 aborted after the acceptance routine). If Yes, then they need to be pulled back into GLCF.
When GL81-Final is run again, on the report column Balance Forward =Last period closed and column New Balance = Last period closed plus GLCF transactions.
Note: Resetting field 44 is critical; if it is not reset then when you rerun GL81-Final, Phase I will skip the GLAF update of those accounts. If GLCF has changed (maybe the user aborted, posted some journal entries and now wants to re-run the final), those new GLCF entries will be reported on the report, will move to GLYH but will NOT be included in the closed balance for the account in GLAF.
Note: If field 2 in SUUD.GL*81 = "*", you must clear that flag before more journal entries can be printed by GL31. You will get a message in GL31 "GL81-Final is in process" if that field has an "*" in it.

Caution 1: If there were any entries that were backdated into a closed period you do not need to pull them back into GLCF (you can not identify them in GLYH). The closed balance for the period that they belong to is already updated.

Caution 2: Transactions move from GLCF to GLYH if the Retain History Flag in GL01 = Y. If not set, then you could be missing records in GLYH. Total DR/CR should = zero in GLYH if all transactions were transferred.

Ran GL81 Final/Final run to completion for Period 12 and still have more year end entries

If there were transactions between the two finals then they would have been reported on the last printing of GL81. They have already rolled into the Period 12 balance in GLAF and will have already transferred to GLYH
GLAF:44 (LASPER$) will = 99. Pass the file and set it back to 12.
GL*FISCAL:12 (YREND$) will = YEAR END. Clear this field.
The user can post their closing entries in GL30 and when GL81-Final/Final is run again, Balance Forward=Period 12 before these entries and New Balance = Period 12 including these entries.

Ran GL81 Final/Final and aborted at A/C for Period 12 and still have more year end entries

These are the steps if there were transactions between the two finals:

If there were transactions between the two finals then they would have been reported on the last printing of GL81. They have already rolled into the Period 2 balance in GLAF but would not have transferred to GLYH yet. If you rerun GL81-Final again, then Period 12 balance will be updated again for those GLCF transactions; they will be overstated. You should complete the second Final from the point of A/C and then go to the recovery step above.
If field 2 in SUUD.GL*81 = "*", you must clear that flag before more journal entries can be entered.

These are the steps if there were NO transactions between the two finals:

If there were transactions between the two finals then they would have been reported on the last printing of GL81. Double check that there are none in GLCF. GLAF:44 (LASPER$) will = 99. Pass the file and set it back to 12.
GL*FISCAL:12 (YREND$) will = “”. (Note: If = YEAR END, then that means they did get past the A/C).
If field 2 in SUUD.GL*81 = "*", you must clear that flag before more journal entries can be entered.
The user can post their closing entries in GL30 and when GL81-Final/Final is run again, Balance Forward=Period 12 before these entries and New Balance = Period 12 including these entries.

Wrong Period End date in CC90 but field is Disabled

Period 02 Ending Date is set to Feb28 instead of Feb29.
If no business has been processed for Feb29 or beyond (meaning nothing got into Next Month in the sales stats), then you could examine the *FISCAL records (for AP, AR, GL, SA) and manually change Feb28 to Feb29 where applicable.
Also, the string of period end dates in 00MCMF record needs to be manually re-keyed to get the correct date to display in CC90.

GLCF has Record with No Date and GL81 was run

and re-adjusted all GLAF balances going forward

If this happened on a Preliminary GL81, the report will show all the period end balances going forward from Period 01 as adjusted but no real harm was done to GLAF. Fix the bad date in the GLCF record and rerun GL81-Preliminary.
If this happened on a Final GL81, the report will show all the period end balances going forward from Period 01 as adjusted (this is the clue to which account has a bad GLCF record) and the BAL fields would have been updated in the GLAF record. The user has to reconstruct each period end balance for that account by looking at prior GL81 reports and picking up the Ending Balance for each period. Then we need to set those period end balance fields in GLAF using UL3011.
A pass should be run afterward to check that the net of each period end balance (BAL1, BAL2, BAL3, etc) across all GL accounts = zero (ie, DR=CR for all closed periods).

Closed Fiscal Period but Period End Date in CC90 was Wrong

Likely are stuck with the bad period end date. As well as GL transactions getting posted to the wrong period by GL81-Final, customer invoices would have updated Current/Next Month sales stats based on the bad period end date.

Ran GL90 too soon

If you still have more entries to make, then you must go to backup to get them into the year just closed.
If you ran GL90 before you printed financials for the year just closed (but all transactions have been posted), then use Future Reporting to get the financials. You are currently sitting in period 01 of the new fiscal year. Generate Future GL files for period 12, run the financials and the balances for the year just closed will be reported in the "Last Year" column.

Transaction Postings showing up under wrong GL account on GL81

Check for key-data mis-match. Sometimes when we rekey a GLCF record we forget to change the value in GLCF(2).

Net Profit on Balance Sheet <> Income Statement

It could be that a new GL account has been added in GL01 but has not been included in the GL05 report parameters or there might be a problem with a formula line.
On the Income Statement, Net Profit/Loss is a formula line and is the bottom line on the report; it should represent the net of all Income & Expense accounts.
On the Balance Sheet it is typically a detail line that is calculated by specifying masked GL accounts such that all Income & Expense accounts would be included (ie, **4*** **5*** **6*** **7***).
If a new account was added in GL01 but not in GL05, then it is conceivable that it would be included automatically (because of masking) on the Balance Sheet but not on the Income Statement because it is not included in a detail line.
Have the user run GL06 to print a copy of the report parameters; this shows what GL accounts are being reported on each report detail line and how the subtotal/total lines are calculated. Next print a Trial Balance (make sure that GL50 is balanced and there are no XYZ accounts with balances because they would not likely be included in any report format). Then start checking that all Income & Expense accounts on the Trial Balance are represented on a report detail line on the Income Statement. Confirm how Net Profit/Loss is calculated. Then do the same for the Balance Sheet.
If they are running future financials, try re-running GL72 first. Erase the workfiles and regenerate the copied files for up to the desired future period. Then rerun the financials. Remember if anything changes in the live GL files it is not reflected in the copied files until you rerun GL72.
Note: Some users think that the Income Statement must be run first to obtain Net Profit/Loss which then gets passed to the Balance Sheet…that is not true. The reports are not linked