Microsoft Dynamics GP integration with MS CRM, where eConnect doesn’t work

So, if you plan “standard” integration, our suggestion is to deploy eConnect.  If you use third party GP modules, such as Wennsoft, Mekorma and others, you will have to use SQL Stored Procedures to feed data into Great Plains.  Let’s consider high-level technical scenarios:

1. CRM->GP.  You have two scenarios here.  The first scenario works if you are strong Visual Studio developer with C# skills, consider Microsoft CRM SDK programming to pull objects from CRM.  Then to push them to GP, you should create series of stored procedures and call them via ADO.Net objects in C# project.  VB.Net should be also OK, however you may see fewer number of sample codes to help you in MS CRM SDK objects programming.  In the second scenario, if you don’t really like the idea to deploy CRM SDK based Visual Studio .Net project, then simply create new database (named something like crmcustomization, as you can not create custom stored procedures and views in CRM databases – they will be wiped out by upgrade).  Then go ahead and create set of stored procedures, which will pull and mark data as processed from MS CRM – here you should get good familiarity with linking CRM tables by GUID column
2. GP->CRM.  If you need objects to go backward to CRM, then the only option would be MS CRM SDK (if you are not using something like Scribe or another tool available for purchase on the market).  Pulling data from Great Plains is fairly simple.  Research tables structure: Tools->Resource Description->Tables and you will be prepared to send master records: customer, vendor, employee, account; work transactions: quotes, orders (SOP10100 and SOP10200 tables), etc.
3. eConnect posting dilemma.  If you are deploying Connect to feed Sales transactions to GP from your eCommerce application, then you will realize that you can not force eConnect to post sales batches.  eConnect by its architecture works with master and work records only.  To do posting you have two options – first one would be code posting logic in SQL or Microsoft Dexterity; the second option is to deploy Albaspectrum posting server, which utilizes Dexterity posting logic and allows you to put the batch in the approved posting queue – then Microsoft Dexterity will do the rest of posting job.  Posting Server works with all standard GP modules