top of page

Destructive Master Data Management

Updated: Mar 20

This is one of the posts which I could probably mark with a Destructive Advice tag. I think I will add it to my list of tags one day. A piece of destructive advice by the Evil ERP Consultant.

Today, in my destructive series, I want to show you how to ruin your dimensions posting in Business Central with the help of the Master Data Management extension. All we need to wreck havoc on our data is the proper setup of the table synchronisation. Dimension Value table is a good candidate for the disastrous configuration - dimensions are often synchronised between multiple companies, and this table has a good potential for exploit. Let's see how we can achieve our evil goals.


First of all, I will copy the Cronus International company into a new company which I call Cronus Intergalactic. I want to set up Cronus Intergalactic as a recipient of the master data feed from Cronus International. To be sure that I can reliably break posted entries, I need to enable the synchronisation of the Dimension Value ID field, which is initially disabled in the default configuration of master data management.



Next step to arranging the guaranteed ruining of the entries is to make sure that dimension values can be created in both companies independently. So Cronus Intergalactic has its own dimension values besides those received from the master data supplier. This can happen in practice and may not be so disruptive, given the proper configuration, but in combination with the Dimension Set ID integration, this setup is a good recipe for disaster.


Now let's create some dimension values. First, create one in the data source company Cronus International. I will take the Departments dimension as an example and add a new department, Accounting.



Note the Dimension Value ID column in the screenshot. I added it to the page for better visibility, this will help us understand the pitfall that expects us down this road.


Now I switch to Cronus Intergalactic and create another value for the same dimension here. Let it be the IT department. Since at this point in time both companies are identical, the new dimension value ID is also the same.



To ensure the new dimension value flow from the master company to its Intergalactic subsidiary, I disable the "Synch. only coupled records" switch in the integration table mapping and run the synchronisation job.




The Accounting department dimension is now created in Cronus Intergalactic. Since the Dimension Value ID field was included in the integration flow, the new dimension value retained the identifier, and we see two dimension values sharing the same ID.




This doesn't look too good, but how bad can this really be and how will it impact the ledgers? Let's see. I will create a payment journal line and set the Department dimension value to IT. When I'm ready setting up the journal line, I run preview posting.

And here is what I see.




The first G/L entry looks OK, but what about the second one? Why is it showing the Accounting department instead of IT?

If I check dimension values for both G/L entries I will find that both dimension sets will show Accounting for the Department dimension. IT is nowhere to be found in dimension sets.



So not only G/L entries display different dimension values - dimension set entries are inconsistent with the G/L entry they are linked to.


I think, the cause of the problem is quite clear. When building the dimension set, Dimension Management codeunit identifies distinct values based on their ID instead of the dimension value code. Since the ID for for both Accounting and IT departments is the same, the following dimension sets produce the same dimension set ID.



The reverse operation that resolves the dimension set ID to dimension values simply picks the first value with the given ID (dimension value ID is supposed to be autoincremetal and unique, no duplicates are assumed here). So the IT department is completely lost now from all dimension sets.


Conclusion


Synchronisation of autoincremental fields and values derived from these fields, the likes of of Dimension Value ID and Dimension Set ID, is a reliable method of messing up your data. Think twice before enabling the Dimension Value ID in the master data management - it is disabled by default for a reason.

If it must be enabled for some reason, make sure that the dimension values can be entered in one and only one company, never in both.


Sincerely yours,

Your Evil Consultant

399 views0 comments

Recent Posts

See All

Comments


bottom of page