| Status | |
|---|---|
| Owner | |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
The purpose of this document is to define the conversion approach to create TM-Transportation zones in S/4 HANA TM (Transportation Management).
The transportation zone is a geographical grouping of locations that is used for the purpose of routing. It can be the combination of country, state, postcodes, or individual locations.
The data for transportation zones in S/4 TM would need to be constructed in data collection template (DCT). The existing legacy data would be provided in google sheet for reference.
The scope of this document covers the approach for creating Transportation zones in S/4HANA following the TM Transportation zones Master Data Design Standard. This includes:
The data from legacy system includes:
The data from legacy system excludes:
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
| DCT | Creation of TM Transportation zones An initial extract of the transportation zones will be provided in google sheet format to assist business in decision making on including any relevant data from PF2 and WP2. | TBD | S/4 HANA (TM) | TBD |
Summarize Multi-language Requirement/s, if any
Summarize Document Management requirement, if any
Summarize Legal Requirement/s, if any
Specify any special requirements or considerations that may impact the data conversion process based on specific locations, regulatory compliance or system limitations. Clearly outline any regional or localization requirements such as country-specific data formats, legal reporting obligations or industry standards that must be adhered to (e.g., localization rules for countries like China).
If the data conversion involves third-party systems or external data sources, such as Icertis, describe any additional requirements related to data mapping, transformation logic, validation rules or security measures that must be followed.
The complete information of the key fields that hold the default route information follows the Master Data Standard document.
The technical design of the target for this conversion approach.
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| /SCMB/ZONE | ID_ZONE | MATNR | Transportation Zone Name | CHAR | 20 | Mandatory |
| /SCMB/ZONET | DESCR | Description | CHAR | 40 | Mandatory | |
| /SCMB/ZONET | SPRAS | Language Key 8 languages in scope: English, French, Italian and Mandarin and Brazilian Portuguese, German, Spanish and Thai, as per KDD055 | CHAR | 1 | Mandatory | |
| /SCMB/ZONE | TYPE_ZONE | Zone Type | CHAR | 1 | Mandatory | |
| /SAPAPO/LOC | XPOS | Longitude coordinate | CHAR | 15 | Optional | |
| /SAPAPO/LOC | YPOS | Latitude coordinate | CHAR | 15 | Optional | |
| /SAPAPO/LOC | PRECISID | Precision of a Geo location | CHAR | 4 | Optional | |
| /SAPAPO/LOC | TZONE | Time Zone | CHAR | 6 | Optional | |
| /SAPAPO/LOC | ZPOS | Location Altitude | NUM | 9,3 | Optional | |
| /SAPAPO/LOC | GEO_VALIDITY_END | Validity End of Geo Data | NUM (DATE) | Optional | ||
| /SAPAPO/LOC | MATCH_GC | Percentage of accuracy (coordinates) | NUM | 3 | Optional | |
| /SAPAPO/LOC | GC_LEVEL | Geocoding Level for a Location | NUM | 4 | Optional | |
| /SAPAPO/LOC | STRATEGY | Strategy to determine the coordinates | CHAR | 10 | Optional | |
| SCMB/ZONE_D | ID_LOC_EXT | Location Code | CHAR | 20 | Optional | |
| SCMB/ZONE_D | LOC_TYPE | Location Type | CHAR | 4 | Optional | |
| SCMB/ZONE_P, SCMB/ZONE_R | COUNTRYISO | Country Key | CHAR | 2 | Optional | |
| SCMB/ZONE_P | PCODE_FROM | Postal code_from | CHAR | 10 | Optional | |
| SCMB/ZONE_P | PCODE_TO | Postal code_to | CHAR | 10 | Optional | |
| SCMB/ZONE_R | REGION | Region (State, Province, County) | CHAR | 3 | Optional |
Transportation zone data will be populated directly in the Data Collection Template (DCT).
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 |
|---|---|---|---|---|---|
The high-level process is represented by the diagram below:
Please note that the data may have to be loaded in multiple target systems (US instance, China instance and RoW).

Extract data from a source into Syniti Migrate. There are 2 possibilities:
The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
<Object> DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
List the steps that need to occur before extraction can commence
| Item # | Step Description | Team Responsible |
|---|---|---|
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:
| 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 |
|---|---|---|---|---|---|---|---|---|---|
| Mapping Table Name | Mapping Table Description |
|---|---|
| Item # | Step Description | Team Responsible |
|---|---|---|
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
The load process includes:
| 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
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
| 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) | |
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 |
|---|---|---|
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Any additional key assumptions.
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.