Purpose

The purpose of this document is to define the conversion approach to create 1151 Certificate Profiles in S/4 HANA.
in S/4 HANA.

Certificate Profiles are used in SAP Quality Management (QM) to control and define the certification requirements for materials and suppliers. A Certificate Profile specifies which quality certificates are required for a material, at what stage of the process they must be provided, and the specific inspection characteristics or parameters to be validated. This ensures that incoming materials or finished products meet the defined quality and regulatory standards before acceptance or shipment.

In SAP S/4HANA, the structure and usage of Certificate Profiles remain consistent with SAP ECC, generally defined by key attributes such as Material / Plant / Certificate Type. Certificate Profiles may include additional parameters such as certificate category, inspection lot linkage, and certificate relevance for procurement or production.

In SAP ECC, aside from the standard structure, Certificate Profiles may also exist with extended combinations or enhancements, for example:
    •    Profiles assigned to multiple materials or plants
    •    Custom fields defining regulatory or customer-specific certification needs
    •    Obsolete or inactive profiles that are no longer in use

Such cases must be reviewed carefully (MDS) to determine whether they remain relevant for migration.

This conversion aims to migrate active and valid Certificate Profiles from existing ECC systems into SAP 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 SAP S/4HANA system using standard SAP mechanisms such as BAPIs (e.g., BAPI_QM_CERTIFICATE_PROFILE_CREATE), IDOCs, or direct table loads, ensuring compliance with quality and regulatory requirements.

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

Conversion Scope

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

The data from legacy system includes:

1. All Active Certificate Profiles(Header table) active/created during the last 4 years
   QCVK-ERSTELDAT >= (CURRENT DATE - 4)

2. Certificate profile characteristics with Active MICs in the last 4 years. Refer Master Inspection characteristics.
   QCVM-MKMNR = QPMT-MKMNR AND QCVM-KATEGORIE = '1'(CHAR.CATEGORY=MIC)
3. Certificate profile characteristics with Active Batch characteristics in the last 4 years. Refer Batch characteristics.
   QCVM-CMERKMALID = CABN-ATINN AND QCVM-KATEGORIE = '2'(CHAR.CATEGORY=BATCH CLASS CHARAC)
4. Certificate profiles with Active Material/Plant/Material Group/Customer in the last 4 years. Follow 1,2 &3 and refer Material master QM view, BP Customer master.

5. Plant-specific Certificate Profiles that will be migrated to the To-Be Plant Mapping in Enterprise Structure Catalog worksheet "30. Plants"

The data from legacy system excludes:

1. All Certificate Profiles(Header table) active/created more than before 4 years
   QCVK-ERSTELDAT < (CURRENT DATE - 4)

2. Certificate profile characteristics with inactive MICs. Refer Master Inspection characteristics.
3. Certificate profile characteristics with inactive Batch characteristics in the last 4 years. Refer Batch characteristics.
4. Certificate profiles with inactive Material/Plant/Material Group/Customer(Assignment/Conditions). Refer Material master QM view, BP Customer master.

5. Certificate profiles with plants not in scope

Relevancy logic for 1,2 & 3
1. QCVK-ERSTELDAT >= (CURRENT DATE - 4) AND

(
(QCVM-MKMNR = QPMT-MKMNR AND QCVM-KATEGORIE = '1'(CHAR.CATEGORY=MIC) )
 OR
(QCVM-CMERKMALID = CABN-ATINN AND QCVM-KATEGORIE = '2'(CHAR.CATEGORY=BATCH CLASS CHARAC) )
)

We consider the certificate profile as Active for migration only if the profile has a valid characteristics data. Either MICs or Batch characteristics for usage and created in Last 4 years.

Case 1(Active): If the certificate profiles satisfy the criteria for 1,2 &3, but no QCVV or assignments data, we will still migrate the data.

Case 2(Inactive): Certificate profiles satisfy the criteria for 1,2 &3, but has invalid data for any of the QCVV or assignments tables.

we have to check 4,5 for the result of 1,2&3 with Material master relevancy/BP relevancy/along with relevant Plant data.

Additional Information

Multi-language Requirement

Not applicable

Document Management

Not applicable

Legal Requirement

Not applicable

Special Requirements

Not applicable

Target Design

The technical design of the target for this conversion approach.

Data Cleansing

Conversion Process

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

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

Extraction

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

1. The data exists. connects to the source and loads the data into . 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 ; 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 . This is to be conducted using DCT (Data Collection Template) in

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

Data Collection Template (DCT)

Extraction Dependencies

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

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

The Certificate Profiles will be loaded in the pre-cutover (PreCutover 4 phase) period.

Before loading, it will have dependency on the following configuration and data objects in the S/4 HANA.

Configuration

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Post-load validation is a critical step in data migration, ensuring that transferred data is accurate, complete, and functional within the target system.

1. Ensuring Data Integrity
After migration, data must be consistent with its original structure. Post-load validation checks for missing records, incorrect mappings, and formatting errors to prevent discrepancies.
2. Business Continuity
Faulty data can disrupt operations, leading to financial losses and inefficiencies. Validating post-load data ensures that applications function as expected, preventing downtime.
3. Error Detection and Resolution
By validating data post-migration, businesses can detect anomalies early, reducing the cost and effort required for corrections

Completeness

Accuracy

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• Certificate Profiles is in scope based on data design and any exception requested by business.
• Data cleansing has met the required percentage threshold for the specified mock cycle and all preparation activities have been completed.
• Data entries in DCT are target-ready data unless a specific transformation rule is stated for that field in the transformation rules.

See also

2009-Material Master QM view

1057-Master Inspection Characteristics

1043-Inspection Methods

3003-Business Partners Customers(Sales/Service)

Change log