Two possible constraints in Dynamics GP design for larger or expanding companies

Steve Endow

I recently talked to a consulting firm that works with Lawson software. They had a client using Lawson who acquired a company that uses Microsoft Dynamics GP. The Lawson client manages 3 companies in their system, while the GP client manages 9.

The Lawson client manages their 3 companies in a single database. The GP client, however, uses 9 separate databases for their 9 companies. This client was deciding whether to stick with Lawson or switch to Dynamics GP. The Lawson consultants were worried the client wouldn’t want to move to a system with separate databases for each company, which would require constantly switching between them.

There are clearly many Dynamics GP users with multiple company databases who don’t have problems with this setup. I personally know of several companies managing over 200 active company databases in Dynamics GP. I don’t know how they stay organized with that many, but they make it work.

Even so, the way Dynamics GP uses a separate SQL Server database for each company is often seen as a drawback for multi-company businesses looking at ERP systems. While some companies are fine with multiple databases, others see it as a major disadvantage that makes things harder, especially when it comes to administration, reporting, and data entry.

Sheldon Gitzel recently wrote a blog post on the Etelligent ERP Blog about this issue and some possible solutions: http://www.esicanada.com/index.php/options-for-handling-multiple-companies-in-dynamics-gp/.

So, if a competitor says GP can’t handle multiple companies, they’re wrong – it just does it differently than some larger ERP systems. Systems that use the same database for multiple companies might have some advantages, but also potential drawbacks, like having to manage a single massive database.

That’s one thing for a large company to consider.

Another limitation of Dynamics GP is its lack of overall support for “effective dates.” This means if an employee’s pay, benefits, or deductions are changing next month, you can’t enter those changes in Dynamics GP ahead of time with a future effective date. Many higher-end systems have built-in support for effective dating, which lets you set future dates for things like discontinuing inventory items, enacting pay raises, or setting time-limited prices and discounts. I’ve only worked with one GP customer who truly needed this feature. They had hundreds of employees, and effective dating was essential for their HR and payroll. However, as companies expand, features like this become increasingly important. If anyone knows of an add-on that enables effective dating in Dynamics GP, please leave a comment.

Along similar lines, Dynamics GP doesn’t track record changes. This means if you update an employee, customer, or vendor address, there’s no history of the old information, only the current version. While customers could buy an add-on like Rockton Auditor to track these changes in GP, it costs an extra $250 per user and still doesn’t provide effective dating.

I’m not trying to bash Dynamics GP; these features often involve complex, fundamental design decisions. I simply wanted to highlight two areas where larger companies might feel they need a “larger” or “tier 1” ERP system and believe Dynamics GP falls short.

Have you encountered situations where clients felt limited by Dynamics GP because it lacked a feature found in larger ERP systems?

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

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Licensed under CC BY-NC-SA 4.0