We have a Dynamics 365 client that distributes their products in the US, Australia/New Zealand and in Europe. Each geographical region is a separate division and has its own ERP system, but shares 1 instance of Dynamics 365. Not all divisions sell all the same products. Furthermore, each division may be the first one to develop and introduce a specific product or products. This gives the divisions flexibility but also makes it more difficult to arbitrarily implement a centralized structure around Product info in Dynamics 365 when the ERP systems feeding it are not subject to that structure.
While the plan is to have everyone on a common ERP system in the near future, it was decided that having a common CRM platform was going to be accomplished first and through that effort some centralization/process homogenization would be accomplished. During discovery, as we looked at the Product data for each division we found that while each division uses the same Product ID/SKU for each Product, there are a number of other attributes for each Product that are not yet standardized or which will never be the same across the divisions:
- Product Name
- Standard Cost
- Current Cost
- Date of Introduction/retirement
As Astro, George Jetson’s dog might say, “Ruh-roh, Reorge” . . .
Where’s my ‘3-in-1’ when I need it?
Working on my bicycle as a kid, I always reached for my can of ‘3-in-1’ oil to stop a squeak. In this case, it seemed like we’d need a 55 gallon drum of it because we have a big squeak here. Luckily, we had a few positives going for us:
- The ERP systems are the ones producing the customer-facing documents. Orders and Invoices are being integrated (pushed) one-way into CRM
- We’re using Scribe Software to perform the integrations
But we also had some other requirements:
- The client wanted to be able to see a few fields of the ‘division-unique’ info on the Product form. We also have a set of standard fields for Products that must represent all divisions as it relates to CRM.
- Besides needing the capture some unique info for each division, we also had to allow each division to display a list of only the Products they sell, not just the entire corporate list of Products. And, we needed to find a way to ‘police’ the ability of each ERP system to submit a Product to CRM for the first time.
Hack my Product form
As it turned out, it wasn’t quite as bad as we thought, mainly because the customer-facing docs are all done using ERP. We ended up modifying the Product form by adding a ‘Global Properties’ tab and a ‘Divisional’ tab. As you can see, fields for which there can only be one value regardless of division ended up in the Global section. Then we set up 3 separate sections in the Divisional tab, each with data that is currently or always will be unique for that division:
Now that we had the right ‘buckets’ in CRM, we still had to handle the other requirements.
Work with what you’ve got
We decided that only one ERP system at a time can be in control of changing the global information for a Product. That’s the system that originally feeds the Product to CRM. That ERP updates the Global tab as well as info in its Divisional area. Whatever division that is, is set to be the ‘Controlled By’ division at the top left of the form during the integrations and the ‘Sold by XX’ field that represents that division is set to ‘Yes’ during the integration. From the latter, we can filter the Product lists. The former controls who gets to update the Global data forever after.
So, the first ERP system ‘in’, gets to set the Product Name and other relevant data and ‘controls’ that global data thereafter. If another division’s ERP system sends data indicating either an addition or an update to that Product, it’s data is only written to the Divisional area (and the ‘Sold by XX’ field may also be updated), but nothing is touched in the Global tab. In the above, only the US can modify the Global tab but Australia/New Zealand and Europe have their own divisional info.
Note, that it was necessary for the divisions to standardize their ERP system values that populate the CRM Global option set fields such as Product Segments, ERP Item Class Code, Product Type . . . but Product Names don’t have to be (yet).
The system is working smoothly and allows us to maintain and have visibility to both Global and Divisional data within the same single Product record. While this isn’t a solution for situations where divisional info is not consistent and there is a need for Product info to be exposed to customers, you may find it helpful in your particular scenario. Contact us if you have complex business rules that need to live in harmony between your ERP system(s) and Dynamics 365 system.
By John Clifton, Application Consultant, Dyn365Pros, Microsoft Dynamics 365 Partner, Southern California, San Diego.
