| Status | Tech Review |
|---|---|
| Owner | |
| Stakeholders |
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:
- 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. - QM Views without deletion flags, ensuring only valid and relevant records are migrated.
- QM Views assigned to in-scope plants, based on the To-Be Plant Mapping (considering new plant definitions).
- Materials with at least one valid and active inspection type in Syensqo (e.g., 01, 02, 04, 05, 06, 08, 10, 11, 12, 17).
- Materials with valid control key, inspection setup, and certificate requirement, consistent with the S/4HANA target design.
- QM master data linked to active materials and plants in scope, ensuring alignment with migrated Material Master data.
The data from legacy system excludes:
Inactive QM Views for materials not used in inspection lots or quality processes within the last four (4) years.
QM Views marked for deletion or with inspection types blocked in ECC.
QM Views belonging to plants that are deleted or out of scope, based on the To-Be Plant Mapping.
Obsolete or invalid inspection types or inspection setup not supported in S/4HANA.
Relevancy rules
- 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. - 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. - 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. 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
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
PF2/WP2 | Material Master QM views will be extracted from source systems. An initial extract of the relevant data will be provided in Google Sheet format to assist business in decision making on including any relevant data from Source Systems. | PF2 WP2 | S4 HANA | 91787 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:
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| MARA | QMPUR | QMPUR | QM in Procurement is Active | CHAR | 1 | C |
| MARC | INSMK | INSMK | Stock Type for Quality Inspection | CHAR | 1 | C |
| MARC | KZDKZ | KZDKZ | Document Required | CHAR | 1 | R |
| MARC | MATNR | MATNR | Material Number | CHAR | 18 | R |
| MARC | PRFRQ | PRFRQ | Inspection Interval | CHAR | 3 | C |
| MARC | QMATA | QMATA | QM Material Authorization | CHAR | 1 | C |
| MARC | QZGTP | QZGTP | Certificate Type | CHAR | 4 | C |
| MARC | SSQSS | SSQSS | QM Procurement Key | CHAR | 2 | C |
| MARC | WEBAZ | WEBAZ | GR Processing Time | CHAR | 3 | C |
| MARC | WERKS | WERKS_D | Plant | CHAR | 4 | R |
| QMAT | AFR | AFR | Inspection for Handling Unit | CHAR | 1 | C |
| QMAT | AKTIV | AKTIV | Active Indicator for Inspection Type | CHAR | 1 | C |
| QMAT | APA | APA | Preferred Inspection Type | CHAR | 4 | C |
| QMAT | APP | APP | Automatic Assignment | CHAR | 1 | R |
| QMAT | ART | ART | Inspection Setup Indicator | CHAR | 1 | C |
| QMAT | AVE | AVE | Automatic UD | CHAR | 1 | C |
| QMAT | CHG | CHG | Control of Inspection Lot | CHAR | 1 | R |
| QMAT | DYN | DYN | Skip Allowed | CHAR | 1 | NU |
| QMAT | INSMK | INSMK | Post to Inspection Stock | CHAR | 1 | C |
| QMAT | MER | MER | Check Chars | CHAR | 1 | NU |
| QMAT | MPDAU | MPDAU | Average Inspection Duration | NUMC | 3 | C |
| QMAT | PPL | PPL | Inspection with Task List | CHAR | 1 | R |
| QMAT | QKZVERF | QKZVERF | Q-Score Procedure | CHAR | 1 | NU |
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.
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
| 2009-001 | C1 | Obsolete material with QM View extension | Materials with an active QM View must have at least one valid and active inspection type assigned to ensure the QM View remains functionally relevant. (MARC-PSTAT contains *Q* but QMTAV<>'X') | Inspection type | PF/WP2 |
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:
- The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
- Perform full data extraction from relevant tables in the source system(s).
- Perform extraction through the application layer.
- Only if Syniti Migrate; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
- 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
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| Extraction Scope Definition | - Identify the source systems and databases involved. - Define the data objects (tables, fields, records) to be extracted. - Establish business rules for data selection. | Syniti /P2F Data team |
| Extraction Methodology | - Specify the extraction approach (full, incremental, or delta extraction). - Determine the tools and technologies used. - Define data filtering criteria to exclude irrelevant records. | Syniti |
| Extraction Execution Plan | - Establish execution timelines and batch processing schedules. - Assign responsibilities for extraction monitoring. - Document dependencies on other migration tasks. | Syniti |
| Data Quality and Validation | - Define error handling mechanisms for extraction failures. | Syniti |
Selection Screen
Not applicable
Data Collection Template (DCT)
A Target-Ready Data Collection Template will be created for all required fields in the Material Master – QM View, except for fields that require transformation in accordance with the defined transformation rules. Each template will follow the structure and format required by the target S/4HANA Material Master configuration for Quality Management.
| Field Name | Field Description | Data Type | Length | Requirement | Rule |
| MATNR | Material Number | CHAR | 18 | Required | Material number as uploaded via CNV–2019 Basic Data View; must exist in MARA/MARC |
| WERKS | Plant | CHAR | 4 | Required | List of valid plants per To-Be Plant Mapping; plant must be active |
| KZDKZ | Document Required Indicator | CHAR | 1 | Required | Set default value = "X" for all materials migrated from DCT |
| QMPUR | QM in Procurement Active | CHAR | 1 | Conditional | Populate based on Procurement Quality requirement; ‘X’ if GR inspection required |
| INSMK | Post to Inspection Stock | CHAR | 1 | Conditional | Required for GR inspection processes; validated against T156 |
| PRFRQ | Inspection Interval | CHAR | 3 | Conditional | Frequency for recurring inspections; fill only if business uses interval-based inspection |
| QZGTP | Certificate Type | CHAR | 4 | Conditional | Populate per certificate requirements; mapped via value mapping (TQ75F) |
| SSQSS | QM Procurement Key | CHAR | 2 | Conditional | Value mapping from legacy → S/4 QM Procurement Keys |
| WEBAZ | GR Processing Time | CHAR | 3 | Conditional | Derived from MRP View |
| AFR | Inspection for Handling Unit | CHAR | 1 | Conditional | Populate only if material uses HU inspection (common in packaging flows) |
| AKTIV | Active Indicator for Inspection Type | CHAR | 1 | Conditional | Default value = X. But it can be "Blank". |
| APA | Preferred Inspection Type | CHAR | 4 | Conditional | Fill if business requires preferred inspection type (01, 04, 09, etc.) |
| APP | Automatic Assignment | CHAR | 1 | Required | ‘X’ if auto selection of inspection type needed |
| ART | Inspection Setup Indicator / Inspection Type | CHAR | 4 | Conditional | Valid inspection types only; validated against TQ30/TQ32 |
| AVE | Automatic UD | CHAR | 1 | Conditional | Populate ‘X’ only if automatic UD process applicable |
| CHG | Control of Inspection Lot | CHAR | 1 | Required | Must align with TQ08 mapping; controls GR/In-process/Delivery logic |
| MPDAU | Average Inspection Duration | NUMC | 3 | Conditional | Duration in minutes; fill only if maintained in legacy; else leave blank |
| PPL | Inspection with Task List | CHAR | 1 | Required | Populate ‘X’ if inspection plan used (PLKO/PLMK exists for material) |
| Note: |
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.
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Source System Availability
| Syensqo IT |
| 2 | Data Structure
| Syniti |
| 3 | Referential Integrity
| Syniti |
| 4 | Extraction Methodology
| Syniti |
| 5 | Performance and Scalability Considerations
| Syniti |
| 6 | Security and Compliance
| Syniti |
| 7 | Data cleansing of legacy Resource If standardization within the DCT begins using relevant data from PF2 and WP2 before the cleansing is finalized, it is understood that the business will take due diligence to ensure any subsequent delta cleansing is verified and aligned within the DCT. | Business |
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:
- Perform value mapping and data transformation rules.
- Legacy values are mapped to the to-be values (this could include a default value)
- Values are transformed according to the rules defined in
- 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
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Obtain DCT Sign-off from Business | SyWay Data Team |
| 2 | <Add steps from Syniti Migrate here> | SyWay Data Team |
| 3 | Review and Validate Error and Preload Reports | SyWay Data Team |
| 4 | Generate Load Files | SyWay Data Team |
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:
- Perform value mapping and data transformation rules.
- Legacy values are mapped to the to-be values (this could include a default value)
- Values are transformed according to the rules defined in
- 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
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
| 1 | PF2/WP2 | MARC | MATNR | Material | S/4HANA | MARC | MATNR | Material | Legacy Material Number mapped to new S/4HANA Material Number per Material Master mapping file |
| 2 | PF2/WP2 | MARC | WERKS | Plant | S/4HANA | MARC | WERKS | Plant | Map legacy Plant to new S/4HANA Plant per To-Be Plant Mapping table |
| 3 | PF2/WP2 | MARC | KZDKZ | Document Required Indicator | S/4HANA | MARC | KZDKZ | Document Required Indicator | Set default value = "X" for all materials migrated from legacy system or DCT. Value from legacy system is ignored to enforce consistent document control in S/4HANA. |
| 4 | PF2/WP2 | MARA | QMPUR | QM in Procurement is Active | S/4HANA | MARA | QMPUR | QM in Procurement is Active | Transfer directly; must match QM Procurement activation setting in target system. |
| 5 | PF2/WP2 | MARC | INSMK | Stock Type for Quality Inspection | S/4HANA | MARC | INSMK | Stock Type for Quality Inspection | Transfer directly; must match valid stock type configuration in S/4HANA. |
| 6 | PF2/WP2 | MARC | PRFRQ | Inspection Interval | S/4HANA | MARC | PRFRQ | Inspection Interval | Transfer directly; numeric interval must be valid in target system. |
| 7 | PF2/WP2 | MARC | QMATA | QM Material Authorization | S/4HANA | MARC | QMATA | QM Material Authorization | Transfer directly; only if authorization is active in source. |
| 8 | PF2/WP2 | MARC | QZGTP | Certificate Type | S/4HANA | MARC | QZGTP | Certificate Type | Transfer directly; must match valid certificate type configuration in target system. |
| 9 | PF2/WP2 | MARC | SSQSS | QM Procurement Key | S/4HANA | MARC | SSQSS | QM Procurement Key | Transfer directly; must match valid procurement control key in S/4HANA. |
| 10 | PF2/WP2 | MARC | WEBAZ | GR Processing Time | S/4HANA | MARC | WEBAZ | GR Processing Time | Transfer directly; ensure numeric value is valid and mapped correctly. |
| 11 | PF2/WP2 | QMAT | ART | Inspection Type | S/4HANA | QMAT | ART | Inspection Type | Value Mapping for Inspection Type |
| 12 | PF2/WP2 | QMAT | AKTIV | Active Indicator | S/4HANA | QMAT | AKTIV | Active Indicator | Migrate materials with both active and inactive inspection types maintained in the QM View, as inactive status may be temporary and subject to change after migration |
| 13 | PF2/WP2 | QMAT | CHG | Control of Inspection Lot | S/4HANA | QMAT | CHG | Control of Inspection Lot | Transfer directly; ensure valid control key is maintained in configuration table TQ08. |
| 14 | PF2/WP2 | QMAT | INSMK | Post to Inspection Stock | S/4HANA | QMAT | INSMK | Post to Inspection Stock | Transfer directly; must match valid stock type configuration in S/4HANA. |
| 15 | PF2/WP2 | QMAT | MPDAU | Average Inspection Duration | S/4HANA | QMAT | MPDAU | Average Inspection Duration | Transfer directly; ensure duration value is numeric and valid. |
| 16 | PF2/WP2 | QMAT | PPL | Inspection with Task List | S/4HANA | QMAT | PPL | Inspection with Task List | Transfer directly; must be consistent with task list settings in production. |
| 17 | PF2/WP2 | QMAT | APA | Preferred Inspection Type | S/4HANA | QMAT | APA | Preferred Inspection Type | Transfer directly; ensure alignment with active inspection types. |
| 18 | PF2/WP2 | QMAT | APP | Automatic Assignment | S/4HANA | QMAT | APP | Automatic Assignment | Transfer directly; must match valid configuration for inspection type assignment. |
| 19 | PF2/WP2 | QMAT | AVE | Automatic UD | S/4HANA | QMAT | AVE | Automatic UD | Transfer directly; ensure flag value is valid per S/4HANA setup. |
| 20 | PF2/WP2 | QMAT | AFR | Inspection for Handling Unit | S/4HANA | QMAT | AFR | Inspection for Handling Unit | Transfer directly; ensure consistency with Handling Unit configuration. |
Transformation Mapping
| Mapping Table Name | Mapping Table Description |
|---|---|
| Material | Mapping of legacy Material Number to new Material Number in S/4HANA target system. Ensures all inspection-related records are aligned with the migrated Material Master. |
| Plant | Mapping of legacy Plant codes to new Plant codes in the S/4HANA target system, based on To-Be Plant Mapping definition. |
| Inspection Type | Mapping of legacy Inspection Types to harmonized Inspection Types in S/4HANA, ensuring alignment with target configuration (TQ07A). |
| Usage Key | Mapping of legacy Usage Key values to standardized Usage Keys as per S/4HANA configuration (TQ09). |
| Control Key | Mapping of legacy Control Key values to target system Control Keys (TQ08) for consistent inspection processing logic. |
| Inspection Lot Origin | Mapping of legacy Inspection Lot Origin values to valid entries in target configuration (TQ85). |
| UoM (Unit of Measure) | Mapping of legacy Units of Measure to ISO-compliant Units of Measure in S/4HANA (T006). |
| Authorization Group | Mapping of legacy Authorization Group values to new Authorization Groups maintained in S/4HANA (TBRG). |
| Quality Level Indicator | Mapping of legacy Quality Level Indicator values to valid target domain values in S/4HANA (TQ07). |
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Ensure tables completeness | Syniti |
| 2 | Ensure all Transformation mappings are up to date. | Syniti |
Pre-Load Validation
Project Team
Completeness
| Task | Action |
|---|---|
| Business validates the load file | Send the load file to the Business Representatives for all plants so they can review and validate the data. |
| Mock 1 test must occur beforehand | The 1st mock load (manual) must be executed before the actual load can take place. |
| Count before and after | Review and document the item counts in the Transformation Files before the load, and verify them again after the load. |
| Validation Reports |
Accuracy
| Task | Action |
|---|---|
| Conversion Accuracy | SyWay P2F-MFG Data Team to verify that all fields below meet pass the checks:
|
| Review Error Reports | Review and correct the errors. Achieve a zero-error record count as much as possible. Raise defects for data remediated and requiring a correction in the source data. |
Business
Completeness
| Task | Action |
|---|---|
| Verify Record Count | Business Data Owner/s to verify that the total number of relevant records from the the system is equal to the total number of records in the Preload and Load Sheets. |
Accuracy
| Task | Action |
|---|---|
| Conversion Accuracy | Business Data Owner/s to verify that all the data in the load table/file is accurate as per endorsed transformation/mapping rules. |
Load
The load process includes:
- Execute the automated data load into target system using load tool or product the load file if the load must be done manually
- Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation
Load Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
1 | Ensure Pre-load sign-offs are obtained. | SyWay Data team |
2 | Go to the load tool and select the correct load Program. | SyWay Data team |
3 | Proceed with Data load. | SyWay Data team |
4 | Validate few records loaded by accessing standard transactions. | SyWay Data team |
5 | Generate the post load reports in the tool. | SyWay Data team |
6 | Log errors as defects, if any and address resolutions. Close defects. | SyWay Data team |
7 | Resolve defects by re-upload and re-generate post load reports if necessary. | SyWay Data team |
8 | Business to validate the post load files as part of post-load validation, raise data defects or provide the post-load sign-off. | Business |
9 | Repeat steps 5 to 7 if necessary. | SyWay Data team |
Load Phase and Dependencies
Pre-Cutover
Configuration
| Item # | Configuration Item |
|---|---|
| 1 | T001W – Plants/Branches: Definition of plants where inspection activities and quality control processes are carried out. Ensures material QM view is maintained only in valid, active plants. |
| 2 | T006 – Units of Measurement (UoM): ISO-compliant UoM definitions to ensure consistent measurement units across all inspection processes. |
| 3 | TQ07A – Inspection Types: Configuration of valid inspection types (e.g., 01, 02, 04, 05, 06, 08, 10, 11, 12, 17, 89) used in material QM view. |
| 4 | TQ85 – Inspection Lot Origin: Configuration of inspection lot origin values to control how inspection lots are created from different business processes. |
| 5 | TQ09 – Usage Keys: Definition of usage keys to specify valid scenarios for inspection (e.g., goods receipt, production, stock transfer). |
| 6 | TQ08 – Control Keys (QM): Definition of control keys determining inspection processing behavior (e.g., automatic lot creation, inspection point usage). |
| 7 | TQ15 – Catalog Types: Definition of catalog types (e.g., defects, results, codes) used in conjunction with inspection types and usage keys. |
| 8 | TQ15T – Selected Sets & Code Groups: Configuration of selected sets and code groups for qualitative results recording and defect tracking. |
| 9 | TQ33 – Catalog Profile Assignment: Configuration of catalog profiles assigned to inspection types and materials for standardized defect documentation. |
| 10 | TBRG – Authorization Groups: Assignment of authorization groups for controlling access and maintenance rights to QM view data. |
| 11 | TQ30 – Reference Indicators: Control of reference indicator usage for linking plant-specific and global quality settings. |
| 12 | TQ75 – Decimal Places & Format: Configuration of decimal places, number format, and rounding rules for quantitative inspection data entry. |
| 13 | T134 – Material Types: Configuration of BOM- and QM-relevant material types (e.g., ROH, HALB, FERT) to control where QM view is required or optional. |
| 14 | TQ02 – Quality Levels / Dynamic Modification: Configuration of quality levels and dynamic modification rules for inspection type control. |
| 15 | TQ03 – Inspection Severity: Configuration of severity levels used in conjunction with dynamic modification rules for quality levels. |
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| 2019 | Material Master - Basic Data View |
| 1047 | Material Master - Batch Characteristics of Class Type : 023 |
Error Handling
| Error Type | Error Description | Action Taken |
|---|---|---|
| 1 | Material/Plant not found in target system (Material master or plant view does not exist for the record to be migrated). | Create/ load the missing material and required MARC plant view first (per conversion sequence). Reprocess the QM view once the prerequisite is available. |
| 2 | Inspection Type not configured/allowed in target (value not in TQ07A or set as not permitted). | Validate configuration in TQ07A; map legacy value to a valid Inspection Type or remove the record from the load file. |
| 3 | Duplicate record for the same Material–Plant–Inspection Type. | Deduplicate in the collection file; keep exactly one active record per Material–Plant–Inspection Type. |
| 4 | Usage Key invalid (value not maintained in TQ09 or not allowed for the Inspection Type). | Map or correct to a valid Usage Key per configuration; where not applicable, remove from the load file. |
| 5 | Inspection Lot Origin invalid (not maintained in TQ85 or not compatible with Inspection Type). | Map/maintain to a valid Lot Origin; correct the record and reload. |
| 6 | Catalog Profile / Selected Set / Code Group not found (catalog profile missing or mismatched with qualitative settings). | Maintain the Catalog Type/Selected Set/Code Group in TQ15/TQ15T and ensure the Catalog Profile assignment (TQ33) is valid; reload. |
| 7 | Dynamic Modification / Quality Level settings invalid (severity or rule not configured). | Review TQ02/TQ03 configuration; align values to target system and correct the record. |
| 8 | Authorization Group invalid (value not in TBRG). | Map to an existing Authorization Group or leave blank as per design; update the file and reload. |
| 9 | Marked for deletion or blocked in legacy (record flagged, or business requested exclusion). | Exclude from migration per data cleansing rules or obtain business approval to reactivate before load. |
| 10 | Inconsistent or unmapped Units of Measure referenced by inspection data (non-ISO or not in T006). | Map legacy UoM to ISO-compliant UoM in T006; correct the value and reload. |
| 11 | Invalid Control Key for QM processing (not maintained in TQ08 or not permitted with the Inspection Type). | Map/maintain the Control Key in TQ08 and correct the record accordingly. |
| 12 | Record references non-existent configuration (e.g., reference indicator behavior, plant authorization, or other dependency). | Validate all dependent config (TQ30, TBRG, T001W, etc.). Update mapping/config, correct the data, and reload. |
Post-Load Validation
Project Team
Completeness
| Task | Action |
|---|---|
| Verify Count | SyWay P2F-MFG Data Team to verify the record count created in target S/4 HANA by accessing post load reports in dspMigrate or standard reports from S/4 HANA. |
Accuracy
| Task | Action |
|---|---|
| Verify Logs | Check if there is data that failed to load and perform the necessary actions (e.g. register as post load issue or attempt to load the record again, etc.). |
Business
Completeness
| Task | Action |
|---|---|
| Verify Count | Download Post Load Reports from dspMigrate and verify that the record count loaded in the target S/4 HANA is the same count as of the endorsed load file. |
Accuracy
| Task | Action |
|---|---|
| Conversion Accuracy | Verify that the Material Master QM View data in target S/4 HANA were loaded correctly via DSP Migrate post load reports or standard reports from S/4 HANA. |
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.
Change log
Workflow history
| Title | Last Updated By | Updated | Status | |
|---|---|---|---|---|
| There are no pages at the moment. | ||||