This particular client uses the eConnect incoming queue to integrate journals and payables invoices into Dynamics GP from a housing management system.
After installing eConnect and configuring the incoming queue I set about doing a test to ensure it was working.
Unfortunately, it didn’t.
I had an issue to deal with for a client recently where messages submitted to eConnect were no longer appearing in Microsoft Dynamics GP. I did the usual things of checking the Windows Event Log and ensuring that the two eConnect services were running.
One item I tried was to submit a test message to eConnect which worked fine; so it worked for the perfectimage user I was logged in as, but no-one else. I eventually found the answer in the Properties of the econnect_incoming queue:
The permissions for the perfectimage account (Full) were still configured correctly, but, somehow, the Send Message permission on Everyone had been removed. Once this setting had been added back, people were able to submit messages to the queue without further problem.
I was recently creating an integration for a client to load some Purchase Orders into Microsoft Dynamics GP using Integration Manager. I added the source and destination adapters and then did the destination mapping. However, when I tried to run the integration I got the following error message:
DOC 1 ERROR: There was no endpoint listening at net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations that could accept the message. This is often caused by an incorrect address or SOAP action. See InnterException, if present, for more details.
While I was working on the series of posts for how to install the Web Services for Microsoft Dynamics GP, I encountered a couple of problems which I thought it might be worth covering in this and the next post.
The first was to do with the eConnect Integration Service which is installed as part of the install of Web Services. The basic problem was that the service was not running;
At the end of December, Developing Microsoft Dynamics GP Business Applications, written by Leslie Vail and published by Packt Publishing was released.
I got a copy of the book in order to do a review and have decided to break the review down into multiple parts. The reason for this is that the book includes some practical examples which I have decided to do and then include the results of this in the review; after all if it is a book on developing how can you accurately review the book if you don’t use what you learn to build something?
The book is aimed at developers new to working with Microsoft Dynamics GP, so bear in mind that I am not a developer when reading my reviews. Quick synopsis of my background: I started my career as a trainee developer and moved through a variety of roles such as developer and support analyst before moving to my current position as consultant and project manager.
I oversee development teams working on additions or amendments to Microsoft Dynamics GP as well as personally undertaking some modifications using Report Writer or Modifier with VBA. So despite not being a developer, I am used to working with them and did, once upon a time, be one myself.
The first chapter of the book covers the Microsoft Dynamics GP Architecture from a high level perspective.
It covers the history of the GP interface from it’s origins with Great Plains Software, an overview of Dexterity and the development environment. There is a detailed explanation of the launch file (Dynamics.set), which included a couple of points of which I wasn’t aware, and the configuration/preferences file (Dex.ini).
The explanation of the Dex.ini file included the ExportOneLineBody switch which I didn’t know about, but for which I have an immediate use.
Leslie then goes on to explain about the structure of the tables in the SQL Database which always strikes newcomers as arcane and overly complex. Leslie explains this well with plenty of detail on both the structure, including both the physical and technical names, and how transactions move between tables as their state changes.
Chapter 1 wraps up with a detailed explanation of the UI covering how forms are constructed, how the scrolling windows work and the common buttons used on forms, scrolling windows and individual buttons.
The second chapter of the book focuses on the fundamentals of integrating applications with Microsoft Dynamics GP.
This is the seventh post in the series on how to install the Connector for Microsoft Dynamics GP; the first six posts covered the prerequisites, installation, adapter configuration, creating a new integration, preparing data for integration and synchronise picklists.
Now that the Connector for Microsoft Dynamics has been installed and configured, the data has been prepared for integration and pickilists synchronised, the next step is to start running the integrations.
As an example, I’m going to step through the process of integrating the Unit of Measure Schedules from GP into the CRM Unit Groups.
In the Connector for Microsoft Dynamics () navigate down to the UofM Schedule to Unit Group node ( );
This is the sixth post in the series on how to install the Connector for Microsoft Dynamics GP; the first five posts covered the prerequisites, installation, adapter configuration, creating a new integration and preparing data for integration.
One of the things that needs to be done before integrating Microsoft Dynamics GP with Microsoft Dynamics CRM is to synchronise the CRM picklists with data in GP. This can be done using the supplied Microsoft Dynamics CRM Picking Sync utility which is installed along with the Connector for Microsoft Dynamics.
There is no menu item created for this utility, so you will need to open Windows Explorer and navigate to the installation folder () and double click the Microsoft.Dynamics.Integration.GpToCrmPicklistSync.exe;
This is the fifth post in the series on how to install the Connector for Microsoft Dynamics GP; the first four posts covered the prerequisites, installation, adapter configuration and creating a new integration.
In this post, I’m going to highlight an issue which bit me when I was creating this series of posts using the Fabrikam, Inc. demo company.
This isn’t an issue I’ve encountered in the wild, so to speak, but it is a difference in how Microsoft Dynamics GP and Microsoft Dynamics CRM handle Unit of Measure Schedules and Unit Groups respectively.
Microsoft Dynamics GP allows for Unit of Measure Schedules to have two UoM details of the same name. For example, the Fabrikam, Inc. Unit of Measure Schedule Wire contains Spool defined as both 100.00 Foot and 33.33 Yard;
This is the fourth post in the series on how to install the Connector for Microsoft Dynamics GP; the first three posts covered the prerequisites, installation and adapter configuration. This one will show the step-by-step process to create a new integration between Microsoft Dynamics GP 2010 and Microsoft Dynamics 2011.
To create a new integration between Microsoft Dynamics GP and Microsoft Dynamics CRM, open the Connector for Microsoft Dynamics from the Windows Start menu ().
To create a new integration, click the New Integration button on the toolbar;