Purpose

The purpose of this document is to define the conversion approach to create Conversion Specification Document CNV-2009 Material Master – QM View in S/4HANA.

The QM View in the Material Master contains quality-related settings that control how a material is handled in Quality Management processes. These settings include inspection types (e.g., goods receipt, in-process, delivery), quality control keys, certificate requirements, preferred inspection plans or material specifications, and the status of quality management activation for the material. Maintaining the QM View ensures that materials are consistently subjected to the correct inspection processes during procurement, production, and sales.

In SAP S/4HANA, the structure and usage of the Material Master QM View remain consistent with SAP ECC. The QM View is defined by material (MARA-MATNR), plant (MARC-WERKS), and the associated quality-related fields. These include inspection setup (QMAT), inspection types (QMAT-ART), active status, and assignment of task lists or material specifications.

In SAP ECC, aside from the standard fields, additional legacy configurations may exist, such as:

• Materials with obsolete inspection types still marked in the QM View.
• Materials assigned to inspection types without corresponding inspection plans or specifications.
• Redundant or duplicate plant-level QM settings for the same material.
• Materials with blocked or obsolete quality control keys.
  These cases will need to be validated and cleansed as part of the Master Data Services (MDS) process prior to migration.

This conversion aims to migrate active and relevant Material Master QM View data from existing ECC systems into S/4HANA by applying the required transformation logic using Syniti as the data migration and transformation platform. The converted records will be loaded into the target S/4HANA system using standard SAP mechanisms such as BAPIs (e.g., BAPI_OBJCL_CREATE or BAPI_MATERIAL_SAVEDATA), IDOCs, or direct table loads where applicable, ensuring that all materials in scope have consistent and accurate QM-related setup in the target system.

This Conversion Specification does not include the WPX system (CUI Objects).

Conversion Scope

The scope of this document covers the approach for converting active Conversion Specification 2009 Material Master – QM View data from Legacy Source Systems into S/4HANA following the MDS-2009 Material Master QM View Design Standard.

From the current system landscape, Material Master QM View data exists separately in the legacy systems (PF2 and WP2), with potential discrepancies in both systems. Harmonization and validation are required to ensure accurate and consolidated data in S/4HANA. While PF2 and WP2 serve as source systems, extensive mapping and transformation logic will be necessary to produce properly formatted load templates in line with the target design.

The data from legacy system includes: 

1. The migration of Material Master – QM View will be governed by the Material Relevancy Criteria (aligned with CNV-2019 Materials - Basic Data View and CNV-2010 Materials - General Plant Data / S.Loc Data), which serves as the foundational rule for identifying and including QM data that is valid, active, and business-relevant for conversion to S/4HANA. The Data Relevancy logic defined in CNV-2019 – Material Master (Basic Views) shall be applied.
   Additionally, the Plant/Material Relevancy logic from CNV-2010 – Materials (General Plant Storage Location Views) must be used for consistency and alignment across objects.
2. QM Views without deletion flags, ensuring only valid and relevant records are migrated.
3. QM Views assigned to in-scope plants, based on the To-Be Plant Mapping (considering new plant definitions).
4. Materials with at least one valid and active inspection type in Syensqo (e.g., 01, 02, 04, 05, 06, 08, 10, 11, 12, 17).
5. Materials with valid control key, inspection setup, and certificate requirement, consistent with the S/4HANA target design.
6. QM master data linked to active materials and plants in scope, ensuring alignment with migrated Material Master data.

The data from legacy system excludes:

1. Inactive QM Views for materials not used in inspection lots or quality processes within the last four (4) years.

2. QM Views marked for deletion or with inspection types blocked in ECC.

3. QM Views belonging to plants that are deleted or out of scope, based on the To-Be Plant Mapping.

4. Obsolete or invalid inspection types or inspection setup not supported in S/4HANA.

Relevancy rules

1. Material/Plant with history and active usage
   Materials must be defined at both global level (MARA) and plant level (MARC) with valid status and assignment to active in-scope plants. Only materials with active QM View (MARC-PSTAT="Q" and MARC-QMATV = "X") are considered relevant. In addition, QM View relevancy must aligned with Material Master Basic Views (CNV-2019) to ensure consistent dependency with MARA-level relevancy.
2. Active Inspection Types
   Only materials with at least one valid and active inspection type (e.g., 01, 02, 03, 04, 05, 06, 08, 10, 11, 12, 17) maintained in QMAT table and linked to relevant plants will be considered in scope.
3. Inspection Setup with Valid Usage 
   Inspection types must be relevant to in-scope Syensqo business processes (e.g., Goods Receipt, In-Process, Delivery). Materials without any active inspection usage in the last four (4) years will be excluded.

4. Plant-Specific Validation
   Materials with QM View will be checked against active plant mappings (To-Be Plant Definition) to ensure that only valid, active plants are considered for migration.

Material/Plant active with four (4) years inspection usage history ➝ validates active QM View (QMAT) with at least one valid inspection type (e.g., 01, 04, 09) ➝ confirms Control Key, Certificate Type, and Q-Score alignment with configuration ➝ ensures accurate integration with incoming inspection and quality processes in S/4HANA.

Plant Merging

Plants will be harmonized based on the To-Be Plant Mapping. As some legacy plants will be merged into one target plant, QM Views will be reassigned accordingly to ensure data consistency and alignment with the new plant structure in SAP S/4HANA.

List of source systems and approximate number of records

Additional Information

Multi-language Requirement

Not applicable

Document Management

Not applicable

Legal Requirement

Not applicable

Special Requirements

Not applicable

Target Design

Inspection Plan strictly adheres to the Master Data Standard. The complete information of the tables and key fields that hold the Inspection Plan information follows the Master Data Standard document.

The technical design of the target for this conversion approach:

Data Cleansing

All data cleansing activities must be performed in the source systems (e.g., PF2, WP2) wherever possible, following the rules and criteria defined in this document. The objective is to ensure that only valid, active, and relevant master data is migrated to S/4HANA, while obsolete, redundant, or inconsistent records are excluded.

If certain data cleansing activities cannot be executed directly in the source systems due to system limitations, they may be managed externally (e.g., using Syniti Migrate, 3rd Party Vendor tools, or DCT processes). In such cases, proper documentation of the cleansing activity must be maintained and appended to this deliverable to support review, validation, and sign-off by stakeholders.

Conversion Process

The high-level process is represented by the diagram below:

The ETL (Extract, Transform, Load) process is a structured approach to data migration and management, ensuring high-quality data is seamlessly transferred across systems. Here’s a breakdown of its key components:

1. Extraction
The process begins with extracting metadata and raw data from source systems, such as Syensqo ECC system (i.e. WP2/PF2) periodically. The extracted data is then staged for transformation.

2. Transformation
Once extracted, the data undergoes cleansing, consolidation, and governance. This step ensures data integrity, consistency, and compliance with business rules. The transformation process includes:
- Data validation to remove inconsistencies.
- Standardization to align formats across datasets.
- Business rule application to refine data for operational use.

3. Loading
The transformed data is then loaded into the target S/4HANA system. 

For sites that are not on SAP-PF2 and WP2 systems, collection will be done manually in the data collection template.

The high-level process for DCT is represented by the diagram below:

Data Privacy and Sensitivity

Not applicable

Extraction

Extract data from a source into Syniti Migrate. There are 2 possibilities:

1. The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
   1. Perform full data extraction from relevant tables in the source system(s).
   2. Perform extraction through the application layer.
   3. Only if Syniti Migrate; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
2. The data does not exist (or cannot be converted from its current state).  The data is manually collected by the business directly in Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate.

The agreed relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target Loads

Extraction Run Sheet

Selection Screen

Not applicable

Data Collection Template (DCT)

The Data Collection Template (DCT) will not be applicable in this case. If there is a need to create a new Master Data (MD) for Material BOM object, the business must perform this activity in the source system. The newly created object will then be captured and migrated as part of the standard migration process.

Extraction Dependencies

Before data extraction can commence, several prerequisite steps and conditions must be met to ensure a smooth and accurate extraction process. These dependencies involve confirming system readiness, validating data structures, and ensuring that appropriate access rights and credentials are in place.

Each step must be clearly defined, assigned to responsible teams, and completed prior to extraction activities. Proper coordination across stakeholders is required to mitigate risks and avoid delays in the migration timeline.

Transformation

The Target fields are mapped to the applicable Legacy field that will be its source, this is a 3-way activity involving the Business, Functional team and Data team. This identifies the transformation activity required to allow to make the data Target ready:

1. Perform value mapping and data transformation rules.
   1. Legacy values are mapped to the to-be values (this could include a default value)
   2. Values are transformed according to the rules defined in
2. Prepare target-ready data in the structure and format that is required for loading via prescribed Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation

Transformation Run Sheet

Transformation Rules

The Target fields are mapped to the applicable Legacy field that will be its source, this is a 3-way activity involving the Business, Functional team and Data team. This identifies the transformation activity required to allow to make the data Target ready:

1. Perform value mapping and data transformation rules.
   1. Legacy values are mapped to the to-be values (this could include a default value)
   2. Values are transformed according to the rules defined in
2. Prepare target-ready data in the structure and format that is required for loading via prescribed Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Load

The load process includes:

1. Execute the automated data load into target system using load tool or product the load file if the load must be done manually
2. Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation

Load Run Sheet

Load Phase and Dependencies

Pre-Cutover

Configuration

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Key Assumptions

• Master Data Standard (MDS) is up to date as of the date of documenting this conversion approach and QM View data load.

• Data cleansing has been completed to ensure that only active, valid, and relevant materials are included. Obsolete, blocked, or marked-for-deletion materials are excluded from the QM View migration scope.

• All plant-specific views required for QM View (e.g., Basic Data, MRP, Work Scheduling) are assumed to be migrated first and available in the target system prior to QM View load.

• Only in-scope inspection types (as defined in TQ07A configuration) will be migrated. Out-of-scope or legacy inspection types are excluded unless approved through exception management.

• Inspection type mapping and configuration (e.g., usage, origin, control indicators) are standardized between the source and target systems, ensuring valid master data consistency in SAP S/4HANA.

• All Units of Measure (UoM) used in QM inspection settings must be pre-mapped to ISO-compliant UoMs (T006) in the target system.

• Number ranges and control logic for inspection type assignments are preconfigured in the target system; no additional numbering will be applied during migration.

• Enrichment activities (such as correcting invalid inspection types, mapping missing usage keys, or resolving obsolete authorizations) are handled outside the automated migration process and require manual intervention or business sign-off.

• Not all legacy QM fields (e.g., custom inspection rules, obsolete catalog profiles, or non-standard inspection types) will be migrated. Only fields required for inspection setup, usage assignment, and operational inspection processing are considered in scope.

• All dependent configuration (e.g., plant, UoM, catalog profile, authorization groups, usage key, lot origin) must exist in the target system prior to load to avoid conversion failures.

• Business users are responsible for final sign-off on inspection type relevance and data readiness before migration execution.

See also

CNV-1057 QM Master Inspection Characteristics

CNV-1041 QM Inspection Plan

CNV-1043 QM Inspection Methods

CNV-1044 Quality Info Record

CNV-1047 Batch Characteristics of Class Type: 023

CNV-1064 QM Sampling Procedure

CNV-2010 Materials - General Plant Data / S.Loc Data

CNV-2019 Materials - Basic Data View

Change log

Workflow history