Why Care? A Case for Really Understanding Your Account Framework

It seems like most of us have had a time in our careers as consultants where we did it all.  We installed the software, configured and trained, migrated data, and even did an upgrade or two.  Over the years, my job has evolved where now I spend a lot more time working with a team.  I don't remember the last upgrade I did (maybe three or four years ago?), other than on my own machine.  And I don't recall the last new install I did. 




So it occurs to me that as we bring people in to consulting, the "do everything" approach is not really used much anymore from what I can tell.  Due to the increasing technical complexities of installing and supporting systems, and larger partner organizations, we tend to see people fall in to one or two of three primary categories- functional, technical, developer.  And for this reason, there is sometime a disconnect between things that each group should know and understand. 




Many years ago, I made the case for waiting to install the software until after we had completed our discovery.  It was common practice to schedule installation as soon as we had registration keys, which sometimes meant even before we had formally kicked off the project.  Why is this an issue?  Account Framework.  This thing that isn't an issue very often, but when it is-- it is a significant issue that can lead a customer to say "Why didn't you anticipate this?".  Which, by the way, is something project managers don't want to be asked.




I want to make a case that everyone on your team, and clients/users as well, needs to understand the significance of the Account Framework.  In many ways, it is the most critical decision (or lack of making a decision) encountered during the installation process.  Handled poorly, it can cost you money, time, and project goodwill.  At a high level, the Account Framework is comprised of three components- maximum number of segments, maximum number of characters for the entire account string, and individual maximum characters for each individual segment.




The Account Framework is defined during the creation of the Dynamics GP system database.  It is defined at this stage because it impacts the fields and sorting available for the chart of accounts in ALL COMPANY DATABASES.  Did you catch that?  ALL COMPANY DATABASES.  Now, let's contrast with the Account Format.  The Account Format is defined during the actual configuration (logging in and setting up) in each company.  The key here is that the Account Format can be different in each company, but all companies' Account Formats must be able to individually fit within the overall Account Framework?




Huh?




Well, let's take the standard example of 66 characters and 10 segments.  This is the largest possible Account Framework in Dynamics GP.  This allows us to grow to use 10 segments of 6-7 characters each (as it allocates the 66 over 10 segments).  So the following Account Formats would be possible with a "66 and 10" Account Framework:




XX-XXXXX-X-XX
XXXX-XX
X-X-XX-XXXX-XX-XXX-X




Wouldn't be possible in this example?



XX-XXXXXXXX-X


Or


X-X-X-X-X-XX-XX-XX-XXXX-XX-X-X




It is important to keep in mind that the Account Framework is the largest the installation can GROW.  So maybe your initial account format for a company is XX-XXXX-X so you decide to specify the same as the Account Framework (a practice we come across frequently).  This works great initially, but if the client ever wants to expand their Account Format (a fairly common request when someone is on the software for a number of years, or even sometimes in the course of an implementation when the need to add an additional segment comes to light), they will have to chance the Account Framework (more on that later) which is not the flip of a switch.  Anecdotally, I have not seen evidence that a smaller account framework yields performance or other benefits.  But if you are reading this and you have seen such benefits, please share!




When a client wants to change the Account Format, it is a fairly straightforward process.  Then can update the Account Format Setup (Setup-Company-Account Format) and then as needed use the PSTL Account Modifier/Combiner tool to update segments as needed.  But if they encounter the boundaries of the Account Framework when doing this, it becomes a much larger issue.  Technically, you can script the changes to the Account Framework to alter the necessary tables and components.  But the recommended approach would be to use the Reformatter tool from Corporate Renaissance (which effectively creates a new Dynamics database and ports over the needed data)...




http://www.crgroup.com/Products/SolutionsforMicrosoftDynamicsGP/Pages/Re-Formatter.aspx




But of course that involved buying a product, testing, and then deploying the fix.  Microsoft used to also offer a service to do this through support (for an additional fee), but that involves additional down time as the data is sent to MS and returned.  In all cases, additional cost and time is involved.  And it takes a change that is intended to make the system flexible (e.g., being able to change the account format and use the PSTL account modified/combiner) and user-friendly, and adds cost and potential consulting hours.




In my not so humble opinion, before an install happens, everyone on the project team should understand what framework is being requested and why.  If you want to check your account framework, one of the easiest places to do so is Setup-Company-Account Format where you can see the maximum number of segments, characters, and the max length for each segment per the framework.




For reference, when installing Dynamics GP for the first time, GP utilities will allow you to select either a Basic or Advanced installation.  The Basic installation will install with a default Account Framework of maximum 5 segments, 45 characters, and 9 characters per segment.  This cannot be changed.  An advanced installation will allow you to specify the framework.









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.