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.
Special Cases
