Introduction
This is the second of the two-part blog series where we discuss some of the key enablers of Mapping in Central Finance. In the first blog, we discussed configuration steps to enable change logs for Key Mappings. In this blog, we turn our attention to Value Mappings.
Yet again, we will dive straight into the technical details of the mapping enablers. As mentioned in my previous blog, for introduction to the concepts of Central Finance, in general, and mapping, in particular, there is a significant amount of information on this site, but I can recommend the following two blogs for familiarising yourselves with the concepts.
- Central Finance Overview from vinay.dhamnani
- Introduction to Mapping from zhengzhang.lu
In this two-part blog series, we will explore the following in detail. If you have read my first blog of this series, you may find some of the information here repetitive. It was done consciously so that both of these blogs can be read independently dependent on the challenge the reader may want to solve.
- Part 1 - Key Mapping - Enable Audit Log for Key Mapping
- Part 2 - Value Mapping - Enable Transports for Value Mapping
Details
Part 2 – Value Mapping - Enable Transports for Value Mapping
Value Mappings are maintained in the Central Finance system primarily for Enterprise Structure (Company Codes, Controlling Area etc.) or Reference Data (Payment Terms, Payment Methods, Document Types etc.). Key Mappings, on the other hand, are mostly maintained for Master Data objects (Customers, Vendors, G/L Accounts, Materials etc.).
Value Mappings are mostly configured in the Development system and transported through the landscape into Production. It makes sense as the target mapping objects (such as Company Codes, Payment Terms etc.) are also configured in the Development system, and captured in transports before they move to Test or Production. Master Data is usually created directly in the Production system and does not necessarily need any transports from Development. Hence mapping between source Master Data and CFIN equivalents is maintained directly in Production via Key Mappings.
Methods to Configure Value Mapping
Value Mapping can be configured in a few different ways. One option is to use the "Maintain Value Mapping" configuration node via Transaction CFINIMG. However, a more user-friendly option, in my personal opinion, is to use Transaction FINS_CFIN_MAP_MANAGE. This transaction allows the users to download a CSV template, populate it with the source and target values, and upload them to the Central Finance system. Please note, loading value mapping via FINS_CFIN_MAP_MANAGE has some limitations, for example, when mapping entities have contexts and they differ in source and Central Finance, this method will not work. However, in scenarios where it works, I find it the more user-friendly and swift way.
In the following figure, I have taken the liberty of showcasing, with a dash of artistic charm, the user experience for configuring Value Mapping via Transactions CFINIMG and FINS_CFIN_MAP_MANAGE. Both have their perks and limitations.
CFINIMG vs FINS_CFIN_MAP_MANAGE
On a vanilla Central Finance system, the configuration of Value Mapping does not come transport enabled. For example, in Transaction FINS_CFIN_MAP_MANAGE if you select any Value Mapping entity, choose the "Upload Mapping" radio button, enter a file name and remove the "Test Run" option, by default, you will not find any placeholder for adding a Customizing Transport Request (please refer to the image below). This blog provides a quick overview of the changes required in your Development environment (configuration client) to enable the transportability of value mappings.
FINS_CFIN_MAP_MANAGE Screen without a Transport Prompt
Configuration Steps
Changes are required in configuration settings for 3 Maintenance Views and 1 View Cluster as follows:
- Maintenance View: MDGV_VM_CODELIST (Assign Code Lists to Elements and Systems)
- Maintenance View: MDGV_CCODEMAP (Define Code-Mapping (Client-Dependent))
- Maintenance View: MDGV_CMAPCONTEXT (Assign Code Lists (Client-Dependent))
- View Cluster: MDGVC_CMAPPING (Configure Code Lists and Value Mapping (client depend.))
Please note, the changes recommended in this blog are only required in your Development environment and configuration client. You wouldn't want to create Customising Requests in your non-Golden clients.
Step 1: Change the "Current Settings" Configuration for Maintenance Objects
Step 1.1: Launch Transaction Code SOBJ (Maintenance Object Attributes)
Launch Transaction Cod SOBJ. On the next screen, click on "Edit"
Transaction SOBJ
Step 1.2: Navigate to "Current Settings"
Repeat this step 4 different times, once each for each of the Maintenance View and View Cluster mentioned above.
Click on the Position button and enter the Maintenance View name or View Cluster Name in the "Object" field. Then double-click on the Maintenance View or View Cluster row. This will navigate you to the "Change View" screen.
Navigate to the View
Step 1.3: Modify "Current Settings"
The "Current Settings" checkbox will be checked by default. Uncheck the box and save the changes into a new Transport request. Please repeat this for all 4 views as mentioned above. The figure below shows the before and after settings of these views.
Changes to Current Settings
Step 2: Change "Dialog Data Transport Details" Settings for Maintenance Views
Step 2.1: Launch Transaction Code SE54 (Generate table view)
Repeat this step 3 different times, once each for each of the Maintenance Views mentioned above.
Launch Transaction SE54, enter the Maintenance View Name, select the Radio Button called "Generated Objects" and click on "Create/Change".
Maintenance View Changes
Step 2.2: Change the "Recording Routine" settings
By default, in the recording routine section, the radio button "no, or user, recording routine" is selected. Change that to "Standard Recording Routine" and save. These changes would have to be captured in a transport. Please repeat this for all 3 Maintenance Views. The following figure shows the before and after images of these settings.
Recording Routine Changes
Once these steps are completed, you should be able to add Value Mapping into Customising Transport Requests.
Results
If you refer to the figure below, you will find an input field called "Customising Request". Chances are, when you log in to your brand new Central Finance system for the first time, you will not find this field as an input parameter. By following the configuration steps mentioned in this blog, you will be able to bring this field to life. Please note, this Customising Request input parameter shows up on the FINS_CFIN_MAP_MANAGE screen only when:
- You have selected a Value Mapping entity (it does not show up for Key Mapping Entities)
- You have selected the "Upload Mapping" or "Delete Mapping" Radio Buttons in User Action
- You have removed the check from the "Test Run" checkbox
Customising Request Input Parameter
Conclusion
The decision to transport Value Mappings, to preserve the sanctity of data across systems, should be ratified by the Project Design Authority. Once it is adopted as the approved mechanism of moving Value Mappings through the landscape, the content of this blog should come in handy. When in doubt, it is always useful to check with SAP Support before making these proposed changes.
This is the second blog in a two-part series. You can read the first part here where we discussed enabling change logs for Key Mappings. Hope you found this blog useful.
Reference:
SOBJ - Definition of Transportable Object Types
Special Thanks:
Rohit Sinha for helping me find the relevant technical details at the early stage of the program.
Mangat Goyal for tirelessly managing all Value Mapping Transports in our recent successful CFIN Implementation.
System Details:
This Blog was written based on S/4HANA 2021 version
System Details
- SAP Managed Tags:
