Purpose

The purpose of this document is to define the conversion approach for assigning the Business Partner role BUP001 (Contact) in SAP S/4HANA. In S/4HANA, Business Partner roles define the context in which a BP can be used. The BUP001 role is essential for identifying individuals as contact persons within customer relationships.

Conversion Scope

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

The scope of this document covers the approach for converting active Contact Person Relationships from Legacy Source Systems into S/4HANA Business Partner (BP) Relationship Master Data Design Standard.

The data from legacy system includes:

1. Individuals classified as contact persons and linked to customers or vendors
   • These are typically maintained in legacy systems in contact tables (e.g., KNVK in ECC).
   • Each contact is tied to a customer/vendor master record and plays a defined communication or business coordination role.
   • These contacts need to be transformed into BPs of type Person and enriched with the BUP001
2. Contact persons already converted as Business Partners (Person) in S/4HANA who now require the BUP001 role
   • These may have been created during the BP General conversion but were not assigned any roles beyond 000000.
   • The current activity focuses on enriching these BPs with BUP001 to make them operational as contact persons.
3. Contacts used in Sales, Service, or Partner Functions in the last 5 years XXXX need to check further
   • Contacts referenced in sales documents (e.g., Sales Orders, Deliveries, Billing documents) or in CRM/service documents.
   • Includes contacts maintained as partner functions such as Contact Person, Employee Responsible, or Sales Contact.
   • Ensures that any contact with business impact in recent years is retained and usable post go-live.
4. Contacts created in the last 1 year and still active, even if not linked to open transactions
   • Captures newly onboarded contacts or relationship personnel who may not yet have generated sales transactions but are expected to play a role going forward. XXXX check further

The data from legacy system excludes:

1. Contacts marked as deleted or obsolete in the legacy system
   • Contacts flagged with deletion indicators or obsolete markers in master data.
   • Prevents cluttering the BP master with outdated or retired individuals.
2. Contacts that are not uniquely identifiable or lack required attributes
   • Contacts with missing mandatory information such as names, identifiers, or linkage to customers/vendors.
   • These are typically filtered during the transformation phase or marked for business clarification.
3. Contacts not linked to any business transactions or customers within scope XXX to check further if a contact person will be brought over to transactional level
   • Includes orphaned records or standalone contacts not tied to any active customer/vendor that is in migration scope.
   • These have no functional relevance in S/4HANA if the parent business entity is not migrating. 
4. Duplicate contact entries with no distinct role or business usage
   • Contacts created redundantly in the legacy system due to lack of governance.
   • Only unique and validated contact roles are migrated; duplicates are eliminated or merged during data cleansing. XXX to check further if a contact person will be brought over to transactional level

Additional Information

Multi-language Requirement

Document Management

Legal Requirement

Special Requirements

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:

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)

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