How to find Dynamics GP Customizations or Third Party Modules

One question that I have to answer frequently for Dynamics GP customers is "How can I tell if I have any Dynamics GP customizations or third party modules?"

When a client gets a new partner, or when a customer is looking to upgrade Dynamics GP, it's important for both the customer and partner to know if any customizations or ISV solutions might be installed so that they can be properly supported or can be upgraded.

So how can you tell what ISV solutions or customizations are installed in your GP environment?  Since there is no single window or feature in GP that completely answers this question, you have to check a few places, and ideally have some familiarity with your GP system to adequately answer this question.

I've listed the things that come to mind when I need to look for customizations or third-party products.  If I missed anything, please post a comment and let me know.


Customization Status

Tools -> Customize -> Customization Status

An easy place to start is the Customization Status window.  It lists the Dynamics GP modules and Dexterity-based ISV solutions or customizations that are installed and active.  Although handy, the problem with this window, or more specifically the list it displays, is that it isn't always obvious which items are standard GP modules, and which items are ISV solutions or customizations.  If you are familiar with the standard list of GP modules, then you can usually pick out the items that are ISV or custom.


Dynamics.set

C:\Program Files\Microsoft Dynamics\GP  (or the application directory where you installed GP)

Locate the Dynamics.set file and open it with Notepad.  The Dynamics.set file is essentially the same list that is displayed in the Customization Status window, but it includes additional technical info, such as the number of modules installed (the number at the very top), the module IDs (the number above each name), and then the module names.  The set file also includes the paths where the dictionary files are located.


This file would allow you to identify the specific third-party or custom Dexterity dictionaries that might be in use.  If you have Dex customizations, make sure that you have a copy of the full Dexterity project and source code, as you will need that to make modifications and upgrade.

One thing to look for in a Dynamics.set file is whether GP is setup to use "shared dictionaries", meaning that all workstations point to a single copy of a modified Forms.dic and Reports.dic.  A standard set file looks something like this:

:C:Program Files (x86)/Microsoft Dynamics/GP2010/Dynamics.dic
:C:Program Files (x86)/Microsoft Dynamics/GP2010/Data/FORMS.DIC
:C:Program Files (x86)/Microsoft Dynamics/GP2010/Data/REPORTS.DIC

If you notice that the path for the FORMS.DIC or REPORTS.DIC is not the same as the Dynamics.dic line above, it's a sign that GP is setup to use shared dictionaries, which usually means that there are modified forms or reports.



Customization Maintenance

Tools -> Customize -> Customization Maintenance

The customization maintenance will list modified forms, modified reports, and custom VBA code and references that are  active on the workstation.  These would be customizations made using Modifier, VBA Editor, or the Dynamics GP Report Writer.  Although this window displays a list, you still need to understand where these customizations are stored.

Modified Forms are stored in the FORMS.DIC file referenced in Dynamics.set file.

Modified Reports are stored in the REPORTS.DIC file referenced in Dynamics.set file.

VBA code, user forms, and references are stored in .VBA files located in the Dynamics GP application directory.  The main file for GP VBA customizations is Dynamics.vba; however, if VBA was added to modules that are not included in Dynamics.dic, then there may be multiple .VBA files with customizations, such as HR.vba or AA.vba.  Note that there are usually many .vba files in the GP application directory--most of those are 'empty' and do not contain any customizations.

One very nice thing about the Customization Maintenance window is that you can export and import customizations using .package files.  This is a great way to backup individual customizations, or all customizations, independent of your FORMS.DIC and .VBA files.


Add Ins

C:\Program Files\Microsoft Dynamics\GP\AddIns

Add Ins are DLL files that were developed using Dynamics GP Visual Studio Tools and Visual Studio .NET.  These are customizations that can offer all of the power and flexibility of .NET, yet run within the context of Dynamics GP and look very much like a standard Dynamics GP window.

By default with GP 2010, it looks like there are 15 files installed in the AddIns directory, most of which are named "Microsoft.Dynamics.GP...", making them easy to rule out as customizations.



Other Customizations to Consider

External Reports and Queries

Many customers use Crystal Reports, MS Access, Excel, SSRS reports, or other tools to query Dynamics GP data.  While GP upgrades may not change database tables enough to cause those reports to break, you may need to 're-point' those reports to the new SQL Server instance or databases after you have upgraded to GP.  And if you have a problem with any of those reports and need support, it's always good to know which custom reports are out there.

One common issue I have seen is that a lot of clients develop and deploy such external reports using the 'sa' login.  When the 'sa' password needs to be changed, it breaks these reports and users complain.  Such reports should never use the 'sa' login, so it's good to review those reports and make sure that they use a dedicated reporting login with limited access.


Integrations

If any data is being imported to Dynamics GP, you will want to identify those integrations.

If you use Integration Manager, you should make sure to backup your IM.mdb database file and have some documentation of your integrations, including source files and an import procedure.

If you have any other tools, such as SmartConnect or Scribe, a similar backup + documentation procedure is recommended.

If you have any custom eConnect integrations, you should ideally have full documentation, an installation (exe and/or msi), and source code, including any database objects (custom tables, stored procs) that the integration may require.


Custom integrations can be challenging for a few reasons.  First, because they are not referenced in any of the standard GP files discussed above, you may not know they exist.

Second, even though an integration may look simple on the surface, it may have horrendously complex and intricate code behind the scenes--something that I've seen numerous times.  This can lead you to believe that they will be simple to support and upgrade, when they will actually be very difficult to deal with.

Finally, custom integrations, such as those developed using Visual Studio, require the full source code to be upgraded.  If a customer has switched partners one or more times, it may be difficult to get the source code for those custom integrations.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Please, Please, Please Upgrade your Dynamics GP software

In the last few months, I have been asked to help several companies that were still using Dynamics GP 9.

I understand the dozens of reasons why many companies are still using GP 9.  Many of those reasons make sense, while some don't.  And I've also seen customers that use old versions for years simply because their business hasn't changed in years and neither have their ERP requirements. 

Regardless of the reason, if you are still using GP 9 and aren't actively working on your migration to GP 2010, I am begging you to upgrade.  If for no other reason than for the sanity of the poor consultants that start twitching when they hear "GP 9".

Two of the companies that use GP 9 have eConnect integrations.  I love eConnect, but with eConnect 9, there are so many "bugs" / "features" that I've had to write dozens of workarounds.  From the lovely "System Error" messages of eConnect 9, to the endless bugs and omissions in the Payroll interfaces, I will not miss good old GP 9.

And then last week I had to look into an Integration Manager 9 issue--back then, Integration Manager apparently wouldn't allow zero dollar transaction distributions.  Lovely.

And this week a client discovered one of the many significant flaws with GP 9 inventory costing and valuation, learning about it much too late to solve the problem.  If you are still using GP 9 and rely heavily on distribution and inventory, I can pretty much guarantee that all is not well with your costing.

And at least two of the GP 9 customers have wanted to submit support cases in the last month, but no such luck, as GP 9 is no longer supported in any form or fashion.

I know that new software versions don't always seem compelling, and that it doesn't necessarily make sense to upgrade to every new version.  And I know that it takes time, effort, and money to upgrade--something that the "cloud computing" and "SaaS" evangelists will point to as one of the great flaws of on-premise software.

But please, please don't stay two or more versions behind with your Dynamics GP software.  When Microsoft announces an end-date for support, there's a pretty good reason, and there are real consequences to that end-date.  And if you are paying your annual enhancement fees each year, you have already invested in the new releases, so you might as well make your investment complete and start using the new software.

So, if you are still on GP 9, please upgrade.  Please?

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Ch-Ch-Changes...And "Checks on the fly"

Interesting tidbits to share regarding the printing of "checks on the fly" from Microsoft Dynamics GP.  But, first, a quick explanation of a "check on the fly".  In GP, you can print a "check on the fly" from the Payables Transaction Entry window by entering an amount in the check field and clicking Print Check.  When you do this, a check is recorded alongside the invoice and the transaction distributions will affect both cash and expense.

Transactions-Purchasing-Transaction Entry

Well, the question comes up...I print the check and realize there was mistake!  What can I change?  Well, from my testing you CAN change:

• Document Number
• Payment terms
• Purchases Amount (but NOT the check amount)
• 1099 Amount
• Distributions
• Check Number
• You can click Print Check and reprint the check using a new check number (it will automatically record the original check number as a void)

What you CANNOT change:

• Vendor ID
• Document Date
• Check Amount
• Checkbook
• Remit To Address
• Although you can change the ID, when you click Print Check again to reprint the check, it will use the original Remit To Address.

Good luck as always!  And let me know your own interesting tidbits regarding this feature in Dynamics GP!

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

BKD GP Team Blog!

Woohoo! It's party time here at BKD, we just launched a blog for our GP team.  Very exciting stuff, especially because we have such a diverse group of people sharing their opinions, tips, and tricks for Dynamics GP.  If you have a chance, check it out!

www.dynamicsGPinsights.com

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Sustainable Development?

Sustainability is a buzzword in business today, whether talking about maintaining growth or minimizing environmental impact, and seems to be tacked on to a variety of products from cereal bars to cars. So what do I mean when I talk about sustainable development with Microsoft Dynamics GP?


Now, first, I have to add in my own disclaimer. I am not a developer. So I really would love to hear from others on their experiences. But I have been involved in enough functional and technical design processes over the years, that I have seen some themes emerge around customizations that truly increase satisfaction with the software versus those that seem to limit the software’s capabilities and the customer’s satisfaction.

In my mind, sustainable development is custom development that is approached in a way that:

• Enhances the user’s experience with the system, does not diminish it

• Does not try to replace the need for training and time to adjust to a new system

• Uses supported tools and recognized approaches for solving a problem

• Includes documentation, including foresight regarding upgrading and changes in business requirements

Given the robust toolset that we now have to customize Microsoft Dynamics GP, it is not unusual to have some degree of custom development on even the smallest projects. These minor customizations can often reap big rewards in terms of satisfaction with the system. How do we go about developing these customizations in a “sustainable” way?

I think that there are three key principles to keep in mind when considering custom development, to ensure that you are approaching it in a sustainable way:

1. Ask Why? Why is this needed? Is it to support a business process and requirements? Get to the heart of the need, and address it appropriately—which may not be with development. It may be training, it may be the learning curve that comes with a new system, it may be understanding that business requirements can sometimes be differ from an individual user’s perspective.

2. Document the design. Putting it down on paper can make a world of difference in terms of the thought processes applied—thinking through upgradeability, appropriateness of the selected toolset, and flexibility for future requirements. Plus this gives everyone something to respond to, something concrete to reference and consider.

3. Don’t limit yourself. This is a hard one, because we all rely on the tools we know best. But when something falls outside your comfort level, or you sense that there may be a better approach, ask around. Trying to shoehorn the tools you know to meet a need can create a cell you will be forced to live in for years…and years…and years :)

Of course, I am always interested in hearing your perspectives! Please let me know if you agree/disagree or want to add to the list above.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Select Blogs Where Smartlist Begins With [%]

I ran in to one of those DOH! moments this past week.  Simple as this...I needed to search for all payables transactions where the document number begins with a percent sign.  Why?  Well, this was how the client was identifying certain invoices that needed additional processing.

So, I dutifully built a Payables Transaction SmartList (Microsoft Dynamics GP menu--SmartList--Expand Purchasing--Expand Payables Transactions--Click on Asterisk--Click on Search button) using the following criteria:

So, I am sure you SQL gurus out there already know my dilemma.  The smartlist returned ALL records that met the other three criteria, seemingly ignoring the first criteria for document number.  Why?  Well, because SQL uses the % as a wildcard in a LIKE statement.  So in this example, it was essentially looking for everything, since the only parameter was the wildcard.  Ugh.  But easily fixable once I thought about.  If, in SQL, I wanted to use LIKE to find something with an actual percent sign it, I would use brackets around the % sign like this [%].  And, well, it works in SmartList too!

And, again, I am sure the SQL gurus already know this....but this actually returned the correct results.  Woohoo.  Party On.  Excellent.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Performance Issues with Dynamics GP on Terminal Server with Mapped Drives

In the last year, I've had three inquiries regarding extreme performance issues when running Dynamics GP on a Terminal Server.  In the three cases, two were using GP 10, and one was using GP 9.

The customers explain that when some users launch GP on a Terminal Server, it can take 5 to 10 minutes for Dynamics GP to launch.  But other users on the same Terminal Server don't have any issues or delays launching Dynamics GP.  Sometimes a user that has been working fine will suddenly experience the issue, and it will persist for that user going forward.

In all three cases, it seems that the primary culprit was mapped drives on the user's terminal server session. 

Two of the customers found that removing the drive mapping option in the user's Active Directory profile solved the problem.  The third customer did not have drive mappings in the AD profile, but found that removing the login script, which mapped drives, solved the problem.

What is strange is that not all GP users were affected, even if all users had the same drive mappings.  And from what I have learned, only Dynamics GP had performance issues.

Since a ton of customers run Dynamics GP just fine in a Terminal Server environment (presumably many with mapped drives), I assume that there is something else involved other than just mapped drives, but I don't yet have any clues as to what that might be, and why it only affects some users.

Since one of the customers needs mapped drives in user TS sessions, they are planning on submitting a support case to understand why the mapped drives cause the issue.  If I learn more, I'll post an update.