Home » Listing Details
Top Websites
  1. Dynamics GP Help
    Over 6500 resources listed.
  2. Mark Polino's DynamicAccounting.net
    Over 5100 resources listed.
  3. Rose Business Solutions Blog New
    Over 2200 resources listed.
  4. Developing for Dynamics GP - By David Musgrave and the MS GP Dev Support Team
    Over 1100 resources listed.
  5. Mariano Gomez at The Dynamics GP Blogster
    Over 1000 resources listed.
  6. Microsoft Dynamics Partner Community Blog
    Over 900 resources listed.
  7. Christina Phillips, Steve Endow & Lorren Zemke at Dynamics GP Land
    Over 700 resources listed.
  8. Mohammad Daoud's Dynamics GP Blog
    Over 600 resources listed.
  9. Vaidy Mohan at Dynamics GP - Learn & Discuss
    Over 500 resources listed.
  10. Inside Microsoft Dynamics GP Official Blog
    Over 500 resources listed.
  11. eOne Business Solutions Blog
    Over 400 resources listed.
  12. About Dynamics, Development and Life
    Over 300 resources listed.
  13. Frank Hamelly at GP2theMax
    Over 300 resources listed.
  14. Dynamics CPM
    Over 300 resources listed.
  15. BKD Dynamics GP Insights Blog
    Over 200 resources listed.
  16. Leslie Vail at Dynamics Confessor Blogspot
    Over 200 resources listed.
  17. Victoria Yudin's Dynamics GP Website
    Over 200 resources listed.
    Victoria Yudin
  18. Janakiram M.P. at DynamicsBlogger
    Over 100 resources listed.
  19. VS Tools Forum
    Over 100 resources listed.
    Your Resource for Visual Studio Tools for Dynamics GP
  20. Inside Microsoft Dynamics GP Official Blog
    Over 100 resources listed.
  21. US Dynamics GP Field Team Blog
    Over 100 resources listed.
  22. Catherine Eibner MBS Developer Evangelist
    Over 100 resources listed.
  23. Sivakumar Venkataraman at Interesting Findings & Knowledge Sharing
    Over 100 resources listed.
  24. Dynamics Small Business
    Over 100 resources listed.
  25. Belinda, The GP CSI
    Over 100 resources listed.

Title:A Critical Miss in CRM - GP Adapter
Description: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.

Link Owner:
Date Added:June 17, 2010 03:11:36 AM
Number Hits:5
RatingsAverage rating: (0 votes)

No Reviews Yet.