Purpose

This document outlines the conversion strategy for migrating Source List data from SAP ECC systems to SAP S/4HANA.

In the legacy systems, Source List entries may be duplicated, outdated, or inconsistently maintained across plants and purchasing organizations. Some entries reference inactive vendors or materials and contain obsolete validity dates. As per SyWay standards, Source List data will be rationalized and aligned to the new S/4HANA data model.

---CHECKLIST---

• Logical Source and Target Systems are identified. 
• Processing Type is specified (i.e. Direct Input, BAPI, IDoc, Web Service, OData API, etc.)
• Standard or custom load program name/BAPI/IDoc is specified to support this functionality.
• Data Mapping is provided for mappings which are not obvious to a suitably-skilled and experienced developer
• All translation requirements are clearly defined (including data validation rules, data derivation/calculation and default values, if applicable)Input and/or Output file layouts are provided for all record types possible
• Transaction volume is specified / Execution frequency is specified / Restart/Recovery requirements have been defined
• Error handling requirements are specified, including alerting requirement and expected action on failure. 
• Application log requirement if applicable to be specified. 

--- Additional topics to check---

• Rules for Data Merging (all systems)

Conversion Scope

The objective is to convert active and relevant Source List entries from legacy systems (PF2, WP2) into S/4HANA in accordance with the Source List Master Data Design.

The Source List in SAP defines the approved supply source(s) for a specific material over a given timeframe and plant. It plays a critical role in the Source-to-Pay process, particularly in automatic sourcing and purchase requisition conversion.

The legacy systems already use Source List functionality, but the structure, completeness, and business relevance vary. A cleansing and standardization process will be undertaken to ensure only valid, non-redundant records are transitioned.

The data from legacy system includes:

1. Valid Source List entries with active Vendor and Material

2. Entries with current or future Validity Period

3. Plant (when applicable) and Purchasing Organization combinations relevant to the business scope

4. Fixed vendor flags and quota arrangements, if maintained

The data from legacy system excludes:

1. Entries with deletion indicators

2. Expired entries with no future relevance

3. Entries referring to blocked materials or vendors

Data will be extracted via Syniti Migrate and formatted into DCTs (Data Collection Templates). Business users will validate and confirm the relevance of each entry.

Additional Information

Multi-language Requirement

Descriptions are not applicable for Source List records, but Plant and Purchasing Organization descriptions may be presented in English and logon language if available.

Document Management

N/A

Legal Requirement

N/A

Special Requirements

Processing Type ETL: 

The extraction and transformation will be done by Syniti, while the loading will be executed by a Standard tool of SAP Migration Cockpit.

• E - Extraction: Data will be Extracted from at least two source systems. This process will be executed by Syniti
• T - Transform: Data will be Cleansed, Transformed, Merged, and staging areas of Migration Cockpit will be updated by Syniti
• L - Loading: Data will be Loaded using the Migration Cockpit

Target Design

The technical design of the target system for this conversion approach is detailed below. All fields subject to mapping tables are highlighted in orange for clarity.

Data Cleansing

Standardization activities include:

Conversion Process

The conversion process begins with the extraction of Source List records from ECC systems based on relevancy criteria. These records are pre-validated to ensure referenced materials and vendors are active and valid. The validated data is then loaded into the DCT where cleansing, standardization, and transformation activities are performed. Once complete, the business reviews the entries and confirms readiness. Following this, load files are prepared and test loads are executed for validation. If successful, a full data load is carried out into S/4HANA, followed by a post-load validation to confirm completeness and accuracy.

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

Relevancy Rules

During data migration for Purchasing Info Records (Info Records), relevancy rules ensure that only valid, useful, and up-to-date records are included in the target SAP S/4HANA system.

• Material and Vendor must exist in the target system. Only include Info Records where both MARA-MATNR and LFA1-LIFNR are valid and being migrated to S4Hana;
• Purchasing Organization and Plant must be relevant (already present in the target system). Only include Info Records for Purchasing Orgs (EINE-EKORG) and Plants (EINE-WERKS) in scope;
• Info Record must be active and relevant to external procurement;
• Recent activity (present in any PO) or validity period (EINE-DATAB / EINE-DATBI). Include only if conditions are valid in the last 3-5 years or used in POs recently (to check EKPO, EKBE);
• Exclusion of deleted (EINA-LOEKZ) or blocked records (LFA1-SPERR). Exclude Info Records where deletion/block flags are set on vendor, material, or info record;
• Valid pricing conditions must exist (check validity period of conditions like PB00). Include only Info Records that has a Price (EINE-NETPR);
• Deduplication: Rule to be confirmed by Business

Extraction Run Sheet

Selection Screen

Data Collection Template (DCT)

DCT Rules

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

Proposal for mapping Tables

Vendors - all fields are key on the table

Create the mapping table LIFNR with the following structure

Materials - all fields are key on the table

Create the mapping table MATNR with the following structure

Plant - all fields are key on the table

Create the mapping table WERKS with the following structure

Purchasing Organization - all fields are key on the table

Create the mapping table EKORG with the following structure

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

Configuration

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Key Assumptions

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

See also

Change log

Workflow history