GPWindow is Everything Dynamics GP. Try the Custom GP Search engine which searches high quality GP Blogs, and the Microsoft Dynamics GP Community Forums.

In this post I will talk about the changes made to the API for eConnect for Microsoft Dynamics GP 2010 and how developers can take advantage of these changes to affect their custom application. If you have been using eConnect 2010 you have already realized that there is a new Windows service running called the eConnect for Microsoft Dynamics GP 2010 Integration Service. This is a change from the version 9 and 10 days where there was a COM+ application for eConnect that appeared under Component Services. Like the eConnect COM+ application, the eConnect 2010 service runs under a Windows user that requires DYNGRP role access in the DYNAMICS and company databases. I will breakdown some of the other changes in the following sections.
eConnectMethods Class
There are several new methods added to this class and they are discussed in the eConnect Programmers guide in MSDN here. These methods provide the functionality for reading and writing to the Dynamics GP databases. One of the more interesting changes is that the CreateTransactionEntity method returns a string value. This string is the XML that is passed to the eConnect API and it includes the generated Document Number of the transaction. So if you are integrating Sales Transactions and do not pass the SOPNUMBE value in the XML, the eConnect API retrieves the next number internally and you will then be able to see the SOPNUMBE in the string value returned by the CreateTransactionEntity method.
The CreateEntity, CreateTransactionEntity, DeleteEntity, DeleteTransactionEntity, UpdateEntity, and UpdateTransactionEntity may have different names but they all go down the same road. In other words, right now they have been named this way for readability but have no real big differences. For instance, it is possible to create a GL Transaction by passing a GL Transaction Type XML document to the DeleteEntity method. The only difference between these methods is that the CreateTransactionEntity returns a string and the others return a bool! An advantage to having different naming conventions would be for readability of your code. If you have an application that does multiple operations like creating new transactions, updating existing customers, and deleting addresses, you could pass the specific XML documents to the desired methods so the code would be easier to understand from a developer perspective. For example, you would pass your XML document that updates a customer record to the UpdateEntity method and you would pass a new Sales Invoice transaction XML document to the CreateTransactionEntity method.
RequireProxyService
You can bypass using the new eConnect Windows service so your application calls the eConnect stored procedures under the context of the user running the application. Thus the eConnect service does not even need to be running and the user(s) running the application will need to have access in SQL server. You can give them DYNGRP role access or something more granular like spefic access to eConnect stored procedures and tables. You can take advantage of this option in a couple ways where you will set the RequireProxyService configuration property to false. The default value for this setting is true so by default the eConnect service needs to be running. If it is not, you will receive a "There was no endpoint listening at net.pipe://localhost/Microsoft/Dynamics/GP/eConnect/EntityOperations that could accept the message" error when the eConnect API attempts to intialize the service proxy.
There are two ways to use this configuration setting:
1. Add a key for this setting in your application config file like below:
<?xml version="1.0"?>
<configuration>
<appSettings>
<add key="RequireProxyService" value="false"/>
</appSettings>
</configuration>
2. In your application code, set the RequireProxyService property of the eConnectMethods class to false:
// Add reference to Microsoft.Dynamics.GP.eConnect.dll in Visual Studio Project
// Add using statement to Microsoft.Dynamics.GP.eConnect namespace
using Microsoft.Dynamics.GP.eConnect;
// Instantiate eConnectMethods class to use RequireProxyService
eConnectMethods eConnect = new eConnectMethods();
eConnect.RequireProxyService = false;
An interesting related tidbit is that the Web Services for Microsoft Dynamics GP 2010 takes advantage of this setting. If you have the Microsoft Dynamics GP Web Services installed, take a peek at the WSServiceAppSettings.config file under the C:\Program Files\Microsoft Dynamics\GPWebServices\ServiceConfigs folder. You will see a line at the bottom of the file that sets the RequireProxyService to false. You can even go ahead and stop the eConnect Integration Service and attempt a call to a method in the Microsoft Dynamics GP 2010 Web Services and it will be successful. Go ahead I know you want to try! The web services call will be successful because the eConnect service proxy is bypassed and the call to the eConnect SQL objects is made under the context of the user running the Microsoft Dynamics GP Service Host service that is used by the Microsoft Dynamics GP 2010 Web Services.
ReuseBaseTransaction
When using multiple transaction types in a single XML document, a change to the API for eConnect 2010 was made in regards to the way transactions are processed. If you use the eConnectProcessInfo node for each transaction type in the XML document, then each transaction type will run as a seperate transaction. This is fairly signficant because the entire XML document is not treated as one transaction. So transaction types that are successful will not rollback if an error is hit with a transaction type that runs later in the XML. Take for example the following XML:
<eConnect>
<SOPTransactionType>
<eConnectProcessInfo>
<ConnectionString>Server=SQLSVR;Database=TWO;integrated security=SSPI;persist security info=False;Trusted_Connection=Yes</ConnectionString>
</eConnectProcessInfo>
<taSopLineIvcInsert_Items>
<taSopLineIvcInsert>
<SOPTYPE>2</SOPTYPE>
<SOPNUMBE>ORDNJ00069168</SOPNUMBE>
<CUSTNMBR>AARONFIT0001</CUSTNMBR>
<DOCDATE>3/16/2011 12:00:00 AM</DOCDATE>
<LOCNCODE>WAREHOUSE</LOCNCODE>
<ITEMNMBR>256 SDRAM</ITEMNMBR>
<AutoAssignBin>0</AutoAssignBin>
<UNITPRCE>15.00</UNITPRCE>
<QUANTITY>48.00</QUANTITY>
<DOCID>STDORD</DOCID>
<UOFM>EACH</UOFM>
<DEFEXTPRICE>1</DEFEXTPRICE>
</taSopLineIvcInsert>
</taSopLineIvcInsert_Items>
<taSopHdrIvcInsert>
<SOPTYPE>2</SOPTYPE>
<DOCID>STDORD</DOCID>
<SOPNUMBE>ORDNJ00069168</SOPNUMBE>
<LOCNCODE>WAREHOUSE</LOCNCODE>
<DOCDATE>3/16/2011 12:00:00 AM</DOCDATE>
<CUSTNMBR>AARONFIT0001</CUSTNMBR>
<CREATECOMM>1</CREATECOMM>
<CREATETAXES>1</CREATETAXES>
<DEFTAXSCHDS>1</DEFTAXSCHDS>
<DEFPRICING>1</DEFPRICING>
<BACHNUMB>CPR 66</BACHNUMB>
</taSopHdrIvcInsert>
</SOPTransactionType>
<POPTransactionType>
<eConnectProcessInfo>
<ConnectionString>Server=SQLSVR;Database=TWO;integrated security=SSPI;persist security info=False;Trusted_Connection=Yes</ConnectionString>
</eConnectProcessInfo>
<taPoLine_Items>
<taPoLine>
<PONUMBER>A-0001</PONUMBER>
<DOCDATE>2011-05-02</DOCDATE>
<VENDORID>ACETRAVE0001</VENDORID>
<LOCNCODE>WAREHOUSE</LOCNCODE>
<VNDITNUM>256 SDRAM</VNDITNUM>
<ITEMNMBR>256 SDRAM</ITEMNMBR>
<QUANTITY>1</QUANTITY>
<REQDATE>2011-05-09</REQDATE>
<RELEASEBYDATE>2011-05-02</RELEASEBYDATE>
<PRMDATE>2011-05-09</PRMDATE>
<PRMSHPDTE>2011-05-02</PRMSHPDTE>
<UNITCOST>3164</UNITCOST>
<UOFM>Each</UOFM>
<ORD>16384</ORD>
</taPoLine>
</taPoLine_Items>
<taPoHdr>
<PONUMBER>A-0001</PONUMBER>
<VENDORID>ACETRAVE0001</VENDORID>
<VENDNAME>IRIDIUM SATELLITE LLC</VENDNAME>
<DOCDATE>2011-05-02</DOCDATE>
<PRMDATE>2011-05-09</PRMDATE>
<PRMSHPDTE>2011-05-02</PRMSHPDTE>
<REQDATE>2011-05-09</REQDATE>
</taPoHdr>
</POPTransactionType>
</eConnect>
If the SOP transaction is successful but the POP transaction fails for some reason, the SOP transaction will not rollback. This is a change when compared to how this worked in previous versions of eConnect. However, there is a configuration setting called ReuseBaseTransaction that can be used to make sure that each transaction type will use the same SQL connection so everything would rollback in the XML document. You can set ReuseBaseTransaction to true by adding it to your application config file or the…

Getting started with GP Integrations?
If you are getting started with Integrations check out these posts - Sandip Jadhav - Types of Integration methods with Dynamics GP, which gives you a brief sneak-peek about the 8 tools available with GP for Integration. Integrating to Dynamics (GP) The Basics by the Touchstone guys. In this post they explain the first question that gets asked is “what is the best way of integrating?” and several ways of finding what tables do you need to integrate to?
There’s also a nice post - Integration - All About Attitude by the nice people at Rose Business Solutions. Steve Endow has a post on "Real Time" Dynamics GP Integrations in which he discusses the steps to create a “real time” integration between Dynamics GP and another system.
Other posts worth highlighting are Integration to Concur Travel & Expense by Geoffrey Wayong, also covered by the Dynamics GP Team at NEW Integration Capabilities with Concur Travel & Expense!
Related categories on GPWindow are DEVELOPMENT which includes – Dexterity, Developer Toolkit, GP SDK, Tables Information, Testing, VBA and VS Tools for GP and CUSTOMIZATIONS which covers – modifier, Extender and Macros.
Steve Gray says - “I spend an amount of time advising people to 'read the manual' when they write in with questions.” and points us to the - eConnect Help Online.
Also in the eConnect sub section, you can view posts regarding using eConnect to get data into Dynamics GP with some examples. eConnect Integration Service for Microsoft Dynamics GP 2010 by Mariano Gomez contains information about eConnect 2010 and how it is better than its predecessors. There other detailed posts by Steve Endow with his troubleshooting notes - More than I ever wanted to know about eConnect and MSDTC and Troubleshooting eConnect "System Error" Message. Steve also shares some performance benchmarks of eConnect in the post eConnect Performance Benchmarks.
Mariano covers Retrieving Microsoft eConnect 10.0 Version and Steve has a post on Checking eConnect Version Number Programmatically.
You can also find some examples to use eConnect to get data into GP from Steve like Using eConnect to import Inventory Adjustments with Multi-Bin, Clearing Existing Field Values Using eConnect, eConnect Bank Transaction Import.
From Sage, Quickbooks, Peachtree
You should definitely check out the posts in the Rapid Migration and Implementation Tools if you are working on bringing customers from one of these accounting systems. The free tools…

The eConnect Programmer's guide discusses creating a custom XML node and stored procedure so developers can process new types of data. For example, a custom or 3rd party table could be updated when integrating a master record like a Customer or a transaction like a Sales Invoice using eConnect. The strategy that I will discuss below is for developers out there that would like to go one step further by referencing their own custom assembly. This assembly can be referenced in their Visual Studio project which would allow them to serialize the eConnect XML document with the custom node.
In the "Custom XML Nodes" section of the eConnect Programmers guide, the custom stored procedure is named eConnectCustomProcedure. It has one input parameter named CUSTNMBR that holds a Customer ID value. The custom XML node would look like this:
<eConnectCustomProcedure>
<CUSTNMBR>AARONFIT0001</CUSTNMBR>
</eConnectCustomProcedure>
To use your custom XML node you will need to include this in a eConnect XML document like the following:
<eConnect xmlns:dt="urn:schemas-microsoft-com:datatypes">
<RMCustomerMasterType>
<eConnectProcessInfo>
<eConnectProcsRunFirst>TRUE</eConnectProcsRunFirst>
</eConnectProcessInfo>
<eConnectCustomProcedure>
<CUSTNMBR>CONTOSOL0002</CUSTNMBR>
</eConnectCustomProcedure>
<taUpdateCreateCustomerRcd>
<CUSTNMBR>CONTOSOL0002</CUSTNMBR>
<CUSTNAME>Contoso, Ltd.</CUSTNAME>
<TAXSCHID>USALLEXMPT-0</TAXSCHID>
<ADRSCODE>PRIMARY</ADRSCODE>
<ADDRESS1>321 Main S </ADDRESS1>
<CITY>Valley City</CITY>
<STATE>ND</STATE>
<ZIPCODE>56789</ZIPCODE>
<COUNTRY>USA</COUNTRY>
<PHNUMBR1>13215550100</PHNUMBR1>
<PHNUMBR2>13215550110</PHNUMBR2>
<FAX>13215550120</FAX>
</taUpdateCreateCustomerRcd>
</RMCustomerMasterType>
</eConnect>
<xs:complexType name="RMCustomerMasterType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="eConnectProcessInfo" nillable="true" type="eConnectProcessInfo" />
<xs:element minOccurs="0" maxOccurs="1" name="taRequesterTrxDisabler_Items" nillable="true" type="taRequesterTrxDisabler_Items" />
<xs:element minOccurs="0" maxOccurs="1" name="taUpdateCreateCustomerRcd" nillable="true" type="taUpdateCreateCustomerRcd" />
<xs:element minOccurs="0" maxOccurs="1" name="taCreateCustomerAddress_Items" nillable="true" type="taCreateCustomerAddress_Items" />
<xs:element minOccurs="0" maxOccurs="1" name="taCreateInternetAddresses_Items" nillable="true" type="taCreateInternetAddresses_Items" />
<xs:element minOccurs="0" maxOccurs="1" name="taCreateParentID" nillable="true" type="taCreateParentID" />
<xs:element minOccurs="0" maxOccurs="1" name="taParentIDChild_Items" nillable="true" type="taParentIDChild_Items" />
<xs:element minOccurs="0" maxOccurs="1" name="eConnectCustomProcedure" nillable="true" type="eConnectCustomProcedure" />
</xs:sequence>
</xs:complexType>
I then added a new complex type near the bottom of the file right above the </ xs:schema> end tag. I used the below string type for the CUSTNMBR parameter that the custom procedure needs like below:
Next I used the xsd.exe tool to build a new class based on the XSD file. I used the below syntax at a command prompt in the C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC directory. This is the Microsoft Visual Studio Command Prompt for Visual Studio 2010 that is available in the Microsoft Visual Studio 2010 program folder.
This step creates a class file named RMCustomerMaster.cs in the C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC folder. I added the new class file to a Visual Studio 2010 C# library project named RMCustomerCustomECONNECT that used a default namespace of RMCustomerCustomECONNECT. You could modify the code in…

I had a case this week that was asking a fairly commonly asked question about integrating address information using eConnect. The scenario is that we want to update a customer or vendor address and the previous address had three lines in the address and the new address only has two lines. When the update is processed, Address Lines 1 and 2 have been updated, but Address Line 3 has the old data and has not been cleared.
So how can I update Address Line 3 with blank data?
Background
Let's start with a little more background information.
Using the <taCreateVendorAddress> node, we can create a new vendor address with 3 lines. Below is the example XML used:
<eConnect>
<PMVendorAddressType>
<taCreateVendorAddress_Items>
<taCreateVendorAddress>
<VENDORID>ACETRAVE0001</VENDORID>
<ADRSCODE>WAREHOUSE</ADRSCODE>
<UPSZONE></UPSZONE>
<SHIPMTHD></SHIPMTHD>
<TAXSCHID></TAXSCHID>
<VNDCNTCT></VNDCNTCT>
<ADDRESS1>Unit 42</ADDRESS1>
<ADDRESS2>XYZ Building</ADDRESS2>
<ADDRESS3>100 Main Street</ADDRESS3>
<COUNTRY>Australia</COUNTRY>
<CITY>Perth</CITY>
<STATE>WA</STATE>
<ZIPCODE>6000</ZIPCODE>
<PHNUMBR1></PHNUMBR1>
<PHNUMBR2></PHNUMBR2>
<PHNUMBR3></PHNUMBR3>
<FAXNUMBR></FAXNUMBR>
<UpdateIfExists>1</UpdateIfExists>
<RequesterTrx></RequesterTrx>
<CCode></CCode>
<USRDEFND1></USRDEFND1>
<USRDEFND2></USRDEFND2>
<USRDEFND3></USRDEFND3>
<USRDEFND4></USRDEFND4>
<USRDEFND5></USRDEFND5>
</taCreateVendorAddress>
</taCreateVendorAddress_Items>
</PMVendorAddressType>
</eConnect>
This creates the address as shown in the screenshot below:
So now we want to update this address. We no longer want the XYZ Building line in the address and…
During an e-connect integration, we might come across a situation where the currency ID remains blank in the transaction entry despite having a functional…
