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

That may answer your EFT import question. Haseet

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.

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.

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.

"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.

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-should-buy-and-incorporate-dynamics-gp Mark

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.