Master Data Management System
Questions & Answers

In this article, we have published the answers to questions we receive from customers on Master Data Management System most frequently. However, the primary information for Master Data Management System has been published on our webpage dedicated to this module. 

Master Data Management System has been certified by Microsoft. What does it actually mean?

Master Data Management System has earned Microsoft’s highest standard for a partner-developed software solution. By granting the Certified for Microsoft Dynamics title and logo, Microsoft has confirmed the innovativeness and quality of the product. The certificate is granted only to reputable independent software vendors (ISV) which meet the highest Microsoft requirements for software development and address unique industry needs with their products. 

IT.integro

Certified for Microsoft Dynamics NAV

Master Data Management System was appreciated as a solution that increases the global reach of Microsoft Dynamics NAV and enhances the system’s performance for global installations. With the Global Template, Master Data Management System supports global companies in the efficient management of local and global data. By providing their references to Microsoft, our group customers (10 companies) confirmed their high rating for the master data structure and management concept incorporated within Master Data Management System. They also emphasized that the system boosts the efficiency of intercompany data exchange and ensures data coherence in a global or group organization.

The solution has been also successfully tested for seamless integration with Microsoft Dynamics NAV.

Microsoft has also appreciated continued efforts of our team. IT.integro has been committed to product development for many years starting with the first version for NAV 2009 (RTC). Each annual product version has been enriched with new enhancements.

Until now, the Master Data Management System module has been developed for the following NAV versions:

  • NAV 2009 (RTC)
  • NAV 2009 R2 (RTC)
  • NAV 2013
  • NAV 2013 R2
  • NAV 2015
  • NAV 2016
  • NAV 2017

The improvements in the following versions on the Master Data Management System Roadmap will focus on:

Advanced error handling. A detailed error log will enable the administrator to quickly track down the origin of the problem. With one click, it will be possible to retrieve all files.

Administrator notifications. Notifications will be sent using a built-in notification system or E-mail message.

Performance boosting features. Metadata pre-processing will no longer be required during import.

If Master Data Management System is installed on an additional database, the customer is obliged to notify IT.integro and pay an additional fee for each new database.

Note:

  1. For Master Data Management System installation, a NAS is required for each database to be synchronized – both the central database and local databases.
  2. If a company owns only one database which is used to set up a master company and local companies, only one NAS is required.
  • Central Module: (a fee for a central database).
  • Local Module: (a fee for each local development database that is to be synchronized with a central database).
  • BREP fee: 16% of the Master Data Management System license value.

It is not required that the same Master Data Management System version should be used for all databases to be synchronized.

In the case of version 5.0 onward, the two options are possible:

  • Interface development for Master Data Management System
  • Technical upgrade to version 2009. If the customer pays a maintenance fee, the NAV partner should complete setup within 16 hours, provided that a technical - not functional upgrade is performed. Technical upgrade can have an impact on the functionality or other interfaces. Therefore, the decision on system upgrade should be made by the customer’s or partner’s employee who knows the environment very well and is able to predict the consequences of a technical upgrade.

As a rule, IT.integro, as a provider, does not permit its customers or partners to modify the module in order to ensure that the concept of master data management is implemented properly.

It all depends on the data scope and business requirements. A typical approach is to run full replication on a daily/weekly basis and incremental replication every day/hour, depending on business requirements. Please keep in mind that you can also run replication manually, when needed.

Yes. With the Job Queue Entry functionality, you can set up how replication is to be run i.e. in a full or incremental mode. You can define and schedule multiple replications for different tables independently.

In the case of Master Data Management System, only communication from a central database to local database is performed. Local databases do not transmit any information to a central database.

The Master Data Management System module has been designed as a platform to be used within all NAV areas for the synchronization of all objects and object elements such as tables and fields. The module does not contain any business logic layer, which means that IT.integro has not incorporated into it any embedded processes. Therefore, the processes such as creating cards can be defined freely based on the organization’s needs. For example, a card can be created by three different teams, with the first team assigning a card number, the second team filling in financial data and the third one approving and accepting the card. Switching the process between organizational entities is one of the options of the card creation process which can differ increasingly between various companies. Therefore, the Master Data Management System module should be treated as a transformation tool. To ensure successful implementation, business logic should be designed for processes within the customer’s organization.

This is a sample text. You can click on it to edit it inline or open the element options to access additional options for this element.

Yes, it is. Master Data Management System enables you to specify not only cards but also card fields that are to be managed globally (from the level of a central database). Owing to this feature, the headquarters can specify which fields (e.g. item number, item name, unit of measure) are to be managed globally and which (e.g., a unit price) can be managed locally. With this setup capabilities, some of the fields will be uneditable for the user who logs into a local subsidiary’s system. This way, the user will not be able to modify a selected unit of measure, but he/she will be able to change a unit price locally.

If a card field is managed globally, users in a subsidiary are not capable of editing it. Therefore, if a user at a local level identifies an item with improper item name managed globally, the user should submit its request to a person in charge of master data. The Master Data Manager is a person to decide whether the change is to be applied or not. Let us note that any changes to a field managed globally can be made only from the level of the central database. As a result, if the change is entered, the item name is changed in all databases in subsidiaries that use the Master Data Management System module.

No. Master Data Management System has been designed for data synchronization whereas creating a new field in a card is a data structure issue. The system’s data structure meaning fields, tables, reports, pages and other Microsoft Dynamics NAV objects is stored in a database. Therefore, if a multi-database environment is used, a new field needs to be created in each database separately. The problem is closely related to the issue of change management in a dispersed environment, which was described in another article.

A 30-minute presentation of the standard functionality of the module is available on our You Tube channel at https://youtu.be/a7ZSVCDSQOw. We would appreciate your watching the video and sending us your feedback and questions. This would enable us to prepare a more detailed presentation that meets the specific needs of your company. Such a presentation usually lasts 1 hour.

When standardizing their systems across subsidiaries, global companies usually encounter problems resulting from data inconsistencies and duplicates. The implementation of MDMS is a trigger that can enable them to organize their data in a structured way, and as a result to improve data management processes.

With MDMS, you can ensure that once data has been cleansed (and is in “a good shape”), you can streamline its distribution. For example, it is possible to set up per record, to which company/companies it should be sent. The user can also define that for a certain subset of table fields (which we call “global” fields), it should not be possible to adjust their values locally. This way, you will be always sure that your data is synchronized between different subsidiaries.

However, the module itself does not incorporate any functionality that allows you to perform the so-called “data cleansing”. Data cleansing is usually a preliminary project step performed before MDMS is implemented. Data is cleansed in local companies (which means that duplicates are deleted, vendor numbers are renamed to new, “standard” values, etc.). Once cleansing has been completed, data is uploaded into an MD – “global” – company and published. Starting from this moment, all subsidiaries use the same master data sets which prevents inconsistencies, duplicates and data conflicts as well as limits data exchange traffic.

Master Data Solution comprises various master data sets, which can be replicated to local companies based on the specific needs. In some cases, it is necessary to define that the complete set of data, e.g. financial data is to be replicated to certain local companies, whereas in the case of another data set e.g. item data, only selected records from specific tables are required to be replicated. To meet such needs, Master Data Management System enables the user to define replication setup at the record level. In practice, this means defining the setup with the Record Level Replication checkmark. The function works at a single record level. By selecting the checkmark, the user defines that a certain record will be replicated to a local company/subsidiary – a recipient. The setup for the replication is a very important step in master data management setup. When performed properly, it ensures that all records e. g. item, vendor, G/L accounts, posting entries are replicated to selected recipients.

The core assumption of data replication is that the process is generic. This means that it is possible to set up the replication process per record for any table.

MDMS for NAV 2017 has been substantially optimised to ensure that it can function as a standalone module which does not intervene into any standard NAV objects. This makes much easier to maintain data and its setup and replication.

Yes, it’s. On the Receiver Card, a network location is defined for a receiver. In this card, you can define the location from which the files are imported and the location where they are exported to within the replication process. The files can be exported in the xml format. Compared to Web services, file-based replication which is a linear process has proven to be much more efficient and easy-to manage, especially when large volumes of data are processed. Xml files are managed via xmlPorts which are a part of the NAV and MDMS object structure.

The MDMS module, itself is not capable of applying bulk changes to a data set. The best way to apply changes to e.g. a set of 1000 items is to run a dedicated script or use an Excel file.

All changes to data items are logged by MDMS, using a tracking functionality.
The change log stores all field changes regardless of the source of the change – a user, batch job, report etc. Then, the log is used to run incremental replication, which works like a delta update.

Incremental Replication, is one of the two replication modes available in MDMS. Contrary to the Full Replication mode, incremental replication exports only data that has been modified since the last replication. This is a time saving feature which enables the user to avoid processing large data volumes each time a single item is modified.

In the 2017 MDMS version, the process has been improved and works much faster. For instance, now the process of scanning for changes of 4 million records lasts no longer than a minute (previously it took as much as 40 minutes to process all records). The selection of the full or incremental mode is defined at the record level.

Each replication generates a replication entry. The module also stores the information about the replication mode selected. There are two replication modes available: 1) Full – all MDMS data is replicated based on the setup defined or 2) Incremental - that includes only records that have been modified since the last replication. In some cases, no records are processed within the incremental mode, which means no modification has recently been made.

The system stores replication entries regardless of the mode. The information is stored separately for each of the selected receivers. This means that for each receiver 3 folders are created:

  • Inbox folder - where files are waiting to be replicated,
  • Archive folder – where files that have been processed are moved,
  • Confirmation folder – that contains stamp files generated by the system that contain information if the file has been imported successfully.

It is possible to set up a script that is run in time intervals to read such confirmation files. This helps keep track of the process and check if the data has been successfully replicated to the receiver. In practise, at the level of the Master Data System (not at the level of a receiver) the user can display an overview of all replication data pending to be read as well as existing confirmations of data processed.

Selected fields can be locked for modification at the local subsidiary level. In the list of fields to be replicated from the central company/headquarters, for each table the user can select fields in each table to be locked. As a result, when another user attempts to modify the field and confirms his changes, an error message is displayed. The whole setup is done within the central company.

Removing records at the level of recipient companies (local subsidiaries) is against the concept of MDMS which defines that all global data is set up and maintained at the central/headquarters level. Therefore, local data modification is not allowed although data is stored by subsidiaries. Each table marked as replicated cannot be modified at the local level.

Deleting records in subsidiaries can cause unpredictable consequences both on the local and global level. The inconsistencies can result in serious errors. However, in order to enable the user some flexibility in this scope, the Master Data Super User role has been designed. The role has unlimited rights. Master Data Super Users are responsible for their application areas (such as logistics, financials, inventory) and should analyse all consequences, both local and global, before any item of data is deleted. They must look at the process from a broader perspective as sometimes a successful deletion of a record in 9 out of 10 companies does not mean that it will not cause critical consequences after the process has been launched in the 10th location. Even the very last step may turn out to be a failure with far-reaching drawbacks.

The necessity of removing data is usually a result of improper data setup and human errors. Most common errors include wrong item numbering. To prevent such errors, IT.integro recommends using a Creation Wizard when defining data e.g. item data at the global level. The guided setup and review of data with the wizard at the initial stage eliminates the necessity to remove records at the local level.

Translations of units of measure are set within a separate table outside MDMs. Therefore, they can be maintained locally.

Basically, for the purpose of translation, MDMS provides the Translated Fields feature which is used to select the table and field number of the field for which translation is to be applied. All information about the assignment of translations to fields to data sets is stored in a separate table outside MDMS. This works similarly to the Receiver Data Record table that contains receiver/replicated record assignment. Translation setup is customised based on individual needs of subsidiaries, therefore the table is not incorporated within the MDMS module. The translation value that is entered into this table. e.g. a description in a local language is automatically used in the field assigned and replicated to relevant companies.

When synchronising the chart of accounts, it is important to apply local names to G/L accounts, taking into account local legal requirements. To avoid maintaining translations in the Master Data company, we add a new field in the G/L card – Global Name.

Global Name is a field where a global name/description is entered at the master data level at the headquarters. The field is locked for editing whereas the standard Name/Description field is editable. The first name when the record is replicated with the global name/description in the Name/Description field. Then the content of the Name/Description field can be replaced with a local name/description. Users in the local company can view both local and global name, however the latter is still uneditable to ensure consistency with the master database.

Master Data Management System keeps track of all the changes made within master data sets. The log it creates can be used to run a batch job to replicate the data changed to specific subsidiaries or to run replication in the incremental mode. This works like a delta update.

Master Data Management System is based on the standard NAV object architecture, so any user who has sufficient development knowledge can define the setup.

In this case, no mapping is required. The price that the subsidiaries pay can be set up as a purchase price in a global company. Obviously, the same vendor number should be used in all companies for the headquarters. Local vendors are also allowed with different vendor numbers based on the global vendor list.

However, referring to retrieving data in a different table: in MDMS as a rule the specific set of data can be pushed only to the same table. Replication of a data item can be handled within different fields but not within different tables. This ensures consistency.

The primary assumption in MDMS is that data flow is managed only from the headquarters to a local company, not vice versa.

It is not permitted to create a data item locally even if it is urgent. The request from a subsidiary to create a data item should be submitted to the headquarters. Despite the time pressure, this rule should be observed.

The process of creating a new data item at the headquarters involves also scanning for changes and replicating new data items in the incremental mode to local companies. This definitely takes longer than just opening a card and creating a data item locally. However, the benefit is data consistency.

As recently many improvements have been implemented for faster scanning for changes, the creation and replication of new data items has been shortened to 5-10 minutes, which is a good result. To speed up the process, it is possible to develop an extra solution using Web services.

Indeed, to respond to users’ claims about time pressure and more flexible flow of data, a global/group organisation should focus on developing policies that prevent situations when it becomes critical to create urgently a data item at a local level. If proper procedures are implemented, creating data solely at the headquarter level, taking into account the time needed, becomes the best practise which is accepted and applied across the entire organisation.

Starting from MDMS for Microsoft Dynamics NAV 2017, the module is completely interdependent from the core Microsoft Dynamics NAV system, which means there are no common objects. Therefore, the MDMS license covers objects only within the module object range.

The module has been certified by Microsoft as an ISV solution based on the complex certification, compliance and quality assurance procedure. The license can be issued as soon as the order is placed by the customer.

The problem is solved by means of creating a new Data Set. If Unit of Measure is set first in the update queue before the item, each time a given unit of measure is updated the relevant item is also updated.

If the file is read in the receiver company, and the system detects an error, the error is logged and as a result no record is created or updated based on the replication file (the number of such records is not displayed).

If a data item has been imported successfully, the system generates a confirmation, that can be automatically retrieved in a central data base. Each replication entry indicates if it has been imported successfully.

Opinion about MDMS solution

TOP