Purpose

This section explains the reason for creating this document. The purpose of a conversion specification is to define how legacy data will be transformed and migrated into SAP S/4HANA. For fixed bins in EWM, the goal is to ensure warehouse operations continue seamlessly by preserving or redesigning fixed bin assignments in the new system. The purpose of this document is to define the conversion approach to create Fixed Bin assignments in SAP S/4HANA EWM. Fixed bins are maintained in storage types where fixed bin determination is enabled. This document outlines how the data will be prepared and loaded into the target EWM system.

Conversion Scope

This section outlines what is included and excluded from the conversion effort. It also provides information on data volumes and source/target systems. Clear scoping ensures everyone understands the boundaries and expectations of the conversion project.

Included:

• Fixed bin records for warehouse and storage type combinations 

Excluded:

• Storage types where fixed bin determination is not enabled.

Source Systems and Record Volume:

Target System and Record Volume:

Additional Information:

• Multi-language: Not applicable

• Legal Requirements: None

• Special Requirements: None

Multi-language Requirement

N/A

Document Management

N/A

Legal Requirement

N/A

Special Requirements

N/A

Target Design

The technical design of the target for this conversion approach. The target design specifies the structure of the SAP table that will hold the converted data. It defines each field's technical properties and whether it is mandatory or optional. This ensures that the load file is aligned with system requirements.

Data Cleansing

Data cleansing is a vital activity to detect and correct errors in the legacy data before conversion. It prevents issues during transformation or loading. The rules listed here help identify incomplete, inconsistent, or invalid records.

Conversion Process

This section provides a high-level view of the sequence of steps needed to move the data from the legacy format into SAP. It includes extraction, transformation, validation, and loading steps.

Data Privacy and Sensitivity

Extraction

Extract data from a source into Syniti Migrate. 

1. The data does not exist (or cannot be converted from its current state). The data is manually collected by the business directly in Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate

The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads

Method: Manual DCT template maintained by business team

Run Sheet:

Selection Parameters:

Data Collection Template (DCT)

<Object> DCT Rules

The DCT is a structured Excel template used when data must be manually gathered. It contains the necessary fields and rules to guide users in submitting complete and valid fixed bin information.

Pre-requisite steps : 

The Data Collection Template (DCT) is the primary input mechanism when assigning products to fixed bins. Business teams must complete the template with accurate and validated information.

The DCT enforces structured input for fixed bin assignments. Each column has a direct mapping to target EWM fields, ensuring data integrity. Failure to provide these fields accurately will result in rejected records during transformation and load.

Transformation

Please check the attached file for the complete source-to-target field mapping, validation checks and proposed error messages. The validation checks list is not exhaustive and may change over time as the design and configuration of the system evolves.

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 Syniti Migrate 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 Syniti Migrate
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 involves converting legacy data values into the formats and structures required by SAP. It can include value mapping, defaulting, or formatting logic to prepare the data for loading.

Transformation Mapping – Legacy Product → SAP Product

Transformation Mapping:

• If a new product is generated, mapping of legacy product number to new product number would be necessary. 

Transformation Dependencies:

• Product master and storage bin master data must be loaded before fixed bins. Party entitled to dispose must also exist in table BUT000 before it can be referenced in a fixed bin. 

List of Custom Target Reports for this object is maintained here: Conversion Specification - Custom Reports Register.

Pre-Load Validation

Pre-load validation is a critical phase that ensures data readiness before it enters the target system. It involves checking for data completeness and accuracy to prevent issues during loading and subsequent warehouse operations. The validation is performed by both the Project Team and the Business Team, each responsible for different aspects of the quality checks.

Project Team

The project team is responsible for verifying the technical integrity of the dataset. This includes ensuring that all mandatory fields are filled and the values conform to expected formats and business rules configured in the system.

Business Team

The business team is responsible for ensuring that the content of the data reflects operational reality. This includes checking whether the right bins are assigned to the correct products and validating that the assignments meet the business process expectations.

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

Sample Load file : Standard SAP upload templates - ERP Rebuild Implementation - Google Drive

Steps:

1. Format flat file from validated DCT

2. Load via standard sap transaction : /scwm/mig_product

3. Confirm load completion in system

Load Phase and Dependencies

The load phase focuses on the technical execution of transferring prepared and validated data into the SAP S/4HANA EWM system. This includes the transformation of the source file into the required format, execution of the load using the appropriate tool (e.g. LTMC or custom LSMW), and validation of the load outcome. Dependencies ensure that all required foundational data and configurations are in place before the load begins.

Configuration

N/A

Conversion Objects

Post-Load Validation

Once data is loaded, post-load validation ensures it has been correctly transferred and is usable in the system. Validation checks are performed by both the project and business teams to ensure that the fixed bin data behaves as expected in the EWM environment.

Project Team

The project team is responsible for performing system-level and technical checks to verify data consistency and integrity after the load. This involves confirming that all records were loaded as expected and that the database reflects the input file.

Business Team

The business team verifies that the loaded data aligns with real-world operations. This includes validating that the fixed bins behave correctly during picking, replenishment, and other EWM processes.

Completeness

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• Data Object is in scope based on data design and any exception requested by business.

• Configuration of storage type, storage bin data is complete 

• Product and bin data are available and valid

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log