First, I want to preface this with the statement to PROCEED WITH CAUTION. I just thought the lessons learned in the post below might benefit someone. But, as with anything, please test, test, test, and test some more if you follow this rabbit trail as well :)
It's not the most common thing, but we do sometimes get requests to adjust or update balances in a historical year (beyond the most recent year). When we do, it is usually do to one of two scenarios (let's assume in this scenario that the current year is 2014, and we just closed 2013).
1. During 2013, something was posted to 2012 on accident. 2013 is closed as normal, and the 2012 posting is uncovered during audit or CPA review.
2. An additional aspect of the company is being brought in to GP, in to an existing GP company and there is a desire to migrate more than one year of history.
In some ways, the migration is fairly straightforward. It seems logical that you would have to, in this scenario...
1. Update the GL history table with the actual transactions (GL30000) for 2012
2. Update the GL history table with the BBF transactions for 2013 (for the balance brought forward)
But, here is the clincher...you also have to create BBFs for 2014 in the GL20000 (GL YTD Open). Since the BBFs for 2014 were already created at the time of the close, they are not updated (even with reconcile) for the open year. So there is a ripple effect for however many years you go back in time. And, keep in mind that the reconcile process will NOT place transactions in to the GL30000 or GL20000, it will only update the balances in the account summary tables (GL10110, GL10111).
This may help you, or maybe it will convince you to never ever ever mess with the GL history tables (which is probably a very good idea).
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
2 comments:
Next time email me. I have a process for this that doesn't require SQL (I have a SQL process too) and is extremely consistent. I don't share it openly because it's too easy to break GP .
Mark
Awesome Mark, I definitely will!
Post a Comment