If your site already has synchronization set up, do not make changes. This documentation-set does not apply to the older sync setup!

Why synchronize?

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.

Which import methods are available?

Manual Sync

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

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.

Matics API

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

Which data to sync?

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.

NOTE

The organizational logic of the client's system data doesn't always match the Matics database structure since these are different types of systems. This sometimes requires inventive workarounds for creating data entities that can be synchronized.

Dress for success!

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

Make sure you've mapped the required fields.
Required fields must contain data values.
Import data in the correct sequence.
This is because there are inherent dependencies. For example, you cannot import job data before you've imported the product data, otherwise the system has no idea what product this job is for.

Table dependencies (key fields)

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.

Example of a dependency between tables (key field in one table is referenced by the other table)

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:

Allow Null column with False value in example auto sync interface object

NOTE

Fields required for importing objects' data are not necessarily required when creating that object manually in the Matics system. For example, when creating an Auxiliary Type in Matics, the ERP ID field is optional, but when you're importing data to Matics, you are required to provide the client's identifier for the auxiliary type as there has to be a key identifier.

And vice versa, fields that are required when manually creating an object in Matics are not necessarily required when creating that object through import. For example, EName in the product record.

Visualizing import dependencies

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:

Overall dependency diagram
Core data dependency diagram

Overall dependency diagram

Primary data import sequence

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.

Import order based on required fields dependencies

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.

NOTE

There are no dedicated tables for importing machines and machine types, since these are a given as part of the system's infrastructure.
If the ERP/MRP system doesn't group machines to machine types this information must be retrieved from the Matics system, since all machine IDs are paired with machine types.

TIP

In the data sync interface itself you have informative descriptions for each field.

Primary data correspond to these Matics tables

* indicates an optional table.

*Matics Table Name*	*Required Fields*	*Purpose*
Products	ProductName, CatalogID, FK_MachineType	Import the product's main identifiers.
*Product Machine	FK_ProductID, FK_MachineID	Import the machine the product runs on. * Optional table since `FK_MachineID` can come from other tables, or be provided ad hoc when activating the job via the system)
Product Recipe	FK_ProductID, FValue, FK_PropertyName	Import the product recipe's production parameters (a.k.a. Channel 0 properties)
*Product recipe standard	FK_ProductID, FK_PropertyName, FK_MachineID, Fvalue	Used for setting the products’ recipe standards for each machine, and these standards will be presented as the Alternative Recipe in jobs created for the product. * Not required for creating the job.
*Product Recipe Job	FK_ERPJobID, Fvalue	* Best practice is to use the `Product Recipe Standard` table for managing job-specific recipe properties, which are usually dependent on the machine the job will run on. If you do choose to use this table, note that even though `FK_PropertyName` isn't marked as required, the `FValue` corresponds to that field.
Mold	FK_MachineType, FK_ERPMoldID, Lname, Cavities, CavitiesCurrent	If the client uses molds to produce the product, first enter the mold's basic identifiers to the system.
Product Molds	FK_ProductID, FK_MoldID	If the client uses molds, in this table you bind between the product and the mold used to produce it.
*Materials	Lname, CatalogID, FK_MaterialGroup	If the client wants to analyze material consumption through Matics, import the material's ERP identifier and the material group it belongs to (`FK_MaterialGroup` is part of the system's infrastructure, established when setting up the system.)
*Product Recipe Material	FK_ProductID, FK_MaterialID, Fvalue NOTE: If the client is importing channel and split information ChannelNum and SplitNum are required too.	If the client wants to analyze material consumption through Matics, you'd import what materials are required for manufacturing the product.
*Product Recipe Job Material	FK_ERPJobID, FK_MaterialID, Fvalue NOTE: If the client is importing channel and split information ChannelNum and SplitNum are required too.	* This table is rarely in use. It's purpose is to import changes in values of product materials' standards for specific jobs.
Job	FK_ProductID, UnitsTarget, ERPJobID, and if not imported through previous tables you can import the FK_MachineID through this interface object.	Import the jobs' data. TIP: If the client's data include machine IDs and the client is interested in automatically advancing imported jobs to status 03 - approved for production, the `AutoChangeJobStatus` system variable should be set to `true`.
*Job Constraints	FK_SourceJobID, FK_DestinationJobID	Use this table when you need to determine leading jobs and following jobs, a.k.a. job dependencies or job trees. These will be reflected nicely in the Gantt.
*Job Activation	ERPJobID	Use this table when you activate jobs using the data import mechanism.

Subsequent dependent data correspond to these Matics tables

*Matics Table Name*	*Required Fields*	*Purpose*
Inventory	FK_InventoryID, EffectiveAmount, FK_MaterialID, FK_ProductID,	If the client is interested in tracking inventory through Matics, import inventory data.
Worker Types	Name, HourlyCost	If the client is interested in tracking and analyzing worker costs, import the worker types/categories the clients uses.
Worker Type Standards	StandardForObject (for which entity the worker type standard is set: 0 = Machine type, 2 = Job, 3 = Product), ObjectERP (ERP ID of the entity that is being synced), WorkerTypeERP, WorkerStandard	If the client is interested in tracking and analyzing worker costs, assign the worker types to system entities and their standards per the assigned context.
Product Children	FK_ParentID, FK_ChildID
JobCustomParams	(no required fields)	If the client is interested in importing custom parameters, import their custom parameters through this table.

*Matics Table Name*	*Required Fields*	*Purpose*
Order	FK_OrderID, FK_ProductID, UnitsReq	To import order data.
Order Lines	FK_OrderID, FK_ProductID, UnitsReq, LineNum	To import order line data.

*Matics Table Name*	*Required Fields*	*Purpose*
S Tbl Auxiliary Types	Name, ERPID	To create the auxiliary category the auxiliaries if you need to import auxiliary data.
Tbl Auxiliaries	Name, ERPID, FK_MachineType, FK_AuxiliaryType	To import auxiliaries to the system.
Tbl Product Auxiliaries	FK_ProductID, FK_Auxiliary	To import the binding between products to auxiliaries.

*Matics Table Name*	*Required Fields*
P Config	FK_PConfigID
P Config Products	FK_PConfigID, FK_ProductID
P Config Tools	FK_PConfigID, FK_MoldID

Non-dependent table objects

Clients, in the meaning of customers (#1)
Users (#18)
Controller Fields (#19)
Report Stop Events (#25)
Suppliers (#31)

Important note about idiosyncratic keys & values

Due to legacy constraints, the primary key CatalogID in the Products table (interface object index 4), is referenced by FK_ProductID in other tables, such as the Job table (interface object index 2).
And the same in the Materials table (interface object index 3), the primary key CatalogID is referenced by FK_MaterialID in other tables, such as the ProductRecipeMaterial table (interface object index 6).
When importing the recipe properties, either production parameters (what was once called 'Channel 0'), or material related properties for channels 1 to 100, the name of the property listed in the FK_PropertyName column must match the property's name as set in the system. Most of them are straightforward, but the Units in Cycle property is based on the legacy property name MoldCavities.