Purpose

Bin Sorting is a new functionality in SAP S/4HANA EWM that determines the order in which bins are processed for warehouse activities such as picking, replenishment, and inventory. Sorting can be created manually, uploaded from a template, or generated automatically by the system using standard transaction /SCWM/SBST. This document defines the conversion approach for setting up bin sorting records, either via automated generation or manual upload of business-provided sequences.

Conversion Scope

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

The data from legacy system includes:

The data from legacy system excludes:

This section clarifies the boundaries of the bin sorting conversion.

Included:

• Creation of bin sorting records where business provides a template with manual sort logic.

• Upload of bin sorting sequences through upload transaction or via conversion load.

• Standard generation of bin sorting via /SCWM/SBST where no business template is provided.

Excluded:

• Creation of bin master data (bins must exist prior to sorting).

• Creation of customizing/master data for activity types, activity areas, storage types, or storage sections.

• Any process re-design not related to sequencing.

Target System and Approximate Volumes:

• SAP S/4HANA EWM: TBD

Source Approx No. of Records

No. of Records

Additional Information

• Multi-language

• : Not applicable.

• Document Management: Per program governance.

• Legal

• Requirements: None identified for sequencing.

• Special Requirements: Sorting must align with business-defined pick paths and operational constraints in each activity area.

Summary paragraph: If business requires custom sorting beyond the system-generated sequence from /SCWM/SBST, this will be captured in the upload template and loaded as part of the migration effort.

Target Design

The bin sorting entries are stored in EWM and reference bin, warehouse, and operational structures. Only target-relevant fields are listed below; any additional DCT fields used for governance or filtering (e.g., Company Code) are staging-only and not loaded.

Target Table:/SCWM/LAGPS technical design of the target for this conversion approach.

Template Upload Fields:

• Warehouse Number (LGNUM)

• Storage Bin (LGPLA)

• Activity (ACT_TYPE)

• Sequence Number (SRT_NR)

• Activity Area (AAREA)

• Storage Type (LGTYP)

• Storage Section (LGBER)

• Sort Sequence 

Summary paragraph:/SCWM/LAGPS holds bin sorting information. If no manual template is uploaded, /SCWM/SBST will generate records automatically using available bins.

Data Cleansing

Data cleansing ensures only valid, load-ready records proceed.

Data Cleansing

Summary paragraph: For manual uploads, data integrity checks prevent duplicates, invalid references, or non-numeric sequences. For /SCWM/SBST, the system inherently generates valid data.

Conversion Process

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

Data Privacy and Sensitivity

Extraction

Image Added

High-level sequence for moving

data from

source

to target.

1. Where business provides input, collect bin sorting sequences in upload template.

2. Validate key references (bin, activity type, activity area, storage type/section).

3. Apply transformation rules and mappings.

4. Prepare target load file

5. Execute load or run /SCWM/SBST if no manual input provided.

Summary paragraph: The process supports both automated (system-generated) and manual (template-driven) sorting, ensuring warehouse flexibility while maintaining system integrity.

Data Privacy and Sensitivity

Extraction

Extraction obtains the raw/bin-level sequencing data.

Method(s):

• Manual DCT maintained by business where manual sorting is required.

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

Extraction Run Sheet

Extraction Dependencies

Selection Screen

Summary paragraph: Manual templates are required only when specific sequences are demanded by business; otherwise, /SCWM/SBST auto-generates sorting data.

Data Collection Template (DCT)

The DCT defines required columns, formats, and validation rules.

DCT Rules

Extraction Dependencies

Summary paragraph: The template is only applicable for manual upload. If no DCT is provided, bin sorting will be auto-generated in /SCWM/SBST with default logic.

Transformation

Transformation aligns source values with target requirements and formats.

Transformation Dependencies

Summary paragraph: Transformation is not required when /SCWM/SBST is used. For manual upload, values are validated and mapped to target definitions before loading.

Transformation Mapping

Summary paragraph: All fields map directly with validation dependencies on existing master/configuration objects. Syniti mapping will ensure governance, cleansing, and automation of the transformation layer.

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

Activity types INTL, INVE,PICK,PTWY,REPL,STCH will be used.

One bin sort record will be required per activity

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Ensures completeness and accuracy of the technical dataset.

Business

Completeness

Accuracy

Business Team
Validates operational alignment of bin sequencing.

Summary paragraph: If no manual sorting is provided, validation focuses on system auto-generated output from /SCWM/SBST. If manual template is used, validation covers both technical integrity and operational correctness.

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 :

Load Run Sheet

Load Phase and Dependencies

Configuration

Conversion Objects

The load process includes the following steps:

1. Prepare Load File: Format and validate the DCT into the target layout.

2. Execute Load: Use manual upload process to load DCT template

3. Post-Load Validation: Run both technical (record counts, field validation) and business (functional sequencing validation) checks.

Summary paragraph: The run sheet provides step-by-step transparency. Data must be re-extracted after loading to confirm alignment with input files and business expectations.

Configuration

Configuration must be completed in the target system before the bin sorting load can commence.

Summary paragraph: Without prerequisite configuration, bin sorting cannot be loaded. Dependencies include bin master creation and setup of activity areas and warehouse structures.

Error Handling

The table below depicts some possible system errors for this data object during data load. All data load errors must be logged as defects and managed within the Defect Management Process.

Error Handling

Summary paragraph: All errors must be systematically logged, triaged, and resolved via defect management tools. This ensures traceability and accountability across migration cycles.

Post-Load Validation

Project Team

Responsible for technical validation of the loaded dataset.

Accuracy

Business

Completeness

Accuracy

Key Assumptions

Business Team
Responsible for confirming operational validity.

Summary paragraph: Project team validates the technical integrity of loaded data, while the business team ensures operational accuracy and usability. Both dimensions must pass before sign-off.

Key Assumptions

• Bin master data exists in /SCWM/LAGP before bin sorting load.

• Activity types (/SCWM/TACTTY), Activity Areas (/SCWM/TAAREA), Storage Types (/SCWM/T331), and Storage Sections (/SCWM/T302) are fully configured before load.

• Business will provide manual template only if a specific sequence is required; otherwise, /SCWM/SBST will be used.

• Upload/load tools are available and tested prior to execution.

• Data validation rules and governance are agreed and signed off before load execution.

Summary paragraph: These assumptions form the basis of the conversion plan. Any deviation (e.g., missing master data or delayed template delivery) may impact load timelines.

See also

Change log

Workflow history