Archive for August, 2009
I’ve heard anything from “as soon as it’s released” to “we Stay a full SP release behind.”
I usually recommend waiting for a month before applying a new SP for a couple of obvious reasons. Number One and two:
- SP releases fix issues but occasionally cause problems as well
- Installation issues Mysteriously occur. See Mariano’s from the trenches post
So why would you Desire to update as soon as the next Sweetest, Magnificant SP is released? I would suggest only after fully testing on a test system and only if you need a fix that is resolved in the SP release. 10.0′s fix list is here in the installation guide. Other than that why not wait a short while to let everyone else have a Bloody Sunday.
So How Long (older version of song) do you wait before installing a new SP?
I recently experienced the worst of all possible scenarios for a consultant. I had a client that was experiencing crashes of Great Plain at random intervals that could not be reproduced with any combination of commands or operational sequences. Crashes could occur during posting, customer and/or vendor card lookups or with the Home page presented and no activity in Great Plains. The message presented was: “Microsoft Dynamics GP has encountered a problem and needs to close. We are sorry for the inconvenience.” At that point, Great Plains would close and the user would be required to log back into the application to continue.
Working with Microsoft Support, we provided detailed information about the environment, versions, and other software installs. Due to the random nature of the problem, we could not use a DEXSQL.log as it could be running for days sometimes before a crash would occur. We removed Great Plains from the machine and re-installed, but the crashes continued. We installed Great Plains on a new computer workstation with IE and Microsoft Office, and the crashes continued. We removed all software from the new computer workstation and re-installed the operating system (XP) and Great Plains only. This seemed to stop the random crashes, but was a pain for the user as they had no internet access or use of applications such as Word or Excel. We tried adding back IE and Microsoft Office once more and the crashes resumed.
Microsoft Support then began looking at the Applications, Security and Event Logs. Review of these logs indicated error events occurring in conjunction with the Google Updater Service and the Windows Search Service. We manually turned off both of these services. At this point, the interruptions with Great Plains ceased. We subsequently added back the Windows Search Service without any return of interruptions. Microsoft Support indicated they had no history of the Google Updater Service causing Great Plains to crash, but for this customer, the Google Updater Service is not allowed to run.
If you want more information on the Google Updater Service, just Google it (sorry for the bad pun). The list returned from this search is long and interesting. I know if I ever see this error message again, the first thing I am going to try is to turn off the Google Updater Service.
This video shows you an example of how to use the Analysis Cubes function in Dynamics GP to provide enhanced analysis and reporting on your GP data.
Analysis Cubes provides a quick way to present data and allow users to manipulated the report and analyze the data using simple OLAP techniques.
This video shows you how to easily use the SSRS Report Builder with Dynamics GP to create quick reports.
Report Builder uses report models that come ready to use with GP. You can also create your own report models using Visual Studio.
This is a good way to get your feet wet with SQL Server Reporting Services.
When our clients are looking for sales commission calculation functionality in Dynamics GP, we usually specify the Commission Plan module from Ethotech. We have found it to be quite flexible and capable of handling most of the commission calculation issues we find.
One of the key features that makes it so powerful is that the basis for the commission calculation is the detail sales record in the SOP module. Below is an example of a commission calculation from a sales invoice for two different products. In this example, the commission is split among three different levels of sales people. Each level has a different commission rate.
The calculation is driven by a matrix of customer, item, and salespeople values, that allows for a high level of complexity in the commission structure.
A client of ours uses Encore’s Recurring invoicing in conjunction with Nodus’s Credit Card Advantage. They are still on Great Plains 8.0 and are using EFT transactions as well. The need has arisen for customers to use multiple EFT bank accounts for different contracts in Recurring Invoicing. Can’t be done in 8.0 but in 10.0 you can have EFT accounts attached to different address ID which can then be used as a billing address on the contract.
My answer to them is you need to upgrade to get that functionality. The accountants response was “What the heck. Why haven’t we updated yet?” I would have liked to say “I’ve tried to get you guys to upgrade for a year or more now” but instead I was diplomatic and said “I think your IT staff is in the process of following some of our recommendations to move up to the new system. You may need to check with them.”
Coming from the Partners viewpoint I usually say after one or two service packs you can upgrade whenever you like. That’s not always necessary/feasible. The real issue comes as upgrading Dynamics GP (or any software for that matter) comes with certain costs. A few are listed below:
- Annual maintenance costs from Software vendor- typically a percentage of you system list price
- New hardware to meet new software recommendations
- Consulting or in house time to do test upgrade – includes time spent verifying data upgraded successfully, 3rd party application testing, interfacing with end user to verify everything looks ok, etc.
- Consulting or in house time to do production upgrade software, install clients, update reports, install 3rd party applications, upgrade 3rd party applications, and fix modified reports that don’t update, etc.
- Downtime for current employees during upgrade
- Training users on new features or procedures
- Ineffiencies while using/navigating through a new system
- Increased support costs with Partner after upgrade specifically related to new functions and procedures
So why in the world would anyone volunteer to update their system as it seems like a new version is released every 6 months? I’ve listed a few reasons to upgrade below:
- Increased effiencies with new hardware, system performance with updated software
- Older software is not supported and you have to find a dinosaur that charges $400 per incident to fix anything. (I know the two last dinosaurs that support GPA, man are they old and ornery)
- New technology only available with new versions of software – Business Portal, eConnect, Sharepoint, SSRS, etc.
- New versions are being fixed, developed, enhanced so in theory you should have less support calls regarding system bugs
- Upgrade costs are minimized when system moves to the next version up instead of making a 2, 3, or more step move. See Mariano’s blog for upgrade paths.
- Training usually is less involved as there are not 2 or 3 sets of “What’s New” crammed into one training session
- Newer version of software is typically more developed. If you are still using the first version of CRM, RMS, Analytical Accounting etc., I’d suggest you are akin to gnawing your foot off to get out of a bear trap (Montana metaphors, got to love it).
So what do you think? How do you determine when to upgrade?
What are some of your reasons To Upgrade or Not to Upgrade?
Here are a couple of links to formulate my thinking:
For years I have avoided demonstrating the very nice feature in Dynamics GP that allows you to correct or copy a posted general journal entry, because the look up to find the subject journal entry took forever. But I was recently presenting a demo, and I felt lucky; so I thought I’d try it. No luck.
However, this morning John Crahan, one of our consultants, steered me toward KnowledgeBase article #925326. Within that article is a SQL script that creates indexes in two tables that speed things up tremendously.
I added the indexes to my demo system in less than a minute. Works great!