Purpose

The Business Partner role UKM000 is used to manage Credit Management data within the FSCM framework. It replaces the old ECC transaction FD32, centralizing credit limits, risk categories, and credit exposure at the Business Partner level. With UKM000, credit data is maintained per credit segment (instead of credit control areas), ensuring accurate credit checks in sales and financial processes. Its purpose is to provide a unified, modern, and integrated way to control customer credit risk across the system.

Conversion Scope

The conversion scope covers BP role assignment (UKM000), credit control area replacement with credit segments, migration of credit master data and exposures, and system configuration alignment to ensure smooth credit checks in S/4HANA.

1. Business Partner Conversion
   - All customers/vendors must be converted into Business Partners.
   - Credit-relevant customers in ECC must have the UKM000 role assigned in S/4HANA.

2. Credit Control Area → Credit Segment Mapping
   - ECC’s Credit Control Areas (CCA) are no longer used.
   - These must be mapped to Credit Segments in S/4HANA.

3. Credit Master Data Migration
   - Credit limits, risk categories, and other credit parameters maintained in FD32 must be transferred to the BP’s UKM000 role.
   - Use report UKM_TRANSFER_CUST (or migration cockpit) to migrate existing credit data.

4. Credit Exposure Migration
   - Open sales orders, deliveries, billing documents, and FI-AR open items from ECC must be migrated so that credit exposure is correctly reflected in S/4HANA.

5. Configuration & Integration
   - Set up credit segments and assign them to company codes.
   - Enable integration of credit checks with SD, FI-AR, and FSCM.
   - Replace obsolete transactions (like FD32) with BP maintenance in UKM000.

The scope of this document covers the approach for converting active Customer Master Data from Legacy Source Systems into S/4HANA Business Partner FI Customer (FLCU00) Master Data Design Standard. 

The CNV-3007 Business Partners – General (Role 000000) relevancy criteria will also be used for this conversion document.

Customer Master Data - General Information

The data from legacy system includes:

1. Customer with AR Balance under the company codes within S4 Hana implementation scope (BSID-KUNNR).
2. or (Customer doesn't have central deletion indicator (KNA1-LOEVM="") AND Customer has active sales view data within the sales organizations in scope(KNVV-KUNNR)) and there is usage within 4 years. * modified on 16/Oct/2025
3. or (Customer doesn't have central deletion indicator and customer has active company code view within the company codes in scope) and there is usage within 4 years. * modified on 16/Oct/2025
4. or there is customer consignment stock and the plant for the consignment stock is within S4 Hana implementation scope. 
5. or Customer is set as the credit account for other customers, and either the customer or credit account customer is not deleted. (if both customer or credit account is deleted, then not in migration scope)

6.  Intercompany customer will be defined based on the Enterprise structure. (To identify Intercompany customer, trading partner will be used. In the meantime, Group field(KNA1-KONZS) from customer general data will be used. For WP2/PF2, Group value = 0000810135 (Syensqo) )

7. or the customer in the partner function is active, then the parent customer will also be migrated. * added on 16/Oct/2025

8. or the customer is active in Salesforce and there are activities within 48 months.* added on 16/Oct/2025

9. or there is an existing forecast for the customer in Kinaxis. * added on 16/Oct/2025

10. or there is active master data for the customer, such as active Pricing Condition records. * added on 16/Oct/2025

or (Customer doesn't have central deletion indicator AND Customer has active sales view data within the sales organizations in scope) and there is usage within 4 years.

Select KUNNR from KNA1 where KNA1-LOEVM="" and KNVV-KUNNR = KNA1-KUNNR AND KNVV-VKORG in (Sales Org in scope) and KNVV-LOEVM = "" and usage within 4 years. 

1. Accounting document (Select MAX(BSAD/BSID-CPUDT) where BSAD/BSID-KUNNR =KNA1-KUNNR and BSAD/BSID-BUKRS = (Company code in scope) )
2. Sales Document (Select MAX(VBAK-ERDAT) WHERE VBAK-VBELN=VBPA-VBELN AND VBPA-KUNNR = KNA1-KUNNR)
3. Delivery Document (Select MAX(LIKP-ERDAT) WHERE LIKP-VBELN=VBPA-VBELN AND VBPA-KUNNR = KNA1-KUNNR)
4. Billing   (Select MAX(VBRK-ERDAT) WHERE VBRK-VBELN=VBPA-VBELN AND VBPA-KUNNR = KNA1-KUNNR)

or (Customer doesn't have central deletion indicator and customer has active company code view within the company codes in scope) and there is usage within 4 years

Select KUNNR from KNA1 where KNA1-LOEVM="" and KNB1-KUNNR = KNA1-KUNNR AND KNB1-BUKRS in (Company code in scope) and KNB1-LOVEM = "" and usage with 4 years

of this document covers the approach for converting active Customer Master Data from Legacy Source Systems into S/4HANA Business Partner Credit management UKM000 Master Data Design Standard. 

The relevancy already applied in CNV3007. Once the customers in scope are finalized and extracted, we need to check the credit management fields for those customers in the legacy system and apply the transformation rules as per the source-to-target mappings.

List of source systems and approximate number of records 

Customer Credit Limits Approach:

1. Customer De-duplication:

a. Consolidate and harmonize Business Partner master data to enable consistent credit limit management at a global level.

b. The current consolidation and deduplication process will provide the output for the master and duplicate customers.

c. This will be used to prepare the global credit limit data.

2. Global Credit Limit Process:

a. Extract the credit limits from PF2 and WP2 based on the deduplication process results, this will include the master and duplicate customers.

b. Add the GBU code to the dataset, ensuring credit limits are structured to support GBU-specific requirements.

c. Include the customer hierarchies in the dataset for each customer.

d. Aggregate individual customer credit limits into a single consolidated global credit limit at master customer level.

e. The consolidated credit limit report will be available via the Syniti ADMM platform. (Cleansing Report)

f. Business Team to assess and validate customer hierarchies and GBU to ensure correct roll-up of the global credit limits.

g. The business team will make the manual adjustment based on their review.

h. The global credit limits will be populated in a DCT for input into the ETL process.

Additional Information

Multi-language Requirement

NA

Document Management

Legal Requirement

NA

Special Requirements

NA

Target Design

The technical design of the target for this conversion approach.

Data Cleansing

This is not applicable for this Object

Conversion Process

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

Data will be extracted using Syniti ADMM from ECC

2. Transformation
Once extracted, the data undergoes cleansing, consolidation, and governance. This step ensures data integrity, consistency, and compliance with business rules. The transformation process includes:
- Data validation to remove inconsistencies.
- Standardization to align formats across datasets.
- Business rule application to refine data for operational use.

3. Loading
The transformed data is then loaded into the target S4 Hana system. 

Data Privacy and Sensitivity

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.

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)

DCT Rules   - No DCT

Extraction Dependencies

1. Accounting document (Select MAX(BSAD/BSID-CPUDT) where BSAD/BSID-KUNNR =KNA1-KUNNR and BSAD/BSID-BUKRS = (Company code in scope) )
2. Sales Document (Select MAX(VBAK-ERDAT) WHERE VBAK-VBELN=VBPA-VBELN AND VBPA-KUNNR = KNA1-KUNNR)
3. Delivery Document (Select MAX(LIKP-ERDAT) WHERE LIKP-VBELN=VBPA-VBELN AND VBPA-KUNNR = KNA1-KUNNR)
4. Billing   (Select MAX(VBRK-ERDAT) WHERE VBRK-VBELN=VBPA-VBELN AND VBPA-KUNNR = KNA1-KUNNR)

Select KNVP-KUNNR INNER

JOIN KNA1 as a WHERE KNVP-KUNNR = a.kunnr and a.loevm = X and KNVP-VKORG in 'Sales Org in scope'

inner join kna1 as b where knvp-kunn2 = b.kunnr and b.loevm  = '' and kunn2 in rule 2

Two reports will be provided.

iCare - If (there is value in field 'PRS Code (Account)' or 'RCS code (Account)') and 'Last Activity' is within 48 months and Type <> "Inactive Customer". then the account is in scope. 'PRS Code (Account)' is mapped to PF2 customer number, 'RCS code (Account)' is mapped to WP2 customer number.

Core CRM - If (there is value in field 'PRS ID / RCS ID') and 'Last Activity' is within 48 months and 'Account Organization' = 'SCO' and 'Status'<>"Rejected", then the account is in scope. 'PRS ID / RCS ID' need to split using "/" to get the PRS/RCS code and 'GBU'  in (Novecare, Technology Solutions). 

• This will be parked for now

or there is relevant Pricing Condition records maintained for the customer 4 years ago.

a. The relevant condition table will be provided, which includes the customer field

b. The price valid-from date is >= current date - 4 years 

c. Based on the selection criteria mentioned in a&b to select the condition header index table (KONH), then use it to match the customer number. If there is match, then the customer is taken into consideration.

Select  KNA1-KUNNR from KONH where KONH-KOTABNR IN (List to be provided) and KONH-DATAB >= current date - 4 years  and  KONH-VAKEY CS KNA1-KUNNR

The data from legacy system excludes:

1. One time customer (Account group is Z004 or ZCPD)

One time customer (Account group is Z004)

List of source systems and approximate number of records 

Additional Information

Multi-language Requirement

Document Management

Legal Requirement

Special Requirements

Target Design

The technical design of the target for this conversion approach.

Data Cleansing

Conversion Process

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

Image Removed

Data Privacy and Sensitivity

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)

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

NA

Transformation Rules

Transformation Mapping

Transformation Dependencies

Transformation Dependencies

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

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