You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Status

  In Progress

Owner

LEW-ext, Chun Ming 

Stakeholders

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:

  1. Documents where the document category (VBAK-VBTYP) is either
    1. "E" Scheduling agreement
    2. "F" Scheduling agreement with external service agent
  2. 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.
  3. The Sales Area of the Scheduling Agreement are within the scope of S4 HANA. 
  4. Scheduling Agreements is created for the Customers and Materials in scope.
  5. Scheduling Agreement is within validity date.

The data from legacy system excludes:

  1. 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.
  2. 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
SourceScope

Source Approx No. of Records

Target SystemTarget 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

Document Management

Legal Requirement

Special Requirements




Target Design

The technical design of the target for this conversion approach.

TableFieldData ElementField DescriptionData TypeLengthRequirement






















Data Cleansing

IDCriticalityError Message/Report DescriptionRuleOutputSource 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 dataIf the sold-to is marked for deletion
PF2/WP2
9064-003
Missing ship-to dataIf the ship-to is marked for deletion
PF2/WP2
9064-004
Missing bill-to dataIf the bill-to is marked for deletion
PF2/WP2
9064-005
Missing payer dataIf the payer-to is marked for deletion
PF2/WP2
9064-006
Missing material masterIf 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. 


Data Privacy and Sensitivity


Extraction

Extract data from a source into Syniti Migrate. There are 2 possibilities:

  1. 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.
  2. 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 DescriptionTeam 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

Selection Ref ScreenParameter NameSelection TypeRequirementValue to be entered/set





















Data Collection Template (DCT)

Target Ready Data Collection Template will be created for data with exception of some fields which require transformation as mentioned in the transformation rule.

DCT Rules

Field NameField DescriptionRule












Extraction Dependencies

Item #Step DescriptionTeam 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:

  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 Run Sheet

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


Transformation Rules

Rule #Source systemSource TableSource FieldSource DescriptionTarget SystemTarget TableTarget FieldTarget DescriptionTransformation Logic









































Transformation Mapping

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


Pre-Load Validation

Project Team

Completeness

TaskAction

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

TaskAction
Validate the transformationMake sure all fields with transformation are populated with S/4 HANA values according to the mapping file. 
Check Data Consistency

  1. 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.

  2. 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.

  3. Customer PO Date

    • Verify that the Customer Purchase Order Date (VBAK-BSTDK) matches between legacy system and pre-load file.

  4. 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.

  5. Number of Line Items

    • Verify that the total number of open line items per sales order matches between legacy system and pre-load file.

  6. Open Quantities

    • Validate that open quantities (Ordered Quantity minus Delivered Quantity) match between legacy system and pre-load file.




Business

Completeness

TaskAction
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

TaskAction
Key fields check

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

  1. 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.

  2. 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.

  3. 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 transformationMake sure all fields with transformation are populated with S/4 HANA values according to the mapping file. 



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

Load Run Sheet

Item #Step DescriptionTeam Responsible
1Load 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
2Load Methodology
- Specify the loading tools and technologies (Migration Cockpit, LSMW, custom loading program).		Synithi
3Data 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
4Load Execution Plan
- Establish execution timelines and batch processing schedules.
- Assign responsibilities for monitoring execution.
- Document dependencies on other migration tasks		Synithi
5Logging 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

Configuration

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

Error TypeError DescriptionAction Taken
Configuration / Data TransformationThe value XXX for field XXX doesn't exist
  1. Check the mapping/conversion is done properly in the loading file
  2. Validate the target value is configured/transported in the target system
  3. Reach out to function team to validate the configuration
ConfigurationThere is mandatory field XXX missing
  1. Validate MDS if the fields are set as mandatory
  2. Validate if there is value in the pre-loading file
  3. Validate if the configuration for the mandatory fields are done properly




Post-Load Validation

Project Team

Completeness

TaskAction

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

TaskAction
Validate Key Fields

  1. 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.

  2. 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.

  3. Key fields for comparison include (but are not limited to):

    1. Sales Document Number

    2. Sales Document Type

    3. Sales Organization

    4. Sold-to Party

    5. Ship-to Party

    6. Customer PO Number and PO Date

    7. Material Number

    8. Ordered Quantity and Open Quantity

    9. Pricing values (Net Value, Tax, Conditions)

    10. Document Currency and Local Currency amounts

  4. 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

TaskAction





Accuracy

TaskAction

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.
  • is in scope based on data design and any exception requested by business.


See also

Change log

Version Published Changed By Comment
CURRENT (v. 5) Dec 08, 2025 10:12 LEW-ext, Chun Ming
v. 6 Nov 24, 2025 12:32 LEW-ext, Chun Ming
v. 5 Sept 28, 2025 11:59 LEW-ext, Chun Ming
v. 4 Sept 23, 2025 07:45 LEW-ext, Chun Ming
v. 3 Sept 23, 2025 07:41 LEW-ext, Chun Ming
v. 2 Jun 17, 2025 09:11 LEW-ext, Chun Ming
v. 1 Jun 17, 2025 07:57 LEW-ext, Chun Ming

Workflow history

Title Last Updated By Updated Status  
There are no pages at the moment.

  • No labels