- Customer has a long fiscal year due to a change in their fiscal year
- The long year has 14 periods, all years prior and after have 12 periods
All ran great when the client depreciated period 13. It is when we get to period 14 that things seem to go haywire. When we run depreciate on period 14, it backs out the depreciation for period 13. Creates a complete reversal entry. The only items that depreciate properly are those items placed in service in periods 12, 13, and 14. Odd, right? Well, wait, it gets better...
I can replicate all of this in sample data on GP2015 (the client is on 2013, so wanted to be as close to that version as possible). So I started wondering what would happen if I backed out the period 14 depreciation. So I did that. Re-ran depreciation for period 13, and it backed out the incorrect entry. But then if I re-ran depreciation for period 14, it calculates correctly. What? Why? Simply backing it out and rerunning it appears to fix the problem. Not normal, right?
From what I can tell, it has to do with reset life and perhaps the back out process triggers a recalc of sorts. Because if I pre-emptively run reset life, period 14 will depreciate properly the first time around. I think there is some conflicting info out there about the need to run reset life if you are creating a long year, but you heard it hear first...always run reset life if you alter (even just lengthening) a year in fixed assets.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director 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.
No comments:
Post a Comment