Synchronization is used for importing data from the client's ERP/MRP system(s) into Matics. The imported data serves as the basis for production processes, and is used for setting up the various production entities such as products and jobs (with the exception of machines, which are set up manually).

There's also an option to export manufacturing data from Matics using data sync into the client's ERP/MRP system. If this is set up, it's usually done for reporting and analysis purposes.

Manual Sync is a utility that can be used to import data from your ERP/MRP systems directly to Matics, by manually uploading CSV or text files through the Matics Web app. This is a useful import option if there's no need for continuous synchronization of large volumes of data.

Auto sync automates the import of data through the Matics sync service installed on a server at the client's site. See the Data Sync Architecture for Auto Sync article for a diagram and description of the topology in use. Using this service you can auto sync data from table views and flat files.

The service's configuration is done via the Data Sync > Auto Sync configurator in Matics and the service installation is through a short wizard-based installer. Configuring auto sync via Matics Web provides maximum flexibility in updating and optimizing data import definitions.

Clients with developer resources may prefer direct data import via the Matics REST API.

Scoping what data to import into Matics depends on the client's production floor processes and what the client wants to track. For example, is the client only interested in tracking a machine's job production rate? Or does the client want to track the consumption of materials as well?

If the former, the interface is minimal and if the latter synchronization involves additional interfaces and requires pulling more information from the ERP/MRP system.

In any case, imported data needs to fit the schema of the Matics database, and exported data should match the schema of the client's database.

There are three key guidelines you need to follow when importing data:

To meet the requirements of the Matics schema, you need to know what dependencies exist between Matics database tables, since even if the target data are minimal this may require mapping additional data keys from other tables.

Table dependencies in databases are when a there is a key column in one table that is used by other tables.

Dependencies indicate that to sync one table you need to sync more tables if there are required columns (fields) the dependent table relies on. For example, table # 2 Job requires the ProductID column's values, which come from the CatalogID column in table # 4 Products.

When setting up synchronization of imported data, you'll need to take into account these dependencies and make sure to map all the relevant and required fields.
Following the previous example, if you want to synchronize jobs, since the Jobs table is dependent on the Products table you will need to map and import all the required fields in both these tables.

Check and map the fields included in each table by clicking the index of the table object in the Data Sync > Auto Sync > Import sync definitions tab, or if using Manual Sync you would do so from the Data Mapping dialog.

Required fields are those that do not accept NULL, for example ProductID in the Job table:

Many tables are dependent on the Product table, including the Job table. The job table also has quite a few dependencies. To get an idea of dependency directionality we've visualized this in two diagrams:

Not all the Matics tables data are required, since each import depends on the client's requirements, but the starting point will always be the Products and the Product Recipe tables, and often include initial Job data to enter the jobs in the system.

ProductRecipeStandard is an optional table, but it’s a useful table since it lets you set the products’ recipe standards for each machine, and these standards will be presented as the Alternative Recipe for jobs created for the product. If the client uses molds in the production process, Mold and Product Molds are required tables that should be imported before importing job data, and if the client is interested in importing material data, this too should be imported before importing jobs.

Each client imports different data, so the tables below are only a rough guideline. The principle is to make sure a required field referenced by an interface object (table) has already been imported through a previous interface object in order to prevent sync failures. This means that required fields can and will be duplicated per the context. For example, the product's table CatalogID field is afterward referenced as FK_ProductID in many other tables.

* indicates an optional table.

Users Data Sync Permission Settings

Manual Sync