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. Data not older than 3 years of usage
2. Data  not flagged for deletion
3. Data that has material / plant relationship and material is active

The data from legacy system excludes:

1. Data older than 3 years
2. Data flagged for deletion
3. Data that has material / plant relationship and material is not active or falged for deletion

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 Method will be extracted from PF2 and WP2	PF2 = records WP2 = records	S/4 HANA	records
				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	Mandatory
QMTB	PMTNR	QPMETHODE	Inspection Method (ID)	CHAR (ALPHA)	8	Mandatory
QMTB	VERSION	QVERSNRPM	Version Number of Inspection Method	CHAR (ALPHA)	6	Mandatory (if versioning used; recommended as standard)
QMTB	GUELTIGAB	DATUV	Valid-From Date	DATS	8	Mandatory
QMTB	SORTFELD	QSORTFELD	Search Field (keyword)	CHAR	40	Recommended (improves search)
QMTB	PRFQL	QPRQUALIF	Inspector Qualification (from TQ11)	CHAR	5	Optional (if client uses qualification control)
QMTB	QAUTH	QMASTAUTH	Authorization Group (QM basic data)	CHAR	8	Optional (depends on security design)
QMTB	LSPER	QVERW	“Data Record Is Used” indicator	CHAR	1	Optional
QMTB	LOEKZ	QLOESCHKZ	Deletion / Status of Master Record	CHAR	1	Optional (blank for active)
QMTB	AUTOR	QERSTELLER	Created By	CHAR	12	Optional (audit)
QMTB	DATES	QDATUMERST	Created On	DATS	8	Optional (audit)
QMTB	AEAUT	QAENDERER	Last Changed By	CHAR	12	Optional (audit)
QMTB	DATAE	QDATUMAEND	Last Changed On	DATS	8	Optional (audit)
QMTB	MANDT	MANDT	Client	CLNT	3	System (no load mapping)
QMTT	WERKS	Q_METH_PLANT	Plant for Inspection Method	CHAR	4	Mandatory (matches QMTB)
QMTT	PMTNR	QPMETHODE	Inspection Method (ID)	CHAR	8	Mandatory (matches QMTB)
QMTT	VERSION	QVERSNRPM_TXT	Version Number for Method Text	CHAR	6	Mandatory (matches QMTB)
QMTT	SPRACHE	SPRAS	Language Key	LANG	1	Mandatory (texts are language-dependent)
QMTT	GUELTIGAB	DATUV	Valid-From Date	DATS	8	Mandatory (text validity)
QMTT	KURZTEXT	QKURZTEXT	Short Text (method description)	CHAR	40	Mandatory (per language)
QMTT	LTEXTKZ	QLTEXTMT	Long Text Exists (flag)	CHAR	1	Optional (if you’ll create SO10 long text)
QMTT	GELOESCHT	QGEL	Text Record Deleted	CHAR	1	Optional
QMTT	MANDT	MANDT	Client	CLNT	3	System (no load mapping)

Data Cleansing

ID	Criticality	Error Message/Report Description	Rule	Output	Source System

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