Contact

Industry Leading Blog for Manufacturers

When integrating Microsoft Dynamics 365 with other systems such as SAP, it's common to store reference/lookup data from the other systems in custom entities in Dynamics 365. For example, SAP has a payment terms table that has both a unique code (e.g., NT30) and a name (e.g., Net 30).

When designing the custom entity in Dynamics 365 to store the reference data, people frequently decide to store either the code OR the name value in the native name field for the custom entity -- in other words, the primary attribute that appears in the lookup fields for the entity. They will then create a custom field for the other value. Then all other solution components, such as integrations, reports, Power BI, plugins, or workflows, are designed and built based on the value in the native name field.

ILLUSTRATION OF A METHOD WE DISCOURAGE

OPTION 1

  • new_name: Net 30
  • new_sap_code: NT30

OPTION 2

  • new_name: NT30
  • new_sap_name: Net 30

This is usually fine to start with. Everything is chugging along nicely, then BAM! The client decides that they want the other SAP value in the native name field because the users find it easier to work with. Which means that all other downstream solution components must be revised, tested, and deployed.

So how do you avoid this situation?

The eLogic recommended practice is to always have custom fields for both the code and name, and then configure/customize the native Dynamics 365 name field (i.e., primary attribute) to use as you wish. You could show only the code, only the name, or a combination of the two in the native name field. Typically, the native name field will be populated via the integration or a workflow. Both methods are easy to change as necessary.

This design provides maximum flexibility in case there is a desire to change the value that appears in the native name field, while having minimal (hopefully zero) impact on any other solution components such as the integrations or reports. It also eliminates any wasted time discussing which value should be in the native name field.

ILLUSTRATION OF THE METHOD WE RECOMMEND

Here are 4 examples of how the data could be mapped using the recommended method:

Option 1

  • new_name: Net 30 (NT30)
  • new_sap_code: NT30
  • new_sap_name: Net 30

Option 2

  • new_name: NT30 (Net 30)
  • new_sap_code: NT30
  • new_sap_name: Net 30

Option 3

  • new_name: Net 30
  • new_sap_code: NT30
  • new_sap_name: Net 30

Option 4

  • new_name: NT30
  • new_sap_code: NT30
  • new_sap_name: Net 30

As you can see from the illustrations of the recommended method, the code and name fields always stay the same. The only thing that changes is the value in the native name field. And the only solution component that changes as a result of the decision to change the value is either the mapping in the integration or the workflow, both of which are simple and quick changes.

Next time you are storing data from another system in Dynamics 365, be sure to use the recommended method and save yourself some trouble in the future!

 

 

x


Stay up to date on the leading industry solutions by subscribing to our blog digest.
What can we help you with?

CONTACT US

(585) 506-4600  |  (844) 506-4600