Status
Owner	SUSANTO-ext, William
Stakeholders

Purpose

The purpose of this document is to define the conversion approach to create Inspection Methods in S/4HANA.

Inspection Methods are master data objects in SAP Quality Management (QM) that describe how inspections are to be carried out. They specify the procedure, tools, or references to be used for measuring or evaluating inspection characteristics, and can include documents such as test instructions, work instructions, or external references. This feature ensures standardized execution of quality inspections across plants, materials, and processes.

In SAP S/4HANA, the structure and usage of inspection methods remain consistent with SAP ECC. Inspection methods are typically created at the plant level and assigned to master inspection characteristics (MICs) or directly to inspection plan characteristics. Methods may also include language-dependent descriptions, versioning, validity dates, and document references.

In SAP ECC, aside from the standard structure of inspection method master data (method number, version, plant, and description), additional combinations may exist, such as methods assigned to specific catalogs, methods linked to custom documentation, or methods maintained with plant-independent validity. Some legacy ECC systems may also contain methods with non-standard extensions or inactive versions that need to be reviewed and cleansed (pending MDS).

This conversion aims to migrate active and relevant inspection method records 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_INSPECTIONMETHOD_CREATE), IDOCs, or direct table loads where applicable, ensuring consistency, compliance, and reusability in quality processes.

Conversion Scope

The scope of this document covers the approach for converting active 1043 Inspection Methods from Legacy Source Systems into S/4HANA following the Inspection Method Master Data Design Standard.

The data from legacy system includes:

1. Active Inspection Methods used within the last three (3) years in inspection plans or master inspection characteristics.

2. Inspection Methods without deletion flag.

3. Plant-specific and global Inspection Methods that will be migrated to the To-Be Plant Mapping (taking into consideration the To-Be definition of Plants).

4. Inspection Methods referenced in active MICs or inspection plans.

The data from legacy system excludes:

1. Inactive Inspection Methods not used in more than three (3) years.

2. Inspection Methods marked for deletion.

3. Inspection Methods belonging to deleted plants (per To-Be Plant mapping).

4. Obsolete or duplicate Inspection Methods that are no longer relevant (e.g., replaced by harmonized corporate standards).

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	Inspection Methods will be extracted from PF2 and WP2	PF2 = records WP2 = records	S/4 HANA	records
DCT	Inspection Methods for Plant / Inspection Plan  which do not have data existing from PF2 and WP2	TBD	S/4 HANA	TBD

Additional Information

Multi-language Requirement

Not applicable

Document Management

None identified. The conversion scope is limited to the migration of Inspection Method object. No document attachments, images, or supporting files are included.

Legal Requirement

Not applicable

Special Requirements

Not applicable

Target Design

Inspection Method strictly adheres to the Master Data Standard. The complete information of the tables and key fields that hold the Inspection Method 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
QMTB	WERKS	Q_METH_PLANT	Plant for Inspection Method	CHAR	4	R
QMTB	PMTNR	QPMETHODE	Inspection Method (ID)	CHAR (ALPHA)	8	R
QMTB	VERSION	QVERSNRPM	Version Number of Inspection Method	CHAR (ALPHA)	6	R
QMTB	GUELTIGAB	DATUV	Valid-From Date	DATS	8	R
QMTB	SORTFELD	QSORTFELD	Search Field (keyword)	CHAR	40	R
QMTB	PRFQL	QPRQUALIF	Inspector Qualification (from TQ11)	CHAR	5	C
QMTB	QAUTH	QMASTAUTH	Authorization Group (QM basic data)	CHAR	8	C
QMTB	LSPER	QVERW	“Data Record Is Used” indicator	CHAR	1	C
QMTB	LOEKZ	QLOESCHKZ	Deletion / Status of Master Record	CHAR	1	C
QMTB	AUTOR	QERSTELLER	Created By	CHAR	12	C
QMTB	DATES	QDATUMERST	Created On	DATS	8	C
QMTB	AEAUT	QAENDERER	Last Changed By	CHAR	12	C
QMTB	DATAE	QDATUMAEND	Last Changed On	DATS	8	C
QMTB	MANDT	MANDT	Client	CLNT	3	NU
QMTT	WERKS	Q_METH_PLANT	Plant for Inspection Method	CHAR	4	R
QMTT	PMTNR	QPMETHODE	Inspection Method (ID)	CHAR	8	R
QMTT	VERSION	QVERSNRPM_TXT	Version Number for Method Text	CHAR	6	R
QMTT	SPRACHE	SPRAS	Language Key	LANG	1	R (texts are language-dependent)
QMTT	GUELTIGAB	DATUV	Valid-From Date	DATS	8	R (text validity)
QMTT	KURZTEXT	QKURZTEXT	Short Text (method description)	CHAR	40	R (per language)
QMTT	LTEXTKZ	QLTEXTMT	Long Text Exists (flag)	CHAR	1	C
QMTT	GELOESCHT	QGEL	Text Record Deleted	CHAR	1	C
QMTT	MANDT	MANDT	Client	CLNT	3	NU

Data Cleansing

ID	Criticality	Error Message/Report Description	Rule	Output	Source System
	C1	Invalid or inactive Plant Assignment	Inspection method (QMTB) is created for a plant that does not exist or is inactive in Plant Master (T001W).	Plant	PF2/WP2
	C1	Missing or invalid Method ID	Inspection method number (QMTB-PMTNR) is blank, duplicated, or not aligned with naming convention.	Method ID	PF2/WP2
	C1	Method not released or obsolete	Method record is flagged for deletion (QMTB-LOEKZ) or has status that is not active. Only active methods should be migrated.	Inspection Method	PF2/WP2
	C1	Invalid or missing Version	Method version (QMTB-VERSION) is missing, invalid, or duplicated. Each method must have a valid version.	Version	PF2/WP2
	C1	Invalid Validity Date	Valid-from date (QMTB-GUELTIGAB) is in the future or expired (Valid-to date before cutover).	Validity Dates	PF2/WP2
	C1	Missing or invalid Short Text	Method description (QMTT-KURZTEXT) missing in key business languages.	Method Text	PF2/WP2
	C1	Orphaned Method Reference	Inspection plan characteristic (PLMK) references an inspection method (QMTB) that does not exist or is inactive.	Inspection Plan Link	PF2/WP2
	C2	Duplicate Methods	Multiple active inspection methods exist with the same Plant + Method ID + Version combination.	Inspection Method	PF2/WP2
	C2	Missing Long Texts	Method flagged for long text (QMTT-LTEXTKZ) but no SO10 text maintained.	Long Text	PF2/WP2
	C2	Invalid Inspector Qualification	Method requires inspector qualification (QMTB-PRFQL) not available in customizing (TQ11).	Qualification	PF2/WP2
	C3	Obsolete Custom Fields	Method contains legacy/custom fields that do not exist in S/4HANA; must be mapped or cleared.	Mapping Issue	PF2/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. 

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

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 / LTC 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

Selection Ref Screen	Parameter Name	Selection Type	Requirement	Value to be entered/set
Not applicable

Data Collection Template (DCT)

Target Ready Data Collection Template will be created for Data Object data with exception of some fields which require transformation as mentioned in the transformation rule.

<Object> DCT Rules

Field Name	Field Description	Rule

Extraction Dependencies

List the steps that need to occur before extraction can commence

Item #	Step Description	Team Responsible

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 Syniti Migrate 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 Syniti Migrate
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

Item #	Step Description	Team Responsible

Transformation Rules

Rule #	Source system	Source Table	Source Field	Source Description	Target System	Target Table	Target Field	Target Description	Transformation Logic

Transformation Mapping

Use the exact name and reference this section in the “Transformation rules” above

Mapping Table Name	Mapping Table Description

Transformation Dependencies

List the steps that need to occur before transformation can commence

Item #	Step Description	Team Responsible

Pre-Load Validation

Project Team

The following pre-load validations will be performed by the Project Team.

Completeness

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Accuracy

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Business

The following pre-load validations will be performed by the business.

Completeness

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Accuracy

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

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

Item #	Step Description	Team Responsible

Load Phase and Dependencies

Identify the phase as to “when” the load for this object will occur. <Pre-Cutover, Cutover, Post Cutover> and list the steps that need to occur before the load can commence

Configuration

List the Configurations required before loading can commence

Item #	Configuration Item

Conversion Objects

Object #	Preceding Object Conversion Approach
	list the exact title of the conversion object of only the immediate predecessor – this will then confirm the DDD (Data Dependency Diagram)

Error Handling

The table below depicts some possible system errors for this data object during data load. All data load error is to be logged as defect and managed within the Defect Management

Error Type	Error Description	Action Taken

Post-Load Validation

Project Team

The following post-load validations will be performed by the Project Team.

Completeness

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Accuracy

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Business

The following post-load validations will be performed by the business.

Completeness

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Accuracy

Task	Action
title	specific details of what and how the task needs to be performed e.g. which reports are being used etc.

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• Data Object is in scope based on data design and any exception requested by business.

Any additional key assumptions.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log

Workflow history