This app replicates master data between different companies of one or more BC databases.
Industry Construction module
. Current Version: 1.0.4.0as of Business Central 21.
Manual
Creation date: 2024/05/17 The current version of this manual can be found at:
☰ Contents
General
App Replication
Setup
App Setup
Tasks
Working with the app
Appendix
Release notes
Docs / NVXRPL Replication / General General
The app enables controlled and transparent replication of master data between companies within the same or a different database. It includes the following functionalities:
Division of companies into master companies, operational companies, and other companies
Detailed replication setup with different options down to the field level
Ability to choose how the data is replicated
Control and transparency are ensured
Replication directly from specific records such as Customer, G/L Account, or Item, etc.
Dependent tables are taken into account
Transparency and control for making the correct decision before the final replication execution
Replication can be automated through a job queue
Replication between databases
Docs / NVXRPL Replication / Setup Setup
There are several setup options available in the replication app. The menu items for this are located in the Replication Menu (RPL Replication -> RPL Setup)
In this page, you will find the setup options as well as the records to be replicated and the "Execute Replication" action.
RPL Setup
The setups must be performed in the following order:
Replication General Setup
Replication Database Setup (if in use)
Replication Setup Companies
Replication Setup Tables
Transfer to Companies default values
Personal Accounts/Country codes Posting Groups
Replication General Setup
The fields and field names are automatically filled in during app installation and cannot be changed. These fields are used to identify what is called master data by the system.
Checking the "Database Replication" checkbox enables replication between different databases. Additional fields and the "Replication Setup Database" become visible and can be defined.
Once "Database Replication" is set, you can decide whether the current database sends or receives data by checking the "Current Database Receiving" checkbox.
Main Master Data
Main master data includes the following tables:
G/L Account, Contact, Customer, Vendor, Item, Job and Resource Group. Only these master data have the fields "Transfer to Company" and "Replicate" , such as here:
The "Transfer to Company" field determines per record where replication will be performed:
"None" - The record will not be replicated.
"All operational" - Data will be replicated to companies with the "Operational Company" flag in the "Replication Setup Companies",
"Some" - When this option is selected, the desired companies must be selected. To do this, click on the three dots to the right of the field.
"Entire Organisation" - Data will be replicated to companies that do not have a "Exclude from Replication" flag in the "Replication Setup Companies".
The default values for this field come from the "Transfer to Companies default values" setup (see below).
"Replicate" is a non-editable field that is automatically set after enabling replication (action "Activate Replication" - data transfers are created).
User setup - Replication with filter
If checked, the "Execute replication with filter" function is available for this user in the "Edit - RPL Replication" window.
Replication Setup Database
Once replication between databases is enabled (see "Replication General Setup"), the "Replication Setup Database" becomes visible.
Multiple databases and multiple remote companies can be set up.
The field "Database Name", specifies the database name from which data should be transferred.
In the field "Database Server Name" must be entered the link to server including "https://".
Port is the OData port from the BC Service - Configuration.
The option "Tenant Database" determines whether the sending database is a cloud DB.
The fields "Client ID Key", "App Company ID" as well as "Client Secret Key" are populated with the data from the Azure App Registry.
Company Name is the name of the master data company from the sending databank.
Once all the necessary information is entered, the Actions -> "Test Connection" action can be used to ensure the setup is correct for cross-database replication.
Replication Setup Companies
.
At the beginning, all desired companies are defined as Replication Setup Companies.
The "Master Data Company" identifier is used to mark the company in which the master data is managed. This identifier can only be set for one company.
With the identifier "Operative Company" the companies are marked, which represent the operative business.
With the identifier "Excluded from Replication" those companies are marked, which will never receive data from the master data company.
Companies, which were entered in this table, but have no identifier, are further named as "other companies". They receive general master data such as payment terms from the master data company. "Main Master Data" (see above) they receive only those who have the entry "Entire Organisation" on the card in the field "Transfer to Company".
For cross-database replication, two additional fields appear here:
"Remote" - If you check this box, only companies from remote databases can be selected.
"Database Name" - Select the database where the remote company is located.
Replication Setup Tables
Use the "Insert Tables" action to add the desired table and the table's fields to the replication setup.
Once a table has been added, the following fields should be noted:
Type
The type differentiates between "Table", "Field" or "Dependent Table".
Table no.
The number of the table is filled by the system if the entry was created with "Insert Tables". It can also be entered manually.
Table Name
Name of the corresponding table, is filled by the system.
Field No.
Number of the field, is filled by the system if the entry was created with "Insert Tables". But can also be entered manually.
Field name
Name of the corresponding field, is filled by the system.
Tables Sequence
Order in which the tables are processed. The lower the number, the earlier the processing.
Skip Field Validation
If this flag is set, the field is transferred with the replication, but there is no validation of the field content. This flag may only be set in certain cases.
Ignore Field
Basically, fields, which are present in the replication setup tables, may only be edited in the master data company. In other replicated companies it comes to an error message.
If this flag is set, this field can be edited in the master data company as well as in all other companies and is not replicated.
System fields, such as "Created by" or "Created on" should always receive this checkmark.
New
Indicates rows which are newly added in the replication setup tables. When closing the "Replication Setup Tables" page, corresponding data transfer entries will be created in the master data company for all lines with this indicator checked. This flag can be removed manually if existing entries from the master data company are not to be transferred. However, this should only be done in special cases.
"Table filter" in "RPL Replication Setup Tables"
The table filter is used to replicate only certain records of the table concerned.
The table filter can only be used for setup data records with the type "Table" and "Dependent table".
If a filter has been created, replication entries (data transfers) are only created for the data records selected according to the filter.
Translated with DeepL.com (free version)
"Ignore for field"/"Ignore for field value".
Sometimes you want to replicate only certain records of a table (depending on the value of a field) and not others.
For this purpose, the "Ignore for field" and "Ignore for field value" fields in the "Replication Setup Tables" are used. These can be used only for the setup with the type "table":
.
For both fields, the values cannot be entered manually (except in "Ignore for field" if you want to delete the value completely).
If you click on Lookup points, the selection list of fields for the selected table will appear:
.
Immediately after that, the corresponding page opens. For options, an option selection will pop-up and for other fields an input page:
Thus, the setup is ready:
IMPORTANT: You have to get out of the "Replication Setup Tables" in order for the changes to be saved.
For the tables with such setup, replication is not enabled at all and they can be inserted/deleted/changed.
Since the field value to be ignored comes into use immediately after record creation, it must be populated as soon as this field is created. In this example, we use the type of a resource. In this way the system should already know the value of the field when creating it.
During the manual input, the input page for the defined field pops up:
.
IMPORTANT: In programmatically created records, the corresponding field value must be provided.
""Ignore for Company"
The "Ignore for Company" field is used in cases where you want to ignore specific tables or fields for certain companies.
When replicating, the "Ignore for Company" setting can be considered at the table level. If "Yes" is selected, you can choose the company. When one or more companies are defined, data transfer for these companies is set to "Skip." The error message will be "The record could not be replicated because there is no definition for this table in the database."
Creation, deletion, and changes in tables are allowed when "Ignore for Company" is set for this company.
At the field level, "Ignore for Company" can also be considered. When set, the field content will not be transferred, as the field in the data transfer details is automatically set to "Skip." Furthermore, changes in fields are allowed when "Ignore for Company" is set for this field for this company.
Transfer to Companies default values
This table lists all the so-called "main master data". Only in these tables can you select, for each record (during record creation), the target companies to which it should be replicated.
You can define the default value for this function ("Transfer to Company") here.
Personal Accounts/Country codes Posting Groups
This setup is relevant for all customers which have companies with different country codes. Example: there is a company with Austrian legislature and a company with German legislature. In this case, for example, the business posting group cannot be filled from the master data company, because a customer in an Austrian company has the business posting group INLAND, but in the German company the same customer needs the business posting group EU.
This setup has to be done in the receiving company. According to this setup the fields will be filled during the transfer to the target company. This setup must be done separately for the type "Customer" and "Vendor".
Docs / NVXRPL Replication / Tasks Working with the App
Replication between companies in one Database
Creating, deleting, or modifying a record in a table set up for replication (see "Replication Setup Tables") triggers the creation of a data transfer for each configured company. These data transfers can be managed using the "RPL Replication" page. When a new record is created, an "Insert" data transfer is generated to create the primary key in the respective target company. The remaining fields are then populated using the "Modify" data transfer. Deleting a table record generates a "Delete" data transfer. Each data transfer contains detailed rows with information about the individual fields.
Using the "Execute Replication" action initiates the processing of pending data transfers. This action can also be performed through a job queue.
All processed entries are marked as "Assumed" along with the date and time of acceptance.
If an error occurs during processing, the "Error" flag is set, and the date and time of the error are recorded. If an error occurs, the processing of all subsequent replication sets from the affected company is stopped. However, replication continues for all other companies. Once the error is resolved, replication for the affected company resumes at this point.
The "Skip" flag allows skipping the processing of a data transfer to proceed with the processing of subsequent records. Removing the "Skip" flag will trigger another attempt to accept the skipped data transfer during replication.
Within a company, the processing in replication is always based on the ascending order of the sequence number. However, for clarity, the data is displayed in descending order.
Replication can also be performed within individual companies, considering only the data transfers for the respective company.
Replication of Main Master Data
For "Main Master Data," replication of records does not occur automatically but needs to be enabled for each individual record. Once you have completed creating the record in the master data company, run the "Execute Replication" function. Additionally, you can choose which companies the record should be replicated to.
Execute replication with filter
This function is only displayed if you have received the corresponding authorization in the "User setup".
When the function is executed, the "Execute replication" function is carried out as usual. However, only those data transfer records that have been filtered in the currently displayed window are processed.
Replication between Databases
During cross-database replication, data transfers from the base database are acquired using the "Transfer from Base-Database" action.
If an error occurs during this process, the transfer is interrupted, and the corresponding data transfer is marked accordingly.
To process records for the clients of this database, the "Execute Replication" action must be selected here as well.
The master data company in the remote database is not strictly required. However, if you want to initiate data transfers for all companies with ONE execution of the "Execute Replication" function, you will need a master data cmpany in the remote database as well.
When fetching replication setup tables, all definitions are always transferred. This occurs automatically during the transfer of data transfers. In a remote database, these definitions should not be altered anymore.
The actions "Transfer from Base Database" and "Execute Replication" can be automated using a task queue (Report 61882 - RPLTransferRemoteDTNVX and Codeunit 61883 - RPLStartReplicationNVX).
Would you like to know what has changed in the extension? Below you'll find an overview of the new features and changes made in the updates.
Build Overview in DevOps
NVXRPL 1.0.4.0
as of Business Central 21 2024/03/08
Improvements
Table filter for replication of only certain records.
NVXRPL 1.0.3.0
as of Business Central 21 2024/03/04
Corrections
Filter is cleared for non-filtered Action.
NVXRPL 1.0.2.0
as of Business Central 21 2024/03/01
Replication entries can now be replicated in a filtered manner.
NVXRPL Replication
In this page, you will find the setup options as well as the records to be replicated and the "Execute Replication" action.
Multiple databases and multiple remote companies can be set up.
.
For both fields, the values cannot be entered manually (except in "Ignore for field" if you want to delete the value completely).
If you click on Lookup points, the selection list of fields for the selected table will appear:
.
Immediately after that, the corresponding page opens. For options, an option selection will pop-up and for other fields an input page:
Thus, the setup is ready:
IMPORTANT: You have to get out of the "Replication Setup Tables" in order for the changes to be saved.
For the tables with such setup, replication is not enabled at all and they can be inserted/deleted/changed.
Since the field value to be ignored comes into use immediately after record creation, it must be populated as soon as this field is created. In this example, we use the type of a resource. In this way the system should already know the value of the field when creating it.
During the manual input, the input page for the defined field pops up:
.
IMPORTANT: In programmatically created records, the corresponding field value must be provided.
This table lists all the so-called "main master data". Only in these tables can you select, for each record (during record creation), the target companies to which it should be replicated.
You can define the default value for this function ("Transfer to Company") here.
This setup is relevant for all customers which have companies with different country codes. Example: there is a company with Austrian legislature and a company with German legislature. In this case, for example, the business posting group cannot be filled from the master data company, because a customer in an Austrian company has the business posting group INLAND, but in the German company the same customer needs the business posting group EU.
This setup has to be done in the receiving company. According to this setup the fields will be filled during the transfer to the target company. This setup must be done separately for the type "Customer" and "Vendor".
