| Status | |
|---|---|
| Owner | RAYUDU-ext, Narasimha Kumar |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
Purpose
The purpose of this conversion is to migrate and create Extended Warehouse Management (EWM) Product Master data in the S/4HANA EWM environment.
The EWM Product Master is an extension of the Material Master, providing warehouse-specific attributes that enable and control warehouse functionality and processes such as putaway, stock removal, replenishment, and physical inventory.
This conversion ensures that each product (material) within the warehouse has a corresponding EWM product master record, containing all relevant attributes aligned with the warehouse organization structure.
Conversion Scope
The scope of this conversion includes the creation of EWM Product Master data in S/4HANA, derived from existing Material Master and WM-related configuration and data in the legacy ECC system.
Because legacy EWM Product Master data does not exist, the conversion is not a one-to-one migration but rather a data derivation and enrichment process. The data will be constructed based on material master attributes and warehouse-specific logic defined during EWM design.
In Scope
Creation of EWM Product Master records for all materials that are in scope for warehouse operations in S/4HANA.
Population of key EWM product attributes including:
Warehouse Number
Putaway and Stock Removal Control Indicators
Storage Type Indicators
Handling Unit Type Assignments (where relevant)
Consolidation Group and Availability Group
Packaging Data and Unit of Measure Information
Product Grouping for Replenishment or Slotting (if applicable)
Alignment of EWM Product Master data with S/4HANA Material Master and EWM design configurations.
Upload of EWM Product Master data via standard EWM transaction
/SCWM/MIG_PRODUCTor approved migration cockpit object.
Out of Scope
Non-warehouse relevant materials.
Any historical WM data or warehouse task information.
Changes to core Material Master data (MARA/MARC) — this will be maintained separately under the Material Master conversion.
Additional Information
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.
| Index | Technical Table-Field | Field Label | Description | Field Format | Allowed Values / Reference | Conditional Logic | Multi-language Field Requirements | Comments / Special Handling Notes | Requirement (R/O/C/S/NU) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | /SAPAPO/MATLWH-MATID | Product ID | Product identifier within EWM | CHAR(22) | None | None | None | Derived from MARA-MATNR | R |
| 2 | /SAPAPO/MATLWH-ENTITLED_ID | Party Entitled to Dispose | Party responsible for stock ownership | RAW(16) | None | None | None | Linked to business partner data | R |
| 3 | /SAPAPO/MATLWH-SCUGUID | Supply Chain Unit | Supply chain unit relevant to warehouse | RAW(16) | None | None | None | Represents warehouse number | R |
| 4 | /SAPAPO/MATLWH-PTDETIND | Process Type Determination Indicator | Controls process type determination for product | CHAR(2) | /SCWM/TPTDETIND-PTDETIND | None | None | Drives task creation behavior | C |
| 5 | /SAPAPO/MATLWH-CCIND | Cycle Counting Indicator | Defines product classification for inventory counting | CHAR(1) | MARC-ABCIN | None | None | Maps ABC indicator to EWM | C |
| 6 | /SAPAPO/MATLWH-PUT_STRA | Putaway Control Indicator | Controls product putaway strategy | CHAR(4) | /SCWM/T305Q-PUT_STRA | None | None | Required for inbound processing | R |
| 7 | /SAPAPO/MATLWH-LGBKZ | Storage Section Indicator | Defines section search strategy | CHAR(4) | /SCWM/T304-LGBKZ | None | None | Used for bin search logic | C |
| 8 | /SAPAPO/MATLWH-LPTYP | Storage Bin Type | Defines type/classification of storage bin | CHAR(4) | /SCWM/T303-LPTYP | None | None | Impacts putaway and removal rules | C |
| 9 | /SAPAPO/MATLWH-BLOCK | Bulk Storage Indicator | Controls bulk storage putaway | CHAR(2) | /SCWM/T338-BLOCK | None | None | Used for bulk materials | C |
| 10 | /SAPAPO/MATLWH-REM_STRA | Stock Removal Control | Controls stock removal strategy | CHAR(4) | /SCWM/T305R-REM_STRA | None | None | Required for picking logic | R |
| 11 | /SAPAPO/MATLWH-STCKDETGR | Stock Determination Group | Determines stock group for picking | CHAR(2) | /SCWM/V_STCKDTGR-STCKDETGR | None | None | Used for batch-managed materials | C |
| 12 | /SAPAPO/MATLWH-DRDETGR | Staging Area Determination Group | Defines staging area determination | CHAR(4) | /SCWM/TDRDETGR-DRDETGR | None | None | Used for outbound staging | C |
| 13 | /SAPAPO/MATLWHST-LGTYTP | Storage Type | Storage space within warehouse | CHAR(4) | /SCWM/T331-LGTYP | None | None | Level-specific configuration | C |
| 14 | /SAPAPO/MATLWHST-SECTIND | Section Indicator | Section indicator at storage type level | CHAR(4) | /SCWM/T304-LGBKZ | None | None | Used for fine-tuning putaway | C |
| 15 | /SAPAPO/MATLWHST-BINTYPE | Bin Type | Bin type assignment for product | CHAR(4) | /SCWM/T303-LPTYP | None | None | Impacts replenishment logic | C |
| 16 | /SAPAPO/MATLWHST-REPQTY_DSP | Minimum Replenishment Qty | Minimum quantity for replenishment trigger | QUAN(15) | None | None | None | Maintained based on planning data | C |
| 17 | /SAPAPO/MATLWHST-REPQTY_UOM_DSP | Display UoM for Replenishment Qty | Unit of measure for replenishment quantity | UNIT(3) | MEINS | None | None | UoM from material master | C |
| 18 | /SAPAPO/MATLWHST-MINQTY_DSP | Minimum Qty | Minimum stock level in storage type | QUAN(15) | None | None | None | Used for replenishment logic | C |
| 19 | /SAPAPO/MATLWHST-MINQTY_UOM_DSP | Display UoM for Minimum Qty | UoM for minimum stock | UNIT(3) | MEINS | None | None | Derived from base UoM | C |
| 20 | /SAPAPO/MATLWHST-MAXQTY_DSP | Maximum Qty | Maximum allowed stock in storage type | QUAN(15) | None | None | None | Used for replenishment ceiling | C |
| 21 | /SAPAPO/MATLWHST-MAXQTY_UOM_DSP | Display UoM for Maximum Qty | UoM for maximum stock | UNIT(3) | MEINS | None | None | Derived from base UoM | C |
| 22 | /SAPAPO/MATLWHST-QUANCLA | Quantity Classification | Classification for stock quantity | CHAR(1) | /SCWM/TQUANCLA-QUANCLA | None | None | Used for volume optimization | C |
| 23 | /SAPAPO/MATLWHST-QUANCLAPUT | Quantity Classification (Putaway) | Classification for putaway quantity | CHAR(1) | /SCWM/TQUANCLA-QUANCLA | None | None | Impacts putaway bin search | C |
Data Cleansing
All data cleansing should take place in the data source system as defined in this document, unless system limitations prevent it.
If data cleansing is managed outside of the source system (e.g. Syniti Migrate, 3rd Party Vendor, DCT), the necessary documentation must be produced and appended to this deliverable for sign-off.
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
Conversion Process
The high-level process is represented by the diagram below:
Summarize High-Level Process. Include diagrams, where applicable. Include information supporting details of Extract, Transform and Load specific to the Data Object
Data Privacy and Sensitivity
Summarize Data Privacy and Sensitivity Requirements, if anyExtraction
Extract data from a source into Syniti Migrate. There are 2 possibilities:
- The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
- Perform full data extraction from relevant tables in the source system(s).
- Perform extraction through the application layer.
- Only if Syniti Migrate; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
- 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
Extraction Run Sheet
| Req # | Requirement Description | Team Responsible |
|---|---|---|
Selection Screen
If applicable, this section will give the details on any selection screen parameters, including the parameter type, that are required to be entered to ensure consistent data extracts.| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
Data Collection Template (DCT)
Target Ready Data Collection Template will be created for Data Object data with exception of some fields which require transformation as mentioned in the transformation rule.<Object> DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
Extraction Dependencies
List the steps that need to occur before extraction can commence
| Item # | Step Description | Team Responsible |
|---|---|---|
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 Syniti Migrate to make the data Target ready:
- Perform value mapping and data transformation rules.
- Legacy values are mapped to the to-be values (this could include a default value)
- Values are transformed according to the rules defined in Syniti Migrate
- 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
| Item # | Step Description | Team Responsible |
|---|---|---|
Transformation Rules
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
Transformation Mapping
Use the exact name and reference this section in the “Transformation rules” above| Mapping Table Name | Mapping Table Description |
|---|---|
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
Pre-Load Validation
Project Team
The following pre-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Business
The following pre-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Load
The load process includes:
- Execute the automated data load into target system using load tool or product the load file if the load must be done manually
- Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation
Load Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
Load Phase and Dependencies
Identify the phase as to “when” the load for this object will occur. <Pre-Cutover, Cutover, Post Cutover> and list the steps that need to occur before the load can commence
Configuration
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| list the exact title of the conversion object of only the immediate predecessor – this will then confirm the DDD (Data Dependency Diagram) | |
Error Handling
The table below depicts some possible system errors for this data object during data load. All data load error is to be logged as defect and managed within the Defect Management
| Error Type | Error Description | Action Taken |
|---|---|---|
Post-Load Validation
Project Team
The following post-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Business
The following post-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
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.
Any additional key assumptions.
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.