Organizations with a heterogeneous landscape (more than one SAP ERP instance or non-SAP system instances) that want to adopt SAP S/4HANA Finance can find the following tasks for this adoption daunting:

• Migrate all the instances to the SAP HANA database
• Upgrade all the instances to SAP ERP Central Component (ECC) 6.0 and enhancement package 7
• Install the SAP S/4HANA Finance add-on on all the instances

These tasks increase the complexity, effort, and cost for adoption of SAP S/4HANA Finance. To keep it minimally disruptive for such customers, SAP came up with an innovative deployment option called SAP Central Finance. This topic has already been covered in detail in a separate Financials Expert article, “A Holistic Approach to Implementing Central Finance.” One of the challenges of moving to SAP Central Finance is to harmonize the data across different source systems. For example, different source systems might be using different operational charts of account. Each financial document posted in the source systems is replicated into the target SAP Central Finance system. However, before the financial postings are replicated, you can harmonize the general ledger (G/L) accounts by maintaining G/L accounts mapping between the source and the target systems

Tools Available for Data Mapping in SAP Central Finance

Data mapping in SAP Central Finance can be done as shown in Figure 1. As you can see in Figure 1, data mapping in SAP Central Finance can be achieved by means of master data governance (MDG) and a cost object mapping framework. The MDG, which is optional, has functionalities such as key mapping and value mapping. Key mapping is used to map the long-living master data between the source and the target system, whereas value mapping is meant to map the customizing objects, such as company codes or document types. Long living master data signifies master data such as customer accounts, vendor accounts, material master, and profit center that do not change frequently and are usually used for a longer duration of time. As shown in Figure 1, an MDG process is in place to control how and when long-living master data is created. The focus of this article is on the functionality offered by the cost object mapping framework in SAP Central Finance. This is used for mapping the short-living master data between the source and the target system. Short-living master data such as an internal order, a production order, and a service order has a very short life and the life span of such cost objects can be as short as a day. As shown in Figure 1, an MDG process is never in place for short-living master data because these orders arise from operational processes. I also explain the difference between short-living cost objects, such as an internal order and a production order, and long-living cost objects, such as general ledger master, vendor master, customer master, and cost center master, and their relevance in the world of SAP S/4HANA Finance. Before I discuss the core topic of the cost object mapping framework, let’s quickly look at what SAP S/4HANA Finance is.

Why Use a Cost Object Mapping Framework?

Long-living master data: As explained above, MDG is used in order to map the long- living cost objects between the source and the target systems. This mapping must be maintained before a financial posting in the source system is replicated into the target SAP Central Finance system. In short, you must create a G/L account in the target SAP Central Finance system, and when it is created in the source systems, the mapping must also be maintained in the SAP Central Finance system. Short-living master data: As explained above, short-living master data may have a very short life. Similar to the long-living master data, the mapping of short-living master data must also pre-exist before a financial posting can be replicated into the target SAP Central Finance system. However, this poses a serious threat to day-to-day operations. It will be very cumbersome if you have to create such master data in the SAP Central Finance system as and when it is created in the source system. SAP introduced the cost object mapping framework to facilitate automatic and dynamic creation of such short-living master data in the SAP Central Finance system as well as maintaining the mapping for the same. With this, the business does not have to manually create each internal order or production order in the target SAP Central Finance system. Rather, this is done automatically and the transaction postings from the source system to the target system never error out for the missing master data in the target SAP Central Finance system.

How the Cost Object Mapping Framework Works

The cost object replication process is as follows:

1. Configure cost object mapping scenarios and define their cardinality of 1:1 or N:1 and activate them
2. Define mapping rules through which the cost objects pass and are created in the SAP Central Finance system
3. Replicate a cost object in the target system by creating a cost object in the source system
4. Replicate a Financial Accounting and Controlling (FI/CO) document whereby the cost object in the source document is automatically replaced by the corresponding cost object in the target system

Note that numbers 1 and 2 above are part of configuration, and numbers 3 and 4 are master data and transaction replication.

A Step-by-Step Guide to Configure the Cost Object Mapping Framework

In this section I explain how to set up the cost object mapping framework. The cost object mapping framework is a new configuration activity introduced by SAP in SAP Central Finance. Step 1. Define scenarios for cost object mapping in SAP Central Finance.In this step, I explain the various possible scenarios available to configure the cost object mapping framework. To complete this step, execute transaction code CFINIMG and follow menu path Central Finance > Mapping > Cost Object Mapping > Define Cost Object Mapping > Define Scenarios for Cost Object Mapping. Click the execute icon beside Define Scenarios for Cost Object Mapping to display the screen in Figure 2. Note that this screen lists five standard scenarios that SAP has provided. I now walk you through each of these scenarios. These scenarios control how a cost object created in the source system is mapped to a cost object in the target system:

• SAP001: Production Order to Product Cost Collector (refer to the first row in Figure 2): The production orders in the source system must be mapped to one product cost collector in the target system. Note that the cost object type itself has changed here. The production orders in the source system cannot be mapped to a production order in the target system. In this case, the mapping (SAP calls it cardinality) rule is obviously N:1. Each production order itself is not taken over in SAP Central Finance because you don’t want to take over all the logistics master data such as bills of material (BOMs), routings, and work centers.

• SAP002: Product Cost Collector (PCC) to Production Cost Collector: The PCCs can have a mapping of 1:1, meaning the moment a PCC is created in the source system, one PCC is created automatically in the target system, thus maintaining a mapping on a 1:1 basis. Note that PCC is a periodic order covering multiple production orders.

• SAP003: Internal Order to Internal Order: In contrast to a PCC, internal orders can be mapped on either a 1:1 or an N:1 cardinality principle. In N:1 mapping, several internal orders in the source can be mapped to a single internal order in the target system. For example, you use internal orders for managing the maintenance expenses and trade promotional activities under two separate order types. The management may choose to have the trade promotion-related internal orders being managed on a 1:1 basis, whereas the maintenance-related internal orders may be aggregated to one internal order.

• SAP004: Maintenance Order to Service Order: Similar to an internal order, maintenance orders can also be mapped on the cardinality principle of either 1:1 or N:1.

• SAP005: Quality Management Order to Quality Management Order – Similar to internal orders, quality management orders are also short-living and they can also be mapped on a cardinality principle of either 1:1 or N:1.

Step 2. Define the source characteristics for the scenarios. In this step, you specify during the cost object replication which fields of the master data from the source system are relevant. To explain this step, I take the example of scenario SAP003 – internal orders with cardinality 1:1. Select the scenario SAP003 in Figure 2, and double-click Source Characteristic on the top left side. This action displays the screen in Figure 3 in which you can see fields such as Order Type and Company Code are already available. You can add to this list by clicking the New Entries button and then entering data in the fields under Characteristic Name and Description. The highlighted fields are mandatory for the replication of internal orders from the source system to the target system. Step 3. Define the central characteristics for the scenarios. In this step, you specify during the cost object replication which fields of the master data must be copied from the source system and which fields must be re-derived in the target system based on the mapping rules maintained in this step. To explain this step, I extend the same example of scenario SAP003 – Internal Orders with cardinality 1:1. Select the scenario SAP003 in Figure 2 and double-click Central Characteristic on the top left side. This action opens the screen in Figure 4. In Figure 4, you can see all the fields that were available in Source Characteristics (Figure 3) and several other fields relevant for internal order replication. These fields are automatically available in this screen and you can add to this list by clicking the New Entries button. These are the fields that you use while creating the internal order in the target system. For some of the fields, such as Company Code, Plant, and Identifier for statistical order, the Derive from Local check box is selected. This means these fields are to be derived as-is from the source system. Other fields that are not selected are re-derived in the target system based on the mapping rules, as explained in step 4. This means that the order type is switched in the target system during the cost object replication. I cover this process in more detail further in the “Cost Object Replication Between the Source and the Target System” section. Step 4. Define the mapping rules for cost object mapping scenarios. This step serves three purposes:

• You specify for which source system the mapping rules are maintained
• You also specify the filtering criteria for the source characteristics (see Figure 3)
• You specify the mapping rules for the fields not marked as Derive from Local in the central characteristics (see Figure 4)

I continue to use the same example of scenario SAP003 for the sake of continuity in the explanation. To complete this step, execute transaction code CFINIMG and follow menu path Central Finance > Mapping > Cost Object Mapping > Define Cost Object Mapping > Define Mapping Rules for Cost Object Mapping Scenarios. Click the execute icon beside Define Mapping Rules for Cost Object Mapping Scenarios and enter scenario SAP003 in the pop-up screen that appears (not shown here). Then press Enter on your keyboard. This action displays the screen shown in Figure 5. The fields in the Figure 5 are correlated to the three purposes as mentioned at the beginning of this step. Column 1 denotes the source system for which the mapping is being maintained. Here, the logical system ID of the source system must be maintained. Columns 2 to 9 contain the same fields as mentioned in the source characteristics in step 2. You can notice that all such fields have a suffix of Source. Here, you can maintain the filter criteria. For example, if you enter 1000 in the field under column 4, only the internal orders pertaining to company code 1000 are replicated. If no filter is applied, then all the internal orders from the source system are replicated to the target system. Column 10 contains the Order Type column, which was not marked as Derive from Local in step 3. Hence, for order type, you need to maintain the mapping rules. In my example, order types 0100 and 0200 are mapped to the order type Z100 in the target system, as shown in Figure 6. You may choose not to have too many order types in the target system, as that may not add any value to the purpose of centralized reporting or centralized processes. You have now completed the configuration required for replicating the cost objects between the source and the target system. The same configuration must be done for the other scenarios as per the business requirement.

Cost Object Replication Between the Source and the Target Systems

In this section, I explain how a cost object created in the source system is replicated into the target system based on the mapping rules that you maintained in step 4 above. Step 5. Creation of a cost object in the source system. To complete this step, execute transaction code KO01. This action opens the screen in Figure 7. For my example, enter 400197 in the Order field to create the internal order 400197 in the source system. You also need to populate the Order Type (0100), Company Code (1000), Plant (1000), Object Class (Cost Overhead), and Profit Center (YB110) fields to create the internal order. Step 6. Automatic creation of a cost object in the target system. Based on the mapping rules maintained in step 4, internal order 700000 was dynamically created in the target system when the internal order 400197 is created in the source system, as shown in Figure 8. In Figure 8, you see that all the values such as Controlling Area, Company Code, Plant, and Profit Center are derived from the local system because you had marked them as Derive from Local in step 3. However, the order type was not to be derived from local and instead supposed to be replaced by Z100 and this is exactly what has happened in the above example.

Step 7. Update the mapping between the source cost object and the target cost object in the table FINS_CFINT_ASGMT. Immediately upon creation of a cost object in the target system as described in step 6, the cost object between the source and the target system is mapped in the table FINS_CFINT_ASGMT in the target system. Against internal order 400197 in the source system, the internal order 700000 created in the target system is mapped in the table, as shown in the first row in Figure 9. Similarly, other internal orders created in the source system are also mapped in the same table.

Step 8. Financial posting replication with the cost object from the source to the target system. This is the final step. When a journal entry is posted in the source system using the cost object 400197 that you created in step 5 above, the posting is replicated to the target system and the posting in the target system is redirected to the internal order 700000 based on the mapping updated in the table FINS_CFINT_ASGMT. With the above steps, the objective of using the cost object mapping framework in SAP Central Finance should now be clear to you. A business does not have to create each short-living cost object in the target system before making any financial posting in the source system. Rather, with the help of chosen cardinality, the cost object master data is automatically taken care of in the target system.