You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Status

  In Progress

Owner
Stakeholders

Purpose

The purpose of this document is to define the conversion approach to create Service Master records in S/4HANA. It follows the Procurement Master Data Design Standard and is based on data being migrated from legacy SAP ECC systems (PF2, WP2) into SAP S/4HANA.

The purpose of this document is to define the conversion approach to upload data in S/4 HANA.


---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 specifiedExecution frequency is specifiedRestart/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---

  • Update the Data Volume with a actual figures
  • Rules for Data Merging (all systems)
  • Mapping Rules & Conversion Rules



Conversion Scope

Current Usage and Setup in Legacy Systems:

In the legacy SAP ECC systems (PF2 and WP2), Service Master records are maintained primarily to support procurement processes involving services. However, the level of data quality and consistency varies across systems. In some cases, key fields such as Service Descriptions, Units of Measure, or Valuation Classes may be incomplete or non-standardized. Additionally, the linkage between services and associated purchasing conditions is often loosely maintained or inconsistently applied.

Target Representation in SAP S/4HANA:

In S/4HANA, Service Master data will be created in alignment with the Procurement Master Data Design Standard. The objective is to ensure that services are structured, clean, and standardized across the entire enterprise. This includes enforcing harmonized naming conventions, classification, and valuation data to support downstream procurement and analytics processes. Where applicable, service hierarchies and pricing conditions will also be defined to enable integrated procurement planning and execution.

Additional Relevant Information:

  • Service Master records in S/4HANA will be loaded using the SAP Migration Cockpit, based on validated and cleansed legacy extracts.

  • Redundant or obsolete service entries will be excluded as part of the cleansing process.

  • Each service entry will be reviewed and approved by the business before final load.

  • The mapping of legacy keys to S/4-compatible structures (e.g., Service Type, Material Group) will be maintained for traceability.


The data from legacy system includes:

  1. Service records marked as relevant for purchasing processes

  2. Entries with valid service numbers and active status

  3. Records linked to active cost centers or purchasing groups

  4. Service descriptions maintained in English

The data from legacy system excludes:

  1. Obsolete or blocked service records

  2. Entries with missing mandatory fields (e.g., Unit of Measure, Valuation Class)

  3. Test or dummy records (e.g., codes starting with “ZZZ”)

  4. Services not linked to any purchasing documents or usage history

  5. Duplicate entries identified through harmonization process


List of source systems and approximate number of records
SourceScope

Source Approx No. of Records

Target SystemTarget Approx

No. of Records

PF2

The Purchasing Info Records will be extracted/collected via DCT. 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.

Any additional data that need to be created to support the new design may be added in the DCT.

A data review and standardization will be done across all Info Records in the DCT. 

TO BE CONFIRMED

S4H

TO BE CONFIRMED

WP2

TO BE CONFIRMEDS4HTO BE CONFIRMED

Additional Information

Multi-language Requirement

Texts associated multiple languages can be mainted a such (in case available on the source system)

International Version

Description

C

Simplified Chinese

R

Cyrillic

K

Kanji (Japanese)

A

Arabic

3

Korean

T

Thai

H

Hangul

E

English

Document Management

Legal Requirement

Minor effort is foreseen for some specific countries having specific taxations, the topic is limited to have the tax codes mapping (from Old to New tax code).

Special Requirements

Processing Type ETL: 

  • Transformation (T): Syniti will be responsible for cleansing, transforming, and merging the data, as well as updating the staging areas of the SAP Migration Cockpit.

  • Extraction (E): Data will be extracted from at least two source systems. This activity will be performed by Syniti.

  • Loading (L): The final data load into the target SAP system will be carried out using the standard functionalities of the SAP Migration Cockpit.





Target Design

The technical design of the target for this conversion approach.

TableFieldData ElementField DescriptionData TypeLengthRequirement
ASMD

ASNUM

Service Number

CHAR

10

Yes

Key field, must be unique

ASMD

KTEXT1

Short Text

CHAR

40

Yes

Service Description

ASMD

MEINS

Base Unit of Measure

UNIT

3

Yes

UoM must exist in target system

ASMD

ASBGR

Service Group

CHAR

6

Yes

Must map from legacy

ASMD

LOEKZ

Deletion Flag

CHAR

1

No

Used to filter out obsolete records


Data Cleansing

IDCriticalityError Message/Report DescriptionRuleOutputSource System


























Conversion Process

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

image-2025-6-20_9-51-38.png




Data Privacy and Sensitivity

N/A


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

Req #Requirement DescriptionTeam Responsible













Selection Screen

Selection Ref ScreenParameter NameSelection TypeRequirementValue to be entered/set





















Data Collection Template (DCT)

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

DCT Rules

Field NameField DescriptionRule












Extraction Dependencies

Item #Step DescriptionTeam 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 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

Item #Step DescriptionTeam Responsible













Transformation Rules

Rule #Source systemSource TableSource FieldSource DescriptionTarget SystemTarget TableTarget FieldTarget DescriptionTransformation Logic









































Transformation Mapping

Mapping Table NameMapping Table Description








Transformation Dependencies

List the steps that need to occur before transformation can commence
Item #Step DescriptionTeam Responsible













Pre-Load Validation

Project Team

Completeness

TaskAction





Accuracy

TaskAction





Business

Completeness

TaskAction





Accuracy

TaskAction





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 DescriptionTeam Responsible













Load Phase and Dependencies

Configuration

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

Error TypeError DescriptionAction Taken










Post-Load Validation

Project Team

Completeness

TaskAction





Accuracy

TaskAction





Business

Completeness

TaskAction





Accuracy

TaskAction





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

Version Published Changed By Comment
CURRENT (v. 9) Nov 20, 2025 09:12 BUOSI-ext, Angelo
v. 368 Nov 18, 2025 15:25 BUOSI-ext, Angelo
v. 367 Nov 13, 2025 08:54 BUOSI-ext, Angelo
v. 366 Oct 30, 2025 09:18 BUOSI-ext, Angelo
v. 365 Oct 21, 2025 10:43 BUOSI-ext, Angelo
v. 364 Oct 21, 2025 10:43 BUOSI-ext, Angelo
v. 363 Oct 20, 2025 10:43 BUOSI-ext, Angelo
v. 362 Oct 20, 2025 10:42 BUOSI-ext, Angelo
v. 361 Oct 17, 2025 13:53 BUOSI-ext, Angelo
v. 360 Oct 17, 2025 13:36 BUOSI-ext, Angelo

Go to Page History

Workflow history

Title Last Updated By Updated Status  
There are no pages at the moment.

  • No labels