Search all GP Blogs, Groups and Forums New!

Parent Category: CUSTOMIZATIONS

Dynamics GP has a trunk full of features, but there will be cases when you need to customize GP for certain specific business requirements or to optimize certain processes. This post covers some great references in the Dynamics GP community related to customizations in Dynamics GP. It covers topics like – when you should customize GP and when you should avoid customizing GP. It also includes some must read best practices when you do have customizations and various options like – Extender, Macros, Modifier.

If you are getting started with customizations check out this post by Michael D. Johnson II for Good Reasons to Customize GP. In this post Michael explains how customizations help – by giving people time to work on more value added activities, saving money and eliminating redundancy.

There is another wonderful post - Customizations that you do not need to do by Patrick Roth where he discusses 3 scenario’s in which you can avoid customizations - “Scenario 1: I need to be able to change the menu item names in Dynamics, Scenario 2: I need to change the Internet Information categories in the Internet Information window from what Dynamics GP uses, Scenario 3: I need to change the User Defined 1 prompt in the Customer Address Maintenance window to a specific value”. Patrick gives simple solutions.

Even though support for a splash screen was added to Dexterity v3.00, Great Plains Dynamics v5.50 was the first version to include a splash.bmp file and Microsoft Business Solutions - Great Plains v8.00 was the last version to include a splash.bmp file. This uncompressed bitmap was displayed as a splash screen when the application was launched. A number of partners had worked out that the splash.bmp file could be customised to add a customer or partner logo, but now the splash.bmp file is not longer used.

I have seen this issue come up a number of times. Trying to automate processes which involve reports and wanting to automate the Report Destination window. Sometimes you can add the Report Destination to Visual Basic for Applications (VBA) and sometimes the system will not add the window to VBA. This post will explain the reason for this "weird" behavior.

One thing about "weird" behavior when it comes to computers, is that once the explanation has been discovered, it all makes perfect sense and the computer is just being logical.

While customization, when not properly planned and justified, can be problematic there are good reasons to customize your system to create long-term, sustainable competitive advantage and build discipline in your organization. I will follow this up with some specific examples of customizations I have built for these reasons and others.

1. Leverage your people for more value added activities. I'm not opposed to relying on people for some things but I don't see the value in having them enter and process data that the system could process unassisted. I've seen too many Controllers that function more like glorified GL Clerks. They spend more time entering and managing data than analyzing it to make decisions. Customizing your system to automate non value added tasks and deliver high quality information could enable you to convert your high paid data entry clerks back into analysts and controllers which in turn would help you identify cost saving and revenue generating opportunities.

2. Eliminate waste and redundancy to make your company scalable. Growth companies are always dealing with too few people doing too many tasks. Everyone is overworked…

How many times have you walked into a GP implementation done by a previous VAR and cannot establish what changes have been done on a report, if any? Or how many times have you come across forms and reports dictionaries with tons of objects and cannot tell by simply looking at these if they have been changed or not? Or have you made some changes to a report a few years aback and now cannot remember what these changes were? I get this question every once in a while and finally someone was keen enough to post it on the Dynamics GP public newsgroup.

Solution

Let me start by saying that ALL modified forms and reports should ALWAYS be backed up in the form of package files, and that ALL these package files should be stored in a source code control repository -- for example, Visual Source Safe -- and versioned if all possible, with notes on all changes done from version to version. However, this is not always possible, especially if the company happens to be a small company with limited technical…

Over the years that I have worked with Great Plains and Microsoft Dynamics GP, I have seen (and written) many customizations at customer sites. Some of those customizations are in the form of products to handle specific vertical markets or generic tools to enhance functionality. Some of those customizations are in the form of customer specific Dexterity or Visual Basic for Applications (VBA) code.

I have seen systems where there is almost more custom code that original code. And I have seen the pain that can be caused by too much customization. Pain caused by trying to…

This is a must read article from Patrick Roth, Customizations that we do not need to do, for every GP Developer / Consultant. At times and at some Customers' environments, the GP Business Study (some call this as Business Mapping) and Implementation is done without a Trained / Experienced GP Functional/Technical Consultants.P…