| Status | Approved |
|---|---|
| Owner | |
| Stakeholders |
Purpose
The purpose of this document is to define the data conversion approach for creating Tax Condition Records in the SAP S/4HANA target system, as part of a Greenfield implementation.
In SAP ECC, sales tax condition records for Tax condition types that exist as part of the pricing procedure configuration and are stored in condition tables such as A*, KONV, and related master and transactional tables. These records are used to define tax elements such as sales tax, VAT, GST, etc., across sales documents.
In SAP S/4HANA, the structure and usage of sales condition records remain largely consistent; however, data models may be simplified, and dependencies on country of sales, receiver's country, Tax Codes for sales become critical in ensuring consistency across sales functions.
This conversion aims to migrate active and relevant tax condition records from the existing ECC system into S/4HANA. The data will be extracted, either by reference or manual entry into the Data Collection Template (DCT). All necessary transformation logic will be applied using Syniti as the data migration and transformation platform, ensuring that the tax determination in S/4HANA aligns with current ECC behavior and meets all applicable tax requirements.. The converted records will be loaded into the target S/4HANA system using standard SAP mechanisms such as SAP Migration cockpit or LSMW.
Conversion Scope
The scope of this document includes the end-to-end approach for:
- Utilize tax requirements documented via SAP S/4HANA R2R Tax Configuration for (VAT/GST) to generate data in Data Collection Templates
- Extracting existing Tax Condition Records from SAP ECC systems WP2 and PF2 as reference and prepare data in Data Collection Templates.
- 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:
- Output Tax (e.g., MWST)
- US Tax per document (e.g., UTXD)
- India GST ( e.g., JOCG )
The data from legacy system includes:
Tax condition records relevant for sales transactions, maintained across applicable tax codes and jurisdiction codes
Tax rates for output tax determination (e.g., VAT, GST, sales tax)
Tax exemption indicators or reduced rates as per customer-specific agreements
Effective and expiration dates for tax condition records
The data from legacy system excludes:
Pricing condition records (managed via CNV-1034 Pricing Condition Records Specification)
Rebate condition records (managed via CNV-9066 Open Condition Contracts Specification)
Withholding tax condition records (Manually maintained during Cutover Activity)
| Source | Scope | Source Approx. No. of Records | Target System | Target Approx. No. of Records |
|---|---|---|---|---|
| WP2 | Tax Condition Records | 104,000 (Used as Reference Only) | S/4HANA System | 0 |
| PF2 | Tax Condition Records | 72,000 (Used as Reference Only) | S/4HANA System | 0 |
| DCT | MWST Condition Records - R2R Tax Configuration for VAT/GST | 3,000 | S/4HANA System | 3,000 |
Additional Information
Multi-language Requirement
Not Applicable
Document Management
None identified. The conversion scope is limited to the migration of tax condition data records. No document attachments, images, or supporting files are included.
Legal Requirement
Special Requirements
Target Design
The technical design of the target for this conversion approach.
Tax condition records Data Structure for Migration
The illustration below depicts the typical structure of Tax 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 Tax Condition Record, with two sub-nodes:
Key Fields for Condition – capturing the access key (e.g., customer, material, sales org, distribution channel) that determines the condition table.
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
| Node / Structure | Technical Table(s) | Purpose / Description |
| Pricing Condition Record | KONH + KONP | Condition header (validity period, release status, condition type, access sequence) - Contains condition rate, currency, unit of measure, etc. |
| Key Fields for Condition | condition tables (Axxx) | Defines the key combination that determines which condition table is used (e.g., Departure Country, Destination Country, Tax Classification for Customer / Material etc.,). |
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 DCT. 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 / not covered in R2R Tax Configuration document. These ad-hoc templates will be used to gather the missing data directly from business stakeholders or relevant functional teams.
Target Structure
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement | Remarks |
|---|---|---|---|---|---|---|---|
Pricing Condition Records | |||||||
| KONH | KNUMH | KNUMH | Condition Record No.* | CHAR | 10 | Required | Temporary number of your condition record. The record will be renumbered in the target system. You can, for example enter the legacy key of your condition record. |
| KONP | KAPPL | KAPPL | Application* | CHAR | 2 | Required | Subdivides the usage of a condition (for example, pricing, tax) for use in different application areas (for example, sales & distribution or purchasing). |
| KONP | KSCHL | KSCHA | Condition Type* | CHAR | 4 | Required | The condition type indicates, for example, whether, during pricing, the system applies a price, a discount, a surcharge, or other pricing elements, such as freight costs and sales taxes. For each of these pricing elements, there is a condition type defined in the system. |
| KONH | DATAB | DATAB | Valid From* | DATS | 8 | Required | When you create an object, the beginning date to which object is valid is defined here. |
| KONH | DATBI | DATBI | Valid To* | DATS | 8 | Required | When you create an object, you use the ending date to define as of when the object is valid. |
| KONP | KRECH | KRECH | Calculation Type | CHAR | 80 | Required | Determines how the system calculates prices, discounts, or surcharges in a condition. For example, the system can calculate a price as a fixed amount or as a percentage based on quantity, volume, or weight. |
| KONP | KBETR | KBETR | Amount | Number | 11,2 | Required | The rate that determines how the system calculates pricing/tax using this condition. Depending on the condition type, the rate can be a fixed amount or a percentage. |
| KONP | KONWA | KONWA | Condition Unit (Percentage) | CUKY | 5 | Required | The unit that determines whether the condition for a product is based on a percentage or on an amount in a particular currency. The use of the condition unit depends on the condition type. Examples: If you are creating a condition based on percentage discounts or surcharges, you leave the field empty or fill %. The system automatically enters a percent sign as the condition unit. |
| KONP | MWSK1 | MWSKZ | Tax Code | CHAR | 2 | Required | The tax code represents a tax category which must be taken into consideration when making a tax return to the tax authorities. Tax codes are unique per country/region. |
| Key Fields For Condition | |||||||
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement | Remarks |
/1LT/DSM23001319 | KNUMH | KNUMH | Condition Record No.* | CHAR | 10 | Required | Temporary number of your condition record. The record will be renumbered in the target system. You can, for example enter the legacy key of your condition record. |
/1LT/DSM23001319 | FIELDNAME | FIELDNAME | Field Name* | CHAR | 30 | Required | Enter the field name for the condition according to SAP note 2332748. |
/1LT/DSM23001319 | FIELDVALUE | N/A | Field Value | CHAR | 80 | Required | Enter the field value that corresponds to the field name. |
Relevancy Criteria Summary
- Select Relevant Records Based on Validity : Extract all Tax 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
- Exclude Condition Records :
- Commission-related conditions records are out of scope, as commissions will be handled through Condition Contracts maintained manually during BAU.
- Rebate-related conditions are excluded from this extraction and will instead be processed in accordance with Conversion Specification 9066.
- Sales Pricing condition records that will be addressed separately in line with Conversion Specification 1034.
- All Tax condition record that is flagged / marked for deletion
- All Tax condition records created for customers or materials that are not within the migration scope, based on the respective Customer and Material Mapping Tables.
- 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).
- Usage-Based Filtering : Only retain Tax condition records that have been used in at least one Sales or Billing document within the last four years.
- As agreed with Barbara Berckmoes,
- The Data Collection Template (DCT) will serve as the primary mechanism for data capture. The DCT will be pre-populated based on the finalized Tax Configuration.
- Where specific data elements cannot be fully derived based on Tax Configuration, ECC source data may be referenced to manually populate into DCT. However, this will only occur in cases where the data meets the defined relevancy criteria defined above.
Data Cleansing
The migration of tax condition records will be based on Data Collection Templates (DCTs) as the primary data source, which are predominantly populated through manual input using newly configured data. Where necessary, data cleansing activities should be performed both during DCT data entry and again as part of the pre-load data validation process to ensure accuracy and readiness for migration. Following rule will be applied only when there is a need to go with the above point 5 from Relevancy Criteria Summary as manual activity
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
1035-001 | C1 | Remove obsolete condition records | Eliminate Tax condition records where the material, customer, or condition type is blocked or discontinued where applicable | List of obsolete records | WP2/PF2 |
1035-002 | C1 | Validate Customer-Material master data | Ensure Tax condition records refer to valid and active Customer and Material master records where applicable. | List of invalid Customer Material combinations | WP2/PF2 |
1035-003 | C1 | Remove expired condition records | Delete condition records where validity end date has already passed. Exception the condition records required for open sales orders under migration scope | List of expired records | WP2/PF2 |
1035-004 | C1 | Validate mandatory fields | Check for missing mandatory fields (e.g. Condition Value, Validity dates, Tax Code for Sales). | List of incomplete records | WP2/PF2 |
1035-005 | C2 | Detect duplicate condition records | Identify and flag duplicate Tax condition records for the same condition type, key combination, and validity period. | List of duplicate records | WP2/PF2 |
Conversion Process
Overview – Tax Condition Record Migration Process
The Data Collection Template (DCT) serves as the primary input source for capturing user-provided tax configuration data.
Based on these inputs, an Extrapolated DCT is automatically generated to pre-populate all necessary tax condition record combinations, minimizing manual effort and ensuring data consistency.
The resulting outputs are delivered in two structured tabs:
Pricing Condition Records – Contains the complete set of tax condition records to be migrated.
Key Fields for Condition – Defines the key field combinations used for access sequence determination during the load process.
These two outputs collectively form the input dataset for loading tax records into S/4HANA via the Migration Cockpit.
Each step in the process is mapped to the corresponding data it utilizes or generates, providing a clear understanding of the workflow and its key dependencies. For example, the data used in Steps 2 and 4 share the same layout i.e., originally derived from Step 1 and subsequently collected during Step 2.
Please refer to the following DCT from Tax Configuration Data collection and Transformation into DCT and Data Load formats
SyWay - DCT - Tax Condition Records - MWST
Data Privacy and Sensitivity
Extraction
Extract data from a source Data Collection templates into . There are 2 possibilities as mentioned in the above process oveview.
Extraction Run Sheet
| Req # | Requirement Description | Team Responsible |
|---|---|---|
| 1035-001 | Confirm scope and extraction approach for each DCT source files | Data Team (L2C), Data Team (Syniti) |
| 1035-002 | Extract Tax configuration data from relevant DCT and also direct tax condition records in the form of DCTs | Functional / Data Team (L2C) |
| 1035-003 | Identify pricing data not present in SAP (e.g., special rates, legacy exceptions) and collect manually via DCT (Data Collection Template) | Business Users / Data Team (L2C), Data Team (Syniti) |
| 1035-004 | Perform data quality checks on extracted records (e.g., missing key fields, invalid dates, incorrect formats) | Data Team (L2C), Data Team (Syniti) |
| 1035-005 | Review and approve extracted data sample sets from each source system before transformation begins | Business / Functional Team |
| 1035-006 | Archive raw extracts and maintain extraction audit logs for traceability | Data Team (L2C), Data Team (Syniti) / PMO Team |
Selection Screen
| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
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 for Tax condition types.
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.
Please note, creation of Data collection template must be aligned with pricing configurations for Tax 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.
DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
| KSCHL | Condition Type | Mandatory. Must be a valid condition type configured in S/4HANA. Use lookup list provided. |
| Field List Based on Chosen Access Table / Key Combination (Refer to Full Template List Above) | ||
| ALAND | Departure Country code | Valid country codes in scope |
| LLAND | Destination Country code | Valid country codes |
| TAXK1 | Tax Classification - Customer | Valid Configured Tax Classification codes for Customer |
| TAXM1 | Tax Classification - Material | Valid Configured Tax Classification codes for Material |
| VKORG | Sales Organization | Mandatory. Must match valid Sales Org values in target system. Only authorized values per scope should be used. |
| VTWEG | Distribution Channel | Optional based on condition table. Must be valid if provided. |
| SPART | Division | Optional. Use only if applicable. Validate against S/4HANA master data. |
| KUNNR | Customer Number | Must be a valid customer number in the S/4HANA master data. |
| LIFNR | Vendor Number | Use only when condition type applies to vendor. Must match master data. |
| MATNR | Material Number | Used only for material-based tax. Should be padded to 18 characters. |
| WERKS | Plant | Optional. Use only if relevant for the tax condition. |
| Mandatory Fields in All DCTs | ||
| KBETR | Condition Rate | Mandatory. Should be numeric. Decimal separator should be "." (e.g., 25.50). |
| KONWA | Currency / Percentage | Mandatory. Fixed Value % |
| DATAB | Valid From Date | Mandatory. Format: YYYYMMDD. Cannot be in the past or beyond system date range. |
| DATBI | Valid To Date | Mandatory. Format: YYYYMMDD. Must be later than Valid From date. |
| MWSK1 | Tax Code for sales | Mandatory : Max 2 Characters. Validate against tax code configuration T007A for the Tax Pricing Procedure from T005 for the Country (Alternatively FM FI_COUNTRY_DATA) Tax Code can be validated using Function Module TAX_INDICATOR_CHECK using Country code, Tax Code and Tax Pricing Procedure |
Extraction Dependencies
| Item # | Step Description | Team Responsible |
|---|---|---|
| Not Applicable | ||
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:
- 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
- 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
Conversion logic for Condition values extraction from S/4HANA
While extracting data between SAP S/4HANA tables condition values from field KBETR for post load validation purpose, condition values may require transformation depending on the condition type and currency. In this example it is only % condition type. f the condition type is percentage (T685A-KRECH = A), divide the value by 10.
Transformation Run Sheet
The transformation process occurs in two key steps:
Step 1: Generate data in the Tax Condition Records DCT format based on the source inputs.
Step 2: Convert the data from the Tax Condition Records DCT into two load-ready files — formatted specifically for use in the Migration Cockpit.
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Read the DCT prepared for input Tax Configuration data and Generate extrapolated data in Data Collection Template format | Functional Team (L2C)+ Data Team (L2C) |
| 2 | Review transformation logic and mappings with Business for confirmation | Business Team + Functional Team (L2C) |
| 3 | Perform initial transformation run and generate draft target-ready dataset | Data Team (Syniti), |
| 4 | Review draft target-ready data for structure and completeness | Data Team (L2C), Functional Team (L2C) |
| 5 | Share transformed data with Business for Pre-load Validation | Business Team |
| 6 | Incorporate feedback from Business and refine mappings or transformation logic as needed | Data Team (L2C) |
| 7 | Finalize and transform the approved DCTs into Target Ready Load File for data load using Migration Cockpit | Business + Functional (L2C) + Data Team (L2C) |
| 8 | Handover final file to Load Team or trigger the load via Syniti Load Workbench | Data Team (Syniti), Data Load Team |
Transformation Rules
The source and target tables have the same fields as listed in the key combination.
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
| Tax Condition Records | |||||||||
Generate one record for each line in the DCT with the following values | |||||||||
| 1035-001 | DCT | DCT | KNUMH | Condition Record No.* | S/4HANA | /1LT/DSM23001318 | KNUMH | Condition Record No.* | Copy KNUMH value from DCT ( Key ) |
| 1035-002 | Fixed value "V" | S/4HANA | /1LT/DSM23001318 | KAPPL | Application* | Fixed Value "V" - Sales and Distribution | |||
| 1035-003 | DCT | KONP | KSCHL | Condition Type* | S/4HANA | /1LT/DSM23001318 | KSCHL | Condition Type* | Copy Condition Type |
| 1035-004 | DCT | KONH | DATAB | Valid From* | S/4HANA | /1LT/DSM23001318 | DATAB | Valid From* | Copy Valid from Date |
| 1035-005 | DCT | KONH | DATBI | Valid To* | S/4HANA | /1LT/DSM23001318 | DATBI | Valid To* | Copy Valid To Date |
| 1035-006 | Fixed Value "A" | S/4HANA | /1LT/DSM23001318 | KRECH | Calculation Type | Determines how the system calculates tax. Current records are always in percentage calculation | |||
| 1035-007 | DCT | DCT | KBETR | Amount | S/4HANA | /1LT/DSM23001318 | KBETR | Amount/Percentage | Copy Condition Rate |
| 1035-008 | Fixed value "%" | S/4HANA | /1LT/DSM23001318 | KONWA | Condition Unit (Currency or Percentage) | Copy value "%" | |||
| 1035-009 | DCT | DCT | MWSK1 | Tax Code | S/4HANA | /1LT/DSM23001318 | MWSK1 | Tax Code | Copy Tax Code |
| Key Fields for Condition | |||||||||
For each condition record identified in the extraction step, one or more entries must be generated in the Key Fields for Condition structure of the migration data template:
| |||||||||
| 1035-011 | DCT | KONH | KNUMH | Condition Record No.* | S/4HANA | /1LT/DSM23001319 | KNUMH | Condition Record No.* | Temporary number of condition record copied from the KNUMH field of the condition record |
| 1035-012 | DCT | All KEY Combination fieldnames | Field Name* | S/4HANA | /1LT/DSM23001319 | FIELDNAME | Field Name* | Enter the field name for the condition | |
| 1035-013 | DCT | All KEY Combination field values | Field Value | S/4HANA | /1LT/DSM23001319 | FIELDVALUE | Field Value | Enter the field value that corresponds to the field name. | |
Transformation Mapping
| Field Name | Mapping Table Name | Mapping Table Description |
|---|---|---|
Transformation Dependencies
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1 | Value Mapping Tables are complete | Functional Team (L2C) + Data Team (L2C) |
| 2 | Pricing configuration for Tax is complete | Functional Team (L2C) + Data Team (L2C) |
| 3 | Org structure configuration is complete | Functional Team (L2C) + Data Team (L2C) |
| 4 | Dependent Master Data records for Customer and Material are loaded | Functional Team (L2C) + Data Team (L2C) |
Pre-Load Validation
Project Team
Completeness
| Task | Action |
|---|---|
| Configuration | Ensure necessary configurations are in place in target system and field mapping is aligned with access sequence, tax condition types |
| Review Mapping Table | Ensure all the source organization units are mapped with target values |
| Check Values | Validate the pre-load data confirming the values are aligned with target system format and |
| Validate template structure and required field population | Ensure mandatory fields like VKORG, VTWEG, MATNR, KUNNR, KSCHL, valid dates are filled |
Accuracy
| Task | Action |
|---|---|
| Check mapping rules against configuration (access sequences, condition tables) | Cross-check mapping sheet with customizing entries in V/03, V/04, V/05, V/08 |
| Perform format validation (date, currency, decimal separators) | Standardize format to match SAP accepted input (e.g., YYYYMMDD for dates) |
| Implement logic to detect duplicate condition records | Example: Run duplicate checks using key combinations (e.g., KSCHL + KEY COMBINATIONS for the condition record) |
| Conduct dry runs using LTMC or BAPIs and review logs | Analyze load results and correct format or conversion errors |
Business
Completeness
| Task | Action |
|---|---|
| Review populated templates for missing or incorrect values | Use checklists to verify completeness and correctness before submission |
| Ensure all required Tax scenarios are covered | Confirm that customer/material-specific special conditions are not missed |
Accuracy
| Task | Action |
|---|---|
| Review condition records for duplicate or conflicting entries | Review for duplicates within key combinations (e.g., Departure Country, Destination Country, Tax Classification codes) |
| Validity Period Check | Review validity period of the condition records to ensure Tax coverage |
| Spot-check high-impact tax conditions for accuracy | Validate tax accuracy for key customers and materials |
Load
The load process includes:
- Execute the automated data load into target system using load tool "Migration Cockpit"
- Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation
Load Run Sheet
| 1 | Confirm readiness of final approved data sets from DCTs | Business / Functional Team |
| 2 | Validate transformation rules and mappings in Syniti tool | Data Team (L2C-Data) |
| 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 automated data load using Syniti into the S/4HANA system (or generate manual load files if required) | Data Team (Syniti) |
| 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 tax condition types | Data Team (L2C-Data) |
| 9 | Log and resolve any data load errors or mismatches identified during validation | Data Team (L2C-Data) + Functional Team |
| 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 (L2C-Data) / Data Team (Syniti) / PMO |
Load Phase and Dependencies
Configuration
| Item # | Configuration Item |
|---|---|
| Condition types | Ensure the condition types are assigned with access sequence and condition tables are active for all the key combinations planned for each condition type |
| Enterprise Data | Ensure configurations for all the organization units involved in tax condition records are imported into the target system |
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| list the exact title of the conversion object of only the immediate predecessor – this will then confirm the DDD (Data Dependency Diagram) | |
Error Handling
As part of the sales tax 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 tax condition load.
| Error Type | Error Description | Action Taken |
|---|---|---|
| Invalid Condition Type | Condition type not found or not configured in target S/4HANA system | Validated against configuration; corrected or replaced with valid KSCHL |
| Missing Key Fields | One or more key fields (e.g., ALAND, LLAND, TAXK1, TAXM1) are blank or incorrectly formatted when required as per the selected Key Combination | Populated missing values; ensured format |
| Invalid Date Range | Valid From (DATAB) is after Valid To (DATBI) | Corrected the date range to ensure DATAB < DATBI and in required date format |
| Duplicate Records | Identical key combinations found more than once in the load file | Duplicates removed or merged as per business rule. Aligned with Business and documented for future loads |
| Unmapped Values | Values for fields like UoM (KMEIN), Currency (KONWA), etc. not mapped in Syniti | Updated mapping tables; ensured value conversion aligned with S/4HANA settings |
| Invalid Currency Format | Incorrect currency formatting or unsupported currency code | Expected value is blank or % |
| Invalid Number Format | KBETR contains special characters or comma separators | Cleaned formatting; ensured decimal values used with '.' as separator |
| Authorization Errors | Lack of access to execute load in target client/system | Raised access request; obtained necessary authorizations |
| Condition Table Mismatch | Field structure in load file doesn’t match condition table in target system | Corrected the file structure to align with condition table (A001, A002, etc.) |
| Transformation Miss | Required transformation logic not applied before load | Re-applied transformation rules and revalidated source-target mapping |
| Technical Load Failure | File not processed due to syntax/format error or system issue | Reviewed logs; regenerated file; re-executed load after resolving issue |
| Missing Condition Record Dependencies | Dependent records (e.g., access sequences, pricing procedures) not available | Reviewed config dependencies; coordinated with config team for correction |
Post-Load Validation
Project Team
Completeness
| Task | Action |
|---|---|
| Execute condition record report (e.g., V/LD, PRC_COND_MONITOR) | Run transaction reports to confirm condition records exist as expected |
Compare uploaded data against source file values | Use Custom reconciliation tools or Excel based comparison tools to validate the following ensure number of records loaded meets the load file record volume |
Check for load errors or partial loads in LTMC | Review Migration Cockpit data load logs for any failures |
Perform technical reconciliation with database tables (e.g., KONH, KONP) | Query SAP tables and match field-level values using SE16N or custom report |
Accuracy
| Task | Action |
|---|---|
| Compare uploaded data against source file values | Use Custom reconciliation tools to validate the following
|
| Verify Key Field Values | Ensure values like Condition Type, Material, Customer, Sales Org, Validity Dates, and Rates are correctly populated |
Business
The business team plays a vital role in validating the completeness and accuracy of sales tax condition data loaded into S/4HANA. Their review ensures that key tax pricing elements such as condition types, customer-material combinations, and validity dates are correctly migrated and aligned with business requirements. This validation helps identify any missing or incorrect records early, supports a smooth cutover, and ensures that pricing processes function correctly from day one in the new system.Completeness
| Task | Action |
|---|---|
| Participate in Post-Load Walkthroughs | Join scheduled validation sessions with the migration and functional teams |
| Review Loaded Condition Records | Access the S/4HANA system (via transactions like VK13 or custom reports) to view loaded tax condition record data |
| Check for Missing Records | Identify any missing condition records or key combinations that were expected but not loaded |
Accuracy
| Task | Action |
|---|---|
| Compare Against Approved Load File | Cross-check data in S/4HANA against the final business-approved load file used for migration |
| Validate Accuracy of Converted/Transformed Data | Review any transformed fields (e.g., currency conversion, unit mappings) for correctness |
| Log and Report Discrepancies | Use provided discrepancy log format or defect management tool to report any findings |
Key Assumptions
- Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
- Tax condition record is in scope based on data design and any exception requested by business.
See also
Change log
Workflow history
| Title | Last Updated By | Updated | Status | |
|---|---|---|---|---|
| There are no pages at the moment. | ||||