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 - DATA TEAM---

• 1) Legacy systems (Logical Source and Target Systems are identified)
• 2) Extraction methods and file types
• 3) Scope relevancy criteria
• 4) Target structure/ Rules
• 5) MDS links
• 6) Cleansing rules
  • 6a) Cleansing reports with technical information
  • 6b) Profiling
  • 6c) Deduplication (with technical details of Table-Fields, Conditions)
  • 6d) Frequency of running reports
• 7) Transformation - and for this DOMD template must be populate and final version of DOMD template should be copied to Transformation section in CSpecs
• 8) Configuration/Value mapping file link
• 9) Value Mappings (Data Mapping is provided for mappings which are not obvious to a suitably-skilled and experienced developer)
• 10) Load template link
• 11) Loading method (Processing Type is specified, i.e. Direct Input, BAPI, IDoc, Web Service, OData API, etc.)
• 12) Loading sequence or dependency
• 13Error handling requirements are specified / including alerting requirement / expected action on failure.
• 13) Data Analysis
• 14) Pre load validation
• 15) Post load validation
• 16) any Exceptions (Data Mapping is provided for mappings which are not obvious to a suitably-skilled and experienced developer)
• 17)Application log requirement if applicable to be specified. 
• 18) Signoff

Conversion Scope

Both object types (ASMD / MARA) 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

MDS Documents

Relevancy Rules

Service Master (ASMD) - Relevancy Rule (meeting 20251015 1733)

Service Master to Material Master Conversion:

• Not All Service Masters Migrated: Only a fixed, business-validated subset of active service masters (with activity in past three years and not marked for deletion) is considered relevant for migration.
• Service Masters Become Material Masters: Migrated service masters are converted to material masters (product type 2).
• No Info Records in Legacy for Services: Generally, info records don’t exist for services. Pricing for services will come from either contracts or is to be collected as part of the master data process (DCT).
• If Service Becomes Material: Once converted, the same PIR relevancy rule applies: if info records are needed (i.e., there is no contract), info record can be created; otherwise, contract is prioritized.
• Price Collection: When collecting service master data, price information is also collected so it can be used to create either an info record or contract in the target system based on business need/decision.
• Further Business Confirmation Needed: Approach is to check feasibility of creating info records for converted service masters and verify with business if their processes require it.
• Summary and DCT instructions:
  • List of Service master records will be provided by functional leads (Dean and Anjali) after validation with Business and all pods. 
  • Pricing data for service masters will be collected in DCT and will be created as contracts or info records based on business confirmation.

  • Data will be captured in DCT(Data collection template)

***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
Will only include materials that are extended to the following:
- only include POs that have Purch Org and Plants in scope

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

TO BE EXCLUDED

Evaluated in this exact order; first match wins:

Scope prerequisites

- Client: MANDT = (PF2 = '020' or WP2 = '400')
- Material types in scope (MARA-MTART): (PF2 = DIEN, Z710, Z720, Z732, 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).

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

2) EXCLUDED (Obsolete text)
If MAKT-MAKTX indicates obsolescence:
   - contains word OBSOLETE or DELETED, or
   - after removing * and spaces, contains OBS, or
   - one of those acronyms mentioned in this file

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) EXCLUDED Material Group Mapping (ZZM_GPS_MATKL)
Match MARA‑MATKL to ZZM_GPS_MATKL‑MATKL with ZZMGOODSER='S'. If a match exists and LOEVM is not initial, the record is excluded. 

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

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

TO BE INCLUDED

Scope prerequisites

- Client: MANDT = (PF2 = '020' or WP2 = '400') 
- Material types in scope (MARA-MTART): (PF2 = (PF2 = DIEN, Z710, Z720, Z732, 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)
- Materials with up to 3 years

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:
-VBAK-VBELN = VBAP-VBELN
- VBAK-VBELN = VBUK-VBELN and
- VBUK.GBSTK = ('A','B')

Purchase Orders (PO)

- Activity (HasPO3Y): EKKO-LOEKZ <> 'X' and EKPO.LOEKZ <> 'X' and EKPO COALESCE(AEDAT) >= @From3Years on a matching EKPO.
- Open: EKKO-LOEKZ <> 'X' and EKPO.EREKZ <> 'X' and EKPO.LOEKZ <> 'X'. 

Production Orders (PP)
- Activity (HasPP3Y): COALESCE(AUFK.ERDAT) >= @From3Years on a matching AFPO AND AUFK.LOEKZ <> 'X'
- Open (HasOpenPP): AUFK.LOEKZ <> 'X' AND Use AUFK for checking Open Process orders. Link field OBJNR to JEST.OBNR to get status codes not equal to TECO AND JEST.INACT=''. Table TJ02 for status descriptions.

4) Inclusion triggers (exceptional list)

- An exception list should be available, and if the material is in the manual table, it must be included.

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:
- only include plants that are in-scope
- only include company codes that are in-scope
- only include purchasing orgs that are in-scope
- only include sales orgs that are in-scope
- only include POs that have Purch Org and Plants in scope
- only include SOs that have Sales Org and Plants in scope
- only include PPs that have Plants 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).

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

TO BE EXCLUDED

Evaluated in this exact order; first match wins:

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

2) EXCLUDED (Obsolete text)
Obsolete text detected in ASMDT (OBSOLETE / DELETED / (OBS) / “ obs ”).

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

4) EXCLUDED (LVORM)
Deletion flag (LVORM=X) and no open PO/SES in the last 3 years.

5) EXCLUDED No activity and AEDAT between 6 months and 3 years ago.

6) EXCLUDED 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) INCLUDED Any entry based on the SES spec path (even in case the service is marked for deletion but the SES remains open)

• Pass ASMD.ASNUM to ESLL.SRVPOS and get ESLL.PACKNO
• Pass ESLL.PACKNO to ESLH.PACKNO and get ESLH.HPACKNO
• Pass ESLH.HPACKNO to EKPO.PACKNO, to get PO document number for the Service Number

2) INCLUDED Default pass (no negatives matched).

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

*** Canonical Key & Deduplication

Current status Production extraction

Deduplication of records from Material as Service (MARA) and Service Master (ASMD) tables. Evaluated in this exact order; first match wins:

Deduplication ASMD Table

Additional Information

Extraction/Transformation Methods and File Types

Data is Extracted and Transformed by Syniti ADM, the stagging area of the Migration Cockpit is updated.

Loading Template

Loading Methods

Migration Cockpit has been elected to execute the data loading of Materials Lean Services. The Loading Method has been defined as Product.

Multi-language Requirement

For all Lean Services in the target S/4HANA system, the default description will be maintained 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 (MARA)

Data Cleansing is necessary, entries exist for EN however it's content concerns another language.

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.
  • The decided loading tool is called 'Service Product' and is available on the 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.

Frequency of running reports

• Preload Reports
  • Run before every load execution (Mock Loads, Dress Rehearsals, Cutover).
  • Purpose: to validate source-to-target transformations, business rules, and check for data quality issues before pushing into the Migration Cockpit.
  • Typically executed each time you release a wave or object for load.

• Postload Reports
  • Run immediately after each load execution.
  • Purpose: to reconcile and confirm that what was loaded into SAP matches the expected records (counts, key fields, value checks, etc.).
  • Typically executed after every migration cycle (mock, dress rehearsal, final cutover).

Target Design

The technical design of the target for this conversion approach.

Value Mappings: Transformation DOMD 

The complete file is available on this LINK

From Service-Material (MARA) to Service-Material (MARA)