20 Apr Master Data Management for Microsoft Dynamics NAV (VIDEO)
Recorded presentation of multiple features of Master Data Management System – IT.integro‘s add-on provided to international companies, using Microsoft Dynamics NAV in multiple subsidiaries.
video transcript
Today we will focus on master data management. What I would like to show you today, is our master data system management module, which we have developed for the purpose of global data synchronization.
We often face the situation when a company has one central data base, from which it wants to replicate certain data, like: item cards, production BOM-s, customer cards – to different subsidiaries, which also operate on Microsoft Dynamics NAV.
We had one goal in mind while developing this solution. It was to make this addition as easy as possible to implement. Also setup should be streamlined and managed globally. This module is also flexible and consists of two sub-modules: first is central and the other one is local. I will now show you what it looks like.
What do we have here is a standard Dynamics NAV 2013 R2 international data base version, with a case of Cronus company. This is the main screen and as you can see. I am assigned to a special role – MDMS Administration. Let me introduce a few major concepts which appear in this module.
First is a receiver. Receiver is a company to which we will replicate our data. Because when we open up companies list we will see Cronos International Ltd. and NL Branch. For the purpose of this presentation Cronos International Ltd. will be our master data company, while NL Branch will be our subsidiary to which we want to replicate our data.
First major concept is the receiver which we need to setup in our master data base. All communication uses XML files, which are placed in the certain network location. We considered using web services, but it is not always available, especially in distributed environments, because one of the problems we have faced is that a company has subsidiary in China or India and in that cases we cannot guarantee that connection will be available 100% of the time. This is we have decided to go with files which have very simple interface, we can establish remote connection to distant location, distant environment and we can use FTP for a file transfers. Afterwards it is not supported by this module, but it is a very easy to setup, or we can even send files using e-mail. This is the most flexible approach we could have taken.
To setup a receiver we need to provide a very basic information like number, description, language code which will be used for the one, and couple of network locations. That concludes our basic setup for receiver.
Another major concept is a data set. Data set is a data structure that we will be using to replicate data. If we open a data set we can see that basically it consists of data set header with basic information, and lines which contain references to NAV tables. We need to re-open the data set to in order to be able to make any changes and here we can specify any table from NAV.
Tables can be linked to each other. For instance here we have customer and customer bank account. While customer bank account is indented – one level. There is a relation established between these two lines. So we make sure that for each customer record we were going to send. We will also send it alone with customer bank account which is assigned to this particular customer record.
We also have couple of options available in data set line – it includes „on record exists”. We have two options available: update and skip. For majority of scenarios we will use update, because the main reason we have developed this module, is to allow companies to distribute their master data cards along the organizations. The main scenario while we should use master data management system is that for instance we want to have customer cards, managed in one, central data base and to be distributed to another companies that run Microsoft Dynamics NAV. Then we need to choose „update” as on record exists action, because whenever we receive an unrecorded from central data base we will update whatever we have locally. „Skip” – this record will be simply skipped when there is a similar record created in local data base.
Record-Level Replication is an advance feature which we will talk about later on.
Here we have two similar options: Disable Local insert and Disable Local Delete. From this place we can tell the module that for this particular table users should not be allowed to insert or delete in local environment. Let me tell you one very important thing about this module: it is that we only need to setup everything in one place – in a central data base. We define all required structures in one central data base. There is no need to set it up once again on the receiver site – now we do it all in central data base.
Both, Record-Level Replication and Workflow Status Code – we will talk about it later. Now let me show you details of the data set. Here we specify which fields we want to transfer to local environment. For each single field, we can for instance declare what is the target Field number, because there are some scenarios when we want to have one field replicated into another on the receiver side.
Validate field indicated that the field value should be imported using validate function in NAV.
Translated Field – this is also a feature that we will talk later on. Here is very important feature – Disable Local Modify – it tells that users will not be able to modify this field in local data base.
Last but not least: Processing Order. It tells NAV to process all this fields in a certain order, because in some cases it might be very important that we validate one field before the other.
It is very easy to add new fields here, we just open new window, for instance Collection and Country Region and add it. It is that easy! We need to remember that we only need to perform this setup once – only in central data base. Only one time.
This is our data set. It can consist of many lines with different relations, with different fields and different setup. While it is basically the same as Report Designer – there are many similar structure in those programs.
Now, let’s move on. Introducing another concept, which is Replication.
Replication is a structure that connects Data sets with Receiver. This is replication that is about to transfer our Customers Data to that subsidiary. We can for instance have more than one Data set included here. I will delete it now. For instance if we are sending out customers information, we can simply create one Data set with all fields that we want to maintain globally and then use this universal Data set for different Replications. Whenever policy changes, whenever we want to add another field to be synchronize, we just need to adjust it in one place and it will be included in our Replication from now one. Every Replication can run in two modes: Full and Incremental. Again, this is a very common concept. Full Replication simply takes all relevant records and sends it to the target Data base – target Receiver, while Incremental grabs only those record which have been changed since last replication took place. It is very easy for instance if we have 10 thousands of items, we only need to perform Full Replication once – at the beginning of the process. Afterwards we just run Incremental Replication.
What is very important is that once we have setup Data sets, Receivers and Replication – once we have all the setup ready, we can go one step further and instead of letting user run all this actions, using this buttons on our Replication card, we can set it up using Job Queue. For instance to have our contacts replicated every hour. This is also possible using that module.
What I will now show you is how easy setup is. Let’s switch to another company – our subsidiary. This is entirely new company. I mean it has just been initialise with a couple initial processes, but it is an empty company. Under MDMS setup all we need to full in are those network locations in which MDMS module should be looking for new files, and that is all. For now on we can simply open Replication Inbound Entries window and hit Read New Files. That is all.
Let me show you how that works. Let’s open a list of customers. See, the last customer is Z001 My Test Customer. Now, let’s switch back to central company, open a customer list and it also ends with Z001. Let’s create a new one: Z002. Now it is here, it has just been created in central company. We will now get back to our Data Set to release it, to indicate that it is now allowed to be used. Run Incremental – that was first. Now let’s switch company to our subsidiary. And now into MDMS, click on Replication Inbound Entries and Read New Files. There is a new integrated. Records count – 1 – Successful. If we open Customers List – the customer is here – so it is that easy.
If you want to, for instance, have our whole customers list replicated to another company, it is also very easy. Let’s give it a try. We will now create new company. Let’s say „DK Branch”. Firstly we will need to set up this as a new receiver: Setup-> Receivers-> DK Branch -> it is here already, so we have all appropriate folders created, but not the company in NA. The company has just been created so we just copy this address, we open our DK Branch – see, it is initialised. Let’s have a look. We do not have any customers. It is entirely empty company and everything we need to set up is this folder. For Inbox it will be Archive folder and Confirmation – and that is all. From now on this company is setup to receive the data from Master Data. What do we need to do – we need to switch to our Central Company. See if we have Customers Data to DK – it has never been run, so we need to run Replication and Master Data. Now we switch company to Danish Branch. Go into MDMS -> Inbound Entries -> Read New Files – well it will take few seconds and as you can see we now have all our Customers created. It is very useful feature.
From the beginning of the development of this module we had one goal – to make it easy to use, easy to implement and to use that together with Global Projects, because we do have International Projects when we have a number of subsidiaries around the world. Usually one of the key features of our strategy is to develop one Central Data base, when we store for instants Global Financial Setup. We have global Chart of Accounts, Global Posting Groups created, Global Country Codes – all this Data that is common throughout all subsidiaries in NAV.
When we want to establish a new company in Dynamics NAV, in our world of different subsidiaries in NAV, then we prepare a package of financial data, setup in MDMS and just simply sent all financial data to this new company in NAV. Then we have all the setup we need. It is very useful when we have a number of different subsidiaries worldwide.
I will now show you a few concepts. What we have seen so far is a simple Replication of simple Data. What is important is that this replication takes all customers. Of course it will take only those which have been change since last replication if we decide to use Incremental Mode in Replication. But what if we would like to send only a certain subset of our data to certain subsidiaries?
Well, we have to possible options here. First is that under replications. Of course I have to open it – we can use filters. So let’s say that for Dutch subsidiary we want only to send „RAW” – items with Inventory posting group RAW. That is one possible approach.
Another one is called Record Level Replication. What is that: here we have a special check-mark available. That is indeed Record-Level Replication. What it does is that this particular Receiver has to subscribe for single record. This is done using our special view.
Right now I am using MDMS Admin profile. I will now switch to MDMS Receiver, because there we have a special option available – My Data Items. The idea is that for sure if we have a central company and a number of different subsidiaries that are going to use Global Data, for instance Items, we will have for each company at least one person who will be allowed to access to our Global Master Data Company and check the data to see what available items are – and so on… So day would open this Data base, open this company and see a list of all Data items, which are using Record-Level Replication. If we hit Records here we can see all items available in the system along with few basic fields. What is extremely important is that, this particular view is generic, so it does not matter which table we choose to replicate using Record-Level Replication. It does not matter at all – it will be available here. It is a very generic window and it will work for every single table we want to replicate. And for our Record-Level Replication we simply need to select a record and Set Released. From now on my company will receive item number 1155. As I said this window is generic, it might not be as functional as it could be, because one of our key goals while developing this module is also that we want to adjust as less standard NAV objects as possible and we have succeed it. We have a total of three NAV objects which we adjusted to implement MDMS Solution:
This is codeunit 1 of course, and user setup, because we need to be able to assign user to particular receiver. So we know in which context every user works. Normally when we make an analysis of global requirements we end up with a list of fields that are going to be managed globally, or instance for items. Then common approach is that we prepare a special page that contains only global fields. We also prepare a special list page. The idea is that we do not want users who are working in central data base, to bother with anything that they should not bother, which means that they need to see only those fields which are relevant for Global Master Data purposes.
We have a special page prepared for them, and it is also very easy to integrate this feature into our special item card. On the item card there will be separate options like – show me the list of receivers which this item will be replicated to. It is very easy. Then what we have here is a generic window, so it will suit everyone’s needs. It will be working fine for every single table. We have not wanted to implement any kind of business process within module itself, because we have wanted to have it as flexible as can be and very easy to adjust.
Basically this is Record-Level Replication. Should be said that we do not want all the records to be replicated to certain subsidiaries, to certain receivers, but we wanted to allow receivers to choose which records they want to receive.
There is one more thing related to that – it is Workflow. For instance for items we might want to establish a simple Workflow, saying that item can be in one of four Workflow statuses: New, Under Revision, Ready, Blocked. For instance there might be different departments working on item cards in order to make it complete. It can start with technical department making sure that the item number is correct and description is correct. Then we can move on to financial department filling in fields like custom method or dimensions – we can have a number of different parties engaged in this process of creating a new item card. This allow you to establish a different statuses for each single item. In our example it is: New, Under Revision, Ready and Blocked. For each of those statuses we can say that it can be replicated but only for this status – or this. If we now have our Record-Level Replication only for status 05Ready, when we go back to Data Items List we can for instance select number of lines and try to replicate them – and it fails, because it has to have Workflow assigned.
How do we assign Workflow status to our record? It is very similar to table sheets data record list – under Workflow Statuses we have records button, which opens very similar window, we have Record ID, Workflow Status Code – we can change status for example on Under Revision.
It is very easy to prepare a Special Item Card which will integrate all this features, but the module is generic. The module has to be flexible so it is said that to not adjust any standard objects, because it is also depending on certain business requirements. One company can decide to go with a five global fields on item and one company can decide to go with 30 global fields on item card, so it is not possible to prepare one solution that will fit everyone’s needs. When we setup Workflow on a single record and we open Record List, we can see Workflow here, let’s say that I want to subscribe to item 1250 – I cannot because the workflow code 02REV does not allow this. I can subscribe to list Released, so from now on I will be receiving two more items in our Replication.
That concludes our short presentation of key features of Master Data Management System module, the most important thing is that is very easy to implement, very easy to setup and very flexible module that will allow you to harmonize and synchronize your data between different NAV companies.