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

Customer Contact Person

The scope of this document covers the approach for converting active Contact Person 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 Business Partner such as customers or vendors.
   • These are typically maintained in legacy systems in contact tables KNVP (Partner function from Partner type AP) and KNVK in ECC.
   • Each contact is tied to a customer 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

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 or identifiers.
   • These are typically filtered during the transformation phase or marked for business clarification.
3. Contacts not linked to any customers within scope
   • Orphaned records or standalone contacts not tied to any active customer 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 person are migrated; duplicates are eliminated or merged during data cleansing. 

Vendor Contact Person

The scope of this document covers the approach for converting active Contact Person related to vendor from Legacy Source Systems into S/4HANA Business Partner (BP) Contact Person.

The data from legacy system includes:

The data from legacy system excludes:

List of source systems and approximate number of records

Additional Information

Multi-language Requirement

The customer and vendor contact person may contain international address. Therefore, the conversion will also need to support the multi-language address.  Below languages (International versions) are supported. 

Document Management

Legal Requirement

CMMC 2.0 is a mandatory DoD cybersecurity certification for contractors handling Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). CUI includes sensitive technical data (e.g., design specs, system info) related to U.S. military and space applications. The Composites Business handles CUI and is therefore within CMMC scope. Without certification, the business risks disqualification from existing and future DoD programs.
It is mandatory to implement CMMC-compliant systems and processes to for all the organizations that are dealing with CUI.

Therefore, there will be one SAP instance specifically for CUI related entities. The migration for CUI related entities will be covered by US based data consultant using separate tools.

Special Requirements

Customer Contact Person

A. Different SAP Instance Migration Approach

Due to compliance requirement, there will be one SAP instance for Rest of the World, one for China and one for CUI.

1. For entities in China, the data will be loaded into SAP China instance while the entire migration process will remain the same as rest of the world.
2. For entities which will reside in CUI, the migration will be handled by US based data consultant. 
3. The contact person should be loaded into the same target instance as the corresponding customer master. If the customer master is loaded into two instances, the contact person should be loaded into both as well.

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