A Critical Miss in CRM – GP Adapter – End

I am working on integrating CRM with GP for very specific requirements and you would have read my findings and explanations in the past two articles.

That’s when I came to read this article: Successful Model for CRM Implementation. This is pointed out in The eOne Dynamics GP and CRM Blog at the right time, I would admit.

Can’t agree for more.

A MUST READ for all Consultants, Customers & Implementation Partners.


A Critical Miss in CRM – GP Adapter – Contd

There is a change in what I explained in previous article.

CRM GP Adapter does have a Mapping Facility where in you can select Sales Document Type & Sales Document Type ID, in the Microsoft Dynamics CRM Adapter Mapping Settings.

If there is no settings done here, it works exactly like what I explained earlier. If it finds this setting done, it creates the Sales Order accordingly.

[Thanks to Consultants, Prince & Prashantha, who are working on this Implementation and sharing this knowledge with me].

But still, the ability to create Sales Orders from CRM to GP by dynamically selecting Order Type ID & respective Document Number is still a miss.

More to follow as and when I gain more knowledge.


A Critical Miss in CRM – GP Adapter

This is the first time I am working on CRM GP Adapter, and I am closely monitoring it being implemented and not working on it directly.

In our business scenario, we maintain different SOP Order Document IDs for different Departments and there by different running SOP Order Document Numbers. For instance, Sales Department Orders will have a Document ID as SALES and SOP Number Sequence will be something like SALES-0000001. Services Department Orders will have a Document ID as SERVS and SOP Number Sequence will be something like SERVS-0000001 and so on.

Incidentally, when I was working on CRM Order Integration to GP Sales Order, I was curious to know how the Sales Order in GP is created by using which Document ID and which running sequence number is used to generate my SOP Number in GP. The below is the answer to this query:

The highlighted SOP Default Order ID is what CRM takes to create all Sales Orders to get pushed from CRM to GP.

This we (I and another Consultant) confirmed by deleting that Default Order ID from SOP Setup and running the CRM to GP Integration for an Order. The below is the eConnect Error Log:

Microsoft.GreatPlains.eConnect Version=
.Net SqlClient Data Provider

Procedure or function ‘taSopHdrIvcInsert’ expects parameter ‘@I_vDOCID’, which was not supplied.

at Microsoft.Dynamics.GP.eConnect.eConnectMethods.ExecStoredProcedures(String xml)

at Microsoft.Dynamics.GP.eConnect.eConnectMethods.eConnect_EntryPoint(String ConnectionString, ConnectionStringType ConnectionType, String sXML, SchemaValidationType ValidationType, String eConnectSchema)

CRM Adapter tries to get the Default SOP Order ID from SOP Setup and when it did not find any one being setup, it passed NULL STRING as DOCID to respective Web Services method and in turn creating a NULL STRING node in respective eConnect method.

But isn’t this absurd? When GP allow us to create as many Order IDs as we want and have as much different SOP Document Number patterns as that of Order IDs, why can’t we have the same in CRM?

In my opinion, when we have an interface between any two applications, we should have atleast the critical fields (or factors) mapped to each other. Otherwise, the purpose of integrating two products is not satisfied completely.

I do understand that some Customers maintain one single Order ID across it’s Sales Orders. But then what about the Customers who religiously maintain different Order IDs for different scenarios?

Will be working more on this in coming days and will update you all with my findings.