So that’s so relieving to know that we do not have to wait to get a compatible Microsoft Dynamics Connector for Microsoft Dynamics GP 2013.
The current version V2 RU2 supports Microsoft Dynamics GP 2013 already. Check out this post on official Connector blog: Connector for Microsoft Dynamics V2 RU2 supports Microsoft Dynamics GP 2013.
VAIDY
This post intends to brief the list of Integration Models that are available and what’s the preferable sequence in which we have to integrate the First Time records.
The Integration Models available are:
1. Account (CRM) to Customer (GP)
2. Customer (GP) to Account (CRM)
3. Flat Fee (GP) to Product (CRM)
4. Kit (GP) to Product (CRM)
5. Miscellaneous Charges (GP) to Product (CRM)
6. Order (CRM) to Sales Order (GP)
7. Price Level (GP) to Price List (CRM)
8. Sales Invoice (GP) to Invoice (CRM)
9. Sales Item (GP) to Product (CRM
10. Sales Order (GP) to Order (CRM)
11. Salesperson (GP) to ERP System User (CRM)
12. Service (GP) to Product (CRM)
13. UofM Schedule (GP) to Unit Group (CRM)
Alright, that’s one long list, not so long though. Now we must understand what’s the scope of this integration and once we install this integration model, what’s the impact on CRM.
The following will be completely disabled in CRM once we install and configure this Adapter:
1. CRM Product will be disabled from allowing users to create new products in CRM.
2. Unit Group will be disabled as well.
3. Price Headers & Details will be disabled as well.
4. Discount Lists will be disabled as well.
5. Invoices can only be viewed in CRM.
6. Orders are editable only till the moment of integrating it into GP.
In a nutshell, you won’t be able to create anything related to a Product in CRM. This will be permanently disabled in order to establish a centralized control in GP.
Now, let’s see the details about CRM Adapter’s Initial Data Synchronization. This Initial Data Synchronization should be run in either of the following scenarios:
1. New GP and New CRM systems.
2. New GP and Existing CRM systems.
3. New CRM and Existing CRM systems.
4. Existing GP and CRM systems.
It depends solely on how a client decides it’s data integration. So let’s not discuss that here.
The following limitation is highlighted in this Adapter, which may or may not go down well with people out there:
Either Account (CRM) OR Contact (CRM) can be mapped and integrated to Customer (GP).
That means, CRM can maintain both Accounts and Contacts, but Adapter can be configured to map only either of both. In an ideal situation, we can map Accounts (CRM) to Customers (GP) and More Address (CRM) to Customer Addresses (GP). Thus removing Contacts (CRM) from our scope.
There is something called Picklist Synchronization Utility, which I will cover in the next post. This must be run before the Initial Data Synchronization. So this process is very important to know.
The following is the sequence with which we are suppose to run the Initial Data Synchronization:
1. Salesperson (GP) to ERP System User (CRM)
2. U of M Schedule (GP) to Unit Group (CRM)
3. Pricing Header:
3.1. Price Levels (GP) to Price List (CRM)
3.2. Items (GP) to Products (CRM)
4. Customers (GP) to Accounts / Contacts (CRM)
The above integrations must be done one by one. All these integrations should not be activated all at once.
Next post will explain Picklist Configuration Utility and how useful it is for us to control the integration in a better manner.
VAIDY
Till now, Microsoft Dynamics Team has released 4 versions of this CRM GP Adapter:
1. CRM Adapter Base Version – GP 10 & CRM 4
Details of this release can be read by clicking the above link. There is a terrific list of FAQ and much needed information. As the title says, it’s the base version and did what it was meant to. Read all CRM fields and make it available for GP integration and vice versa.
2. CRM Adapter FP1 – GP 10 & CRM 4
Tremendous improvement with this FP1. Below are the notable ones:
2.1. CRM Custom Fields are made available for Integration Mapping.
2.2. Critical fixes pertaining to previous release.
2.3. Integration Status messages are more meaningful and logging of those messages (from GP Web Services) are comprehensive.
2.4. Picklist Synchronization Utility – We will discuss this utility as a separate topic. Trust me, this is certainly a boon to this Adapter.
3. CRM Adapter FP2 – GP 10 & CRM 4
With this release comes the power of choice (as mentioned in the release article). You can select the integration configuration between:
3.1. CRM On-Premise Integration alone.
3.2. CRM On-Premise and CRM Hosted Integration.
More technical details are clearly explained in the release article. So I have got nothing more to say.
4. CRM Adapter FP3 – GP 10 / 11 (GP2010) & CRM 4
With this release, we have got an Adapter which is Dual Compatible. It now supports GP10 / GP2010 along with CRM4 (Hosted / On Premise).
I have not implemented this version yet and am scheduling it at the earliest.
Question: Why do I have to know the history of this Adapter? I will just download the latest one, follow the instructions to implement it. What’s the big deal in that?
Answer: The first release of this Adapter was in October 2009. The FP3 release was in May 2010. Now that’s what I admire. This tool has been taken seriously by Microsoft Dynamics Dev Team and they have given us a tremendously important and easy-to-use Integration tool. People may think that I am advocating for this Tool without knowing it’s complete character. But for me, till I have seen it, it’s awesome. What you need as a basic integration between GP and CRM, scope of the integration is very well defined and quite contenting.
This article is aimed at instilling a Confidence in Consultants & Customers that this tool is certainly a good one for real-time implementations.
More to come.
VAIDY
The best thing that could happen for Dynamics GP is the CRM Integration tool. This leverages the GP Functionality and extends it to CRM (or vice versa may be). There are so many things that I could talk about this beautiful Integration Tool. Some of them are:
1. Free of cost (though it must be obtained thru’ a Partner).
2. No extra software licenses.
3. eConnect as backbone.
4. Utilizes GP Web Services thoroughly.
5. Easy to use.
6. Scheduling each and every Integration to and fro GP & CRM.
7. A perfect two-way integration model without much hassles.
8. Very intuitive configuration (though it requires a bit of technical knowledge).
9. Tools such as Picklist Configuration, enhances the control of data flow.
10. Standard CRM Fields & Custom CRM Fields mapping To & Fro GP.
… and more.
There are several comprehensive tools available from reputed ISVs such as SmartConnect from eOne. And those are pretty elaborative and extensive. But this particular tool from Microsoft Team does give you what you require as basic need. To integrate data from CRM to GP and vice versa.
Not all clients would require elaborative tool for their day to day business. For instance, a business unit which require to integrate only Accounts (CRM) and Customers (GP) alone does not require a tool more than Microsoft Dynamics CRM Adapter.
Let’s start discussing about this tool in depth thru’ coming posts in this series.
Disclaimer: I discuss this based on what I have learned and how I have implemented this. I may be focussing on a particular way of implementing and using this. That’s not the end of it. We may have more ways (optimized ways) of implementing and using it. I welcome comments, feedbacks, advises, etc. from all of you to make this series meaningful and informative.
VAIDY
Inside Microsoft Dynamics GP announces the Release of Microsoft Dynamics GP 10.0 & CRM 4.0 Adapter Feature Pack 1 & SDK.
And this would mean a lot to existing customers who have implemented this Integration or on the verge of implementing it.
Personally I would like to explore this release to gain more information how to leverage my current GP CRM Integration Process.
All Consultants, Partners & Existing Customers, please do make a visit to the Article (link given above).
VAIDY
It was a pretty long day today. We had a Conference Room Pilot session on CRM & GP Integrated Solution.
While doing the testing, the Consultants were pretty much cleared all possible scenarios in CRM and at critical stage, demonstrating the CRM to GP Sales Order Integration. Much to our frustration, integration failed. They checked everything: CRM Adapter Mapping, Customer Record, almost everything. Yes, ALMOST everything and NOT everything.
Could not trace out the issue and we continued with GP side testing. Once the session got over and End-Users left for the day, I and the Consultants started debugging the issue further.
I always had insisted every Developer to open eConnect Logs in case there is any issue with Integration Tool, Web Portal, Web Services and anything which uses eConnect as business logic. And I was right. eConnect stored the error messages for those failed transactions. And once we probed those messages, we got clarity. It was simple record issue and nothing to do with Integration Adapter. We have planned to correct the record and then continue with our next level testing.
One critical issue with this CRM to GP Adapter is that it does not intimate the User who enter the records in CRM about the validation errors. Something like “Customer Payment Terms does not exist.”, “Document ID does not exist.”, etc.
While we could still go and check the Adapter log or eConnect, how the User would come to know that he entered a wrong record and tried integrating it? This particular Adapter is not User-Friendly to the extent that we would like to see. Though it is in its initial phase, this is very basic.
If I don’t know what wrong I committed when I entered a record and forced to depend on a Consultant to trace the issue, it is really something which is clearly not a positive sign.
We still have to live with it, unless Microsoft Tech Team consider this and do something about it.
VAIDY
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.
VAIDY
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.
VAIDY
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
Dynamics GP - Learn & Discuss 