Skip to main content

Integration Frustration: Why Microsoft Dynamics GP Integration Tools Need a Kickstart

by Mark Polino
Director of Client Services, Fastpath, Integrated Business Group
March 29 2011

I've done a ton of integration work with Microsoft Dynamics GP recently and it's left me frustrated. The common tools, Integration Manager and eConnect still have some frustrating holes. As a result, any third party tools, like SmartConnect, that rely on eConnect have the same limitations. 

An example I keep bumping into over and over is integrating EFT information for Vendors. In an initial implementation, we generally use the Table Import feature to populate EFT data because it's all stored in one table. The problem comes when companies want regular vendor integrations with EFT. For example, one firm I know has affiliates that they pay in a program similar to Amazon Associates or Google's AdWords. The affiliates can sign up or change their payment information online and the changes need to be integrated into Dynamics GP.  Except that there is no way to regularly integrate new or updated EFT information in conjunction with vendor changes without writing custom code.

It seems to me that Dynamics GP's integration tools have stagnated. Integration Manager's default connectors continue to be slow and buggy. The only recent "advancement" was the replacement of the SQL optimized connectors with eConnect adapters. This helped Microsoft but it did very little for the end user or consultant. eConnect-based integrations are just as fast as their SQL predecessors but the fields missing in the Integration Manager interface for high speed SQL connections are still missing in the eConnect-based interface. And users still can't reasonably schedule an Integration Manager integration without shelling out for an Integration Manager add-in.  Silly, I know.

For some reason Microsoft just keeps repaving the integration cow path in Dynamics GP when they should be building an integration super highway, with Dynamics GP as the destination.

<... class="become-member ms-auto me-auto">

FREE Membership Required to View Full Content:

Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here

About Mark Polino

Mark Polino is a Certified Public Accountant (CPA) and a former Microsoft MVP (2007-2018) for Business Solutions. He is the author or coauthor of 5 books related to Microsoft Dynamics GP.  Mark also maintains the Dynamics GP focused website DynamicAccounting.net. He speaks and writes regularly about ERP related topics. Mark has been a controller and CFO for a division of a publicly traded company and he has  worked as a consultant implementing ERP solutions. Mark holds additional certifications including Certified Information Technology Professional (CITP), Certified in Financial Forensics (CFF) , Chartered Global Management Accountant (CGMA). Dynamics Credentialed Professional for Dynamics GP 2015 (Core Install and Core Financials), Xero Certified. He holds a bachelor's degree in accounting from the University of Central Florida and an MBA from Rollins College. Mark lives with his family in Florida.

More about Mark Polino
Mariano
Submitted by mgomezb on Tue, 03/29/2011 - 14:25 Permalink

Well said! It seems we have so many tools that don't really get the job *completely* done. Too many pieces of add-ins, add-ons, VBScripts, T-SQL queries, connectors with no connection, connections with no connectors, half-put together integrations, half-put together transactions, transactions with half-put together integrations, rapid migration tools that are slow, slow integration tools that supposed to be rapid, too much planning for one time events, repeated events that supposed to require little planning. As a result, folks are using, well, Table Import. So much for the integration tools. Mariano Gomez, MVP

In reply to by anonymous_stub (not verified)

Jon
Submitted by JonEast on Wed, 03/30/2011 - 06:14 Permalink

I agree with what you are saying and I would love for eConnect to be able to do everything I want but from a development point of view how long would that take Microsoft? They would need to copy all of the business logic for each entity out of Dex and into SQL, not something I would fancy doing! Jon Eastman.

In reply to by anonymous_stub (not verified)

Marius
Submitted by MEvE777 on Wed, 03/30/2011 - 07:40 Permalink

Truly understand where you are coming from re: the lack of standard functionality. I have been using SmartConnect for a number of years now & seen the product grow significantly over the years. One of the strengths is the concept of custom nodes and using those from within the product. Once the custom code is written - in the correct format (same format as an eConnect node re: parameters) - you can re-use. We are now using this functionality to build integrations from GP to other SQL based systems. Hence SmartConnect will be the tool to manage all integrations in and out of GP.

In reply to by anonymous_stub (not verified)

Chris
Submitted by chrisdew on Wed, 03/30/2011 - 10:37 Permalink

Mark, I agree with what you are saying. Often times it is these little things like EFT or Vendor Remit To Address that never get added to eConnect that are the frustration. We write eConnect nodes all the time for our partners to help them with gaps in GP. This can sometimes be expensive for a little piece of functionality that should be there. At Convergence we will be officially launching Node Builder that allows you to create a new eConnect Node in minutes. It will allow you to add your own error codes to be returned by eConnect and most importantly allow you to add logic to your eConnect Node without need to write code. One of the important aspects is that it won't overwrite your data if you have an existing record and don't supply all of the fields again like many of the GP eConnect Nodes. Since it is an eOne product it will actually show up inside of SmartConnect as soon as you publish. So literally in one minute you can have a new eConnect Node for any GP or Custom table and integrate inside of SmartConnect.

In reply to by anonymous_stub (not verified)

Denny
Submitted by wellda on Wed, 03/30/2011 - 13:01 Permalink

"Microsoft just keeps repaving the integration cow path in Dynamics GP when they should be building an integration super highway" I think this is the most apt description of GP I've read in a while. Thanks for the honesty. Remove "integration" and replace with "functionality", "useability", "reporting", or pretty much any other adjective you would use to describe a modern, forward looking data system, and they all fit into this statement. They really need to quit spending so much time on fluff (who really cares if it looks like Outlook, or if I can export to Word - lipstick and rouge), and start genuinely bringing this system out of the 80's in deep and meaningful ways. Screens should be fast. Integration should be deep and easy. Clicks should be optimized. Standard reporting should be screen based and dynamic rather than printer-based and proscribed. I'm not holding my breath.

In reply to by anonymous_stub (not verified)

Mark
Submitted by mpolino on Wed, 03/30/2011 - 14:33 Permalink

I've seen Node Builder in pre-release form and I'm already setup with some time with eOne at Convergence. We built our own EFT node and used it in SmartConnect to deal with EFT info. My point is still that while it's great that Node Builder is there, I shouldn't have to buy a product to build a solution for what is a very straighforward and common integration. By the way, I've also already argued that MS should buy SmartConnect and replace IM in http://msdynamicsworld.com/story/accounting/ten-isv-products-microsoft-… Mark

In reply to by anonymous_stub (not verified)

Huber
Submitted by hcooney on Wed, 03/30/2011 - 14:41 Permalink

Our firm is actively looking at alternatives to Dynamics GP for all but the smallest deals, not because GP doesn't have great horizontal and even vertical functionality, but because its late-80's, closed architecture has become too opaque to administer easily. Other company's ERP solutions (i.e., Sage) are parameter-based and can be configured more transparently. Business logic, including report-rendering, is done through SQL sprocs that can be examined easily to determine what they are doing. Not that they don't have issues. They do. But I'd so much rather troubleshoot an issue, or build custom solutions/integration, with those solutions than Dynamics GP. The reality Microsoft is facing is that to bring Dynamics GP out of the technology dark ages would require a HUGE investment, and the payoff on that is uncertain, to say the least. They're going to just hang onto the water wagon as long as they can. But we're getting off.

In reply to by anonymous_stub (not verified)

Mariano
Submitted by mgomezb on Thu, 03/31/2011 - 21:05 Permalink

Even with the "huge investment", the technological upgrade is being done. See my article The Future of Microsoft Dynamics GP: 5 Cool Technologies You Should Watch For (and Learn) in the Coming Years. In addition, I have published a roadmap comparison that would help you understand how the product is trending towards the future - The Evolution of the Microsoft Dynamics GP Roadmap. I think Mark's article is more focused around the integration tools - not to say there aren't things in GP that don't need to be revisited, but I guess the roadmap will help you understand this. MG.- Mariano Gomez, MVP