MX supports product data sync from ERP to MX, which includes sync of units of measurement, primary product data (Material ID, Material Basic Data Text), Product/Material classification data, product sales text, and Product Variants.

 

From the ERP side, you can limit the number of products going into MX by creating the views which act as a filter on top of the ERP Data. 

 

The product sync is split into two parts, first (initial) product data sync and second (subsequent) delta product sync, which allows sync of newly added or changed materials from ERP system. The changes are recognized based on the last change date in ERP.

 

MX uses a Uniform Resource Identifier (URI) to identify each object uniquely. The materials and other objects coming from ERP are identified by a URI that includes the hostname of the ERP system (source system) plus the material/object ID to make a unique URI per material/object. The hostname is found from the destination ECC_RFC_DESTINATION and follows the pattern of hostname and client.

 

For example, a material URI would look like:

http://imc.prod/800/Product#000000000000123456

where

• prod is the ERP hostname and comes from jco.client.ashost or jco.client.mshost
• 800 is the client and comes from client.client
• Product is the name of the type of the object
• 123456 is the material ID

Note: Note that in MX, Product and Material are used interchangeably.

 

Important: For materials synchronized from ERP, the linkage with its Unit of Measure is done based on URI only. Unit of Measurement (UoM) also has a similar URI. To link the two together, UOM should be first synchronized from the ERP before starting with the Product sync.

 

To start the product data synchronization, go to:

Administration→ Data Synchronization → ERP Data Synchronization

Order to Synchronize Data

First, sync all Unit of Measurement and Product Hierarchy (optional).

Next, start syncs of the product together with classified* data. Enable the setting SettingProductSyncDownloadClassification if classification data is needed. If enabled, products are synced along with their classified data, which includes the classification class and characteristic values.

The data sync first synchronizes the characteristics, followed by the classes, the product itself, and finally, product classification.

In ERP, the classification data can be maintained in various classes. The setting SettingClassificationToLoad is useful in listing which class type (class name) to use for classification data, and the default is class type 001.

The following data points are extracted from the ERP system:

Unit of Measure

• Short text (imported as a label) in all maintained languages.
• All units of measurements maintained in the ERP system.

 Material Hierarchy

• Material hierarchy maintained in the ERP system.
• Short text (imported as a label) in all maintained languages.
• Hierarchy ID is mapped to objectERPId.

Material

• Product (materials) maintained in the ERP system.
• Short text (imported as a label) in all maintained languages.
• Base texts (imported as description) in all maintained languages.
• Sales text (if the setting is on)
• Unit of measurement
• Product hierarchy (imported as product category).
• Deletion flag (mapped to product status)
• Material number (mapped to objectERPId)
• Last Change Date

Classifications

• Classifications (knowledgebase) maintained in the ERP system.
• Short text (imported as a label) in all maintained languages.
• Long text (imported as description) in all maintained languages.
• Class name mapped to objectName
• Last change date

Characteristics

• Characteristics maintained in the ERP system.
• Short text (imported as a label) in all maintained languages.
• Characteristic name mapped to objectName.
• Last Change Date

Characteristics Value

• Short text (imported as a label) in all maintained language.
• Characteristic value mapped to objectName.

Custom Table View

Not part of product data syncs, however useful in synchronizing any custom/standard table from ERP. See Internal Price Engine Guide for more information.
The relations between MX and ERP are mapped as follows:

Used BAPI’s:

• RFC_READ_TABLE
• BAPI_MATERIAL_GET_PRODUCTHIER
• BAPI_CHARACT_GETDETAIL
• BAPI_CLASS_READ
• BAPI_MATERIAL_GETALL
• CLAF_CLASSIFICATION_OF_OBJECTS

Limitations: 

• Only hierarchy nodes that are referenced by-products will be fetched.
• Only one material class (class type 001 or another) is taken into consideration for classification.
• The product variant is considered on top/separately.

• During the product sync, no relationship between hierarchy nodes is maintained, so the hierarchy tree is not available.  

• No long texts are fetched for characteristic values. 

• No units are fetched for characteristics. 

• No class hierarchy information is fetched.

• Inherited characteristics are not considered during product sync. 

• Time and date characteristics are fetched as string values only.

Data Selection / Filtration in ERP

MX uses database views in ERP to check which objects should be synced to MX. It also applies to products, classes, and characteristics sync. We recommend maintaining all the views below at one time.

Database views in ERP can be created using transaction SE11.

Tip: Database filters might return duplicated records since ERP does not support the DISTINCT concept when creating views. This is currently handled on the MX side, where duplicates are eliminated.

Product Sync Procedure

Create database view “Z_ISS_MAT” with columns “MANDT”, “MATNR” and “LAEDA” in ERP. This view is based on the standard ERP table “MARA”. This view can do the pre-filtering of products/materials in ERP, which is to be synced to MX. 

Depending on the filter conditions, the view might need to perform a join on different tables and a set of selection conditions. 

Those filters need to be applied depending on the business case of the customer. We recommend to carefully put in selection the product that should be made available in the MX system as this impacts the performance of data sync. The larger the set of data, the more time will take to complete the sync. If the products are not sales relevant, do not sync them to MX.

Manual and Explicit Material Synchronization

To synchronize an individual material (or list of materials) from the ERP System. The user needs to go to:

System Processes → Products Synchronization → Click on the download button. Add the ERP ID of the materials fully qualified that is with leading zeros in case the material ID/name is numeric.

The screenshot above shows the example where the material ID’s INV_266765, INV_266764, INV_266763, and 000000000000123456 are to be synced from the ERP system.

Background Product Synchronization

In the main product sync, the products can be synchronized in the background by using: 

System Processes → Synchronize products and by selecting Run in background parameter.

Background Product Sync System Task

You can set up a system task to run the product sync in the background. Administration → System Task → create a new task with a cron expression string and using the task resource “Product Sync Job”.

For more information on cron expressions: please refer to https://www.freeformatter.com/cron-expression-generator-quartz.html.

Some of the settings that affect the Product Sync Job are as follows:

SettingProductSyncDownloadProducts	Setting to enable sync of products in background system tasks
SettingProductSyncDownloadClassification	Setting to enable sync of classification data of the products. Should be enabled before the start of product sync.
SettingClassificationToLoad	Setting to override which classtype to load the classification data. Default is 001
SettingProductSyncBatchSize	Setting to setup a batch size for product sync.
SettingProductSyncBatchSyncInactive	Setting to also sync mark for deleted products in ERP
SettingProductSyncBatchMarkAsExportToCRM	Setting to enable the flag export to crm on products synced from ERP
SettingUseDisplayMatNoFromBAPIForObjectName (Deprecated: since 1902, MX now applies the product object name by removing prefix zeros from the material number.)	If true, it would allow the 18-digit numeric material number coming from ERP to remove its prefix zeros. That is if a material number is 000000001234567800 it would become 1234567800 and this 10 digit number would be the object name of the product.

 

ERP Material Class Sync Procedure

For syncing the classification data of the material, the following steps need to be undertaken in ERP.

Create database view “Z_ISS_CLASSES” with columns MANDT, CLINT, KLART, CLASS, and VDATU in ERP. It is based on the standard table “KLAH”. It’s needed to control the pre-filtering of classes in ERP, which are to be synced.

One can set the filtering conditions in this view. An example: Created by a User and class type

Manual Class Synchronization

To synchronize individual class in the ERP system. Follow the steps as listed in the screenshot below.

ERP Characteristic Sync Procedure

For syncing the Class characteristic data, the following steps need to be undertaken in ERP. Create database view “Z_ISS_CHARAC” with columns MANDT, ATINN, ADZHL, ATNAM, and VDATU in ERP. It is based on the standard table “CABN”. It’s needed to control the pre-filtering of characteristics in ERP, which is to be synced. 

Example of filter criteria:

Manual Characteristic Synchronization

To synchronize individual characteristics in the ERP system, use the process shown in the screens shot below.

Product Sales Text Sync

In the ERP system, material sales text is maintained in a way that they are the org unit and distribution channel-specific. 

Product sales text is governed by SettingProductSyncDownloadProductSalesText Boolean setting. If this setting is on, sales text is synced along with the product sync. RFC_READ_TEXT BAPI is used to read sales text from the ERP system. This BAPI needs to be enabled from the SAP Cloud Connector. 

MVKE and LANGUAGEKEYS lookup tables in MX are also used in the sync process. MVKE contains records on a product, sales organization, and distribution channel relationships. Data for this table can be directly synced from the corresponding ERP tables. (If the data is too much, a view can be created in an ERP system with some filtering criteria that can be synced or can be maintained manually). LANGUAGEKEYS table is used to keep the mapping between language key and corresponding 2-character SAP language code. T002 is the corresponding table from the ERP system.

Field Name	Description
MATNR	Product ERP ID / Material number
VKORG	Sales organization ERP ID
VTWEG	Distribution Channel ERP ID

MVKE Lookup Table

Field Name	Description
SPRAS	Language key
LAISO	2-character SAP language code

LANGUAGEKEYS Table

Sales organizations, distribution channels, and languages need to be maintained in MX along with their ERP IDs.  In the ERP system sales text may be kept for several languages, but in the sync process, only the languages maintained in MX are considered. 

Usage of Product Sales Text in MX

Product’s sales text can be viewed under the product’s General Information -> Sales Labels,

Here ERP ID is the combination of the ERP IDs of product, sales organization, and distribution channel.

Sales text of a product can also be viewed from the product catalog given that the product catalog is launched from within the quote and sales org and distribution channel are maintained for the quote. MX finds the sales text with the combination of sales organization and distribution channel of the quote and the locale language of the current logged in user. 

Sales text in product catalog view,

Sales text from product details view,

Once a product is added to the quote, the sales quote can also be viewed from the line item view.

Extension Points in Sales Text Reading

A groovy extension point is made available to map the user’s locale language to sales text language. UserLangToTextLangMappingScript can be used to code any custom logic for the mapping. If a script is present, the system will execute the script to figure out sales text language, and else it will use the user’s locale language. 

Sample script:

/* This script determines sales text language for a given user language. It will be executed at the time of reading the sales text in MX.

 * Binding objects

*  userLanguage : String // String representing user's language("en" for example)

*  textType : String // String representing text type ("SALES_TEXT" for example)*

*/

if (textType.equals("SALES_TEXT")) {

return "en_sg";

}

return userLanguage;

Synchronization History

If any of the above synchronizations are triggered, MX will generate a synchronization status report, as shown below:

Clean Up

A system task (CRON job) is provided to clean up synchronization history. Users can either manually clear synchronization history from UI or set up a CRON job. The following screenshot shows to set up a system task from master data management. The most critical point of this screenshot is task resource, and it must be “DeleteSyncHistoryJob”.

 

There is a case that the user wants to keep the synchronization history in MX for a few days to check whether sync is successful or not. A setting can define how long the synchronization history will stay in the MX in terms of days. If the setting is not specified explicitly, MX will take the default setting value of “30”. The clean-up job will delete the synchronization history that existed more than 30 days ago.