Status	Revision in Progress
Owner	LEW-ext, Chun Ming
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 order items 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:

Documents where the document category (VBAK-VBTYP) is either
1. "C" Standard order
2. "I" Order without charge
3. "K" Credit memo request
4. "L" Debit memo request
5. "H" Return order
Sales Order items with Open Quantities:
1. Delivery relevant order items with undelivered items, i.e., delivery quantity < order quantity.
2. Non delivery relevant order items (Credit/Debit Memo etc) with unbilled items, i.e., billed quantity < order quantity.
3. Order items where the delivery status is not marked as complete.
The Sales Area of the Sales Order are within the scope of S4 HANA.
Sales Orders created for the Customers and Materials in scope.

The data from legacy system excludes:

Fully Delivered and Billed Sales Order 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.
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.
M3 (VBAK-AUART) orders, these will be migrated as contract instead of Sales order,

The following table illustrating the possible legacy sales scenarios and it's corresponding S4 sales scenarios. The SAP documents might change due to re-design of the system landscape or system process.

Definition of documents :

Standard Sales Orders and Customer Orders: Normal Sales Order
Direct Delivery Sales Orders: Where a sales org is selling, but delivering from a plant that belongs to another affiliate
IC SO : Sales Order created for another affiliate
IC PO : Purchase Order created for another affiliate (Not in 9065 scope)
IC STO : Intercompany Stock Transport Order
Third Party Sales Orders : A purchase requisition (and subsequently a purchase order) is automatically triggered from the sales order. The vendor delivers the goods directly to the customer. No physical goods movement occurs in the Syensqo system, as the delivery is managed externally by the vendor. Generated PO in the legacy shall be closed if the SO is in the migration scope.
Individual Purchase Order Sales Orders : A purchase requisition (and subsequently a purchase order) is automatically triggered from the sales order. The vendor delivers the goods to the Syensqo plant as Sales Order Special Stock (E-stock). The stock is reserved specifically for that sales order, and actual goods receipt and goods issue are recorded and managed within the system. Generated PO in the legacy shall be closed if the SO is in the migration scope.

Scenario No	Source	Scope (Legacy Scenario)	Supplying Entity Target System	Receiving Entity Target System	Source Approx No. of Records	Target System	Target Approx No. of Records
1	WP2	Standard Open Sales Orders	S/4HANA ROW	S/4HANA ROW	7500	S/4HANA ROW	7500
2	PF2	Standard Open Sales Orders	S/4HANA ROW	S/4HANA ROW	5500	S/4HANA ROW	5500
3	WP2	Standard Open Sales Orders	S/4HANA China	S/4HANA China	1500	S/4HANA China	1500
4	PF2	Standard Open Sales Orders	S/4HANA China	S/4HANA China	1500	S/4HANA China	1500
5	WP2	Standard Open Sales Orders	S/4HANA CUI	S/4HANA CUI	22000	S/4HANA CUI	22000
6	PF2	Standard Open Sales Orders	S/4HANA CUI	S/4HANA CUI	0	S/4HANA CUI	0
7	WP2	Direct Delivery Open Sales Orders	S/4HANA ROW	S/4HANA ROW	500	S/4HANA ROW	500
8	PF2	Direct Delivery Open Sales Orders	S/4HANA ROW	S/4HANA ROW	500	S/4HANA ROW	500
9	WP2	Direct Delivery Open Sales Orders	S/4HANA China	S/4HANA China	50	S/4HANA China	50
10	PF2	Direct Delivery Open Sales Orders	S/4HANA China	S/4HANA China	500	S/4HANA China	500
11	WP2	Direct Delivery Open Sales Orders	S/4HANA CUI	S/4HANA CUI	2000	S/4HANA CUI	2000
12	PF2	Direct Delivery Open Sales Orders	S/4HANA CUI	S/4HANA CUI	0	S/4HANA CUI	0
13	WP2	Direct Delivery Open Sales Orders	S/4HANA ROW	S/4HANA China	0	S/4HANA China - Customer SO S/4HANA China- IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	0
14	PF2	Direct Delivery Open Sales Orders	S/4HANA ROW	S/4HANA China	200	S/4HANA China - Customer SO S/4HANA China- IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	200
15	PF2	Direct Delivery Open Sales Orders	S/4HANA ROW	S/4HANA CUI	0	S/4HANA CUI - Customer SO S/4HANA CUI - IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	0
16	WP2	Direct Delivery Open Sales Orders	S/4HANA ROW	S/4HANA CUI	0	S/4HANA CUI - Customer SO S/4HANA CUI - IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	0
17	WP2	Direct Delivery Open Sales Orders	S/4HANA China	S/4HANA ROW	150	S/4HANA ROW - Customer SO S/4HANA ROW - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	150
18	PF2	Direct Delivery Open Sales Orders	S/4HANA China	S/4HANA ROW	20	S/4HANA ROW - Customer SO S/4HANA ROW - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	20
19	WP2	Direct Delivery Open Sales Orders	S/4HANA China	S/4HANA CUI	200	S/4HANA CUI - Customer SO S/4HANA CUI - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	200
20	PF2	Direct Delivery Open Sales Orders	S/4HANA China	S/4HANA CUI	0	S/4HANA CUI - Customer SO S/4HANA CUI - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	0
21	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA ROW	S/4HANA ROW	N/A	S/4HANA ROW - IC STO (Out of Scope)	N/A
22	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANA ROW	S/4HANA ROW	N/A	S/4HANA ROW - IC STO (Out of Scope)	N/A
23	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA China	S/4HANA China	N/A	S/4HANA China - IC STO (Out of Scope)	N/A
24	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANA China	S/4HANA China	N/A	S/4HANA China - IC STO (Out of Scope)	N/A
25	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA CUI	S/4HANA CUI	N/A	S/4HANA CUI - IC STO (Out of Scope)	N/A
26	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANACUI	S/4HANA CUI	N/A	S/4HANA CUI - IC STO (Out of Scope)	N/A
27	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA ROW	S/4HANA China	N/A	S/4HANA China -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
28	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANA ROW	S/4HANA China	N/A	S/4HANA China -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
29	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA ROW	S/4HANA CUI	N/A	S/4HANA CUI -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
30	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANA ROW	S/4HANA CUI	N/A	S/4HANA CUI -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
31	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA China	S/4HANA ROW	N/A	S/4HANA ROW - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
32	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANA China	S/4HANA ROW	N/A	S/4HANA ROW - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
33	WP2 PF2	WP2 IC Purchase Order PF2 IC Sales Order	S/4HANA China	S/4HANA CUI	N/A	S/4HANA CUI - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
34	WP2 PF2	PF2 IC Purchase Order WP2 IC Sales Order	S/4HANA China	S/4HANA CUI	N/A	S/4HANA CUI - IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
35	WP2	WP2 STO	S/4HANA ROW	S/4HANA ROW	N/A	S/4HANA ROW - IC STO (Out of Scope)	N/A
36	PF2	PF2 STO	S/4HANA ROW	S/4HANA ROW	N/A	S/4HANA ROW - IC STO (Out of Scope)	N/A
37	WP2	WP2 STO	S/4HANA China	S/4HANA China	N/A	S/4HANA China - IC STO (Out of Scope)	N/A
38	PF2	PF2 STO	S/4HANA China	S/4HANA China	N/A	S/4HANA China - IC STO (Out of Scope)	N/A
39	WP2	WP2 STO	S/4HANA China	S/4HANA CUI	N/A	S/4HANA CUI - IC STO (Out of Scope)	N/A
40	PF2	PF2 STO	S/4HANA China	S/4HANA CUI	N/A	S/4HANA CUI - IC STO (Out of Scope)	N/A
41	WP2	WP2 STO	S/4HANA ROW	S/4HANA China	N/A	S/4HANA China -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
42	PF2	PF2 STO	S/4HANA ROW	S/4HANA China	N/A	S/4HANA China -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
43	WP2	WP2 STO	S/4HANA ROW	S/4HANA CUI	N/A	S/4HANA CUI -IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
44	PF2	PF2 STO	S/4HANA ROW	S/4HANA CUI	N/A	S/4HANA CUI - IC PO (Out of Scope) S/4HANA ROW - IC SO (Out of Scope)	N/A
45	WP2	WP2 STO	S/4HANA China	S/4HANA ROW	N/A	S/4HANA ROW -IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
46	PF2	PF2 STO	S/4HANA China	S/4HANA ROW	N/A	S/4HANA ROW -IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
47	WP2	WP2 STO	S/4HANA China	S/4HANA CUI	N/A	S/4HANA CUI -IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
48	PF2	PF2 STO	S/4HANA China	S/4HANA CUI	N/A	S/4HANA CUI -IC PO (Out of Scope) S/4HANA China - IC SO (Out of Scope)	N/A
49	WP2	Third Party Open Sales Orders	S/4HANA ROW	S/4HANA ROW	100	S/4HANA ROW *PO will be created automatically	100
50	PF2	Third Party Open Sales Orders	S/4HANA ROW	S/4HANA ROW	100	S/4HANA ROW *PO will be created automatically	100
51	WP2	Third Party Open Sales Orders	S/4HANA China	S/4HANA China	0	S/4HANA China *PO will be created automatically	0
52	PF2	Third Party Open Sales Orders	S/4HANA China	S/4HANA China	0	S/4HANA China *PO will be created automatically	0
53	WP2	Third Party Open Sales Orders	S/4HANA CUI	S/4HANA CUI	0	S/4HANA CUI *PO will be created automatically	0
54	PF2	Third Party Open Sales Orders	S/4HANA CUI	S/4HANA CUI	0	S/4HANA CUI *PO will be created automatically	0
55	WP2	Individual Purchase Order Open Sales Orders	S/4HANA ROW	S/4HANA ROW	0	S/4HANA ROW *PO will be created automatically	0
56	PF2	Individual Purchase Order Open Sales Orders	S/4HANA ROW	S/4HANA ROW	0	S/4HANA ROW *PO will be created automatically	0
57	WP2	Individual Purchase Order Open Sales Orders	S/4HANA China	S/4HANA China	50	S/4HANA China *PO will be created automatically	50
58	PF2	Individual Purchase Order Open Sales Orders	S/4HANA China	S/4HANA China	0	S/4HANA China *PO will be created automatically	0
59	WP2	Individual Purchase Order Open Sales Orders	S/4HANA CUI	S/4HANA CUI	0	S/4HANA CUI *PO will be created automatically	0
60	PF2	Individual Purchase Order Open Sales Orders	S/4HANA CUI	S/4HANA CUI	0	S/4HANA CUI *PO will be created automatically	0
61
62
63
64
65

Additional Information

Multi-language Requirement

Document Management

Open Sales Orders attachment will be managed under CNV-9067 Attachment for open sales transaction

Legal Requirement

Special Requirements

Target Design

The technical design of the target for this conversion approach.

Table	Field	Data Element	Field Description	Data Type	Length	Requirement
VBAK - Sales Order header
VBAK	AUART	AUART	Sales Document Type	CHAR	8	Mandatory
VBAK	VKORG	VKORG	Sales Organization	CHAR	8	Mandatory
VBAK	VTWEG	VTWEG	Distribution Channel	CHAR	4	Mandatory
VBAP - Sales Order Items
VBAP	VBELN	VBELN_VA	Sales Document	CHAR	20	Mandatory
VBAP	POSNR	POSNR_VA	Sales Document Item	NUMC	12	Mandatory
VBAP	UEPOS	UEPOS	Higher-Level Item in Bill of Material Structures	NUMC	12
VBAP	POSEX	POSEX	Item Number of the Underlying Purchase Order	CHAR	12
VBKD - Sales Document Business Data
VBKD	BSTDK	BSTDK	Customer Reference Date	DATS	16
VBKD	BSARK	BSARK	Customer Purchase Order Type	CHAR	8
ADRC - Addresses

ADR2 - Telephone Numbers


In this section, the fields will be split by Table, since the data definition is at the table level. For example, VBKD will not appear twice though it's used in header and item structure. Full table design list

Data Cleansing

ID	Criticality	Error Message/Report Description	Rule	Output	Source System
9065-001	C-1	Sales order open for more than 3 years.	Orders created for more than 3 years ago.	List of affected Sales Order	PF2/WP2
9065-002	C-1	Missing sold-to data	If the sold-to is marked for deletion	List of affected Sales Order	PF2/WP2
9065-003	C-1	Missing ship-to data	If the ship-to is marked for deletion	List of affected Sales Order	PF2/WP2
9065-004	C-1	Missing bill-to data	If the bill-to is marked for deletion	List of affected Sales Order	PF2/WP2
9065-005	C-1	Missing payer data	If the payer-to is marked for deletion	List of affected Sales Order	PF2/WP2
9065-006	C-1	Missing material master	If the material master is marked for deletion	List of affected Sales Order	PF2/WP2
9065-007	C-3	Delivery note with planned PGI date beyond go-live date	If the DN PGI is beyond go-live date, delete the DN	List of affected Sales Order	PF2/WP2
9065-008	C-3	Open Credit / Debit Memo Request	If the document is not fully billed	List of open Credit / Debit Memo Request	PF2/WP2
9065-009	C-3	Open Return Order	If the Return Order is not processed completely	List of open Return Order	PF2/WP2
9065-010	C-3	Purchase order generated from "Third Party / Individual Purchase Order" with planned delivery date beyond go-live date.	If the PO planned delivery date is beyond go-live date, delete the PO.	List of affected Purchase Order	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

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
1	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.	LTC Data team
2	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.	Syniti
3	Extraction Execution Plan - Establish execution timelines and batch processing schedules. - Assign responsibilities for extraction monitoring. - Document dependencies on other migration tasks.	Syniti
4	Data Quality and Validation - Define error handling mechanisms for extraction failures.	Syniti

Selection Screen

Selection Ref Screen

Parameter Name

Selection Type

Requirement

Value to be entered/set

SE16N

Standard Open Sales Order

Direct Delivery Open Sales Orders

Individual Purchase Order Sales Order

To select:

Standard or FOC Sales Order that is not fully delivered

Scenario 1-20, 49-54 under conversion scope

This is to extract standard sales order and FOC sales order with open quantity.

As long as the order is having open quantity, be it full or partially open, and it is not rejected, the order should be included in the migration.

* The IC SO will be automatically created even though it is cross instance in S4 Hana. This is the design now, but yet to officially confirm

SELECT -- These are baseline fields only, extend according to needs
vbak.vbeln AS sales_order,
vbak.vbtyp AS doc_category,
vbak.auart AS order_type,
vbak.vkorg AS sales_org,
vbap.posnr AS item_no,
vbap.matnr AS material,
vbap.arktx AS short_text,
vbap.kwmeng AS order_qty,

COALESCE(b.delivered_qty, 0) AS delivered_qty,

-- (open item)
vbap.kwmeng - COALESCE(b.delivered_qty, 0) AS open_qty

FROM vbak
JOIN vbap
ON vbak.vbeln = vbap.vbeln

-- ensure item status indicates not completed (join VBUP)
LEFT JOIN vbup
ON vbup.vbeln = vbap.vbeln
AND vbup.posnr = vbap.posnr

-- sum delivered quantity from delivery items (LIPS) mapped to the order via VGBEL/VGPOS

LEFT JOIN (
SELECT vgbel AS order_vbeln, vgpos AS order_posnr, SUM(lfimg) AS delivered_qty
FROM lips
GROUP BY vgbel, vgpos
) b
ON b.order_vbeln = vbap.vbeln
AND b.order_posnr = vbap.posnr

WHERE
vbak.vbtyp = 'C' OR 'I' -- only sales orders and FOC orders(document category)

AND vbak.auart <> 'M3'
-- not fully delivered:
AND open_qty > 0

AND vbup.absta <> 'C' - item is not rejected

ORDER BY vbak.vbeln, vbap.posnr;

IC STO (Out of scope)

To select:

IC PO/SO from legacy, converting to IC STO scenario

Scenario 21-26 under conversion scope

Situation :

IC PO/SO in legacy will be converted to Intercompany STO if the buying and selling entities are from the same S4 Hana system

IC Open Sales Order (Out of scope)

To select:

IC PO/SO from legacy, converting to IC PO/SO scenario

Scenario 27-34 under conversion scope

* The IC SO will be automatically created even though it is cross instance in S4 Hana. This is the design now, but yet to officially confirm

Situation :

IC PO/SO in legacy will be converted to Purchase Order and Sales Order if the buying and selling entities are from different S4 Hana system

To-be :

Open PO quantity will be converted into a Purchase Order under buying entity
The Purchase Order will be the base for the IC Sales order in the selling entity

IC STO (Out of scope)

To select:

STO from legacy, converting to STO scenario

Scenario 35-40 under conversion scope

Situation :

Intercompany STO in legacy will be converted to Intercompany STO if the buying and selling entities are from the same S4 Hana system

IC Open Sales Order (Out of scope)

To select:

STO from legacy, converting to IC PO/SO scenario

Scenario 41-48 under conversion scope

* The IC SO will be automatically created even though it is cross instance in S4 Hana. This is the design now, but yet to officially confirm

Situation :

Stock Transport Order in legacy will be converted to Purchase Order and Sales Order if the buying and selling entities are from different S4 Hana system

To-be :

Open STO quantity will be converted into a Purchase Order under buying entity
The STO will be the base for the IC Sales order in the selling entity

Third Party Sales Order

To select:

Third Party Sales Order that is not fully billed

Scenario 55-60 under conversion scope

This is to extract Third Party Sales Order sales order with open quantity.

As long as the order is having open quantity, be it full or partially open, and it is not rejected, the order should be included in the migration.

There is no delivery created for this case, hence, the open quantity is equal to the SO quantity minus the billed quantity.

SELECT -- These are baseline fields only, extend according to needs
vbak.vbeln AS sales_order,
vbak.vbtyp AS doc_category,
vbak.auart AS order_type,
vbak.vkorg AS sales_org,
vbap.posnr AS item_no,
vbap.matnr AS material,
vbap.arktx AS short_text,
vbap.kwmeng AS order_qty,

COALESCE(b.billed_qty, 0) AS billed_qty,

-- (open item)
vbap.kwmeng - COALESCE(b.billed_qty, 0) AS open_qty

FROM vbak
JOIN vbap
ON vbak.vbeln = vbap.vbeln

-- ensure item status indicates not completed (join VBUP)
LEFT JOIN vbup
ON vbup.vbeln = vbap.vbeln
AND vbup.posnr = vbap.posnr

-- sum billed quantity from delivery items (VBRP) mapped to the order via VGBEL/VGPOS

LEFT JOIN (
SELECT vgbel AS order_vbeln, vgpos AS order_posnr, SUM(fkimg) AS billed_qty
FROM vbrp
GROUP BY vgbel, vgpos
) b
ON b.order_vbeln = vbap.vbeln
AND b.order_posnr = vbap.posnr

WHERE
vbak.vbtyp = 'C' OR 'I' OR 'H' -- only sales orders FOC orders and return orders(document category)

AND vbak.auart <> 'M3'
-- not fully delivered:
AND open_qty > 0

AND vbup.absta <> 'C' - item is not rejected

ORDER BY vbak.vbeln, vbap.posnr;

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 Name	Field Description	Rule

Extraction Dependencies

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.	Syniti
3	Referential Integrity Ensure dependent records are extracted together.	Syniti
4	Extraction Methodology Define whether extraction is full, incremental, or delta-based. Establish batch processing schedules for large datasets.	Syniti
5	Performance and Scalability Considerations Optimize extraction queries to prevent system overload. Ensure network bandwidth supports data transfer volumes.	Syniti
6	Security and Compliance Adhere to regulatory standards for sensitive information if applicable	Syniti
7	Close all Credit / Debit Memo Request and Return Order All Credit / Debit Memo Request and Return Order has to be completely billed or rejected	Data team and Business
8	Close all Delivery Note Once a delivery note is created, the corresponding quantity is deducted from the open quantity in the sales order. To ensure accurate reflection of open sales order quantities, all delivery notes must be closed. During migration, each delivery note should be completed through to the billing document posted to accounting. If a delivery note cannot be completed, it should be deleted.	Data team and Business

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, Functional Team
2	Data Mapping and Standardization - Align source fields with target fields. - Ensure unit consistency (e.g., currency, measurement units)	Data Team, Functional Team
3	Business Rule Application - Implement data enrichment/collection if applicable - Apply conditional transformations based on predefined logic/business rules	Data Team, Functional Team
4	Transformation Execution Plan - Define batch processing schedules. - Assign responsibilities for monitoring execution. - Establish error-handling mechanisms	Syniti
5	Configure transformation rules in Syniti Migrate (including calculated fields, formatting rules, etc.)	Syniti
6	Review transformation logic and mappings with Business for confirmation	Business Team + Functional Team (L2C)
7	Perform initial transformation run and generate draft target-ready dataset	Data Team (Syniti),
8	Review draft target-ready data for structure and completeness	Data Team (L2C), Functional Team (L2C)
9	Share transformed data with Business for Pre-load Validation	Business Team
10	Incorporate feedback from Business and refine mappings or transformation logic as needed	Data Team (L2C)
11	Finalize and approve transformed data as Target Ready Load File	Business + Functional (L2C) + Data Team (L2C)
12	Handover final file to Load Team or trigger the load via Syniti Load Workbench	Data Team (Syniti), Data Load Team

Transformation Rules

Rule #	Target Table	Target Field	Target Description	Transformation Logic	Mapping Table
Header
1	VBAK	VBELN	Sales Document	Copy 1:1
2	VBAK	AUART	Sales Document Type	Mapping	MAP_AUART
3	VBAK	VKORG	Sales Organization	Rule	If cannot find the mapping (1:N Mappings), refer to material master sales view (MVKE), take the Sales Org extended the company code. The assumption is that the same material should be extended to only 1 GBU within the same company code Select VKORG from MVKE A, TVKO B where A.MATNR = VBAP-MATNR and B.BUKRS = VBAK-BUKRS_VF If there are materials from several sales orgs, the Sales Order need to be split according by sales org
Item
78	VBAP	VBELN	Sales Document	Copy 1:1
79	VBAP	POSNR	Sales Document Item	Copy 1:1
80	VBAP	UEPOS	Higher-Level Item in Bill of Material Structures	Copy 1:1
In this section, the fields will be split according to LTMC input structure per below illustration. For example, VBKD will appear twice in both header and item sections. Full transformation list, the grouping is stated in column A.

Transformation Mapping

Mapping Table Name

Mapping Table Description

Will be updated once the transformation is confirm

Refer to gsheet

Ignore the below from previous version

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.	Syniti
2	Referential Integrity - Ensure dependent records are transformed together or in advance	Syniti
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	Syniti
5	Logging and Error Handling - Maintain detailed logs of transformation activities. - Define error-handling procedures for failed transformations	Syniti

Pre-Load Validation

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

Completeness

Task

Action

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

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. The Net Value should be migrated proportionally according to the open order quantities.
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).	Syniti
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	Syniti
4	Load Execution Plan - Establish execution timelines and batch processing schedules. - Assign responsibilities for monitoring execution. - Document dependencies on other migration tasks	Syniti
5	Logging and Reporting - Maintain detailed logs of loading activities. - Generate summary reports on loaded data volume and quality. - Define escalation procedures for errors	Syniti

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
1034	Sales Pricing Conditions
1036	Customer Material Information Records(CMIR)
1042	TM - Transportation Lanes
1046	Classes Type: 023 ( Batch)
1047	Batch Characteristics of Class Type: 023
1048	Batch Master
1051	TM - Locations
1052	TM - Transportation Zones
1053	TM - Default Routes
1058	Batch Classification Data
1062	Batch Search Strategy
1134	Output determination for application V1/V3
1135	Z tables (variant table)
2001	Material Listing and Exclusions
2002	Material Substitution
2003	Materials - Sales view with sales long text
2005	Materials - MRP view (4 views)
2011	Materials - WM Execution ( EWM )
2012	Materials - Accounting 1
2013	Materials - Costing 1
2014	Materials - Accounting 2
2015	Materials - Costing 2
2019	Materials - Basic View
2027	Materials - Foreign Trade Views
3003	Business Partners - Customer (Sales and Service) - FLCU01
3007	Business Partners - General (Role 000000)
3010	Business Partners - Relationship for contact person
3011	Business Partners - Contact Persons (BUP001)
3017	Business Partners - FI Customer (FLCU00)
3019	Business Partners - Credit Management (UKM000)
3022	Business Partners - Collection Management (UDM000)
3027	Business Partners - Plants/Intercompany Suppliers
3039	Business Partners - GTS Master
3040	Business Partners - Treasury

Error Handling

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
Obsolete Master Data	Customer or material master data no longer exists in target system	Replaced or removed based on business input

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 Sales Order 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):
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
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
Review Loaded Condition Records	Access the S/4HANA system (via transactions like VA05 or custom reports) to view loaded sales order

Accuracy

Task	Action
Display Records	Pick up few random sales document number numbers, display with Tcode VA03 and validate the details

Key Assumptions

Adapting S4 cross instances direct delivery solutions, where a plant from a different S4 instance can be entered in the Sales Order.
Adapting S4 cross instances inter-company Purchase Order solution. The subsequent Sales Order will be automatically created even though it's in a separate instance.

Change log

Version	Published	Changed By	Comment
CURRENT (v. 55)	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.

Apr 20, 2026	Actor	Type	Activity	Version
Revision in Progress	LEW-ext, Chun Ming	Edit	updated the page at 6:39 am Update VTWEG logic to derive from Sales Org country
Apr 14, 2026
	LEW-ext, Chun Ming	State	changed state to Revision in Progress at 12:45 pm	v83
From Apr 02, 2026 to Apr 14, 2026
Approved	LEW-ext, Chun Ming	Edit	updated the page at 4:36 pm
	TAMRAKAR-ext, Pooja	State	changed state to Approved at 4:19 pm	v82
Revision under Review	TAMRAKAR-ext, Pooja	State	gave Minor change approval at 4:19 pm

Workflow history

Space shortcuts

Page tree

CNV-9065 Open Sales Order

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