Monday, October 5, 2015

Oddities- Missing Project Accounting Accounts

So we all know (or are constantly reminded) that the simplest answer is usually correct.  So when a client recently called to report that their project accounting accounts were missing (PA43001), we immediately started brainstorming "simple" explanations...

1. Maybe they aren't really "gone" (no, they really are gone)
2. Maybe somebody removed them (but how, I mean it's just the COGS accounts and they are simply gone)
3. Maybe someone working on another support case inadvertently removed them (not likely, as they were there at 2pm and gone at 4pm, and no cases were being worked in that time)

To be noted, the client is on GP2013 R2/YE 2014 (12.00.1801).

My coworkers sometimes give me a hard time because the last thing I tend to consider is an actual bug in the software.  The reason I avoid this explanation is that it is too easy, and often is not the case. And particularly when data just disappears with no other process/issue/explanation, it doesn't seem likely that the software just decided to dump the data without provocation.  So I like to make sure we exhaust other routes.  So we went about fixing the issue in this case, restoring the accounts, but it was still bothersome that we could offer no explanation as to why it happened (again, racking my brain on a simple answer).

So we start a case, and found out that this is indeed a quality report (#9120 to be exact).  An apparent bug in GP, that several clients have reported but Microsoft has been unable to replicate.  Odd. Very odd.  The good news being two-fold- first, of clients who have reported it, no one has had a second instance of it.  And second, Microsoft GP support has a script you can run to create a shadow table that will track the project posting accounts table so you can monitor if something were to recur.

What's the lesson in this?  The simplest explanation may just be that it is indeed a software bug.  I guess that's it?

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.

5 comments:

Beat BUCHER said...

Hi Christina,
Thanks for posting this (as a confirmation) ... other users seems to have run into same issue :
https://community.dynamics.com/gp/f/32/t/177530

Will try to find out a little more about a quick work-around on this.
Have a great time,
Beat

Unknown said...

Any chance they ran file maintenance before this issue appeared? I’ve seen this on a couple of sites and it was directly linked to the PAChecklinks for PA Budgeting Cards and PA Accounts Setup, so we exclude those options from maintenance unless there’s an issue that requires it. If there is an issue that needs those options in Checklinks, we backed up the accounts table and DTS’d it back in after maintenance (only had to do that once)– it’s been forever since I worked this through, but I am pretty sure that it had to do specifically with NONE account sources…

Unknown said...

To be clear for end users - the DTS solution was definitely a pre-planned exception to the rule. That is not recommended unless you are very familiar with the tables and data and have someone who can do a detailed review when you're finished and before you let anyone back into GP.

Christina Phillips said...

A few notes. One, they did not run PA checklinks beforehand. They literally were just entering transactions and noticed when they started back after a meeting (e.g, 4pm) that they were gone. And it did not impact the NONE series, it impacted those with a Specific source in this case.

Unknown said...

I was able to find my notes and the issue I was fighting was related to the Specific source, as well; however in my case, it was definitively after running pachecklinks and showed on the report consistently. Thanks for the version information - will keep an eye out!