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

Compare with Current View Page History

« Previous Version 8 Next »

Status

  Revision in Progress

Owner
Stakeholders

Purpose

The purpose of this document is to define the conversion approach to create Open Sales Order in S/4 HANA.

Open sales orders are orders that are not fully delivered or billed and still require fulfillment or financial processing. This conversion ensures business continuity and data consistency for ongoing customer transactions. It should be a seamless migration, and business is able to continue working with open Sales Order in S/4 HANA.


Conversion Scope

The scope of this document covers the approach for converting Open Sales Orders, including relevant schedule lines and partner data, from legacy source systems into SAP S/4HANA.

From the current system landscape, open sales order data resides separately across legacy systems (WP2 and PF2), often with inconsistent formatting, incomplete references, and varying document structures. It is required to harmonize, cleanse, and validate the sales order data to ensure that only business-relevant, open orders are migrated to S/4HANA.

While WP2 and PF2 serve as the primary source systems, various transformation and mapping logic will be applied to generate load templates that conform to the target S/4HANA order structure, including header, item, schedule line, pricing, and partner functions. The conversion scope specifically includes orders that are not fully delivered or billed, with open quantities, future delivery dates, or billing schedules, and which remain critical to business continuity post go-live.

The data from legacy system includes:

  1. The Sales Area of the Sales Orders are within the scope of S4 HANA
  2. Sales Orders with Open Quantities:
    1. Orders with undelivered items, i.e., delivery quantity < order quantity.
    2. Orders where the delivery status is not marked as complete.
    3. Orders with open billing quantity, meaning not fully invoiced.
  3. Special Sales Documents Still in Processing: XXX to be decided. Ideally all CN, DN and return should be closed in legacy.  
    1. Return orders or debit / credit memo requests not yet fully processed.
    2. Partial deliveries or partial credit documents awaiting completion.

The data from legacy system excludes:

  1. Fully Delivered and Billed Sales Orders:
    1. Orders where all items are delivered (delivery complete) and invoiced (billing complete).
    2. Orders archived in legacy system and no longer used operationally.
  2. Rejected or Cancelled Orders:
    1. Sales orders where header or item status indicates cancellation or rejection.
    2. Orders marked with final rejection reason codes.
  3. Out-of-Scope Sales Document Types or Sales Areas:
    1. Document types not in use 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.
  4. Orders Without Business or Legal Justification:
    1. Orders with no meaningful transactional history, or created erroneously.
    2. Orders flagged by business for exclusion due to redundancy.


List of source systems and approximate number of records
SourceScope (Legacy Scenario)

Supplying Entity Target System

Receiving Entity Target System

Source Approx No. of Records

Target SystemTarget Approx

No. of Records

WP2

Standard Open Sales Orders

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW

 XXX

PF2

Standard Open Sales Orders

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW

 XXX

WP2

Standard Open Sales Orders

S/4HANA China

S/4HANA China

 XXX

S/4HANA China

 XXX

PF2

Standard Open Sales Orders

S/4HANA China

S/4HANA China

 XXX

S/4HANA China

 XXX

WP2

Standard Open Sales Orders

S/4HANA CUI

S/4HANA CUI

 XXX

S/4HANA CUI

 

PF2

Standard Open Sales Orders

S/4HANA CUI

S/4HANA CUI

 XXX

S/4HANA CUI

 

WP2

Direct Delivery Open Sales Orders

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW

 XXX

PF2

Direct Delivery Open Sales Orders

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW

 XXX

WP2

Direct Delivery Open Sales Orders

S/4HANA China

S/4HANA China

 XXX

S/4HANA China

 XXX

PF2

Direct Delivery Open Sales Orders

S/4HANA China

S/4HANA China

 XXX

S/4HANA China

 XXX

WP2

Direct Delivery Open Sales Orders

S/4HANA CUI

S/4HANA CUI

 XXX

S/4HANA CUI

 

PF2

Direct Delivery Open Sales Orders

S/4HANA CUI

S/4HANA CUI

 XXX

S/4HANA CUI

 

WP2

Direct Delivery Open Sales Orders

S/4HANA ROW

S/4HANA China

 XXX

S/4HANA ROW - IC SO

S/4HANA China - Customer SO

 

PF2

Direct Delivery Open Sales Orders

S/4HANA ROW

S/4HANA China

 XXX

S/4HANA ROW - IC SO

S/4HANA China - Customer SO

 

PF2

Direct Delivery Open Sales Orders

S/4HANA ROW

S/4HANA CUI

 XXX

S/4HANA ROW - IC SO

S/4HANA CUI - Customer SO

 

WP2

Direct Delivery Open Sales Orders

S/4HANA ROW

S/4HANA CUI

 XXX

S/4HANA ROW - IC SO

S/4HANA CUI - Customer SO

 

WP2

Direct Delivery Open Sales Orders

S/4HANA China

S/4HANA ROW

 XXX

S/4HANA China - IC SO

S/4HANA ROW - Customer SO

 

PF2

Direct Delivery Open Sales Orders

S/4HANA China

S/4HANA ROW

 XXX

S/4HANA China - IC SO

S/4HANA ROW - Customer SO

 

WP2

Direct Delivery Open Sales Orders

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA China - IC SO

S/4HANA CUI - Customer SO

 

PF2

Direct Delivery Open Sales Orders

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA China - IC SO

S/4HANA CUI - Customer SO

 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW - STO, Out of Scope

 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW - STO, Out of Scope

 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA China

S/4HANA China

 XXX

S/4HANA China -  STO, Out of Scope

 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANA China

S/4HANA China

 XXX

S/4HANA China -  STO, Out of Scope

 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA CUI

S/4HANA CUI

 XXX

S/4HANA CUI -  STO, Out of Scope

 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANACUI

S/4HANA CUI

 XXX

S/4HANA CUI -  STO, Out of Scope

 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA ROW

S/4HANA China

 XXX

S/4HANA ROW - IC SO


 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANA ROW

S/4HANA China

 XXX

S/4HANA ROW - IC SO


 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA ROW

S/4HANA CUI

 XXX

S/4HANA ROW - IC SO


 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANA ROW

S/4HANA CUI

 XXX

S/4HANA ROW - IC SO


 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA China

S/4HANA ROW

 XXX

S/4HANA China - IC SO

 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANA China

S/4HANA ROW

 XXX

S/4HANA China - IC SO

 

WP2

PF2

WP2 IC Purchase Order

PF2 IC Sales Order

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA China - IC SO

 

WP2

PF2

PF2 IC Purchase Order

WP2 IC Sales Order

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA China - IC SO

 

WP2


WP2 STO

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW - STO, Out of Scope

 

PF2


PF2 STO

S/4HANA ROW

S/4HANA ROW

 XXX

S/4HANA ROW - STO, Out of Scope

 

WP2


WP2 STO

S/4HANA China

S/4HANA China

 XXX

S/4HANA China -  STO, Out of Scope

 

PF2


PF2 STO

S/4HANA China

S/4HANA China

 XXX

S/4HANA China -  STO, Out of Scope

 

WP2


WP2 STO

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA CUI -  STO, Out of Scope

 

PF2


PF2 STO

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA CUI -  STO, Out of Scope

 

WP2


WP2 STO

S/4HANA ROW

S/4HANA China

 XXX

S/4HANA ROW - IC SO


 

PF2


PF2 STO

S/4HANA ROW

S/4HANA China

 XXX

S/4HANA ROW - IC SO


 

WP2


WP2 STO

S/4HANA ROW

S/4HANA CUI

 XXX

S/4HANA ROW - IC SO


 

PF2


PF2 STO

S/4HANA ROW

S/4HANA CUI

 XXX

S/4HANA ROW - IC SO


 

WP2


WP2 STO

S/4HANA China

S/4HANA ROW

 XXX

S/4HANA China - IC SO

 

PF2


PF2 STO

S/4HANA China

S/4HANA ROW

 XXX

S/4HANA China - IC SO

 

WP2


WP2 STO

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA China - IC SO

 

PF2


PF2 STO

S/4HANA China

S/4HANA CUI

 XXX

S/4HANA China - IC SO

 

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
S_VBAKVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBAKAUARTAUARTSales Document TypeText80    mandatory for sheet
S_VBAKVKORGVKORGSales OrganizationText80    mandatory for sheet
S_VBAKVTWEGVTWEGDistribution ChannelText80    mandatory for sheet
S_VBAKSPARTSPARTDivisionText80    mandatory for sheet
S_VBAKVKBURVKBURSales OfficeText80    
S_VBAKVKGRPVKGRPSales GroupText80    
S_VBAKBSTNKBSTNKCustomer Purchase Order NumberText35    
S_VBAKVDATUVDATURequested Delivery DateDate
mandatory for sheet
S_VBAKBSTDKBSTDKCustomer Purchase Order DateDate

S_VBAKFAKSKFAKSKBilling Block in SD DocumentText80    
S_VBAKAUGRUAUGRUOrder ReasonText80    
S_VBAKPRICE_DATEPRICE_DATEPricing DateDate

S_VBAKEXCHG_RATEEXCHG_RATEExchange Rate for Price Det.Number9     
S_VBAKAUDATAUDATDocument DateDate

S_VBAKINCOVINCOVIncoterms VersionText80    
S_VBAKINCO1INCO1Incoterms (Part 1)Text80    
S_VBAKINCO2_LINCO2_LIncoterms Location 1Text70    
S_VBAKINCO2INCO2Incoterms (Part 2)Text28    
S_VBAKINCO3_LINCO3_LIncoterms Location 2Text70    
S_VBAKZTERMZTERMTerms of Payment KeyText80    
S_VBAKBILL_SCHEDBILL_SCHEDInvoicing DatesText80    
S_VBAKWBS_ELEMWBS_ELEMWBS ElementText80    
S_VBAKNAMENAMENameText35    
S_VBAKTELEPHONETELEPHONETelephoneText16    
S_VBAKKVGR1KVGR1Customer Group 1Text80    
S_VBAKKVGR2KVGR2Customer Group 2Text80    
S_VBAKKVGR3KVGR3Customer Group 3Text80    
S_VBAKKVGR4KVGR4Customer Group 4Text80    
S_VBAKKVGR5KVGR5Customer Group 5Text80    
S_VBAKCOND_HANDLECOND_HANDLESwitch for Condition Lines HandlingText1     
S_VBAK_CONDVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBAK_CONDKSCHLKSCHLCondition TypeText80    mandatory for sheet
S_VBAK_CONDKBETRKBETRAmountNumber31    
S_VBAK_CONDKONWAKONWACondition Unit (Currency or Percentage)Text80    
S_VBAK_CONDKPEINKPEINCondition Pricing UnitNumber5     
S_VBAK_CONDKMEINKMEINCondition Unit of MeasureText80    
S_VBAK_TEXTVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBAK_TEXTTDIDTDIDText IDText80    mandatory for sheet
S_VBAK_TEXTTDSPRASTDSPRASLanguage KeyText80    mandatory for sheet
S_VBAK_TEXTTEXTLINETEXTLINETextTextunrestrictedmandatory for sheet
S_VBAPVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBAPPOSNRPOSNRSales Document ItemNumber6     mandatory for sheet
S_VBAPHG_LV_ITEMHG_LV_ITEMHigher-Level Item in Bill of MaterialNumber6     
S_VBAPPOSEXPOSEXExternal Item NumberText6     
S_VBAPMATNRMATNRProduct NumberText80    mandatory for sheet
S_VBAPZIEMEZIEMESales UnitText80    
S_VBAPUMZIZUMZIZNumerator Conversion to Base UnitNumber5     
S_VBAPUMZINUMZINDenominator Conversion to Base UnitNumber5     
S_VBAPCHARGCHARGBatch NumberText10    
S_VBAPWERKSWERKSPlantText80    
S_VBAPLGORTLGORTStorage LocationText80    
S_VBAPPSTYVPSTYVSales Document Item CategoryText80    
S_VBAPSHORT_TEXTSHORT_TEXTItem DescriptionText40    
S_VBAPINCOVINCOVIncoterms VersionText80    
S_VBAPINCO1INCO1Incoterms (Part 1)Text80    
S_VBAPINCO2_LINCO2_LIncoterms Location 1Text70    
S_VBAPINCO2INCO2Incoterms (Part 2)Text28    
S_VBAPINCO3_LINCO3_LIncoterms Location 2Text70    
S_VBAPZTERMZTERMTerms of Payment KeyText80    
S_VBAPKOKRSKOKRSControlling AreaText80    
S_VBAPPROFIT_CTRPROFIT_CTRProfit CenterText80    
S_VBAPWBS_ELEMWBS_ELEMWBS ElementText80    
S_VBAP_CONDVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBAP_CONDPOSNRPOSNRSales Document ItemNumber6     mandatory for sheet
S_VBAP_CONDKSCHLKSCHLCondition TypeText80    mandatory for sheet
S_VBAP_CONDKBETRKBETRAmountNumber31    
S_VBAP_CONDKONWAKONWACondition Unit (Currency or Percentage)Text80    
S_VBAP_CONDKPEINKPEINCondition Pricing UnitNumber5     
S_VBAP_CONDKMEINKMEINCondition Unit of MeasureText80    
S_VBAP_TEXTVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBAP_TEXTPOSNRPOSNRSales Document ItemNumber6     mandatory for sheet
S_VBAP_TEXTTDIDTDIDText IDText80    mandatory for sheet
S_VBAP_TEXTTDSPRASTDSPRASLanguage KeyText80    mandatory for sheet
S_VBAP_TEXTTEXTLINETEXTLINETextTextunrestrictedmandatory for sheet
S_VBPAVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBPAPOSNRPOSNRSales Document ItemNumber6     
S_VBPAPARVWPARVWPartner FunctionText80    mandatory for sheet
S_VBPAKUNNRKUNNRCustomer NumberText80    mandatory for sheet
S_VBPAEXTADDRNUMBEREXTADDRNUMBERExternal Address NumberText20    
S_VBPASTREETSTREETStreet and House NumberText35    
S_VBPAPOSTL_CODEPOSTL_CODEPostal CodeText10    
S_VBPACITYCITYCityText35    
S_VBPACOUNTRYCOUNTRYCountry/RegionText80    
S_VBPAREGIONREGIONRegionText80    
S_VBPATEL_NUMBERTEL_NUMBERTelephone NumberText16    
S_VBPAFAX_NUMBERFAX_NUMBERFax NumberText31    
S_VBPANAME1NAME1Name 1Text35    
S_VBEPVBELNVBELNLegacy Sales DocumentText80    mandatory for sheet
S_VBEPPOSNRPOSNRSales Document ItemNumber6     mandatory for sheet
S_VBEPETENRETENRDelivery Schedule Line NumberNumber4     mandatory for sheet
S_VBEPWMENGWMENGOrder Quantity in Sales UnitsNumber13    mandatory for sheet
S_VBEPETDATETDATSchedule Line Date/Delivery DateDate


Data Cleansing

IDCriticalityError Message/Report DescriptionRuleOutputSource System
9065-001
Sales order open for more than 3 years.Orders created for more than 3 years ago.
PF2/WP2
9065-002
Missing sold-to dataIf the sold-to is marked for deletion
PF2/WP2
9065-003
Missing ship-to dataIf the ship-to is marked for deletion
PF2/WP2
9065-004
Missing bill-to dataIf the bill-to is marked for deletion
PF2/WP2
9065-005
Missing payer dataIf the payer-to is marked for deletion
PF2/WP2
9065-006
Missing material masterIf the material master is marked for deletion
PF2/WP2
0065-007
Delivery note with planned PGI date beyond go-live dateIf the DN PGI is beyond go-live date, delete the DN
PF2/WP2
0065-008
Invalid reference documentIf the Credit Note, Debit Note and Return order was created with a reference document
PF2/WP2




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

N/A


Extraction

xtract 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
N/A



















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 VA05 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 Sales Orders 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

Open Sales Orders will be loaded in the pre-cutover or cutover phase, depending on business cut-off.

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

The following post-load validations will be performed by the 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 Sales Order 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 VA03 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. 8) Apr 20, 2026 06:39 LEW-ext, Chun Ming Update VTWEG logic to derive from Sales Org country
v. 83 Apr 14, 2026 12:45 LEW-ext, Chun Ming Update report 9065-010 to not applicable
v. 82 Apr 02, 2026 17:33 LEW-ext, Chun Ming
v. 81 Apr 02, 2026 16:36 LEW-ext, Chun Ming Update EQART to not used
v. 80 Apr 01, 2026 19:04 LEW-ext, Chun Ming fine tune rule 215
v. 79 Apr 01, 2026 18:01 LEW-ext, Chun Ming Fine tune rule 88
v. 78 Mar 30, 2026 08:06 LEW-ext, Chun Ming Update transformation rule 88 to consider VBRK-VBTYP
v. 77 Mar 06, 2026 08:36 LEW-ext, Chun Ming Added M2 order type in exclusion criteria
v. 76 Feb 23, 2026 14:02 LEW-ext, Chun Ming Correction after approved
v. 75 Feb 23, 2026 13:58 LEW-ext, Chun Ming

Go to Page History

Workflow history

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

  • No labels