Replication of master data between different companies of one or more BC databases.
Current Version: 26.1.0.1as of Business Central 26. AppSource Name: NAVAX Replication
Manual
Creation date: 2026/02/26 The current version of this manual can be found at:
☰ Contents
General
NAVAX Replication NAVAX Replication replicates master data between different companies of one or more BC databases...
Setup
General In the Replication Setup General, basic settings are configured...
Databases If replication should also be performed to other databases, you must set up the other databases here...
Companies Here you configure the individual companies that are involved in the replication...
Company Groups A Company Group combines multiple companies...
Companies in Company Group Enter the individual companies here that should be assigned to a company group...
Tables The Replication Setup Tables defines which tables and fields are considered in the replication process and how they behave during replication...
Table Filter Setup Here you can specify for the tables that they should only be replicated to one or more companies under certain conditions (filters)...
Manual Replication Setup Each table that has one or more line entries here is defined for Manual Replication...
Customer/Vendor Country Posting Groups If your participating companies represent different countries, you probably do not want to roll out the posting groups of your customers and vendors identically to all companies. For example, an AT vendor can be a domestic vendor in one company, an EU vendor in another, and an export vendor in a third company. Therefore, there is an option to replicate the posting groups differently to individual companies during replication, depending on the Country/Region Code...
Automatic Status Change Here you can define for each replicated table whether Replication Entries defined by a filter should be automatically set to a specific status...
Replication Administrator There are various functions that are only available to the user with the Replication Administrator permission. This is noted directly for the corresponding functions...
Working with the App
Replication Entries Creating, deleting, modifying, or renaming a record of a table that is set up for replication triggers the creation of replication entries...
Manual Replication
Cross-Database Replication In each recipient database, the recipient companies of this database must be defined in the Replication Setup Companies. One of these companies should be defined as the Master Data Company of the recipient database...
Errors Caused by Replication Entries Due to setup errors or special data constellations, a replication entry may receive the status Error when executing the replication. Such an entry causes the replication in the affected company to not be performed for all replication entries after the defective entry...
Replication Entry Dependencies For tables that have the Manual Replication parameter set, it is possible to define Dependent Tables...
Tasks When working with the app, several task areas arise...
Special Cases Replicating tables is usually a straightforward matter...
Developer Information
Enable Manual Replication for Additional Tables NAVAX Replication is already integrated into many card pages by default via page extensions...
Event Request Do you need a function or an event that is not yet included in the current application? Contact us and we will review your request. If possible, we will implement the desired extension promptly. If not, we will inform you and briefly explain the reason. In that case, do not be discouraged - reconsider your approach and feel free to submit a new request...
Appendix
NAVAX License Management The NAVAX License Management page (in older versions NAVAX License Overview or NCEX License Overview) displays the current license status of the NAVAX extensions...
Installation Notes
Release Notes
Docs / App / NAVAX Replication / General NAVAX Replication
NAVAX Replication replicates master data between different companies of one or more BC databases.
Navigation
You perform most replication tasks on the RPL Replication page. Here you can see the replication entries and carry out all necessary setups.
You can identify all NAVAX Replication functions by the prefix RPL.
Permission Sets
The following permission sets are available for NAVAX Replication:
Name
Description
NVXRPL, SETUP
NAVAX Replication Setup
You need these permissions to fully use NAVAX Replication.
NVXRPL
NAVAX Replication
You need this permission set to carry out the setup of NAVAX Replication.
Important
NAVAX Replication interacts with a large number of standard tables/processes. Therefore, you also need this permission set to edit data in the BC database in general. It is recommended to assign this permission set to every BC user.
In the Replication Setup General, basic settings are configured.
Fields
Cross-Database Replication
Enabling this option activates cross-database replication.
Current Database is Receiver
If Cross-Database Replication is enabled and the current database is not the database containing the master data company, you must enable this parameter.
Ignore Cust. Def. Dim. on Job
This parameter is only relevant if you replicate jobs.
When you enter a customer on a job card, all default dimensions on the job card are replaced by those of the customer. If the customer has no default dimensions, the existing default dimensions on the job card are simply deleted. This behavior is also triggered by replication.
If you want to prevent the default dimensions on the job card from being replaced by those of the customer, you must enable this parameter.
Replication Enabled
This parameter is only visible if you are a Replication Administrator.
If you uncheck this parameter, replication will no longer be performed. This applies to all users, not just you.
This function is useful, for example, when you want to carry out setup data changes (e.g., importing via configuration packages) that should not be replicated.
CAUTION: Do not forget to re-enable this parameter after completing your tasks.
Abort Replication on Error
This field is only visible if you are a Replication Administrator.
This parameter only takes effect when you start the replication directly in the target company. When executing replication in the target company, the function is aborted with the triggering error message in case of an error.
Note: If you execute this in the master data company, the error message will not be displayed.
When this parameter is enabled, extended information is displayed in the event of a program abort (in the target company), which is very helpful for developers.
Adding Repl. Entries Active
This parameter is only visible if you are a Replication Administrator.
There are time-intensive replication processes that can generate many replication entries. For example, adding a new table definition (with automatic initial replication) or the "Initialize Company" action. During these processes, no other replication entries may be created - therefore, you must not modify any master data that is being replicated during this time.
Replication prevents this and notifies you with a corresponding error message.
If one of the above-mentioned processes is terminated with a program abort, this parameter remains enabled and it is still not possible to modify replicated data. ONLY in this case (program abort) may you manually deactivate this parameter.
Repl. Table Setup in Progress
This parameter is only visible if you are a Replication Administrator.
When someone is modifying the table setup, no second user may perform similar operations at the same time. Replication prevents this and notifies you with a corresponding error message.
If the table setup is terminated by a program abort, this parameter remains enabled and it is still not possible to modify replicated data. In this case, you may manually deactivate this parameter.
CAUTION: If the session with the table setup is terminated by closing the browser window, it may take a few minutes before the lock for further editing of the table setup is automatically removed.
Actions
NAVAX License Management
Opens the NAVAX License Management, which displays the current license status of the NAVAX extensions.
Docs / App / NAVAX Replication / Setup Databases
If replication should also be performed to other databases, you must set up the other databases here.
The following describes the required setup for data replication between different databases.
In the main database, the additional databases must be created in order to define their companies.
In each additional database, the main database must be created and configured.
In a receiver database, the following information about the main database must be provided (in the Database Card).
Fields
Code
Assign a unique code.
Description
Specifies the value of the "Description" field.
Endpoint Server
Specifies the base URL through which the API call reaches the web service.
Server Instance
Specifies the value of the "Server Instance" field.
Port
Specifies the value of the Port field. If the remote database is cloud-based, this field is not relevant.
SaaS
Specifies whether the remote database is cloud-based.
Tenant ID
Specifies the tenant ID of the app registration for this database.
Client ID
Defines the application ID of the client app registration.
Client Secret
Defines the client secret of the client app registration.
Master Data Company Central Database
Enter the name of the master data company in the main database here.
In the main database, you only need to fill in the following fields from the above parameters: Code, Description, and Server Instance. Only these three parameters are displayed.
Actions
Remote - Companies
Note
This action is only visible in the main database.
Enter the individual companies for each receiver database here in the main database. Pay attention to the exact spelling of the company name.
You can find these in the "Name" column of the "Companies" list in the receiver database.
The exact entry of the names cannot be verified at this point, but it is essential for the cross-database replication to function correctly!
Test Connection
Note
This action is only visible in the receiver database.
With this action, you can verify whether the setup for cross-database replication is correct.
Docs / App / NAVAX Replication / Setup Companies
Here you configure the individual companies that are involved in the replication.
In the main database:
Each row represents a company from the main database or from a receiver database. Define all companies here - including those that are not integrated into the replication.
In a receiver database:
Each row represents a company of the receiver database. Define all companies here - including those that are not integrated into the replication.
Fields
Remote
Check this parameter if the company is located in a receiver database.
Note
This column is only visible if you have set up cross-database replication and you are currently in the main database.
Server Instance
If "Remote" is checked, select the relevant database (from the "Replication Setup Database") here.
Note
This column is only visible if you have set up cross-database replication and you are currently in the main database.
Name
Select the name of the desired company. The companies of the receiver databases must have been previously created in the main database under "Replication Setup Databases" for the respective receiver database.
Master Data Company
You must set this check mark for exactly one company in the main database. This is the company in which the master data is managed.
In each receiver database, you should also set this check mark for one company (if you replicate to multiple companies there). This company then allows you to replicate the replication entries to all other companies.
Omit from Replication
Companies with this check mark are not considered during replication.
Replication Active
Indicates whether replication is currently running for this company. The value is automatically set and removed by the system. It should only be changed manually in exceptional cases. For this reason, the field is hidden by default and is only visible to the "Replication Administrator".
Company Initialized
Indicates whether the "Initialize Company" function has already been performed for this company. If you want to perform the initialization again, you must first manually remove the check mark. This option/setting is only visible to the "Replication Administrator".
Replication Init. in Progress
Indicates whether the "Initialize Company" function is currently active for this company. The value is automatically set and removed by the system. It should only be changed manually in exceptional cases and is only visible to the "Replication Administrator".
Actions
Initialize Company
This action creates replication entries for the selected company for all data that is to be replicated according to the replication setup. This means that all records that are to be replicated in principle are delivered once to this company - just as if they had just been created. You can use this, for example, to initialize a newly created company with the master data (that is being replicated).
If some of these records already exist in the company, the replication skips the creation for these records and merely updates them to the current values from the master data company.
In the "Replication Setup Tables", you can specify for each table whether it should be considered during the "Initialize Company" action. You can also influence the order in which the replication entries are created. This applies to the order of the tables as well as the order of the fields within the tables.
Please note that after this step, you still need to execute the replication with "Execute Replication".
Caution
While this action is active, no master data changes to replicated data can be made. Since the "Initialize Company" action can be very time-consuming, you must carefully consider when to perform this action.
Docs / App / NAVAX Replication / Setup Company Groups
A Company Group combines multiple companies.
If certain tables or individual records should not be replicated to all companies, you can specify this either in the Replication Setup Tables or directly on the record by specifying the desired companies individually.
Alternatively, you can use company groups:
Instead of specifying the desired companies individually, you group them together and select the corresponding group.
Fields
Code
A unique identification code for the company group (e.g., OP1_2).
Description
A brief description that explains the purpose or content of the group (e.g., Operative Companies 1 and 2).
Docs / App / NAVAX Replication / Setup Companies in Company Group
Enter the individual companies here that should be assigned to a company group.
Fields
Company Name
Defines the company.
Docs / App / NAVAX Replication / Setup Tables
The Replication Setup Tables defines which tables and fields are considered in the replication process and how they behave during replication.
There are a variety of parameters that must be carefully configured.
The setup screen is divided into Header Area (Tables) and Details (Fields and Dependent Tables).
Header Area (Tables)
You can minimize the header data to display more detail lines for the currently selected table.
Below you will find the description of the fields in the header area.
Column
Description
Type
The setup table contains different record types. Depending on the type, different parameters (columns) are relevant.
In the header area, only the type "Table" is allowed.
Table
This is the header record for each table to be replicated. Here you enter basic information about the table.
Table No.
Specifies the number of the table.
Table Name
Display name of the corresponding table.
Table Filter
You can define a filter here to replicate only specific records of the table. Only records that match the filter will be replicated. Table Filter Setup
Note
Note that non-replicated records can still be edited in all companies.
Table Sequence
Only relevant when Manual Replication is enabled and when using "Initialize Company".
All dependent tables (linked via the type "Dependent Table") are replicated according to this value.
Details can be found in the Manual Replication section and in the detail lines for the record type.
When using the "Initialize Company" action, the tables are replicated according to this sequence.
Note
Note that non-replicated records can still be edited in all companies.
New
Set automatically by the system.
If the checkbox is set, this is a new setup line.
When closing the "Replication Setup Tables" page, a prompt appears if at least one line with "New = Yes" exists:
Activate setup and generate replication entries
All required Replication Entries for the initial rollout will be created for the newly added tables and fields. The "New" checkboxes will be removed.
Close setup without replication entries
The new setups will be saved and the "New" checkboxes will be removed. No Replication Entries will be created for already existing records of the tables to be replicated.
If you want to designate the table for "Manual Replication", for example, you must choose this option when leaving the "Replication Setup Tables".
Reset Setup (delete new lines)
The new setup lines will be deleted and therefore will not be applied.
Note
The "Replication Setup Tables" window may only be opened in one session at a time. It is locked for further access. If you leave the "Replication Setup Tables" not through the program but, for example, through a program abort or by directly closing the browser window, the setup may remain locked for the next few minutes.
Ignore Company
If set to "Yes", you can click on the three dots to define in which companies this table should not be replicated. This setup takes effect before all other setups as well - for example, if you replicate using company groups or have set filters.
Manual Replication
This parameter cannot be set here but is automatically activated when the table has been entered in the "Manual Replication Setup".
"Manual Replication" offers flexible and transparent control of individual tables. When activated, newly created records of this table will only be replicated when the user triggers it via the "Repl. Companies" parameter in the Replication FactBox of the corresponding record.
When the record is created, the "Repl. Companies" parameter is automatically set to "None". As soon as the user changes this parameter to a different value, the corresponding Replication Entries are created and the record is included in the replication processes.
Important
Since the required Replication FactBox is displayed in the card view, a card view is a prerequisite for this. If you activate this parameter and the Replication FactBox is still not displayed on the respective card, this table does not support the function. In this case, you either cannot use this function, or you must contact your system administrator to have the extension of this table implemented through customization.
Enable Manual Replication for Additional Tables
Do not execute Insert trigger
This parameter causes insert triggers not to be executed when replicating this table.
Important
The functions executed by insert triggers usually exist for good reason. Therefore, this setting should only be made in coordination with your system administrator.
Do not execute Modify trigger
This parameter causes modify triggers not to be executed when replicating this table.
Important
The functions executed by modify triggers usually exist for good reason. Therefore, this setting should only be made in coordination with your system administrator.
Do not execute Delete trigger
This parameter causes delete triggers not to be executed when replicating this table.
Important
The functions executed by delete triggers usually exist for good reason. Therefore, this setting should only be made in coordination with your system administrator.
Ignore on "Initialize Company"
If activated, this table will not be considered during the "Initialize Company" action.
Details Area
In the lower screen area, you will find the detail lines for the currently selected table.
This area can also be minimized to display more header data lines simultaneously.
Column
Description
Type
Each line can have a specific record type that defines its function:
Field
Defines which fields of the table should be replicated. Fields not listed will not be replicated. However, it is recommended to list all fields.
A listed field can also be explicitly excluded from replication by marking it with the "Ignore Field" parameter.
Dependent Table
If "Manual Replication" is activated for a table, you can define dependent tables in the details.
A dependent table will only be replicated after the associated record of the main table (the one where it is listed as a dependent table) has been replicated.
Note that the dependent table must also be set up as a table to be replicated. A "dependent table" must not be set up as manually replicated.
Example: The bank accounts of a vendor should only be replicated after the vendor itself. However, if the vendor is manually replicated, it may happen that the created vendor bank account generates Replication Entries before the actual vendor - and this would lead to an error. Therefore, the table "Vendor Bank Account" must be stored as a "Dependent Table" under the table "Vendors".
Replication Entries of the dependent table are created with the status "Waiting" and are only replicated after the main table has been replicated.
Field No.
Number of the field in the table.
For the line type "Dependent Table", the field number of the main table must be specified here, which establishes the unique link to the dependent table (e.g., field "No.").
Note
Dependent tables can only be linked to the main table via ONE unique key field. A link that requires more than one key field is currently not supported.
Field Name
Name of the field, automatically populated by the system.
Dependent Table No.
Only relevant for the type "Dependent Table". Number of the dependent table.
Dependent Table Name
Name of the dependent table, automatically populated by the system.
Dependent Field No.
Through this field number of the dependent table, the link to the main table is established.
Dependent Field Name
Name of the field, automatically populated by the system.
Dependency Condition
An optional filter that allows you to further narrow down the records to be linked. You need this filter, for example, for table 352 (Default Dimension) to only set the default dimensions for this specific main table as dependent.
Example: Table 167 "Job" is set to "Manual Replication". To prevent a replication error when entering a default dimension on the job card, you set up table 352 "Default Dimension" as a "Dependent Table". However, table 352 "Default Dimension" also contains records for other tables, so the filter "Table ID = 167" must be entered for the dependent table 352 line.
Field Sequence
Specifies the order in which fields are processed within the replication of a record. The smaller the value, the earlier the processing occurs.
When using the "Initialize Company" action, the fields are replicated according to this sequence.
Important
When a newly created record is not set to "Manual Replication" or when an existing record is modified, the Replication Entries are in most cases created according to the order of your data entry. In this case, the "Sequence" parameter usually has no effect.
Skip Field Validation
If activated, the field content is replicated but not validated.
Important
The functions executed by validations usually exist for good reason. Therefore, this setting should only be made in coordination with your system administrator.
Ignore Field
If set, this field is excluded from replication. This has the same effect as if you did not create a setup line for this field.
We recommend creating the line anyway, because on one hand it serves as documentation and on the other hand, future functions (e.g., a check for which fields have not been defined for this table) will take these lines into account.
Ignore Company
Can have the following values:
None - This selection means that no companies should be ignored and therefore has no effect.
Yes - This selection means that companies should be ignored. Click on the three dots to open an overview where you can define to which companies this field should not be replicated.
New
This parameter is set automatically and marks a new setup line. When closing the page, a prompt appears for saving or discarding all lines marked as "New". Only when you confirm upon closing that the setup lines should be retained will the required Replication Entries be automatically created. These can be entries for an entire table or just for a field of an already replicated table that was newly added.
Important
In some situations it may be useful to manually manipulate this parameter, which is possible in principle. For example, if you want to include a new field in replication but do not want an initial rollout for it. In that case, remove the "New" checkbox and click "OK" in the save prompt.
Write on Insert
When a new record of a replicated table is created, a Replication Entry with the field Action = "Insert" is first created. This entry contains only the key fields of the table regarding the fields. Then any number of Replication Entries with the field Action = "Modify" follow. These entries contain the information regarding the fields that are not key fields.
However, there are situations where you want certain data fields to be written already with the Replication Entry with the Action = "Insert". This can be the case, for example, when the insert trigger of this table performs functions based on these field values.
If such fields exist, the "Write on Insert" checkbox must be set for them.
Note that a popup window is displayed for entering these fields immediately when creating a new record.
Ignore on "Initialize Company"
If activated, this field will not be considered during the "Initialize Company" action.
Actions
Add Tables
Select the desired table (you can also select multiple). Setup lines are automatically generated for this table, which you can modify manually. New lines are automatically marked with the status "New".
Only when leaving the setup screen do you have to decide whether these setup lines should actually be applied - and thereby Replication Entries should be created for an initial replication.
Activate "New"
This action sets the "New" status in all detail lines of the current table.
Remove "New"
This action removes the "New" status from all detail lines of the current table.
This is useful, for example, if you have created new setups but want to prevent the Replication Entries for the initial rollout from being created.
Activate "Ignore Company Init"
This action sets the "Ignore on Initialize Company" status in all detail lines of the current table.
Remove "Ignore Company Init"
This action removes the "Ignore on Initialize Company" status from all detail lines of the current table.
Obsolete Fields
Microsoft informs you when delivering a new version (somewhat hidden in the table definitions) which fields will no longer exist in the future, which fields have been changed or were changed (e.g., field lengths), or which fields were removed with this delivery.
The replication makes this information visible here for all fields that are currently considered in the replication setup.
When you select the action, only those fields that have been removed from the database are initially displayed. These fields must also be removed from the "Replication Table Setup". You can do this very easily by selecting the "Replication Setup Tables - Field" action and deleting the corresponding setup there.
Additionally, you can remove the filter on "Obsolete state" to also see those fields that have already been flagged by Microsoft for deletion in later versions or have other changes.
Important
You should check the "Obsolete Fields" action immediately after each delivery of a new program version.
Each table that has one or more line entries here is defined for "Manual Replication".
Please note the following rules for the setup:
Tables designated for "Manual Replication" must not have filters in the "Table Filter Setup".
The setup for the suggested target companies is only a default value and can be individually changed by the user for each record.
Since the user can choose for each record where it should be replicated to, preventing the rollout to specific companies can only be achieved through the "Ignore Company" parameter in the "Replication Setup Tables".
Fields
Table No.
Number of the affected table.
Table Name
Name of the corresponding table.
Table Filter Sequence
You can create multiple lines for each table, which receive a unique sequence for consideration through this field. If the "Apply Default Values" action is used to automatically determine for which companies Replication Entries should be created, the lines are processed according to the sequence. The first matching line according to the filter is applied; all subsequent ones are ignored.
Important
If no matching line according to the filter is found during the "Apply Default Values" action, this record will not be designated for replication. If you want all companies to be replicated to in this case, create a last line for this table without a table filter and with "Manual Replication Default Value = All according to Setup".
Table Filter
If you enter a filter here, this line applies to the corresponding table only under the specified filter condition. Therefore, you can create multiple lines with different filters for one table.
This allows you, for example, to replicate rows of the posting matrix where the General Business Posting Group starts with AT only to the AT company group. And all rows of the posting matrix where the General Business Posting Group starts with DE should only be replicated to the DE company group.
Please also note that these lines are only suggestions and can be overridden by the user.
Manual Replication - Default Value
This is the corresponding default value for this line. Details on the possible parameters can be found in the chapter "Manual Replication".
Company Group
For "Manual Replication - Default Value" = Company Group, this is the desired company group.
Docs / App / NAVAX Replication / Setup Customer/Vendor Country Posting Groups
If your participating companies represent different countries, you probably do not want to roll out the posting groups of your customers and vendors identically to all companies. For example, an AT vendor can be a domestic vendor in one company, an EU vendor in another, and an export vendor in a third company. Therefore, there is an option to replicate the posting groups differently to individual companies during replication, depending on the Country/Region Code.
Important
Please note that this setup must be stored in the respective affected target company. If you store this setup in the Master Data Company, it has no effect on the replication.
Fields
Type
You must decide whether this line should apply to customers or vendors. There is no option to create lines that apply to both types of personal accounts.
Country/Region Code
This is the "Country/Region Code" stored for the corresponding vendor or customer. For example, if you replicate a customer with a corresponding Country/Region Code, the groups in this line will be applied instead of those set up for the customer in the master company.
General Business Posting Group
This "General Business Posting Group" will be applied when replicating the corresponding customers/vendors. If you leave the field empty, the General Business Posting Group from the record in the master company will be applied.
VAT Business Posting Group
This "VAT Business Posting Group" will be applied when replicating the corresponding customers/vendors. If you leave the field empty, the VAT Business Posting Group from the record in the master company will be applied.
Customer/Vendor Posting Group
This "Customer/Vendor Posting Group" will be applied when replicating the corresponding customers/vendors. If you leave the field empty, the customer or vendor posting group from the record in the master company will be applied.
Here you can define for each replicated table whether Replication Entries defined by a filter should be automatically set to a specific status.
This allows you, for example, to automatically set non-critical tables to "To Review" in case of an error. This way, the replication run is not blocked by errors in this table.
Fields
Table No.
Select the table for which you want to define the automatic status change.
Table Name
Shows the name of the selected table.
Description
Describe the automatic status change.
Table Filter
Define through the filter for which Replication Entries of this table the status should be automatically changed.
Please note that a filter on the "Status" field is mandatory. Otherwise, the automatic status change cannot be activated.
New Status
Define the new status that should be set for the Replication Entries in the defined table filter.
Active
Here you can deactivate or activate the automatic status change.
There are various functions that are only available to the user with the Replication Administrator permission. This is noted directly for the corresponding functions.
For example, only as a Replication Administrator do you have the right to execute the "Execute Replication with Filter" function. Additionally, only with this permission are additional parameters visible in the "Replication Setup".
The setup for the Replication Administrator is to be set in the "User Setup".
Fields
Replication Administrator
If checked, this user is a "Replication Administrator".
Docs / App / NAVAX Replication / Working with the App Replication Entries
Creating, deleting, modifying, or renaming a record of a table that is set up for replication triggers the creation of replication entries.
These replication entries can be reviewed, edited, and of course executed via "RPL Replication Entries".
When a new record is created, an Insert entry is created, which creates the primary key in the respective target company. In some situations, the insert entry may not be created. In this case, the record is then automatically created with the modify entry as well. With the Modify entry, the remaining fields are populated, or if there is no insert entry, the record is created (note that in this case all fields according to the setup are rolled out once). Deleting a table record creates a Delete entry. Each entry contains detail lines with information regarding the individual fields. By clicking on "Replication Entries" or "Details", you can expand and collapse these lines respectively.
Fields
View
Here you can filter to the desired status of the lines.
Replication Entries
Entry No.
The replication entries are automatically numbered in ascending order. When entries are transferred to another database, this entry no. remains the same as in the master company. Therefore, there are usually gaps in the entry no. in the target database.
Remote
If checked -> this entry will be replicated to another database.
Company
This is the "Company" to which this entry is to be replicated.
Table No.
No. of the affected table.
Record
This column provides you with the information (key values) about which record of the table is to be replicated. You can click on the field to display the record.
Operation
Operation of this entry: Insert, Modify, Delete, Rename.
Dependencies
If this record is a replication entry of a dependent table, you will receive information about the main table here.
Status
Open - This entry still needs to be replicated. If you manually change the status from another status to "Open", the system will attempt to replicate this entry during the next replication run.
Replicated - This entry has been successfully processed.
Skipped - Entries with this status are ignored during processing. They also no longer stop processing if there is an error text in this line. You can set this status manually in an entry. In various situations, this status is also set automatically by the replication. E.g., when a record is to be deleted that no longer exists, or when a record is to be inserted that already exists.
Error - If an error occurs during processing, the status "Error" is set and the date and time of the error are documented. The full error text is displayed in the "Error Text" column. Processing of all subsequent entries for this company is then stopped. All other companies continue to be replicated. When the error is resolved, replication will resume at this point for the affected company on the next call.
Waiting - These records have not yet been replicated and are waiting for another event. This is often the case with dependent tables where the record of the main table has not yet been replicated.
To check - This status has the same effect as the "Skipped" status. Replication is therefore also not stopped with the "To check" status. For example, you can set defective replication entries to this status so that they do not block the replication run, and resolve the cause of the error at a later time.
The advantage of this status is that you can use a filter to display only those entries that still need to be checked, and not all consciously skipped entries with the "Skipped" status.
Error Text
If an error occurred during replication, the corresponding error text is displayed here.
Creation Date/Time
Specifies when this replication entry (triggered by inserting, modifying, renaming, or deleting a record) was created.
Transfer Date/Time
Specifies when this entry was successfully executed.
Error Date/Time
Specifies when an error occurred for this entry. If no error has occurred or it has been resolved, this field is empty.
Created by User ID
Specifies who caused the replication entry by inserting, modifying, renaming, or deleting a table entry, or also through the replication setup of the table.
Details
Here you can see the detailed replication data (fields) of the selected replication entry. For each field to be replicated, there is a detail entry.
Entry No.
The detail entries for the replication entry are automatically numbered in ascending order.
Table No.
Identifies the affected table.
Field No.
Identifies the affected field.
Field Value
(New) value of the field.
Field Name and Field Caption
Technical name and display name of the field.
Skip
Specifies whether this field should be skipped during replication.
Actions
Replication Setup General
Replication Setup Databases
Replication Setup Companies
Replication Setup Company Groups
Replication Setup Tables
Table Filter Setup
Manual Replication Setup
Person Accounts/Country Codes Posting Groups
Automatic Status Change
Execute Replication
This action starts the processing of the replication entries.
This action can also be performed via a job queue. If you start the replication not in the master data company but in a target company, only replication entries of the current company will be processed. Processing within a company always occurs in ascending order by entry no. However, for clarity, the data is displayed in descending order - with the most recent replication entry at the top.
Execute Replication with Filter
This function is only displayed if you are a "Replication Administrator". When executed, the "Execute Replication" function is performed as usual. However, only those replication entries are considered that have been filtered in the current window.
Execute Status Change with Filter
This function is only displayed if you are a "Replication Administrator". When called, a filter window is displayed showing the currently set filter of the replication entries. You must confirm this and select the desired status for all filtered entries. This status will be applied to all entries upon execution.
Please note that execution WITHOUT a filter is not permitted.
Show Record
The selected record is displayed.
Transfer from Base Database
This function is only available in target databases (i.e., not in the database of the master data company).
It imports all not yet imported replication entries from the base database that concern this database. In addition, the replication setups are automatically updated.
Docs / App / NAVAX Replication / Working with the App Manual Replication
Not Found
The requested topic was not found on this server.
Docs / App / NAVAX Replication / Working with the App Cross-Database Replication
In each recipient database, the recipient companies of this database must be defined in the Replication Setup Companies. One of these companies should be defined as the "Master Data Company" of the recipient database.
Only in this company can replication for this (entire) database be started after receiving the replication entries. Replications for individual companies can also be started in a recipient database within the respective company itself.
To replicate, you must perform the following steps:
Transfer from Base Database
All new replication entries that concern this database are imported from the base database, and the setups are updated.
Execute Replication
This triggers the replication in the recipient database - just as you know it from the base database.
You can automate both steps via an entry in the job queue.
(Report 70161752 - "NVXRPL Transfer Remote Entries" and Codeunit 70161755 "NVXRPL Start Replication").
Important
The master data company in the additional database is not mandatory. However, if you want to start the replication for all companies with a single call of the "Execute Replication" function, you also need a master data company in the additional database from which you can start the replication for all companies.
In the additional database, the table definitions cannot be changed. Changes must always be made in the base database and are then automatically rolled out.
Docs / App / NAVAX Replication / Working with the App Errors Caused by Replication Entries
Due to setup errors or special data constellations, a replication entry may receive the status Error when executing the replication. Such an entry causes the replication in the affected company to not be performed for all replication entries after the defective entry.
If you have entries with the status "Error", there are several options to resolve this situation. This should only be done by an experienced BC user who also understands the database structures well.
Among others, the following correction options are available:
Fixing the cause of the error
With each replication run, the system will attempt to replicate the record again. If the cause of the error is resolved, the replication will be performed normally.
Set status to "Skipped"
This replication entry will no longer be considered during replication and thus no longer blocks the replication.
Please note that this entry has therefore not been replicated, which may lead to subsequent errors in individual cases.
The replication itself automatically sets some entries to "Skipped". For example, when a record is to be deleted but no longer exists in this company. Or when a record is to be newly created but already exists in this company.
Set status to "To check"
This replication entry will no longer be considered during replication and thus no longer blocks the replication.
You can review this entry at a later time and decide whether to skip or replicate it.
Manually correct an invalid field value
If, for example, an invalid field value in the details caused the error, you can also manually change this field value directly in the replication entry. On the next replication call, the replication will attempt to replicate this entry with the changed value.
Docs / App / NAVAX Replication / Working with the App Replication Entry Dependencies
For tables that have the Manual Replication parameter set, it is possible to define "Dependent Tables".
When a table depends on another, the associated replication entries are initially set to Waiting automatically.
Only when the record of the main table has been replicated will this waiting replication entry also be replicated. If the record of the main table has already been replicated, the "Waiting" status is of course omitted for all dependent tables.
An example is "Vendor" as the main table and the "Vendor Bank Account" table as a dependent table.
Fields
Dependencies
If this record is a replication entry of a dependent table, you will receive information about the main table here.
Docs / App / NAVAX Replication / Working with the App Tasks
When working with the app, several task areas arise.
Tasks After the Upgrade
1. In the previous version of the replication, "manual replication" was permanently set for the following tables:
Table 15 - G/L Account
Table 18 - Customer
Table 23 - Vendor
Table 27 - Item
Table 152 - Resource Group
Table 167 - Project
Table 5050 - Contact
"Manual replication" can now be configured individually for most tables. Further details can be found in the corresponding chapters. You must carry this out or verify it.
If you previously used the value "Operative Only" in the parameter "Transfer to Company" within "RPL Transfer to Companies Default Values", this value was automatically changed to "Company Group" during the upgrade.
You must now create this company group manually!!!
You may, for example, name it "Operative Only" and assign the companies that were marked as operative in the legacy system to this group.
The categorization “Operative Only” is no longer supported directly by the companies.
(Note: Therefore, the company group described above is required.)
If you used the option "Only Certain Companies" for tables or fields in the legacy system, you must review and, if necessary, correct these settings in the new system, as in many cases they cannot be transferred automatically by the upgrade routine.
In general, all other table settings must also be reviewed, as during an upgrade table names, field names, or field numbers of replicated tables may change. The upgrade routine cannot automatically account for such changes.
2. Permission sets for users must be reassigned after the upgrade:
RPLNormalNX → NVXRPL
RPLSuperNX → NVXRPL, Setup
Interface Between Databases
When testing the interface connection between two databases, you must assume that HTTP requests are automatically blocked in a test database.
In the extension settings entry, the checkbox "Allow HttpClient Requests" must be activated for a test database so that the connection can function.
More information can be found in the Microsoft documentation:
HttpClient data type - Business Central | Microsoft Learn
Job Queues
The action "Run Replication" starts the processing of all replication entries that have not yet been processed. This action can also be executed via the job queue.
Codeunit 70161755 - "NVXRPL Start Replication"
Docs / App / NAVAX Replication / Working with the App Special Cases
Replicating tables is usually a straightforward matter.
With manual replication, dependencies (via dependent tables) must be considered.
With automatic replication, the order of replicated data rarely requires special attention - however, you must ensure that sub-tables have been replicated. For example, if you replicate a customer with a filled reminder method, you must make sure that either the reminder method was replicated beforehand - or was manually created in the corresponding target company.
So much for the theoretical perspective. With extensive use of replication, you will find that in practice much more complex challenges await you. The reason for this is automatic functionality that the BC standard executes when validating fields. Or also through so-called triggers when writing, modifying, or deleting a record. If you observe unexplainable behavior when replicating seemingly simple data, have your system administrator investigate in this direction first.
Below we share some experiences on this topic.
Special Case: Post Code and City
In the BC standard, a "Post Code" table is usually associated with "Post Code" and city fields. When validating the Post code and city fields, interactions with automatic overwriting of already stored values can occur. This can lead to unwanted data changes, especially for large cities that have different Post codes (all with the same city name, of course).
Important
Therefore, we recommend not executing field validation when replicating Post code and city fields.
Replication of Contacts, Customers/Vendors and Business Relations
If you maintain contacts in BC in addition to customers and vendors, the data structure is a bit more complex. To keep it simple, we will only look at the area of contacts and vendors below.
Vendors (Table 23) can be created from contacts (Table 5050). The business relation (Table 5054) is then automatically created by BC. The prerequisite for this is a setup in "Marketing & Sales Setup", which can look like this, for example (business relation code for vendors):
Please note the following special considerations in the setup:
Contacts (Table 5050)
For the following fields, field validation must be deactivated, as it can otherwise cause problems with BC standard functions.
Marketing & Sales Setup
It is very important that the field "Bus. Rel. Code for Vendors" is only filled with a value in the master company. In all target companies, this field must remain empty.
Additional Setup for Manual Replication
If you have activated "Manual Replication", you must consider additional setup requirements:
Contacts (Table 5050)
If contacts are also replicated manually, the contact must already be replicated before you replicate an associated vendor.
This is best solved organizationally. You cannot ensure this through setup.
Business Relation (Table 5054)
This table is to be set up without any special considerations. However, when leaving the "Replication Table Setup", the option "Leave setup without creating replication entries" must be selected.
Vendor (Table 23)
We assume that this table is replicated manually.
Here, the business relation (Table 5054) must be linked as a "Dependent Table".
Import (Migration) of Contacts, Customers/Vendors and Business Relations from Previous System
The import of existing contacts, customers/vendors and their business relations from previous NAV or BC environments is performed using configuration packages.
For this purpose, the business relation codes in "Marketing & Sales Setup" must be removed to ensure the import is performed correctly.
The import using configuration packages follows these steps:
Import of existing contacts
Import of existing customers/vendors
Import of existing business relations
After the import is completed, the business relation codes in "Marketing & Sales Setup" must be re-entered. The created replication entries can be replicated independently of this.
Important
(see also "Replication of Contacts, Customers/Vendors and Business Relations")
The business relation codes in "Marketing & Sales Setup" may only be entered in the master data company. In the target companies, they must remain empty.
Docs / App / NAVAX Replication / Developer Information Enable Manual Replication for Additional Tables
NAVAX Replication is already integrated into many card pages by default via page extensions.
The underlying code is identical on all pages.
Therefore, NAVAX Replication can also be integrated into additional card pages with minimal effort via individual development.
Below is an example code for integration on the Customer Card page.
pageextension 70161751 "NVXRPL Customer Card" extends "Customer Card"
{
ContextSensitiveHelpPage = 'ReplicationFactbox';
layout
{
addfirst(factboxes)
{
part(ReplicationPart; NVXRPLReplicationFactbox)
{
ApplicationArea = All;
Visible = ManualReplicationActivated;
}
}
}
trigger OnAfterGetCurrRecord()
var
ReplicationTableSetup: Record "NVXRPL Replication Table Setup";
Ref: RecordRef;
begin
Ref.GetTable(Rec);
ManualReplicationActivated := ReplicationTableSetup.NeedsFactBox(Ref.Number());
if ManualReplicationActivated then
UpdateReplPart(false);
end;
trigger OnModifyRecord(): Boolean
begin
if ManualReplicationActivated then
UpdateReplPart(false);
end;
trigger OnInsertRecord(BelowxRec: Boolean): Boolean
begin
UpdateReplPart(false);
end;
trigger OnNewRecord(BelowxRec: Boolean)
begin
UpdateReplPart(true);
end;
var
ManualReplicationActivated: Boolean;
local procedure UpdateReplPart(CallFromOnNewRec: Boolean)
var
RecId: RecordId;
RecRef: RecordRef;
begin
if CallFromOnNewRec then
Clear(RecId)
else begin
RecId := Rec.RecordId;
CurrPage.ReplicationPart.Page.SetRecId(RecId);
if RecRef.Get(Rec.RecordId) then
CurrPage.ReplicationPart.Page.SetRecords();
end;
CurrPage.ReplicationPart.Page.Update(false);
end;
}
Do you need a function or an "event" that is not yet included in the current application? Contact us and we will review your request. If possible, we will implement the desired extension promptly. If not, we will inform you and briefly explain the reason. In that case, do not be discouraged - reconsider your approach and feel free to submit a new request.
If you're building your own app and need something specific from us, like an event, you can help improve the general extensibility of our apps. We'll have a look at your request, and if we can we'll implement it asap. If we can't we'll let you know and briefly explain why not. When that happens, don't be discouraged. Go back to the drawing board, see if you can work it out, and then come back and submit another request.
The NAVAX License Management page (in older versions "NAVAX License Overview" or "NCEX License Overview") displays the current license status of the NAVAX extensions.
Fields
Name
Specifies the name of the Extension.
License Status
Specifies the current license status of the Extension.
Serial No.
Specifies the serial number of the Extension.
Version
Specifies the currently installed version of the Extension.
Trial Version
A NAVAX extension can be tested or used free of charge for 30 days after installation. After that, the extension can only be used with a valid license.
Request License
The license can be requested or checked via the Current Status action. This opens a new page.
The following example shows the NAVAX extension Excel Report Builder.
Fill in the fields in the page and then click Send License Request. Please note that the licensing process may take some time. In the next few days you will receive an email with further information.
Note
For licensing, calling the online help and performing some actions, access to https://www.navax.app must be granted.
Public IP from www.navax.app for setting firewall access: 94.136.22.236, Port: TCP/443
Checking the connection to https://www.navax.app using PS: Test-NetConnection navax.app -port 443 (PS must be performed with the M-Tier service user)
CRL Servers In addition, the following CRL Servers must also be accessible for the certificate check: https://certificates.godaddy.com/* http://crl.godaddy.com/* or their IP: 192.124.249.36
Activate/Update License
As soon as the licensing has been completed, you will receive an email and the license can be activated via the Update License action. The license is company independent. So it does not matter in which company the action is called.
Note
The licence must be updated once a year via the Update License action.
The update is only possible or necessary within the last 30 days before the license expires, or afterwards. Within the last 30 days before the license expires, notes are displayed.
If the Automatic License Renewal is enabled, the Update License action is called automatically before the license expires. During this process, all licenses for which automatic license renewal is enabled are checked and updated if necessary. If automatic renewal is not successful, notifications will be displayed within the last 15 days before the license expires. Note that the setting is only active after the license has been activated.
This action can be used to open the Microsoft AppSource ratings page for the extension. We would be very happy if you submit your rating and let us know about your experience with the Extension.
The following Granules are required for an On-Premises installation:
70714855 NAVAX Replication
1010860 Extension Base by NAVAX
External Addresses
https://www.navax.app
For licensing, calling the online help and performing some actions, access to https://www.navax.app must be granted.
Public IP from www.navax.app for setting firewall access: 94.136.22.236, Port: TCP/443
Checking the connection to https://www.navax.app using PS: Test-NetConnection navax.app -port 443 (PS must be performed with the M-Tier service user)
CRL Servers In addition, the following CRL Servers must also be accessible for the certificate check: https://certificates.godaddy.com/* http://crl.godaddy.com/* or their IP: 192.124.249.36
NAVAX Replication
To replicate, you must perform the following steps:
More information can be found in the Microsoft documentation:
HttpClient data type - Business Central | Microsoft Learn
Fill in the fields in the page and then click Send License Request. Please note that the licensing process may take some time. In the next few days you will receive an email with further information.
