| Status | |
|---|---|
| Owner | |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
Purpose
The purpose of this document is to define the conversion approach to create Business Partners - Customer (Sales and Service) - FLCU01 in S/4 HANA.
In SAP ECC, the Customer Sales View is part of the Customer Master Data, which is used to store customer-related information for sales transactions. It includes details such as sales area, pricing, delivery preferences, and billing information. The setup typically involves maintaining customer records separately for different sales organizations, distribution channels, and divisions.
In SAP S/4HANA, the Customer Sales View is integrated into the Business Partner (BP) model, which replaces the traditional customer/vendor objects from ECC. The Business Partner serves as a central entity, allowing a single record to hold multiple roles (e.g., customer and vendor). The Customer Sales View in S/4HANA is represented under the BP role FLCU01, which contains sales-specific data such as sales area assignments, pricing conditions, and delivery preferences
Conversion Scope
The scope of this document covers the approach for converting active Customer Sales view from Legacy Source Systems into S/4HANA following the Business Partners - Customer (Sales and Service) - FLCU01 Master Data Design Standard.
The data from legacy system includes:
a. The BP(customer) general data is migrated under conversion spec CNV-3007
b. The sales area under which the sales view data is maintained for the customer is within the scope of S4 Hana
c. There is usage for the customer within 4 years within the sales org in scope.
| Criteria | Relevancy Rule | Technical Details |
|---|---|---|
| 1 | The BP general is migrated | Select where KNVV-KUNNR = KNA1-KUNNR in scope |
| 2 | AND The sales area under which the sales view data is maintained for the customer is within the scope of S4 Hana | AND KNVV-VKORG in (Sales Org in Scope) |
| 3 | AND There is usage for the customer within 4 years within the sales org in scope (even there is deletion indicator in the customer sales view, this customer will still be migrated). | Select KUNNR from KNA1 where KNA1-KUNNR = KNVV-KUNNR AND KNVV-VKORG in (Sales Org in scope) and usage within 4 years.
|
| 4 |
The data from legacy system excludes:
- The sales org for the sales view is out of scope, such as Oil & Gas and Aroma specific sales organizations.
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
| WP2 | Customer Master Data Sales View Extract from KNVV/KNVI/KNVP etc. | 110897 | S4 Hana ROW/China | 110897 |
| PF2 | Customer Master Data Sales View Extract from KNVV/KNVI/KNVP etc. | 87252 | S4 Hana ROW/China | 87252 |
Additional Information
Multi-language Requirement
N/A
Document Management
N/A
Legal Requirement
CMMC 2.0 is a mandatory DoD cybersecurity certification for contractors handling Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). CUI includes sensitive technical data (e.g., design specs, system info) related to U.S. military and space applications. The Composites Business handles CUI and is therefore within CMMC scope. Without certification, the business risks disqualification from existing and future DoD programs.It is mandatory to implement CMMC-compliant systems and processes to for all the organizations that are dealing with CUI. Therefore, there will be one SAP instance specifically for CUI related entities. * 20260219 remove CUI
Special Requirements
A. Different SAP Instance Migration Approach
Due to compliance requirement, there will be one SAP instance for Rest of the World (ROW), one for China and one for CUI* 20260219 remove CUI. For BP general data, the same data will be created in all 3 SAP instances as it is Tier 1 object with central data governance and maintenance rule.
B. One Sales Organization per GBU
As elaborated in KDD060 - Sales Enterprise Structure - Sales Organization, in the S4 Hana design, one sales organization will be mapped to one GBU. Therefore, it is possible that one sales organization in legacy system is mapped to multiple sales organization in the S4. When such scenario happens, one record of customer master data sales view will be split into multiple records based on the mapping.
C. Distribution Channel Transformation
In S4 Hana design, there will be 3 distribution channels defined.
- Domestic
- Export
- Intercompany
Domestic/Export distribution channel is used for external customers, and determined based on the Departure country (from Plant, or Sales Organization/Company code country if plant information is not applicable)/Destination Country (Ship-to Party country).
Intercompany distribution channel is determined based on the nature of the business partner, i.e. if it is Syensqo entity or affiliated companies, it will be defined as Intercompany Distribution Channel.
To identify Domestic/Export distribution channel, it will apply below logics.
- Fetch the Sales history of the customer within the sales organization in scope (VBAK/VBAP/VBPA).
Derive the matrix of Sales Organization/Plant/Plant country/Ship-to party/Ship-to country(CR0455 Derive the matrix of Sales Organization/Sales Org country/Ship-to party/Ship-to country)If Plant country is same as Ship-to country,(CR0455 If Sales Org country is same as Ship-to country) then for key combination of Sales Organization/Ship-to party, the transformed distribution channel will be Domestic.If Plant country is different as Ship-to country,((CR0455 If Sales Org country is different from Ship-to country)) then for key combination of Sales Organization/Ship-to party, the transformed distribution channel will be Export(there will be scenarios that the customer under the sales organization can be extended to both domestic and export distribution channel).- Apply the result to rest of the customers in the same sales document, e.g., Sold-to customer, Payer, Bill to etc. It will then get a matrix of Sales Org/Customer/Distribution Channel(After transformation)
start of CR0455
To identify Domestic/Export distribution channel, it will further consider below scenarios on top of the sales document usage.
a. Delivery usage - fetch the delivery history of the customer within the sales org in scope (LIKP/LIPS/VBPA)
b. Billing usage - fetch the billing history of the customer within the sales org in scope (VBRK/VBRP/VBPA)
The DC determination logic is the same as the sales document logic, using the Sales Org country to compare the ship-to customer country.
With the enhanced logic considers sales document/delivery/billing, in alliance with the relevancy rule, the data will be based on 4 year usage ( VBAK/LIKP/VBRK-ERDAT field).
end of CR0455
If there is no sales history as this is a new customer, similar logic will be applied using Customer master data sales view partner data.
- Fetch the partner information from customer master data sales view for sales organization in scope (KNVV/KNVP).
- Derive the matrix of Sales Organization/Country/Ship-to party/Ship-to country
- If Sales Organization country is same as Ship-to country, then for key combination of Sales Organization/Ship-to party, the transformed distribution channel will be Domestic.
- If Sales Organization country is different as Ship-to country, then for key combination of Sales Organization/Ship-to party, the transformed distribution channel will be Export.
- Apply the result to rest of the customers in the same customer master data, e.g., Sold-to customer, Payer, Bill to etc. It will then get a matrix of Sales Org/Customer/Distribution Channel(After transformation)
Consolidate all the entries and remove the duplicate records. As a result, there will be a matrix based on Sales Organization/Distribution Channel/Customer. This information will be the base to migrate the customer sales view data (such as KNVV/KNVP etc.).
D. Intercompany Customer Sales Area Data
For Intercompany customer, it is in the migration scope. However, as the definition of the to-be Intercompany customer is different from the existing ECC Intercompany customer definition, instead of migrating the ECC Intercompany customer directly, a DCT will be utilized to collect the sales data. The DCT template will take reference from ECC sales data and business will need to validate and update the information.
Target Design
With Functional input, document the technical design of the target fields that are in the scope of this document.
The technical design of the target for this conversion approach.
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| KNVI | KUNNR | KUNNR | Customer | CHAR | 10 | Mandatory |
| KNVI | ALAND | ALAND | Departure Ctry/Reg. | CHAR | 3 | Mandatory |
| KNVI | TATYP | TATYP | Tax Condition Type | CHAR | 4 | Mandatory |
| KNVI | TAXKD | TAXKD | Tax Classification | CHAR | 1 | Mandatory |
| KNVP | KUNNR | KUNNR | Customer | CHAR | 10 | Mandatory |
| KNVP | VKORG | VKORG | Sales Organization | CHAR | 4 | Mandatory |
| KNVP | VTWEG | VTWEG | Distribution Channel | CHAR | 2 | Mandatory |
| KNVP | SPART | SPART | Division | CHAR | 2 | Mandatory |
| KNVP | PARVW | PARVW | Partner Function | CHAR | 2 | Optional |
| KNVP | KUNN2 | KUNN2 | Customer | CHAR | 10 | Optional |
| KNVP | LIFNR | LIFNR | Supplier | CHAR | 10 | Optional |
| KNVP | PERNR | PERNR | Personnel Number | NUMC | 8 | Optional |
| KNVP | PARNR | PARNR | Contact Person | NUMC | 10 | Optional |
| KNVP | KNREF | KNREF | Partner description | CHAR | 30 | Optional |
| KNVP | DEFPA | DEFPA | Default Partner | CHAR | 1 | Optional |
| KNVV | KUNNR | KUNNR | Customer | CHAR | 10 | Mandatory |
| KNVV | VKORG | VKORG | Sales Organization | CHAR | 4 | Mandatory |
| KNVV | VTWEG | VTWEG | Distribution Channel | CHAR | 2 | Mandatory |
| KNVV | SPART | SPART | Division | CHAR | 2 | Mandatory |
| KNVV | LOEVM | LOEVM | Del. indicator for sales area | CHAR | 1 | Optional |
| KNVV | AUFSD | AUFSD | Order block for sales area | CHAR | 2 | Optional |
| KNVV | KALKS | KALKS | Cust.Pric.Procedure | CHAR | 2 | Mandatory |
| KNVV | KDGRP | KDGRP | Customer Group | CHAR | 2 | Not in Use |
| KNVV | INCO1 | INCO1 | Incoterms | CHAR | 3 | Optional |
| KNVV | LIFSD | LIFSD | Delivery block for sales area | CHAR | 2 | Optional |
| KNVV | AUTLF | AUTLF | Complete Delivery | CHAR | 1 | Optional |
| KNVV | ANTLF | ANTLF | Max.Part.Deliveries | DEC | 1 | Optional |
| KNVV | KZTLF | KZTLF | Part.dlv./item | CHAR | 1 | Optional |
| KNVV | KZAZU | KZAZU | Order Combination | CHAR | 1 | Optional |
| KNVV | LPRIO | LPRIO | Delivery Priority | NUMC | 2 | Optional |
| KNVV | VSBED | VSBED | Shipping Conditions | CHAR | 2 | Optional |
| KNVV | FAKSD | FAKSD | Billing block for sales area | CHAR | 2 | Optional |
| KNVV | PERFK | PERFK | Invoicing Dates | CHAR | 2 | Optional |
| KNVV | PERRL | PERRL | Invoice List Sched. | CHAR | 2 | Optional |
| KNVV | WAERS | WAERS | Currency | CUKY | 5 | Mandatory |
| KNVV | KTGRD | KTGRD | Acct Assmt Grp Cust. | CHAR | 2 | Mandatory |
| KNVV | ZTERM | ZTERM | Terms of Payment | CHAR | 4 | Optional |
| KNVV | VWERK | VWERK | Delivering Plant | CHAR | 4 | Optional |
| KNVV | VKGRP | VKGRP | Sales Group | CHAR | 3 | Optional |
| KNVV | VKBUR | VKBUR | Sales Office | CHAR | 4 |
*20260128 update Mandatory |
| KNVV | KVGR1 | KVGR1 | Customer Group 2 | CHAR | 3 | Optional |
| KNVV | KVGR1 | KVGR1 | Customer Group 1 | CHAR | 3 | Not in use |
| KNVV | KVGR5 | KVGR5 | Customer Group 5 | CHAR | 3 |
Not in use*20260305 update |
| KNVV | KURST | KURST | Exchange Rate Type | CHAR | 4 | Optional |
| KNVV | PRFRE | PRFRE | Price determination | CHAR | 1 | Not in use |
| KNVV | KABSS | KABSS | Paymt guarant. proc. | CHAR | 4 |
Not in use*20260305 update |
| KNVV | CASSD | CASSD | Sales Block for Sales Area | CHAR | 2 | Optional |
| KNVV | AGREL | AGREL | Settlement Mgmt. | CHAR | 1 | Optional |
| KNVV | UEBTO | UEBTO | Overdeliv. Tolerance | DEC | 3 | Optional |
| KNVV | UNTTO | UNTTO | Underdel. Tolerance | DEC | 3 | Optional |
| KNVV | PODKZ | PODKZ | Relevant for POD | CHAR | 1 | Mandatory |
| KNVV | INCO2_KEY | INCO2_KEY | Incoterm Location 1 | RAW | 16 | Optional |
| KNVV | ZZ_SINGLE_PACKING_LIST | ZZ_SINGLE_PACKING_LIST | Single Packing List | Optional | ||
| KNVV | ZZ_SINGLE_PARENT_BATCH | ZZ_SINGLE_PARENT_BATCH | Single Parent Batch | Optional | ||
| KNVV | ZZ_WHOLE_NUMBER_REQUIRED | ZZ_WHOLE_NUMBER_REQUIRED | Whole number Required | Optional | ||
| STXH | TDOBJECT | TDOBJECT | Text object | CHAR | 10 | Optional |
| STXH | TDNAME | TDNAME | Text Name | CHAR | 70 | Optional |
| STXH | TDID | TDID | Text ID | CHAR | 4 | Optional |
| STXH | TDSPRAS | TDSPRAS | Language Key | LANG | 1 | Optional |
| STXL | TDOBJECT | TDOBJECT | Text object | CHAR | 10 | Optional |
| STXL | TDNAME | TDNAME | Text Name | CHAR | 70 | Optional |
| STXL | TDID | TDID | Text ID | CHAR | 4 | Optional |
| STXL | TDSPRAS | TDSPRAS | Language Key | LANG | 1 | Optional |
| STXL | CLUSTD | CLUSTD | Data | LRAW | 7902 | Optional |
| KNVV | PODTG | PODTG | POD TIMEFRAME | CHAR | Optional |
Data Cleansing
All data cleansing should take place in the data source system as defined in this document, unless system limitations prevent it.
If data cleansing is managed outside of the source system (e.g. Syniti Migrate, 3rd Party Vendor, DCT), the necessary documentation must be produced and appended to this deliverable for sign-off.
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
|
*20260120 Update. Since the relevancy is based on 4 year history usage, the block is not considered as part of the relevancy rule, so remove the report | ||||
| 3003-002 | C-2 | Fill in mandatory fields based on master data standards or non-ISO incoterm used, such as COL. CPU, DAT(replaced by DPU), PPA, PPD (for DCT purposes) or Incoterm part 2 with "." maintained *20260120 Update. combine the incoterm into one cleansing report | For all the sold-to party (partner function SP or AG) and the sales view is active, but there is no incoterm maintained | Customer/Name/Country/Sales Org/Distribution Channel/Division/Incoterm1/Incoterms 2/ Sales Office(with Description *20260314 update) / Sales Group(with Description *20260314 update) / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
| 3003-003 | C-1 | Fill in mandatory fields based on master data standards the payment term is not in the S4 Hana scope *20260120 Update. combine the payment term into one cleansing report | For all the payer party (partner function PY) and the sales view is active, but there is no payment term maintained | Customer/Name/Country/Sales Org/Distribution Channel/Division/Payment Term/ Sales Office(with Description *20260314 update) / Sales Group(with Description *20260314 update) / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
| 3003-004 | C-2 | For all the ship-to party (partner function SH or WE) and relevant for migration, but there is no shipping condition maintained | For all the start of *20260314 change To check the customer is used as Ship-to, instead of checking customer master data, the logic will validate the sales document usage instead (check VBPA table) end of *20260314 change start of *20260323 change Instead of ship-to party, use the sold-to party as the shipping condition in the sales order is copied from sold-to end of *20260323 change | Customer/Name/Country/Sales Org/Distribution Channel/Division/Shipping condition/ Sales Office(with Description *20260314 update) / Sales Group(with Description *20260314 update) / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
| 3003-007 | C-2 | 6. Update obsolete CSR as business partner | For all the active customer in migration scope, if there is partner function ZI/ZN for WP2. VE/VW for PF2 | Customer/Name/Country/Sales Org/Distribution Channel/Division/Partner function/Personnel Number/Name/ Sales Office(with Description *20260314 update) / Sales Group(with Description *20260314 update) / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
| WP2/PF2 | |||||
| 3003-010 | C-2 | Fill in mandatory fields based on master data standards 9. Missing sales office | For all the active customer in migration scope, the sales office field is blank Start of *20260314 update + scenario when the sales office description includes ZZZ, which could be obsolete sales office for business review End of *20260314 update | Customer/Name/Country/Sales Org/Distribution Channel/Division/ Sales Office(with Description *20260314 update) / Sales Group(with Description *20260314 update) / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
*20260120 Update. Remove as there is only one customer | |||||
| 3003-012 | C-1 | Due to sales area definition change, multiple sales view record might merge into one record. If multiple records have different values, pick the main records. | For all the active customer in migration scope, there is duplicate entries after transformation, and the KNVV/KNVP holds different values start of *20230314 change Split the KNVV and KNVP into separate reports as 1 customer in 1 sales area is 1 to many (1 KNVV vs X KNVP). For KNVP, the logic will compare all different types of partners including customer/vendor/contact person/personnel number as all those will be migrated/transformed into S4 hana end of *20230314 change | Customer/Name/Country/Sales Org/Distribution Channel/Division/Fields with different values / Sales Office(with Description *20260314 update) / Sales Group(with Description *20260314 update) / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
|
|
*20260120 Update. Since the relevancy is based on 4 year history usage, the block is not considered as part of the relevancy rule, so remove the report | |||
| 3003-014 | C-2 | Customer with Obsolete GBU segment (KNVV-KVGR2) | For all the active customer in migration scope, the GBU segment value is not in the list for S4 Hana | Customer/Name/Country/Sales Org/Distribution Channel/Division/GBU Segment and Description / CSR Name / Account Manager Name / Geo Region / GBU/ (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
| 3003-015 | C-2 | Customer with Team Cluster information (for DCT purposes) | For all the active customer in migration scope, there is team cluster information maintained in the sales data *20260203 update general to sales data as the info in KNVV | Customer/Name/Country/Sales Org/Distribution Channel/Division/Team Cluster and Description / CSR Name / Account Manager Name / Geo Region / GBU / (include account group/description into each report (KNA1-KTOKD, description T077D)*20260314 update ) | WP2/PF2 |
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 using migration cockpit.
Data Privacy and Sensitivity
N/A
Extraction
Extract data from a source into Syniti Migrate for SAP ROW and SAP China relevant entities. There are 2 possibilities:
- The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
- Perform full data extraction from relevant tables in the source system(s).
- Perform extraction through the application layer.
- Only if Syniti Migrate cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
- The data does not exist (or cannot be converted from its current state). The data is manually collected by the business directly in Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate
The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads.
Extraction Run Sheet
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| Extraction Scope Definition | - Identify the source systems and databases involved. Major tables to be extracted are KNVV/KNVI/KNVP | Data team |
| 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 |
| Extraction Execution Plan | - Establish execution timelines and batch processing schedules. - Assign responsibilities for extraction monitoring. - Document dependencies on other migration tasks. | Syniti |
| Data Quality and Validation | - Define error handling mechanisms for extraction failures. | Syniti |
Selection Screen
If applicable, this section will give the details on any selection screen parameters, including the parameter type, that are required to be entered to ensure consistent data extracts.| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
| N/A | ||||
Data Collection Template (DCT)
Target Ready Data Collection Template will be created for Customer sales view data with exception of some fields which require transformation as mentioned in the transformation rule.Customer sales view DCT Rules
A. Sales Group
| Field Name | Field Description | Rule |
|---|---|---|
| KUNNR | Customer Number | Mandatory Key link to Customer master table KNA1. Prepopulate the customer number which has value in |
| NAME1 | Customer Name | Display only link to Customer master table KNA1 |
| VKORG | Sales Org | Only allow valid sales org for this customer based on the KNVV record after sales transformation |
| VTWEG | Distribution Channel | Only allow valid distribution channel for this customer based on the KNVV record after sales transformation |
| SPART | Division | default 01 |
| VKGRP | Sales Group | Refer to Table MAP_ZZTEAMC for mapping first |
| TEXT40 | Sales Group Description | Display only |
B. Customer Group 1
| ||
| ||
| ||
|
C. Incoterm *20260203 There is ongoing ECC project to clean this, so no need to use DCT any more.
| ||
| ||
| ||
|
D. Customer Sales View data collection - Sales Data (For intercompany and any new customer outside of ECC)
For Customer Sales View, the the intercompany part, the value will be prepopulated based on the enterprise structure and the configuration of sales area/plant assignment.
| Field Name | Field Description | Rule |
| KUNNR | Customer Number | mandatory for sheet |
| VKORG | Sales Organization | mandatory for sheet check table TVKO. Include the code and description *20260210 update |
| VTWEG | Distribution Channel | mandatory for sheet check table TVTW. Include the code and description *20260210 update |
| SPART | Division | mandatory for sheet |
| VKBUR | Sales Office | check table TVBUR. Include the code and description *20260210 update |
| VKGRP | Sales Group | check table TVBVK. Include the code and description *20260210 update |
Remove *20260210 update | ||
| WAERS | Currency | |
| KURST | Exchange Rate Type | check table TCURV. Include the code and description *20260210 update |
| KALKS | Price Procedure Dterm. | check table TVKD. Include the code and description *20260210 update |
| AGREL | Indicator: Rel. for Settlement Managment | |
| LPRIO | Delivery Priority | check table TPRIO. Include the code and description *20260210 update |
| KZAZU | Order Combination | |
| VSBED | Shipping Conditions | check table TVSB. Include the code and description *20260210 update |
| PODKZ | POD-Relevant | |
| PODTG | POD Timeframe | |
| VWERK | Delivery Plant | check table T001W. Include the code and description *20260210 update |
| AUTLF | Complete Delivery Required | |
| ANTLF | Maximum Number of Part. Deliveries | |
| KZTLF | Partial Delivery per Item | |
| UNTTO | Underdelivery Tolerance | |
| UEBTO | Overdelivery Tolerance | |
| PERFK | Invoicing Dates | check table TFACD. Include the code and description *20260210 update |
| PERRL | Invoice List Schedule | check table TFACD. Include the code and description *20260210 update |
| INCO1 | Incoterms | check table TINC. *20260210 update |
| INCO2_L | Inco. Location1 | |
| ZTERM | Payment Terms | check table T052U. Include the code and description *20260210 update |
| KABSS | Payment Guarantee Procedure |
Not in use*20260305 update |
| KTGRD | Account Assignment Group | check table TVKT. Include the code and description *20260210 update |
| KVGR1 | Customer Group 1 | check table TVV1. Include the code and description *20260210 update |
| KVGR2 | Customer Group 2 | check table TVV2. Include the code and description *20260210 update |
Not in use*20260305 update |
E. Customer Sales View data collection - Partner Data (For intercompany and any new customer outside of ECC)
| Field Name | Field Description | Rule |
| KUNNR | Customer Number | mandatory for sheet |
| VKORG | Sales Organization | mandatory for sheet check table TVKO. Include the code and description *20260210 update |
| VTWEG | Distribution Channel | mandatory for sheet check table TVTW. Include the code and description *20260210 update |
| SPART | Division | mandatory for sheet |
| PARVW | Partner Function | mandatory for sheet check table TPAR. Include the code and description *20260210 update |
| KUNN2 | Customer ID | |
| LIFNR | Vendor ID | |
| PERNR | Employee ID | |
| PARNR | Contact Person ID | |
| DEFPA | Default | |
| KNREF | Partner Description |
F. Customer Sales View data collection - Output Tax (For intercompany and any new customer outside of ECC)
| Field Name | Field Description | Rule |
| KUNNR | Customer Number | mandatory for sheet |
| LAND | Country/Region | mandatory for sheet check table T005. Include the code and description *20260210 update |
| TATYP | Tax Category | mandatory for sheet |
| TAXKD | Tax Classification | check table TSKD. Include the code and description *20260210 update |
Extraction Dependencies
List the steps that need to occur before extraction can commence
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Source System Availability
| Syensqo IT |
| 2 | Data Structure
| Syniti |
| 3 | Referential Integrity
| Syniti |
| 4 | Extraction Methodology
| Syniti |
| 5 | Performance and Scalability Considerations
| Syniti |
| 6 | Security and Compliance
| Syniti |
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.
- Legacy values are mapped to the to-be values (this could include a default value)
- 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 | Identify target S/4HANA fields and determine applicable legacy source fields from both ECC systems WP2, PF2 | Functional Team + Data Team |
| 2 | Map legacy field values to S/4HANA target values (including field-level mapping and technical names) | Data Team, Data Team (Syniti) |
| 3 | Define value mapping rules for fields requiring standardization or harmonization across the two source systems WP2, PF2 | Functional Team + Data Team |
| 4 | Identify and agree on default values where legacy data is incomplete or inconsistent | Business Team + Functional Team |
| 5 | Configure transformation rules in Syniti Migrate | Data Team (Syniti), Data Team |
| 6 | Review transformation logic and mappings with Business for confirmation | Business Team + Functional Team |
| 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 , Functional Team |
| 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 |
| 11 | Finalize and approve transformed data as Target Ready Load File | Business + Functional + Data Team |
| 12 | Handover final file to Load Team or trigger the load via Syniti Load Workbench | Data Team (Syniti), Data Load Team |
Transformation Rules
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
| 1 | WP2/PF2 | KNVI | KUNNR | Customer | S4 Hana | KNVI | KUNNR | Customer | Mapping - Map based on new S4 BP partner number |
| 2 | WP2/PF2 | KNVI | ALAND | Departure Ctry/Reg. | S4 Hana | KNVI | ALAND | Departure Ctry/Reg. | Rule - Join KNVV with TVKWZ and T001W, it will get the combination of VKORG/LAND. |
| 3 | WP2/PF2 | KNVI | TATYP | Tax Condition Type | S4 Hana | KNVI | TATYP | Tax Condition Type | Rule - Join KNVV with TVKWZ and T001W, it will get the combination of VKORG/LAND. Then join TSTL using the LAND, it will get the condition type (TATYP) enabled in the system. KNVI will be based on this logic to determine how many records will be maintained. |
| 4 | WP2/PF2 | KNVI | TAXKD | Tax Classification | S4 Hana | KNVI | TAXKD | Tax Classification | Rule - 1. Refer to MAP_TAXKD mapping first, if there is entry found, map based on the value in the mapping table 2. If there is no value found, default to TBD |
| 5 | WP2/PF2 | KNVP | KUNNR | Customer | S4 Hana | KNVP | KUNNR | Customer | Mapping - Map based on new S4 BP partner number |
| 6 | WP2/PF2 | KNVP | VKORG | Sales Organization | S4 Hana | KNVP | VKORG | Sales Organization | Rule - Refer to MAP_VKORG When one legacy VKORG is mapped to multiple VKORG based on mapping table, it should multiply the sales view data, meaning creating additional KNVV/KNVP/KNVI records etc |
| 7 | WP2/PF2 | Distribution Channel | S4 Hana | KNVP | VTWEG | Distribution Channel | Rule - Follow KNVV records transformation result | ||
| 8 | WP2/PF2 | Division | S4 Hana | KNVP | SPART | Division | Default - Default to 01 - Product | ||
| 9 | WP2/PF2 | KNVP | PARVW | Partner Function | S4 Hana | KNVP | PARVW | Partner Function | Rule - 1. Refer to MAP_PARVW for existing partner function 2. Add a new partner function VE |
| 10 | WP2/PF2 | KNVP | KUNN2 | Customer | S4 Hana | KNVP | KUNN2 | Customer | Mapping - 1. For existing partner, Map based on new S4 BP number |
| 11 | WP2/PF2 | KNVP | LIFNR | Supplier | S4 Hana | KNVP | LIFNR | Supplier | Mapping - Map based on new S4 BP number |
| 12 | WP2/PF2 | KNVP | PERNR | Personnel Number | S4 Hana | KNVP | PERNR | Personnel Number | Rule - 1. Map based on new S4 BP Employee partner number 2. When KNVV-VKGRP has value, map it to VE partner function. For the value, refer to mapping file MAP_VKGRP |
| 13 | WP2/PF2 | KNVP | PARNR | Contact Person | S4 Hana | KNVP | PARNR | Contact Person | Mapping - Map based on new S4 BP number |
| 14 | WP2/PF2 | KNVP | KNREF | Partner description | S4 Hana | KNVP | KNREF | Partner description | Copy - |
| 15 | WP2/PF2 | KNVP | DEFPA | Default Partner | S4 Hana | KNVP | DEFPA | Default Partner | Copy - |
| 16 | WP2/PF2 | KNVV | KUNNR | Customer | S4 Hana | KNVV | KUNNR | Customer | Mapping - Map based on new S4 BP partner number |
| 17 | WP2/PF2 | KNVV | VKORG | Sales Organization | S4 Hana | KNVV | VKORG | Sales Organization | Rule - Refer to MAP_VKORG When one legacy VKORG is mapped to multiple VKORG based on mapping table, it will create multiple KNVV/KNVP/KNVI records etc. |
| 18 | WP2/PF2 | KNVV | VTWEG | Distribution Channel | S4 Hana | KNVV | VTWEG | Distribution Channel | Rule - When it is external customer and the Ship to customer (KNVP-KUNNR where PARVW = SH) is in the same country (KNA1-LAND) as the sales org (T001-COUNTRY WHERE TVKO-BURKS = T001-BUKRS), it is mapped to Domestic When it is external customer and the Ship to customer is in the different country as the sales org, it is mapped to Export When it is external customer, and there are multiple ship-to, some is domestic, some is export. then multiply the sales view data based on Domestic/Export distribution channel. Validate VBPA records for 4 year transaction. Check Ship-to party is Export or Domestic. Then apply the result to all the VBPA-KUNN2 for the same documents. Compare based on KUNN2(KUNNR)/VKORG combination with KNVV records to see if it is matching or there is missing. If there is missing, it will require to create the KNVV records for the combination of KUNNR/VKORG for the missing distribution channels When it is an intercompany customer, it is mapped to Intercompany |
| 19 | WP2/PF2 | KNVV | SPART | Division | S4 Hana | KNVV | SPART | Division | Default - Default to 01 - Product |
| 20 | WP2/PF2 | KNVV | LOEVM | Del. indicator for sales area | S4 Hana | KNVV | LOEVM | Del. indicator for sales area | Copy - |
| 21 | WP2/PF2 | KNVV | AUFSD | Order block for sales area | S4 Hana | KNVV | AUFSD | Order block for sales area | Mapping - refer to MAP_AUFSD |
| 22 | WP2/PF2 | KNVV | KALKS | Cust.Pric.Procedure | S4 Hana | KNVV | KALKS | Cust.Pric.Procedure | Default - '1' |
| 23 | WP2/PF2 | KNVV | KDGRP | Customer Group | S4 Hana | KNVV | KDGRP | Customer Group | Not in Use |
| 24 | WP2/PF2 | KNVV | INCO1 | Incoterms | S4 Hana | KNVV | INCO1 | Incoterms |
Copy - For standard incoterm, it will be copy only.
|
| 25 | WP2/PF2 | KNVV | LIFSD | Delivery block for sales area | S4 Hana | KNVV | LIFSD | Delivery block for sales area | Mapping - refer to MAP_LIFSD |
| 26 | WP2/PF2 | KNVV | AUTLF | Complete Delivery | S4 Hana | KNVV | AUTLF | Complete Delivery | Copy - |
| 27 | WP2/PF2 | KNVV | ANTLF | Max.Part.Deliveries | S4 Hana | KNVV | ANTLF | Max.Part.Deliveries | Copy - |
| 28 | WP2/PF2 | KNVV | KZTLF | Part.dlv./item | S4 Hana | KNVV | KZTLF | Part.dlv./item | Copy - |
| 29 | WP2/PF2 | KNVV | KZAZU | Order Combination | S4 Hana | KNVV | KZAZU | Order Combination | Copy - |
| 30 | WP2/PF2 | KNVV | LPRIO | Delivery Priority | S4 Hana | KNVV | LPRIO | Delivery Priority |
*20260317 Mapping - Refer to MAP_LPRIO |
| 31 | WP2/PF2 | KNVV | VSBED | Shipping Conditions | S4 Hana | KNVV | VSBED | Shipping Conditions | Mapping - Refer to MAP_VSBED |
| 32 | WP2/PF2 | KNVV | FAKSD | Billing block for sales area | S4 Hana | KNVV | FAKSD | Billing block for sales area | Mapping - Refer to MAP_FAKSK |
| 33 | WP2/PF2 | KNVV | PERFK | Invoicing Dates | S4 Hana | KNVV | PERFK | Invoicing Dates | Mapping - Refer to MAP_PERFK |
| 34 | WP2/PF2 | KNVV | PERRL | Invoice List Sched. | S4 Hana | KNVV | PERRL | Invoice List Sched. | Mapping - Refer to MAP_PERFK |
| 35 | WP2/PF2 | KNVV | WAERS | Currency | S4 Hana | KNVV | WAERS | Currency | Copy - |
| 36 | WP2/PF2 | KNVV | KTGRD | Acct Assmt Grp Cust. | S4 Hana | KNVV | KTGRD | Acct Assmt Grp Cust. | Rule - Based on Distribution channel to determine the value 01 Domestic Revenues for 20 DC |
| 37 | WP2/PF2 | KNVV | ZTERM | Terms of Payment | S4 Hana | KNVV | ZTERM | Terms of Payment | Mapping - Refer to MAP_ZTERM |
| 38 | WP2/PF2 | KNVV | VWERK | Delivering Plant | S4 Hana | KNVV | VWERK | Delivering Plant | Mapping - Refer to MAP_WERKS |
| 39 | WP2/PF2 | KNVV | ZZTEAMC | Sales Group | S4 Hana | KNVV | VKGRP | Sales Group | DCT - Refer to Table MAP_ZZTEAMC for mapping first Data collection based on customer market segment. 001 Mining Solutions 002 Phosphorous Specialties 003 Polymer Additives 004 Home and Personal Care 005 Agro 006 Coatings 007 Industrial Process Solutions 008 Transportation 009 Batteries 010 Green Hidrogen 011 Life Solutions 012 Channel & Digital Sales 013 Electronics & Industrial 014 Intercompany 015 Aerospace and Defense 016 Consumer, Healthcare, Environment 017 Channel Partners 018 Transportation (Auto and Aero) |
| 40 | WP2/PF2 | KNVV | VKBUR | Sales Office | S4 Hana | KNVV | VKBUR | Sales Office | Mapping - Refer to MAP_VKBUR |
| 41 | WP2/PF2 | KNVV | KVGR2 | Customer Group 2 | S4 Hana | KNVV | KVGR2 | Customer Group 2 | Rule - Copy from KNVV-KVGR2 field, but only below value allowed *20260317 Mapping - MAP_KVGR2 CS1 - Strategic Key Accounts |
| 42 | WP2/PF2 | KNVV | KURST | Exchange Rate Type | S4 Hana | KNVV | KURST | Exchange Rate Type |
Mapping - refer to MAP_KURST |
| 43 | WP2/PF2 | KNVV | PRFRE | Price determination | S4 Hana | KNVV | PRFRE | Price determination | Not in use |
| 44 | WP2/PF2 | KNVV | KABSS | Paymt guarant. proc. | S4 Hana | KNVV | KABSS | Paymt guarant. proc. |
Not in use*20260305 update |
| 45 | WP2/PF2 | KNVV | CASSD | Sales Block for Sales Area | S4 Hana | KNVV | CASSD | Sales Block for Sales Area | Copy - *20260219 update to copy
|
| 46 | WP2/PF2 | KNVV | AGREL | Settlement Mgmt. | S4 Hana | KNVV | AGREL | Settlement Mgmt. | Copy - |
| 47 | WP2/PF2 | KNVV | UEBTO | Overdeliv. Tolerance | S4 Hana | KNVV | UEBTO | Overdeliv. Tolerance | Copy - |
| 48 | WP2/PF2 | KNVV | UNTTO | Underdel. Tolerance | S4 Hana | KNVV | UNTTO | Underdel. Tolerance | Copy - |
| 49 | WP2/PF2 | KNVV | PODKZ | Relevant for POD | S4 Hana | KNVV | PODKZ | Relevant for POD | Default to 'X' |
| 50 | WP2/PF2 | Incoterm Location 1 | S4 Hana | KNVV | INCO2_KEY | Incoterm Location 1 |
Rule: by default it will be the same ID as BP number (BUT000-PARTNER) (10 digits with leading 0). | ||
| 51 | WP2/PF2 | KNVV | ZZ_SINGLE_PACKING_LIST | Single Packing List | S4 Hana | KNVV | ZZ_SINGLE_PACKING_LIST | Single Packing List | Copy - |
| 52 | WP2/PF2 | KNVV | ZZ_SINGLE_PARENT_BATCH | Single Parent Batch | S4 Hana | KNVV | ZZ_SINGLE_PARENT_BATCH | Single Parent Batch | Copy - |
| 53 | WP2/PF2 | KNVV | ZZ_WHOLE_NUMBER_REQUIRED | Whole number Required | S4 Hana | KNVV | ZZ_WHOLE_NR | Whole number Required | Copy - |
| 54 | WP2/PF2 | STXH | TDOBJECT | Text object | S4 Hana | STXH | TDOBJECT | Text object | Copy - It will include those KNVV object text |
| 55 | WP2/PF2 | STXH | TDNAME | Text Name | S4 Hana | STXH | TDNAME | Text Name | Rule - The format is AAAAAAAAAA/BBBB/CC/DD A - Customer Number map to S4 BP Number B - Sales Org mapping - MAP_VKORG C - Distribution Channel mapping - Follow KNVV-VTWEG conversion value D - Division default to 01 |
| 56 | WP2/PF2 | STXH | TDID | Text ID | S4 Hana | STXH | TDID | Text ID | Mapping - Refer to MAP_TDID_KNVV |
| 57 | WP2/PF2 | STXH | TDSPRAS | Language Key | S4 Hana | STXH | TDSPRAS | Language Key | Copy - |
| 58 | WP2/PF2 | STXL | TDOBJECT | Text object | S4 Hana | STXL | TDOBJECT | Text object | Copy - |
| 59 | WP2/PF2 | STXL | TDNAME | Text Name | S4 Hana | STXL | TDNAME | Text Name | Mapping - The format is AAAAAAAAAA/BBBB/CC/DD A - Customer Number map to S4 BP Number B - Sales Org mapping - MAP_VKORG C - Distribution Channel mapping - Follow KNVV-VTWEG conversion value D - Division default to 01 |
| 60 | WP2/PF2 | STXL | TDID | Text ID | S4 Hana | STXL | TDID | Text ID | Mapping - Refer to MAP_TDID_KNVV |
| 61 | WP2/PF2 | STXL | TDSPRAS | Language Key | S4 Hana | STXL | TDSPRAS | Language Key | Copy - |
| 62 | WP2/PF2 | STXL | CLUSTD | Data | S4 Hana | STXL | CLUSTD | Data | Copy - |
| 63 | WP2/PF2 | S4 Hana | KNVV | KVGR1 | Customer Group 1 | Not in Use
| |||
| 64 | WP2/PF2 | S4 Hana | KNVV | KVGR5 | Customer Group 5 |
Not in use*20260305 update | |||
| 65 | WP2/PF2 | KNVV | PODTG | POD timeframe | KNVV | PODTG | POD timeframe | Copy |
List of Custom Target Reports for this object is maintained here: Conversion Specification - Custom Reports Register.
Transformation Mapping
Use the exact name and reference this section in the “Transformation rules” above| Mapping Table Name | Mapping Table Description |
|---|---|
| MAP_VKORG | Sales Organization Mapping Table |
| MAP_ZTERM | Payment terms Mapping table |
| MAP_PARVW | Partner Function Mapping table |
| MAP_VKGRP | Sales Group Mapping to new partner function |
| MAP_PERFK | Invoice/Invoice List Calendar Mapping |
| MAP_VKBUR | Sales Office Mapping |
| MAP_VSBED | Shipping Condition Mapping |
| MAP_TDID_KNVV | Text in Sales View mapping |
| MAP_TATYP | Customer Tax condition type mapping |
| MAP_TAXKD | Customer Tax classification mapping |
| MAP_WERKS | Plant Mapping |
| MAP_LIFSD | Delivery block mapping |
| MAP_FAKSK | Billing block mapping |
| MAP_AUFSD | Customer Order Block |
| MAP_KURST | Exchange Rate mapping |
Not in use*20260305 update | |
Not in use*20260305 update | |
| MAP_KVGR2 | GBU (Customer group 2 field) *20260317 Mapping table update |
| MAP_ZZTEAMC | Sales Group mapping *20260317 Mapping table update |
| MAP_LPRIO | Delivery priority mapping *20260317 Mapping table update |
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, such as CNV-3007 Business Partner General | 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
The following pre-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| Compare Data Counts |
|
| Validate the mandatory fields | Validate there is value for all the mandatory fields |
| Validate Primary Keys and Unique Constraints |
|
| Test Referential Integrity | Confirm dependent records exist in related tables |
Accuracy
| Task | Action |
|---|---|
| Validate the transformation | Validate the fields which require transformation have the value after transformation instead of the original field value |
| Check Data Consistency |
|
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 |
|---|---|
| Compare Data Counts |
|
| Review populated templates for missing or incorrect values | Use checklists to verify completeness and correctness before submission |
Accuracy
| Task | Action |
|---|---|
| Check Data Consistency |
|
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 | Confirm readiness of final approved data sets for each ECC source system WP2 and PF2 | Business / Functional Team |
| 2 | Validate transformation rules and mappings in Syniti tool | Data Team |
| 3 | Generate target-ready load files based on S/4HANA condition table format | Data Team (Syniti) |
| 4 | Review and approve load files before execution | Business / Functional Team |
| 5 | Execute the custom loading program in the S/4HANA system | Data Load Team |
| 6 | Monitor load progress and capture load statistics (records loaded, errors, duplicates, etc.) | Data Team (Syniti) / Technical Team |
| 7 | Extract loaded data from S/4HANA for post-load validation | Data Team (Syniti) |
| 8 | Perform post-load data validation (compare target data with source/approved files) for all loaded customer sales view data | Data Team |
| 9 | Log and resolve any data load errors or mismatches identified during validation | Data Team + Functional Team + Syniti |
| 10 | Obtain business sign-off on successful load and validation | Business Team |
| 11 | Archive load logs, error reports, and validation results for audit/compliance | Data Team Data Team (Syniti) / PMO |
Load Phase and Dependencies
The Business Partner General will be loaded in the pre-cutover period.
Before loading, it will have dependency on the configuration.
Configuration
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
| 1 | Sales Area Definition |
| 2 | Sales Office Definition |
| 3 | Sales Group Definition |
| 4 | Payment Term definition |
| 5 | Define Tax Determination Rule |
| 6 | Define Billing Block |
| 7 | Define Delivery Block |
| 8 | Define Calendar |
| 9 | Define ABC Class |
| 10 | Define customer account assignment group |
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| 3007 | Business Partner General (Role 000000) |
| Employee Personal Information | |
| 3011 | Business Partners - Contact Persons (BUP001) |
| 1051 | TM - Locations |
Error Handling
The table below depicts some possible system errors for this data object during data load. All data load error is to be logged as defect and managed within the Defect Management
| Error Type | Error Description | Action Taken |
|---|---|---|
| Configuration / Data Transformation | The value XXX for field XXX doesn't exist |
|
| Configuration | There is mandatory field XXX missing |
|
Post-Load Validation
Project Team
The following post-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| Perform Source-to-Target Comparisons |
|
Accuracy
| Task | Action |
|---|---|
| Execute Sample Queries and Reports |
|
| Conduct Post-Migration Reconciliation | Generate reports comparing pre- and post-migration data. |
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 |
|---|---|
| Perform Source-to-Target Comparisons |
|
| Conduct Post-Migration Reconciliation | Go through reports comparing pre- and post-migration data. |
Accuracy
| Task | Action |
|---|---|
| Perform Manual Testing | Conduct manual spot-checks for additional assurance. |
Key Assumptions
- Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
- BP Customer sales view is in scope based on data design and any exception requested by business.
- There will be 2 SAP instances, one for ROW, one for China
and one for CUI only.* 20260219 remove CUI - One sales org will represent one GBU as captured in KDD060 - Sales Enterprise Structure.
See also
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.