Year End Close Issue with AA – Workaround

Hi all

Recently, I was working on the year end for one of our clients and landed up in the error shown below during the YEC process for the General Ledger.

image

Based on the error message, I believed it was some issue in GP’s Year End Process. But on analysis, I found out some interesting information, which gave me some insight on how the year end process works when Analytical Accounting is installed and configured to include dimension codes during the year end process.

As you all know, during the YEC process, GP creates a journal entry for rolling forward the balance sheet account balances and to bring forward the retained earnings account balances (based on P & L balances) into the subsequent year. And Analytical Accounting process is triggered after the standard GP’s YEC process to create the relevant AA records in the AAG30000 series of  tables for the BBF(Balance Brought Forward) journal entry. It also moves the open year records from the 30000 series of tables in AA to the 40000 series of tables.

But in certain cases, we could have a GL account in GP which has a zero balance at the account number level, but they could have balances at dimension code level. E.g. An account 000-2300-00 could have a zero balance at the account level (from GP’s Summary Inquiry window), but they could have a debit balance of $1000 with a dimension code AAAAA and a credit balance of $10000 with a dimension code BBBBB. In such cases, even though GP’s BBF entry does not have a brought forward entry does not have a distribution line for this account (since account balance is zero), Analytical Accounting module appends an additional line into the BBF journal entry with both the debit amount and credit amount as zero. And in the AA tables, it inserts the appropriate balances brought forward at the appropriate dimension code level.

So consider this scenario: If there are 10 GL accounts in a company out of which only one GL account has a balance to be rolled forward. 5 accounts have zero balance at account level, and zero balance at dimension code level. 4 accounts have zero balance at the account level, but have a balance at dimension code level. In this scenario, GP would automatically create the BBF journal entry with one distribution line bring forward the balance of the 1 account which had a balance to roll forward. However, for the other 4 accounts with zero balance at account level and a balance at dimension code level, Analytical Accounting module tries to identify the journal entry number created for GP during the year end process, and appends 4 additional lines for these accounts with both credit and debit as zero to the specific BBF journal entry, and updates the AA tables with the relevant dimension code balances for all the 5 GL accounts rolled forward.

Further, in the same example above, if all 10 GL accounts had a zero balance at the account level, but had a balance at the dimension code level, GP does not create the standard BBF entry at all… In this case, the Analytical Accounting module tries to identify the journal entry number created by GP for the BBF and it identifies a NULL value (since there was no journal entry created by GP). But  Analytical Accounting still append lines for these accounts with a zero balance at account level, but a balance at the dimension code level, to the BBF journal journal entry (with a NULL value). Thus the above error surfaces. Ideally, Analytical Accounting module has to create the BBF journal entry from scratch, but instead, it looks for a journal entry already created by GP and tries to append additional lines to a journal entry which does not exist, which causes this issue.

I had to figure this out after digging into the YEC procedures in GP and Analytical Accounting. The SQL procedure which is causing the issue here is aagYearEndCloseMain. A ticket has been logged with Microsoft on this who has assigned it to the development team to have it fixed in the subsequent service pack/hotfix.

However, since we had to close the year in the interim and could not wait for a response from Microsoft. So this is what I had performed as an interim workaround to close the year without the above issue. I identified 2 balance sheet accounts (could be any BS account) and created a reversing journal entry in the specific company with a transaction date as 12/31/2009 and a reversing date as 01/01/2010. I debited one balance sheet account to $0.01 and credited the other balance sheet account to $0.01. Once I posted this entry, the YEC process identifies a balance of $0.01 in both these balance sheet accounts to be rolled forward and GP creates a journal entry during the YEC process, which will facilitate the AA procedure to successfully append the additional lines for the accounts which have zero balance at the account level, but a balance at the dimension code level. Also since we posted the entry as a reversing entry, the $0.01 balance which was rolled forward during the YEC process, into the 2 balance sheet accounts, would be cleared on 01/01/2010.

Trust me, this idea struck my mind, as I was having my breakfast listening to music… And for the fact that I was breaking my head for the last few days on identifying an interim solution for the same, it is quite amazing that i found a solution when relaxing… . :) Following the path of Archimedes/Newton, though I am not one definitely… :)

So this article gives a work around solution for many who use AA and are looking for their YEC process and have the same scenario. Apart from the work around, it also gives you all a little tip that whenever you are stressed at work, trying to figure out a solution, go have a break and I am sure your would get easy and fast solutions to issues which would have haunted you for a long time…

Note: This issue has been resolved in GP v10 Service Pack 5.

Until next post!!!

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

June 8, 2010 · veeyeskay · 3 Comments
Tags: , , , , , ,  Â· Posted in: Analytical Accounting, General Ledger, Great Plains Total Views: 954