BRF Customization

In this page outlined the required BRF+ configuration steps used for mapping the fields between source and the target system.

How to maintain the BRF+ Rules for mapping between Legacy system and S/4HANA

• XCM has delivered the BRF+ application (/XCM/MIGRATION) to your ECC system as part of the Migration Kit, now available in your ECC system. This kit enables you to map fields and values from your legacy system to the S/4HANA environment
• Configure the BRF+ Decision Tables to align with your specific customizing requirements
• To minimize manual entries, take advantage of the Excel export and import features in BRF+ when working with the Decision Tables
• Make sure the application and all related objects are saved and activated after configuration

Maintain field mappings in the DEC_FIELD_MAPPING Decision Table

The first decision table is used to define field mappings from the legacy system to S/4HANA. Follow the steps below:

→ Decision Table Input Columns

• Input Structure: Define fields used as input from the legacy system
• **RECORD_TYPE** - this represents the record type in the legacy system

→ Decision Table Output Columns

• **SOURCE_NODE_TYPE**:

  • Represents the item-level category from the legacy system

  • SOURCE_NODE_TYPE is only required for item-level fields. It should not be maintained for header-level fields

  • These are the Constant values, can be adjusted based on your Change Management process

    • Document → PLM_DIR
    • Material → PLM_MAT
    • Recipe → PLM_RCP
    • Specification → PLM_RSPSUB

• **SOURCE_FIELD**: Specifies the field in the legacy system that needs to be mapped. This can be either a standard or custom field from the legacy system’s database table

  • This determines the Field in the legacy system that is to be mapped

• **TARGET_NODE_TYPE**:

  • Corresponds to the item type in the S/4HANA system

  • There is no TARGET_NODE_TYPE needs to be maintained for Header fields

  • These are the Constant values that needs to be maintained correctly based on the what Source_Node_type is given

    • Document → DIR
    • Material → MAT
    • Recipe → RCP
    • Specification → SPC
    • And maintain all relevant object types as required by your internal change management process

• **TARGET_FIELD**:

  • For standard fields, the field names must be referenced from the official SAP API documentation: Refer to the API here: SAP API - Change Record
  • You need to expand the specific Target Association in order to get TARGET_FIELD
  • There is no TARGET_NODE_TYPE needs to be maintained for Header fields

    *   The API provides details on standard header and item-level fields
    *   TARGET\_FIELD Can be a standard or custom field from the legacy system database table
    *   **Note:** Maintain correct naming conventions, including **case sensitivity** (uppercase/lowercase), as per API or structure definition

Maintain field value mappings in the DEC_FIELD_VALUE_MAPPING Decision Table

The Field Value Mapping decision table defines how specific values in the legacy system (Engineering Record) are mapped to corresponding values in the target system (Change Record in S/4HANA)

• Condition Columns: Include RECORD_TYPE and other source-related fields
• Result Columns: Include the corresponding target fields and their mapped values

Record Header-Level Mapping:

• You only need to maintain RECORD_TYPE as the condition column in the Decision Table

• And in the Decision Table output columns as below:

  • Source Field: ECR_TYPE (e.g., value = ECRD from the legacy system)
  • Target Field: Must exactly match the field name defined in the S/4HANA Change Record API (Change Record API)
  • Target Value: The corresponding record type used in the S/4HANA system (e.g., C01, S02)

Record Item-Level Mapping:

• Input Columns:

  • Source Node Type: Represents the Change Item object types, e.g., PLM_DIR, PLM_MAT
  • Source Field: CHANGE_RELEVANT
  • Source Value: Blank (Since no value is provided in the legacy system, this is left empty)

Output Columns:

*   **Target Node Type:**

    *   _Blank_ for header-level entries
    *   `DIR` for `PLM_DIR`, `MAT` for `PLM_MAT` (Change Item level)

*   **Target Field:** This must be taken exactly as defined in the S/4HANA Change Record API (refer to the field mapping screenshot)
*   **Target Value:** The appropriate value as defined in the target S/4HANA system for the corresponding field
*   Once mapped, the **Target Value** will be reflected in the Change Record after the data is migrated or created through BRF+.

Maintain Object mappings in the DEC_OBJECT_MAPPING Decision Table

• The Object Mapping decision table defines how specific business objects from the source system are mapped to their corresponding counterparts in the target system. This table is primarily used for item-level objects such as documents, materials, specifications, and recipes an so on based on your change management process
• You can assign different objects to various types of Change Records by using **RECORD_TYPE** as an input field
• The field **CR_RECORD_TYPE** specifies the target Change Record type in the S/4HANA system to which the object should be mapped
• The **TARGET_ASSOCIATION** field must be maintained exactly as defined in the official S/4HANA Change Record API (Change Record API).
• Please refer to the highlighted values in the referenced image, these represent the valid Target Associations. No additional entries or extensions are needed.

Maintain RFC Value mappings in the DEC_RFC_VALUE_MAPPING Decision Table

RFC (Remote Function Call) value mappings in UI, API, and BP (Business Partner) contexts involve aligning values from one system to another; below are the 3 different RFC’s that needs to be created in the legacy system

• BP - The RFC BP used to get the Business partner from the target system by passing USER ID

• API - The RFC API can be used to create CRs (Change Records) in the new system with the initial status

• UI - The RFC UI is used for the status change which is provided in the XCM Migration kit target status column

• Please ensure that the path prefix used while creating the three RFCs matches exactly with what is shown in the referenced image above
• Under the value column, You need to provide the RFC destination that was created in the legacy system

Maintain Target Status mappings in the DEC_TARGET_STATUS_MAPPING Decision Table

The Target Status Mapping decision table is used to map the status of an Engineering Record (ER) to the corresponding target status in the Change Record (CR) within the Migration kit application, to support the scenarios of different status net in the S/4HANA system vs Legacy system

• When an ER is created and processed, the default target status is automatically determined based on the entries defined in this decision table

  • If the Copy Process column is maintained with the value X (Yes), the corresponding checkbox in the FPM application will be automatically selected, refer to this documentation for more details about the copy process Migration Cockpit (ER → CR)
  • If the value is False or left blank, the Copy Process checkbox will not be selected—only the target status will be set by default

• Note: If a specific ER status is not maintained in the BRF+ decision table, the target status field will remain blank for that record. In such cases, users can manually select the appropriate target status within the Migration Kit application, if needed

See Also

Migration Cockpit (ER → CR)

Keywords

BRF+ Application, Mapping field values, RFC, Object Mapping

Prerequisites

Make sure to create the 3 RFC’s before you define the RFC Value Mapping decision table.