Purpose

The purpose of this document is to define the data conversion approach for creating Pricing Condition Records in the SAP S/4HANA target system, as part of a Greenfield implementation.

In SAP ECC, sales pricing condition records exist as part of the pricing procedure configuration and are stored in condition tables such as KONV, A*, and related master and transactional tables. These records are used to define pricing elements such as base price, discounts, freight, and surcharges across sales documents.
 
In SAP S/4HANA, the structure and usage of pricing condition records remain largely consistent; however, data models may be simplified, and dependencies on business partners (replacing customer/vendor master records) become critical in ensuring consistency across sales and purchasing functions.
 
This conversion aims to migrate active and relevant sales pricing condition records from existing ECC systems into S/4HANA by applying required transformation logic using Syniti as the data migration and transformation platform. The converted records will be loaded into the target S/4HANA system using standard SAP mechanisms such as IDOCs, BAPIs, or direct table loads where applicable.

Conversion Scope

The scope of this document includes the end-to-end approach for:

• Extracting existing Pricing Condition Records from SAP ECC systems WP2 and PF2.
• Applying transformation and cleansing logic via Syniti to conform with the S/4HANA data model and business partner framework.
• Loading the transformed condition records into SAP S/4HANA while ensuring data integrity, correct assignment to condition types, condition tables, access sequences, and pricing procedures.

This process will support the migration of condition records such as:

• Base Price (e.g., PR00)
• Discounts (e.g., K007, K004)
• Freight and surcharges
• Transfer Prices

The conversion will ensure all condition records are aligned to the new Pricing Key combinations defined for example, based on Business Partner, Material Masters and relevant Organizational Units (Sales Org, Distribution Channel, Division) as designed for the target S/4HANA landscape.

The data from legacy system includes:

1. List price at various key combinations including scale-based pricing as applicable
2. Discounts and surcharges at various key combinations
3. Freight condition records at various key combinations

The data from legacy system excludes:

1. Rebate condition records will be managed via Condition contracts set up
2. Commissions condition records will be managed via Condition contracts set up ( Condition types : CV, CV1, CV2, Z95A, ZCOA, ZCOM )
3. Tax condition records that will be covered in CONV-1035 Tax condition records spec. 

Additional Information

Multi-language Requirement 

Not Applicable

Document Management

None identified. The conversion scope is limited to the migration of pricing condition data records. No document attachments, images, or supporting files are included.

Legal Requirement

N/A

Special Requirements

N/A

Target Design

The technical design of the target for this conversion approach.

Pricing Condition Data Structure for Migration

The illustration below depicts the typical structure of pricing condition records as used in S/4HANA. Each record is defined at the level of an access sequence (key combination) and a validity period for a given condition type.

In the SAP S/4HANA database, the condition data is physically stored across several transparent tables — primarily KONH (Condition Header), KONP (Condition Items) + Axxx Condition tables, KONW (Scales), and KONM (Scale Base). However, for migration purposes, the data must be organized into a structured file format that aligns with the Migration Cockpit upload template.

This structure consists of a parent node representing the Pricing Condition Record, with two sub-nodes:

1. Key Fields for Condition – capturing the access key (e.g., customer, material, sales org, distribution channel) that determines the condition table.

2. Scales – holding scale values, quantities, or amounts that define graduated pricing within the condition record.

This logical representation ensures that condition records can be uploaded consistently into S/4HANA using the Migration Cockpit app, while still preserving the technical mapping to the underlying condition tables in the system.

Overview of target S/4HANA transparent tables

The SAP tables listed above represent the final target tables that receive data upon completion of the overall migration process. However, during the conversion phase, each of these tables will have corresponding staging tables, which will serve as the target structures from a data migration perspective.

A separate migration template must be generated for data extraction from each source system. This ensures that system-specific values can be captured and transformed consistently.

In addition, there may be cases where ad-hoc data collection templates are required for specific target condition types that do not have corresponding or sufficient data available in the current ECC systems. These ad-hoc templates will be used to gather the missing data directly from business stakeholders or relevant functional teams.

Target Structure

Data Cleansing

Conversion Process

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

Overview of Pricing Conversion objects

Data Privacy and Sensitivity

Relevancy Criteria Summary

1. Select Relevant Records Based on Validity :  Extract all pricing condition records that are valid as of the defined cut-off date for open sales order migration. Only include records with a validity end date greater than four years prior to the go-live date for the sales organizations in scope 
2. Exclude Condition Records :  
     - Commission conditions records are out of scope, as commissions will be handled through Condition Contracts maintained manually during BAU.
     - Rebates condition records are excluded from this extraction and will instead be processed in accordance with Conversion Specification 9066.
     - Tax condition records are excluded and will be addressed separately in line with Conversion Specification 1035. 
     - All pricing condition record that is flagged / marked for deletion
     - All pricing condition records created for customers or materials that are not within the migration scope, based on the respective Customer and Material Mapping Tables.
3. Condition Types in Scope :  The list of condition types to be migrated will be controlled via a custom mapping table MAP_KSCHL_PRICING. This table will be maintained and updated for each conversion cycle (e.g., Mock, UAT, ACO).
4. Usage-Based Filtering :  Only retain pricing condition records that have been used in at least one Sales or Billing document within the last four years, specifically considering documents created for the sales organizations and sales document types within the defined project scope. Condition records that have not been referenced in any relevant transactional documents during this period, or that pertain to sales organizations outside the scope, will be excluded from the dataset.

Extraction

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

1. The data exists. connects to the source and loads the data into . 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 ; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
2. The data does not exist (or cannot be converted from its current state). The data is manually collected by the business directly in . This is to be conducted using DCT (Data Collection Template) in

The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads

Extraction Run Sheet

Selection Screen

Data Collection Template (DCT)

A Target Ready Data Collection Template will be created for the required data, except for fields that need transformation as per the defined transformation rules. These templates will follow the format required by the target S/4HANA pricing configuration.

Each template corresponds to a specific condition table structure, designed to handle data based on the key combinations used for one or more condition types. You can identify the correct template based on the condition type and the relevant sales organizations or entities.

Please find the complete list of Data Collection Templates in the link attached below.

DCT-CNV-1034-Pricing Condition Records V1.0

Please note, creation of Data collection template must be aligned with pricing configurations for Condition types, Access sequence and Associated Condition Tables.  For now, the following Template is prepared based on Pricing Configurations from S/4HANA Sandbox environment.  This will be replaced once the pricing configuration is ready.

Based on feedback received during DCT Rollout sessions conducted on 28-Jan-2026 and subsequent alignment discussions, it is agreed that the data collection specific to SPEC ID pricing will no more required as the necessary data currently available in Salesforce system and it will be applied in Sales Contracts and Quotations from Salesforce. The required pricing for SPEC ID will flow into S/4HANA as contract / quotation specific prices.

DCT Rules

Extraction Dependencies

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 to make the data Target ready:

1. Perform value mapping and data transformation rules.
   1. Legacy values are mapped to the to-be values (this could include a default value)
   2. Values are transformed according to the rules defined in
2. Prepare target-ready data in the structure and format that is required for loading via prescribed Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation

Transformation Run Sheet

Transformation Rules

The source and target tables have the same fields as listed in the key combination.  

Transformation Mapping

Transformation mapping must be applied using the respective MAP_* tables for the fields listed below. The transformed values will be used in the Key Fields for Condition section of the migration template.

For each field included in the target key combination, the source value must be validated and, if required, transformed using the corresponding mapping table before being assigned to the target field. This ensures consistency between source and target systems and prevents invalid or unmapped values from being migrated.

Proposed Mapping for Pricing Condition Types (Data Construction Page) 

The following mapping table has been designed to define the relationship between source Pricing Condition Types and their corresponding target condition types and transparent tables in S/4HANA. In addition to serving as the basis for determining the appropriate target objects, this mapping acts as a control mechanism to ensure that only valid records with corresponding configuration available in the target system are migrated.

Any records that lack a valid target condition type or condition table assignment will be excluded from the data extraction process. Sample entries have been included based on the current ECC data. The final target values will be manually maintained once the pricing configuration is completed and the condition tables are available.

Key Combination Field Transformation

The Key Combination field defines the set of fields that uniquely identify a condition record. For each source condition record, the values of these fields must be mapped (where applicable) using the relevant mapping tables and then transferred to the equivalent fields defined in the target Key Combination.

The list of fields used in a given key combination can also be derived from the DD03L table in the respective source and target systems.

Example:

• Source Key Combination: VKBUR / VKORG / VTWEG / SPART / KUNNR / MATNR

• Target Key Combination: VKBUR / VKORG / VTWEG / SPART / KUNNR / MATNR

In this case, the value found in the source field VKBUR must be transformed using the MAP_VKBUR mapping table. The transformed value is then assigned to the VKBUR field in the target key combination, creating a new key-value pair in the target Key Fields for Condition structure.

When Release Status is enabled, a new Key value pair for field "KFRST" with Blank value needs to be added in the target Key Fields for Condition structure.

Distribution Channel Mapping

Transformation Dependencies

Conversion logic for Condition values

When copying data between SAP tables condition values from field KBETR can be copied directly without transformation.  But for ETL involving extracted load file,  condition values may require transformation depending on the condition type and currency.

The following rules apply:

• Condition Type (%)
• If the condition type is percentage (T685A-KRECH = A), divide the value by 10.
• Currency Conversion (TCURX Table Reference)
• Check the number of decimal places maintained for the currency in TCURX.
• Conversion rule:

Scale Factor=10^{(2−Decimal_Places)}

• If the result is positive, multiply the value.
• If the result is negative, divide the value.
• If the result is zero, keep the value unchanged.
• Other Cases
• Copy the value as-is.

 Example :

Unit of Measure ISO Code determination

1. S/4HANA uses ISO codes for Units of Measure.
2. "ST" might exist in legacy ECC system as a UoM for pieces, but in S/4, the system expects PC (or another ISO-compliant code).
3. The Migration Cockpit validates the mapping against table T006 (Units of Measure) and ISO code mapping.
4. Input PC Preferably internal code ST in T006 and get the ISO Code as input to the load file

Key Adjustment for Legacy KNUMH

During data migration, the legacy key KNUMH must be adjusted to ensure uniqueness across multiple source systems.

• Replace the first character of the 10-digit legacy KNUMH with a system-specific prefix:

  • PF2: Replace the first character with 1

  • WP2: Replace the first character with 2

Example:

• Legacy KNUMH 0016781971 → Migrated as 1016781971 (for PF2)

• Legacy KNUMH 0016781971 → Migrated as 2016781971 (for WP2)

This ensures that condition records originating from different source systems remain uniquely identifiable in the target migration data.

Based on distribution channel determination, there might be a need to split a condition record into two when the existing ECC condition records used in both Domestic and Export sales.  Please apply the following logic to KNUMH record which needs to be unique in the load file to enable loading two records in target system S/4 HANA. The expectation is to have unique legacy number in KNUMH field which is temporary only and will be re-numbered when the condition record created in target system. So, the logic can be applied only for the newly inserted condition record  in order to simplify the approach.

In scenarios where records are split for Export and Import, it is proposed to utilize the second character of the KNUMH to indicate the distribution channel:

• Use “1” as the second character for Distribution Channel 10
• Use “2” as the second character for Distribution Channel 20

Examples:

• For Distribution Channel 10: 1108397114 : Legacy KNUMH 0016781971 → Migrated as 1116781971 (for PF2) & Migrated as 2116781971 (for WP2)
• For Distribution Channel 20: 1208397114 : Legacy KNUMH 0016781971 → Migrated as 1216781971 (for WP2) & Migrated as 2216781971 (for WP2)

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Load

The load process includes:

1. Execute the automated data load into target system using load tool or product the load file if the load must be done manually
2. Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation

Load Run Sheet

Load Phase and Dependencies

Configuration

Conversion Objects

Error Handling

As part of the sales pricing condition data load from multiple SAP ECC systems to a single S/4HANA instance using the Syniti data migration tool, various data quality, configuration, and technical challenges may arise. These errors typically occur during the transformation, load, and post-load validation phases and can impact the accuracy, completeness, or acceptance of condition records in the target system.

The following table outlines the most commonly observed error types during data load, and the corrective actions typically taken to resolve them. This helps ensure consistency in issue handling, improves traceability during cutover, and supports smooth end-to-end execution of the pricing condition load.

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• is in scope based on data design and any exception requested by business.

See also

Change log

Workflow history