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.

This file is aligned with the Conversion Specification Guidelines

---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 havee 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) - DEDUPLICATION RULES

Conversion Scope

The migration will consolidate two existing legacy object types into a single Lean Service model in S/4HANA:

1. Materials created as Services – Material Master records with service-related material types (PF2 = DIEN, Z710, Z720, Z732, ZB10, ZB20, ZESE, ZFS1, ZPSE, ZU10, ZU20 or WP2 = DIEN, ZDIE) ==> main table = MARA
2. Service Master Data – Maintained in SAP ECC ==> main table = ASMD

Both object types are currently used in parallel to support service procurement. While they may sometimes represent similar business needs, they are maintained and processed independently in the legacy systems.

In the target system (S/4HANA), all services will be represented exclusively as Lean Services within the Material Master (Material Type = SERV or ZSER), in line with the Procurement Master Data Design Standard. This approach eliminates the need for separate Service Master objects and service material types, providing:

• A single master data object for all services.

• Standardized naming, classification, and valuation.

• Harmonized Material Groups for enterprise-wide reporting and spend analysis.

The conversion scope includes:

• Extracting both Service Master (ASMD) and Materials-as-Services records (MARA).

• Cleansing, harmonizing, and deduplicating entries across both object types.

• Mapping legacy keys to new Lean Service material numbers for traceability.

• Excluding obsolete, incomplete, or unused records.

List of source systems and approximate number of records

Relevancy Rules

***SERVICES AS MATERIALS (MARA TABLE) - System PF2/WP2

Relevant Tables for the Extraction

Execution Logic:

>>>========================================================================================

SINGLE

- All materials created in the previous 6 months will be included unless flagged for deletion.

GLOBAL
We will only include materials that are extended to the following:
- We will only include plants that are in-scope
- We will only include company codes that are in-scope
- We will only include purchasing orgs that are in-scope
- We will only include sales orgs that are in-scope

===========================================================================================

TO BE EXCLUDED

1) EXCLUDED (No activity, when >= 6m and <=3y) ← targeted recency rule

Evaluated in this exact order; first match wins:

2) EXCLUDED (Obsolete text)
If MAKT-MAKTX indicates obsolescence:
   - contains word OBSOLETE or DELETED, or
   - after removing * and spaces, contains OBS.

3) EXCLUDED (MSTAE)
System-specific status code (PF2: Z3/Z4/ZZ; WP2: Z0).

4) EXCLUDED (LVORM)
If LVORM = 'X' and there is no open order within the last 3 years across SO/PO/PP:
HasOpenSO3Y = 0 AND HasOpenPO3Y = 0 AND HasOpenPP3Y = 0 exclude entry

5) EXCLUDED (No plant in scope)
If HasInScopePlant = 0 (and @RequirePlantExtension = 1).

6) EXCLUDED (No activity, 6m-3y) ← targeted recency rule
Exclude when all are true: 
   - Created window: ERSDA_date <= @From6Months and ERSDA_date >= @From3Years, and
   - No 3y activity: HasSO3Y = 0 AND HasPO3Y = 0 AND HasPP3Y = 0.

7) Material Group Mapping (ZZM_GPS_MATKL)
Match ASMD‑MATKL to ZZM_GPS_MATKL‑MATKL with ZZMGOODSER='S'. If a match exists and LOEVM is not initial, the record is excluded. The solution publishes MAPPED/UNMAPPED reports for governance visibility.

If none of the above exclusions apply, the material is included (see topic 4 for more details).

===========================================================================================

TO BE INCLUDED

1) Scope prerequisites

- Client: MANDT = (PF2 = '020' or WP2 = '400') 
- Material types in scope (MARA-MTART): (PF2 = DIEN, Z710, Z720, Z732, ZB10, ZB20, ZESE, ZFS1, ZPSE, ZU10, ZU20 or WP2 = DIEN, ZDIE)
- Plant in scope (MARC-WERKS): Material must be extended to at least one plant in
- Exclusion indicator (MARA-MSTAE): exclude materials with the following status (PF2 = Z3/Z4/ZZ; WP2 = Z0).

2) Time windows (used everywhere)

- Materials with <= 6 month since its creation, don't need to have any activity (PurchOrder, SalesOrder, Production)
- Newness: @Today – 6 months

3) Activity & Open definitions (last 3 years)

Sales Orders (SO)
- Activity (HasSO3Y): exists VBAP line joined to VBAK with VBAK.ERDAT >= @From3Years.
- Open (HasOpenSO): line is open if any:
   - VBUK.GBSTK NOT IN ('C','D'), or
   - VBUP.GBSTA NOT IN ('C','D'), or
   - no VBUP and VBAP.ABGRU = '' (blank).
- Open within 3y (LVORM override): same open condition AND VBAK.ERDAT >= @From3Years >>> HasOpenSO3Y.

Purchase Orders (PO)
- Activity (HasPO3Y): EKKO header date COALESCE(AEDAT,BEDAT) >= @From3Years on a matching EKPO.
- Open (HasOpenPO): EKPO.ELIKZ <> 'X' AND EKPO.LOEKZ <> 'X'.
- Open within 3y (LVORM override): open AND COALESCE(AEDAT,BEDAT) >= @From3Years >>> HasOpenPO3Y.

Production Orders (PP)
- Activity (HasPP3Y): COALESCE(AUFK.ERDAT, AFKO.GLTRP) >= @From3Years on a matching AFPO.
- Open (HasOpenPP): AUFK.LOEKZ <> 'X' AND (AFKO.GLTRP IS NULL OR AFKO.GLTRP >= @Today).
- Open within 3y (LVORM override): open AND COALESCE(AUFK.ERDAT, AFKO.GLTRP) >= @From3Years >>> HasOpenPP3Y.

4) Inclusion triggers (exceptional list)

- If the material is in the manual table, it must be included.

5) Available Stock (note this migration regards SERVICES, therefore this rule should be treated as an exceptional situation)

If any of the below table-fields are greater than 0 and the material has current stock, it should be included for migration, even if other activity rules (PO, SO, PP) are not met. This has priority over all other rules.

- Check if Storage Location Stock (MARD) <> 0
MARD-LABST = Unrestricted stock
MARD-INSME = Stock in quality inspection
MARD-SPEME = Blocked stock
MARD-UMLME = Stock in transfer (to another storage location)

 - Special Stocks (as needed in migration scope)
MKOL-KALAB = Consignment stock (vendor consignment)
MSLB-LABST = Special stock with customer (sales order stock)
MSKA-LABST = Sales order stock
MSPR-LABST = Project stock

6) Final filters before output

Even if a row/material has an INCLUDED reason, it must still pass all of these steps:

   - IsObsoleteText = 0
   - ExcludeByMSTAE = 0
   - Not (LVORM='X' AND HasOpenSO3Y=0 AND HasOpenPO3Y=0 AND HasOpenPP3Y=0)
   - And (IsForceIncluded = 1 OR EligibilityReason LIKE 'INCLUDED%')

========================================================================================<<<

***SERVICES MASTER DATA (ASMD TABLE) - System PF2/WP2

 Relevant Tables for the Extraction

Execution Logic:

>>>========================================================================================

SINGLE

- All materials created in the previous 6 months will be included unless flagged for deletion.

GLOBAL
We will only include materials that are extended to the following:
- We will only include plants that are in-scope
- We will only include company codes that are in-scope
- We will only include purchasing orgs that are in-scope
- We will only include sales orgs that are in-scope

===========================================================================================

SINGLE

- All services created in the previous 6 months (ASMD-ERDAT >= @From6Months) are included unless excluded by LVORM/MSTAE/text rules. (Services are client-level; no plant extension applies.)

GLOBAL

- Client: MANDT IN (PF2-020, WP2-400)

- Company codes / purchasing orgs in scope: restrict via your in-scope lists, applied through the documents that reference the service (POs/Entry Sheets).

- Purchasing Organization in scope: restrict via your in-scope lists, applied through the documents that reference the service (POs/SOs/Entry Sheets).

===========================================================================================

• Services that have had business activity in the last 3 years will be included.

• Services with open Purchase Orders (EBAN, EKPO) will be included.

• Services created within the last 6 months are in scope, unless explicitly marked for deletion or obsolescence.

• Services with confirmed Deletion Flags will be excluded. When ASMD–LOEKZ (Deletion indicator) or MARA–LVORM is not initial.

• Services marked as Excluded in MARA-MSTAE are not selected.

• Services marked as OBSOLETE (or similar) in the description text will be excluded, subject to business confirmation.

• Certain Material Types must be included even if no activity is founded: DIEN\

• All dependent data objects linked to in-scope Services must also be migrated:

- Texts (STXH/STXL linked to Services).
- Classifications & Characteristics (KLAH, KSML, AUSP).
- Purchasing Info Records for Services (EINA/EINE).
- Conditions linked to Services (KONP/KONV).

• Golden Record Principle
  - In case of duplicates, the survivorship logic from the Deduplication Rules will apply.
  - Only one “Golden Service Record” per unique Service will be migrated.

TO BE EXCLUDED

1) EXCLUDED (No activity, when >= 6m and <=3y) ← targeted recency rule

Evaluated in this exact order; first match wins:

2) EXCLUDED (Obsolete text)
If MAKT-MAKTX indicates obsolescence:
   - contains word OBSOLETE or DELETED, or
   - after removing * and spaces, contains OBS.

3) EXCLUDED (MSTAE)
System-specific status code (PF2: Z3/Z4/ZZ; WP2: Z0).

4) EXCLUDED (LVORM)
If LVORM = 'X' and there is no open order within the last 3 years across SO/PO/PP:
HasOpenSO3Y = 0 AND HasOpenPO3Y = 0 AND HasOpenPP3Y = 0 exclude entry

5) EXCLUDED (No plant in scope)

If WERKS = '' then there is no verification to be done.

Elseif HasInScopePlant = 0 (and @RequirePlantExtension = 1).

6) EXCLUDED (No activity, 6m-3y) ← targeted recency rule
Exclude when all are true: 
   - Created window: ERSDA_date <= @From6Months and ERSDA_date >= @From3Years, and
   - No 3y activity: HasSO3Y = 0 AND HasPO3Y = 0 AND HasPP3Y = 0.

If none of the above exclusions apply, the material is included (see topic 4 for more details).

*** Canonical Key & Duplication Detection

Deduplication of records from MARA and ASMD tables

...

Additional Information

Multi-language Requirement

For all Lean Services in the target S/4HANA system, the default description will be maintaineed in English.

Where available in the source systems (PF2, WP2), additional language-dependent descriptions will also be migrated. This applies to both:

• Service Master records (ASMD).

• Materials-as-Services (Material Type DIEN or equivalent).

Migration rules:

• Only languages available and supported in the target S/4HANA system will be migrated.

• If a description exists in a custom or unsupported language key in the source, that language entry will be skipped.

• The migration will preserve the link between the Lean Service material number and each language-specific description.

• Where the same service exists in multiple languages in the source, all valid language versions will be migrated together with the default English text.

This approach ensures that Lean Services are available in multiple languages for purchasing, reporting, and user interaction, while maintaining compliance with the target system’s supported language set.

Languages to be extracted (available on Source Systems)

SAP standard supports all ISO languages, ensure that all standard languages are considered in scope.

Languages to don't be extracted

The Z9 language code represents “Multilingual / Other,” which is a generic placeholder rather than a specific language. It does not correspond to a standard ISO language code and therefore cannot be mapped reliably to a target language in the S/4HANA environment. Including Z9 would result in ambiguous or duplicate entries, making data validation, reporting, and translation maintenance inconsistent. To ensure data quality and consistency, records with Z9 will be excluded from the extraction scope.

Document Management

N/A.

Legal Requirement

Minor efforts with taxation are 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.

Deduplication Rules

Ensure that Lean Service Materials (stored in MARA and related tables) are unique and free of redundancies prior to migration into S/4HANA. The rules mentioned below validate duplicates across standardized descriptions, language, material group, and units of measure, while also considering long texts for confirmation.

Additionally, unsupported or custom languages (such as Z9) are excluded unless explicitly required, ensuring alignment with SAP standard language configurations. This prevents proliferation of redundant Lean Service materials and supports a harmonized catalog in the target system.

Target Design

The technical design of the target for this conversion approach.

To be decided what to do with the Z Fields below:

Tables to be migrated as Basic Data:

Data Cleansing

All data cleansing should take place in the data source system as defined in this document, unless system limitations prevent it.

If data cleansing is managed outside of the source system (e.g. Syniti Migrate, 3rd Party Vendor, DCT), the necessary documentation must be produced and appended to this deliverable for sign-off.

Conversion Process

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

Data Privacy and Sensitivity
N/A

Data Merging / Data Consolidation

The data merging is restricted to the Materia Types Z720 / ZB20 / ZDIE being Deduplicated/Merged into ZSER in combination with the Service Master.

eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IkJVT1NJLWV4dCwgQW5nZWxvIiwib3V0cHV0VHlwZSI6ImJsb2NrIiwibGFzdE1vZGlmaWVyTmFtZSI6IkJVT1NJLWV4dCwgQW5nZWxvIiwibGFuZ3VhZ2UiOiJlbiIsInVpQ29uZmlnIjoie30iLCJkaWFncmFtRGlzcGxheU5hbWUiOiIiLCJzRmlsZUlkIjoiIiwiYXR0SWQiOiI5NDUwMzY1MDIiLCJkaWFncmFtTmFtZSI6IkRhdGEgTWVyZ2luZyBlbmdpbmUiLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiQ05WLTIwMTYgU2VydmljZSBNYXN0ZXIgcmVjb3JkIChMZWFuIFNlcnZpY2VzKSIsInRic3R5bGUiOiJ0b3AiLCJjYW5Db21tZW50IjpmYWxzZSwiZGlhZ3JhbVVybCI6IiIsImNzdkZpbGVVcmwiOiIiLCJib3JkZXIiOnRydWUsIm1heFNjYWxlIjoiMSIsIm93bmluZ1BhZ2VJZCI6OTM3MDExNjkwLCJlZGl0YWJsZSI6ZmFsc2UsImNlb0lkIjo5NDUwNTM5NzMsInBhZ2VJZCI6IiIsImxib3giOnRydWUsInNlcnZlckNvbmZpZyI6eyJlbWFpbHByZXZpZXciOiIxIn0sIm9kcml2ZUlkIjoiIiwicmV2aXNpb24iOjI4LCJtYWNyb0lkIjoiYjIxN2U4YjktNjVhMC00MzJjLTllNjctMWNjMmE4YjA0YzdjIiwicHJldmlld05hbWUiOiJEYXRhIE1lcmdpbmcgZW5naW5lLnBuZyIsImxpY2Vuc2VTdGF0dXMiOiJPSyIsInNlcnZpY2UiOiIiLCJpc1RlbXBsYXRlIjoiIiwid2lkdGgiOiIxMzY3Iiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNzYxMDQzNDE4ODc3LCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==

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)

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

Transformation - Special Requirements

Custom Fields - to be identified the usage of those and whether they will be moved into S4/Hana

Tables: MARA / MAKT

Custom Unit of Measures: to be identified the usage of those and whether they will be moved into S4/Hana

Data Mapping: Account Group

* some materials were originally created under type ZNLA (e.g., electricity). However, these must be converted to type ZSER. An exception list table should be created to capture all relevant materials, ensuring they are flagged as in-scope for migration.

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

Syniti Reports

Open Questions

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