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=10.0.0.0
.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.

VAIDY