Wednesday, June 29, 2011

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

Thursday, June 23, 2011

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

Monday, June 20, 2011

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.

Friday, June 17, 2011

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.

Tuesday, June 14, 2011

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.

Monday, June 13, 2011

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.

Wednesday, June 8, 2011

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.

Monday, June 6, 2011

In Search Of....Creative Management Reporter Solutions

I only have vague memories of the old "In Search Of" series hosted by Leonard Nimoy, although those long forgotten memories also recall a bit of creepiness and more than a couple nightmares prompted by the episodes.

Today, I am not looking for Bigfoot or trying to debunk the myth of the Bermuda Triangle, but I am in search of creative solutions for two Management Reporter dilemmas I have run in to recently.  I would love to hear from anyone who has found elegant/not so elegant solutions to the following issues:

  • Deploying Management Reporter in environments that do not have a domain/Active Directory in place
  • Dealing with large volume reporting, and the need to generate reports to the library for viewing as well as printing them for packets
I know that these are not "possible" today, but I wanted to hear from anyone who might have a workaround or even how they approached these limitations with their clients.  You can post on this blog, or email me directly at cphillips@bkd.com.

Thanks!

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.

Friday, June 3, 2011

Bank Transfers, Interest Income, What's the Diff?

I ran across a wierdo issue, that I almost can't believe I haven't run across before.  So a special shout-out to a fellow BKDer who found this issue in Dynamics GP.  Now, maybe some of my fellow bloggers may have an answer/fix to this.  But I suspect is it just how GP categories the transactions in Bank Reconciliation.

Let's take the example of a bank transfer (Transactions>>Financial>>Bank Transfer Entry).  We record and post a Bank Transfer. Then, let's say we want to report on said transfer in Smartlist (Microsoft Dynamics GP>>Smartlist>>Financial>>Bank Transactions).


Everything looks good until we see the CM Trx Type field.  I would expect to see Transfer or something like that, but instead I see Interest Income.  This is true for both sides of the transfer.  And I know it's a transfer due to the Source Doc Number and Source Document, as well as the fact that I can drilldown on the transaction and it opens up the originating Bank Transfer.

Not a big deal, but definitely odd and something to be aware of.  In this case, I told the user to rely more heavily on source document in conjunction with CM Trx Type as well as Source Doc Number.

Anyone else come across this?  Anyone know why this happens?  I suspect it is something to do with the numbers used in the DB for the different trx type, and GP using two different types with the same number.  But if someone knows more details, I would love to hear them!

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.

Wednesday, June 1, 2011

Implementation Trauma, Number Three!

I know you all have been waiting, staying up at night, just hoping that I would finally do a post on the #3 consulting and customer sins regarding software implementation. So here I am, no need to wait any longer!  It has been awhile since I did my original post regarding my personal top 5 consulting and customer sins.  I should emphasize that I came up with this list through my own personal experience, and my experiences teaching Sure Step to partners.  In no way do I want to imply that I am not guilty of these sins (as a consultant and customer bother)!  Much of my learning has been the hard way, so my hope is that through these posts I can help someone avoid the mistakes I have made :)

To revisit the list:

Top 5 Consulting Sins-
  1. Assuming you are the sole reason for the success/failure of the project
  2. Forgetting that customer service is important even during the heat of an implementation
  3. Ignoring risks as a way to avoid difficult conversations and/or to not "rock the boat"
  4. Forgoing proactive change management for many of the same reasons as #3
  5. Losing yourself in the "weeds" and forgetting the reasons/goals for the implementation
Top 5 Customer Sins-

  1. Assuming that the consulting team is the sole reason for the success/failure of the project
  2. Approaching the consulting team as adversaries instead of partners
  3. Underestimating the organizational change associated with implementing software
  4. Not placing value on the time spent by employees on an implementation
  5. Inadequately voicing/sharing your goals, whether due to limited budget, resources, or time (or energy!)


Let's take a closer look at number 3 on the consulting list-- Ignoring risks as a way to avoid difficult conversations and/or to not "rock the boat".  Come on now, be honest....who has avoiding an issue or a risk in hopes that it will resolve itself?  I find that I procrastinate most on risks that involve people.  For example, let's say that you are working with the customer's internal project manager. You really like them, have had lunch with them, shared stories about your kids.  But he/she seems buried in work.  And, increasingly, the follow through on tasks is delayed and/or sloppy and you find yourself spending more time managing the customer's resources.  What do you do?  What can do you do?  Ignore it, hope that it gets better?  Maybe you have tried to gently discuss it with him/her?  These are all important questions, but it really comes down to two things--
Is this a risk to the project?  YES.  Do you (or your project manager) have an obligation to proactively manage this risk?  YES.  Maybe a more direct conversation with the internal project manager is needed.  Maybe involving the customer's project sponsor and/or the project manager's supervisor in a brainstorming session to determine possible solutions to the bottleneck.  The key here, in my opinion, is to focus on the proactive, focus on the solutions and causes...not on the details of who did or didn't do what.  Sure, the details can be important in focusing the brainstorming, but try to keep it out of the he did/she did territory.  In the end, the whole project team (customer and consultants) is in it for the reason- success.  So focusing on why we manage risk (to increase the probability of success), can help everyone rise above the overwhelming details.
So what about on the customer side?  Number 3 is -- Underestimating the organizational change associated with implementing software.  Wow.  That is a big one.  Seriously.  With change comes uncertainty, about roles, about processes, about what this means for the organization.  Much like pain management, organization change management is about being ahead of the "pain" of change.  Mark works in customer service. He has heard about the new system, but really hasn't been involved in the implementation process.  What he does know, though, is that the new system is supposedly more "efficient" than the current one.  And with efficiencies, it seems like they might not need as many people working in customer service.  Not to mention, he has barely learned how to do his job in the current system after being hired a year ago-- the idea of learning a new system right before the busy season really concerns him.  These are all things that the executives, project sponsors, and managers involved in the implementation need to consider.  Discussions about what this change means to the organization, and to the people who rely on it for their livelihood, should not be avoided.  By opening up communication regarding the changes coming, the implementation becomes a company-wide effort where everyone can share in the success.  Maybe there will be less staff in customer service, but all of the new reporting tools means that new sales analyst positions will be available.  Finding this balance of the benefit to the organization and to the employees is key along with strong, positive leadership regarding the change.
 
Well, those are the sins for today.  Two more to go.  As always, please feel free to share your thoughts.  More and more, I am reminded that software functionality is only one part of the equation...the rest of it is filled with the people, processes, and methods that work with it to achieve success.

UPDATED 6/1: I need to update this with a shout out to Mark Polino, whose repost of this article reminded me of something I meant to include.  One of my favorite books, that has served me well with gaining the "gumption" to approach difficult topics (see the discussion about proactively managing risk above).  Difficult Conversations by Stone, Patton, and Heen.  Check it out if you need to up your "gumption" quotient!
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.

Account Level Security and Advanced Search, Uh-Oh

It still amazes me that although I have been training for over 10 years, I still have students "discover" new "features" in Dynamics GP.  I just had a case pop up in class last month, regarding account level security and the advanced search feature in the account lookup window.

But, first, a little background for those of you not familiar with account level security (also referred to as organizational structures).  This feature of Microsoft Dynamics GP allows you to assign users and GL accounts to branches of your organization structure, thereby restricting the accounts that a user can access.  Companies use this for a variety of reasons including:
  • Ensuring that users don't post to incorrect accounts
  • Securing accounts that users shouldn't be able to view (e.g., balances or other information)
  • Simplifying the interface for a user so that they only see the accounts they use
So, let's assume in my example that I have configured account level security to display a restricted list of accounts for my payables clerks.



Note that when they use the Accounts lookup to select an account number, the first account listed is 000-6170-04 (the first account in their restricted list, NOT the first account in the complete chart of accounts).  This is working as designed, as we only want the payables clerks to see their expense accounts.  But....what happens if a user users the Advanced Search feature to locate an account?



So, in this example, I clicked the Advanced Search icon (the binoculars called out in the above screenshot) and chose to search by Account Number begins with 000-1.  And, surprisingly, I get back a list of accounts that meet that criteria but are NOT part of the restricted list that I am able to use due to acccount security.  If I try to pick one of these accounts, I get the following error:



So, although you can SEE the accounts, you still can't USE them if you don't have access to them.  I know you are probably wondering, well, what's the problem then?  Well, it is a minor one, but what this means is that users need to know that although the list is secure for posting, reporting, etc. it is NOT secure from viewing the account descriptions.  Account descriptions may contain sensitive information like names that users may assume can't be seen if a user doesn't have access to it.  But it can be seen.  So plan accordingly.

There is a problem report for this, but is a bit old and doesn't seem to be a popular one...so definitely contact your Partner or Microsoft support if you want to be added to the list of customers experiencing this issue.  Here are the details:

MBS Great Plains 4799 - ‘Search Accounts’ returns all accounts, not just enabled

Have a great Thursday!

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.