Why the eOne CRM to GP templates include custom Entities
Friday, November 26, 2010
Microsoft Dynamics CRM and Dynamics GP are very different applications and exist for very different purposes. What this means is that moving data between them is not necessarily all that simple, and concepts in one application may not exist in the other.
With SmartConnect and the eOne templates we have set out to smooth over as many of these instances as possible to make the integration process easier. I will look at a couple of those scenarios here:
Class ID: You will find that with the eOne templates we have added a field and entity called Class ID onto the account Entity. The Class ID is an important field in GP and needs to be populated when creating a customer in Dynamics GP. So there are a couple of options when building an integration:
1. Use another field in CRM to store a value for Class ID. This could accept free form data entry or be a fixed drop down list.
2. Use a complex calculated field to determine what the class ID should be, based upon other information on the account. e.g. Country, city, type etc
3. Use the templates to have a dedicated field for Class ID.
This class ID has been created as an entity in its own right in CRM. We have a map that keeps this entity in Sync with GP so that any new classes added in GP will automatically be added in CRM. This makes integration mapping easy as you are able to map the Class ID in CRM directly to a validated class ID in GP. This is an example of the flexibility SmartConenct provides. You can use the custom entity provided in the templates or map the Class ID in any other way that is appropriate to a particular implementation.
Payment Terms: This is another field in CRM that acts very differently to the payment terms field in GP. In GP this field drives due dates on invoices – and will impact on cash flow for a business. In CRM this is an informational field that ‘does nothing’. In CRM the payment terms field is a pick list. This causes an issue as there is no way to automate new the addition of new values into this pick list in CRM. So when a new payment term is added in GP it would need to be manually added into CRM.
In the eOne templates we have removed the standard payment term from CRM and replaced it with a new entity and field for Payment terms. This entity is kept in Sync with GP so any new payment terms added to GP will automatically end up in the CRM list. this also ensures that only valid payments can be selected in CRM and passed to GP.
Aging Buckets: On thing that every body within an organization can use is the ageing buckets for a customer. For this reason the templates add a new series of fields to store this information within CRM. The standard maps take this information from GP and moves it across to CRM on a regular basis.
With SmartConnect and the eOne templates we have set out to smooth over as many of these instances as possible to make the integration process easier. I will look at a couple of those scenarios here:
Class ID: You will find that with the eOne templates we have added a field and entity called Class ID onto the account Entity. The Class ID is an important field in GP and needs to be populated when creating a customer in Dynamics GP. So there are a couple of options when building an integration:
1. Use another field in CRM to store a value for Class ID. This could accept free form data entry or be a fixed drop down list.
2. Use a complex calculated field to determine what the class ID should be, based upon other information on the account. e.g. Country, city, type etc
3. Use the templates to have a dedicated field for Class ID.
This class ID has been created as an entity in its own right in CRM. We have a map that keeps this entity in Sync with GP so that any new classes added in GP will automatically be added in CRM. This makes integration mapping easy as you are able to map the Class ID in CRM directly to a validated class ID in GP. This is an example of the flexibility SmartConenct provides. You can use the custom entity provided in the templates or map the Class ID in any other way that is appropriate to a particular implementation.
Payment Terms: This is another field in CRM that acts very differently to the payment terms field in GP. In GP this field drives due dates on invoices – and will impact on cash flow for a business. In CRM this is an informational field that ‘does nothing’. In CRM the payment terms field is a pick list. This causes an issue as there is no way to automate new the addition of new values into this pick list in CRM. So when a new payment term is added in GP it would need to be manually added into CRM.
In the eOne templates we have removed the standard payment term from CRM and replaced it with a new entity and field for Payment terms. This entity is kept in Sync with GP so any new payment terms added to GP will automatically end up in the CRM list. this also ensures that only valid payments can be selected in CRM and passed to GP.
Aging Buckets: On thing that every body within an organization can use is the ageing buckets for a customer. For this reason the templates add a new series of fields to store this information within CRM. The standard maps take this information from GP and moves it across to CRM on a regular basis.
