Status
Owner	LEW-ext, Chun Ming
Stakeholders	The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name

Purpose

The purpose of this document is to define the conversion approach for migrating Open Sales Scheduling Agreements (SAs) from legacy systems into SAP S/4HANA. Scheduling Agreements represent long-term agreements with customers with pre-defined delivery schedules. The migration ensures continuity in customer commitments, supply planning, and delivery accuracy post-cutover.

Conversion Scope

The scope of this document includes the identification, extraction, transformation, and loading of Open Sales Scheduling Agreements (SAs) and their associated delivery schedule lines into SAP S/4HANA. The objective is to ensure that ongoing and active customer delivery commitments are maintained post-go-live and that planning and fulfillment processes can continue seamlessly within the new system.

The data from legacy system includes:

Documents where the document category (VBAK-VBTYP) is either
1. "E" Scheduling agreement
2. "F" Scheduling agreement with external service agent
Scheduling Agreement is with:
1. Order items where the delivery status is not marked as complete.
2. Order items with open billing quantity, meaning not fully invoiced.
The Sales Area of the Scheduling Agreement are within the scope of S4 HANA.
Scheduling Agreements is created for the Customers and Materials in scope.
Scheduling Agreement is within validity date.

The data from legacy system excludes:

Fully Delivered and Billed Scheduling Agreement items:
1. Order items where all items are delivered (delivery complete) and invoiced (billing complete).
2. Order items archived in legacy system and no longer used operationally.
Out-of-Scope Sales Document Types or Sales Areas:
1. Document types not in used or excluded by process design (e.g., internal orders, sample/test).
2. Orders belonging to sales organizations, distribution channels, or divisions not part of S/4 scope.

List of source systems and approximate number of records

Source	Scope	Source Approx No. of Records	Target System	Target Approx No. of Records
WP2	Open Scheduling Agreements	XXX	S/4HANA System	XXX
PF2	Open Scheduling Agreements	XXX	S/4HANA System	XXX

Additional Information

Multi-language Requirement

Summarize Multi-language Requirement/s, if any

Document Management

Summarize Document Management requirement, if any

Legal Requirement

Summarize Legal Requirement/s, if any

Special Requirements

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.

Target Design

With Functional input, document the technical design of the target fields that are in the scope of this document.

The technical design of the target for this conversion approach.

Table	Field	Data Element	Field Description	Data Type	Length	Requirement
MARA	MATNR	MATNR	Material Number	CHAR	18	Mandatory

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	Error Message/Report Description	Rule	Source System
9064-001	Sales order open for more than 3 years.	Orders created for more than 3 years ago.	PF2/WP2
9064-002	Missing sold-to data	If the sold-to is marked for deletion	PF2/WP2
9064-003	Missing ship-to data	If the ship-to is marked for deletion	PF2/WP2
9064-004	Missing bill-to data	If the bill-to is marked for deletion	PF2/WP2
9064-005	Missing payer data	If the payer-to is marked for deletion	PF2/WP2
9064-006	Missing material master	If the material master is marked for deletion	PF2/WP

Conversion Process

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

The ETL (Extract, Transform, Load) process is a structured approach to data migration and management, ensuring high-quality data is seamlessly transferred across systems. Here’s a breakdown of its key components:
1. Extraction
The process begins with extracting metadata and raw data from source systems, such as Syensqo ECC system (i.e., WP2/PF2) periodically. The extracted data is then staged for transformation.

2. Transformation
Once extracted, the data undergoes cleansing, consolidation, and governance. This step ensures data integrity, consistency, and compliance with business rules. The transformation process includes:
- Data validation to remove inconsistencies.
- Standardization to align formats across datasets.
- Business rule application to refine data for operational use.

3. Loading
The transformed data is then loaded into the target S4 Hana system.

SyWay Project > CNV-ZZZZ Open Sales Scheduling Agreements with long text with customized fields > image-2025-6-6_10-55-42-1.png

Data Privacy and Sensitivity

Summarize Data Privacy and Sensitivity Requirements, if any

Extraction

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:
1. Perform full data extraction from relevant tables in the source system(s).
2. Perform extraction through the application layer.
3. 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
Extraction Scope Definition	- Identify the source systems and databases involved. - Define the data objects (tables, fields, records) to be extracted. - Establish business rules for data selection.	Synithi
Extraction Methodology	- Specify the extraction approach (full, incremental, or delta extraction). - Determine the tools and technologies used. - Define data filtering criteria to exclude irrelevant records.	Synithi
Extraction Execution Plan	- Establish execution timelines and batch processing schedules. - Assign responsibilities for extraction monitoring. - Document dependencies on other migration tasks.	Synithi
Data Quality and Validation	- Define error handling mechanisms for extraction failures.	Synithi

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
1	Source System Availability Ensure that the source database or application is accessible. Confirm that necessary credentials and permissions are granted	Syensqo IT
2	Data Structure Identify relationships between tables, views, and stored procedures.	Synithi
3	Referential Integrity Ensure dependent records are extracted together.	Synithi
4	Extraction Methodology Define whether extraction is full, incremental, or delta-based. Establish batch processing schedules for large datasets.	Synithi
5	Performance and Scalability Considerations Optimize extraction queries to prevent system overload. Ensure network bandwidth supports data transfer volumes.	Synithi
6	Security and Compliance Adhere to regulatory standards for sensitive information if applicable	Synithi

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.
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
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
1	Transformation Scope Definition - Identify the source and target data structures. - Define business rules for data standardization. - Establish data cleansing requirements to remove inconsistencies.	Data Team
2	Data Mapping and Standardization - Align source fields with target fields. - Ensure unit consistency (e.g., currency, measurement units)	Data Team
3	Business Rule Application - Implement data enrichment/collection if applicable - Apply conditional transformations based on predefined logic/business rules	Data Team
4	Transformation Execution Plan - Define batch processing schedules. - Assign responsibilities for monitoring execution. - Establish error-handling mechanisms	Synithi

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
MAP_ZTERM	Payment term Mapping
MAP_PARVW	Partner function Mapping
MAP_INCO1	Incoterm1 Mapping
MAP_VKORG	Sales Organization Mapping
MAP_VTWEG	Distribution Channel Mapping
MAP_TDID	Text ID Mapping
MAP_VRKME	Unit of Measure
MAP_WERKS	Plant
MAP_SPART	Division

Transformation Dependencies

List the steps that need to occur before transformation can commence

Item #	Step Description	Team Responsible
1	Source Data Integrity - Ensure extracted data is complete, accurate, and consistent. - Validate that data types and formats align with transformation requirements.	Synithi
2	Referential Integrity - Ensure dependent records are transformed together or in advance	Synithi
3	Transformation Logic and Mapping - Define data mapping rules between source and target schemas.	Data Team
4	Performance and Scalability Considerations - Optimize transformation processes for large datasets. - Ensure system resources can handle transformation workloads	Synithi
5	Logging and Error Handling - Maintain detailed logs of transformation activities. - Define error-handling procedures for failed transformations	Synithi

Pre-Load Validation

Project Team

The following pre-load validations will be performed by the Project Team.

Completeness

Task

Action

Validate mandatory and key fields

Mandatory field check.
Based on S/4HANA target design fields, sales order type configuration, item category determination and schedule line category.

Check if records have all mandatory fields filled and mapped (e.g. Sales Document Type, Sales Organization, Distribution Channel, Division, Sold-to Party, Ship-to Party, Material, Quantity, Requested Delivery Date, Pricing Conditions, etc.).
Records missing any mandatory fields must be flagged as error.

Check Business Partners Master Data

Verify that Sold-to Party, Ship-to Party, Bill-to Party, and Payer exist as Business Partners in S/4HANA (tables: BUT000, KNA1, KNVV).
Ensure the BP is extended to the required Sales Organization, Distribution Channel, and Division.
Check BP deletion flags: KNVV-LOEVM (Deletion flag for sales area data) must not be set.

Check Material Master Data

Confirm that Material Numbers exist in S/4HANA Material Master (MARA, MVKE and MARC).
Validate that materials are extended to relevant Sales Org and Distribution Channel.
Check that the material is not flagged for deletion (MARA-LVORM must not be set).

Check Sales Order Item Consistency

Validate item category and schedule line category are mapped accordingly
Ensure quantity fields are populated and non-zero.
Check schedule lines have valid requested delivery dates.

Check Currency and Pricing Data

Validate pricing conditions are correctly mapped and exist in condition master data.
Check currency fields: Sales Order currency and pricing currency must be populated and valid (against TCURC / currency customizing).
Ensure that net values and tax amounts are correctly calculated and populated.

Reconciliation check

Record Count

Check that the total number of open sales order records in the load file matches the source system.
The record count will be reconciled on a group basis. The grouping fields are:
- Sales Organization
- Sales Document Type
- Sold-to Party
- Sales Document Number
Any mismatch in record count between source and load file must be flagged for investigation.

Check Amount in Document Currency and Local Currency

Sum the total Net Value (Document Currency) for Sales Orders in the load file and compare with the total from the source system.
Sum the Tax (Document Currency) for Sales Orders in the load file and compare with the total from the source system.
Any difference in sum between source and load file must be flagged as an error.

Check Total Quantity

Sum the ordered quantity matching with open quantities in the source system.
If there is a UOM changes, the quantity must be converted with the correct conversion rate.
Compare aggregated quantities per Material and Sales Organization to ensure data consistency.
Any mismatches must be flagged for investigation.

Accuracy

Task	Action
Validate the transformation	Make sure all fields with transformation are populated with S/4 HANA values according to the mapping file.
Check Data Consistency	Sold-to Party Verify that the Sold-to Party (Customer Number) in the pre-load file matches the corresponding value in the legacy system. Validate customer master mapping if applicable. Ship-to Party Verify that the Ship-to Party in the pre-load file matches the corresponding value in the legacy system. Validate partner function assignments if applicable. Customer PO Date Verify that the Customer Purchase Order Date (VBAK-BSTDK) matches between legacy system and pre-load file. Pricing Validate that key pricing condition values (e.g. base price, discounts, surcharges) are consistent between legacy system and pre-load file. Compare condition type values (e.g. KONV-KBETR) where feasible. Number of Line Items Verify that the total number of open line items per sales order matches between legacy system and pre-load file. Open Quantities Validate that open quantities (Ordered Quantity minus Delivered Quantity) match between legacy system and pre-load file.

Business

The following pre-load validations will be performed by the business.

Completeness

Task

Action

Conversion check

In legacy system, execute report Open Sales Orders List (e.g. via transaction code VA35 or equivalent custom report).

Group the output of the report by Sales Organization and Sold-to Party using the subtotal function and compare the count in this report against the Open Sales Orders count in the pre-load file.

The record count for Open Scheduling Agreements may also be done at a more granular level. The recommended granular level or subtotal fields can consist of:

Sales Organization
Sales Document Type
Sold-to Party
Material Number

If any of the count is different, raise a defect and flag the relevant record as error.

Accuracy

Task

Action

Key fields check

Perform the following checks on a selected sample of open sales orders:

Total Net Value Check
- Compare the total Net Value (VBAK-NETWR) per Sales Organization and Sold-to Party between legacy system and pre-load file.
Total Tax Amount Check
- Compare the total Tax Amount (if applicable, e.g. from pricing conditions or summarized tax amount) between legacy system and pre-load file.
Material Number and Open Quantity Check
- For each Sales Order Item (VBAP):
  - Verify that Material Numbers match between legacy system and pre-load file.
  - Verify that Open Quantities (Ordered Quantity minus Delivered Quantity) are accurate.

Validate the transformation

Make sure all fields with transformation are populated with S/4 HANA values according to the mapping file.

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
1	Load Scope Definition - Identify the target system and database structure. - Define data objects (tables, fields, records) to be loaded. - Establish business rules for data validation.	Data team
2	Load Methodology - Specify the loading tools and technologies (Migration Cockpit, LSMW, custom loading program).	Synithi
3	Data Quality and Validation - Ensure data integrity checks (null values, duplicates, format validation). - Perform pre-load validations to verify completeness. - Define error handling mechanisms for load failures	Synithi
4	Load Execution Plan - Establish execution timelines and batch processing schedules. - Assign responsibilities for monitoring execution. - Document dependencies on other migration tasks	Synithi
5	Logging and Reporting - Maintain detailed logs of loading activities. - Generate summary reports on loaded data volume and quality. - Define escalation procedures for errors	Synithi

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
1	Order type
2	Item categories
3	Schedule lines categories
4	Pricing procedure
5	Number range settings for orders

Conversion Objects

Object #	Preceding Object Conversion Approach
1	Business Partner
2	Material Mater
3	Price condition
4	Output condition

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
Configuration / Data Transformation	The value XXX for field XXX doesn't exist	Check the mapping/conversion is done properly in the loading file Validate the target value is configured/transported in the target system Reach out to function team to validate the configuration
Configuration	There is mandatory field XXX missing	Validate MDS if the fields are set as mandatory Validate if there is value in the pre-loading file Validate if the configuration for the mandatory fields are done properly

Post-Load Validation

Project Team

The following post-load validations will be performed by the Project Team.

Completeness

Task

Action

Validate Record count

Total number of records loaded for Open Sales Orders will be generated in the post-load reports in the tool based on the target tables and fields mentioned in section target design.

The reconciliation needs to be executed on the total number of 'valid' records and amounts per Sales Organization in the source compared to total number of records and amounts in S/4HANA.

Record Count

Check that the total record count of Open Sales Orders in the pre-load file matches the number of records loaded into S/4HANA.
The record count will be validated on a group basis. The recommended grouping fields are:
- Sales Organization
- Sold-to Party
- Sales Document Type
Any mismatch in record count between pre-load file and S/4HANA must be flagged for investigation.

Check Amount in Document Currency and Local Currency

At the line item level, sum the Net Value amounts in both Document Currency and Local Currency from the pre-load file and compare to the values posted in S/4HANA.
Any mismatches in totals must be flagged as errors for investigation.

Accuracy

Task	Action
Validate Key Fields	Post-load reports will have the same structure as the Open Scheduling Agreements load file, with additional columns as required to support post-load validation. Utilize the migration tool to generate a Post-Load Report that displays S/4HANA loaded records alongside the corresponding legacy system values. This side-by-side comparison will enable a 100% field-level validation of all key fields in the shortest possible time. Key fields for comparison include (but are not limited to): Sales Document Number Sales Document Type Sales Organization Sold-to Party Ship-to Party Customer PO Number and PO Date Material Number Ordered Quantity and Open Quantity Pricing values (Net Value, Tax, Conditions) Document Currency and Local Currency amounts Any mismatches identified will be captured in the Post Load - Error Report for further investigation and resolution.

Business

Post-load validation is a critical step in data migration, ensuring that transferred data is accurate, complete, and functional within the target system.

1. Ensuring Data Integrity
After migration, data must be consistent with its original structure. Post-load validation checks for missing records, incorrect mappings, and formatting errors to prevent discrepancies.
2. Business Continuity
Faulty data can disrupt operations, leading to financial losses and inefficiencies. Validating post-load data ensures that applications function as expected, preventing downtime.
3. Error Detection and Resolution
By validating data post-migration, businesses can detect anomalies early, reducing the cost and effort required for corrections

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
Display Records	Pick up few random sales document number numbers, display with Tcode VA33 and validate the details

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.

Purpose

Conversion Scope

Additional Information

Multi-language Requirement

Document Management

Legal Requirement

Special Requirements

Target Design

Data Cleansing

Conversion Process

Data Privacy and Sensitivity

Extraction

Extraction Run Sheet

Selection Screen

Data Collection Template (DCT)

Extraction Dependencies

Transformation

Transformation Run Sheet

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Load

Load Run Sheet

Configuration

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Key Assumptions

See also

Change log

Workflow history