0% found this document useful (0 votes)
146 views6 pages

Configuration in Central Finance System: Mapping

The document discusses configuration of data mapping in the Central Finance system, including: 1) Defining mappings between identifiers of business objects that may differ between source systems and Central Finance, such as customer IDs. 2) Mapping codes that may be configured differently between systems, such as company codes. 3) Additional mapping of cost object types may be needed beyond just identifiers.

Uploaded by

GK SK
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
146 views6 pages

Configuration in Central Finance System: Mapping

The document discusses configuration of data mapping in the Central Finance system, including: 1) Defining mappings between identifiers of business objects that may differ between source systems and Central Finance, such as customer IDs. 2) Mapping codes that may be configured differently between systems, such as company codes. 3) Additional mapping of cost object types may be needed beyond just identifiers.

Uploaded by

GK SK
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Configuration in Central Finance System:

Mapping
Send feedback

Data Mapping

Data mapping has to be configured so it can be carried out when accounting documents from source
systems are posted into the Central Finance system.

Identifiers of business objects may be different in the source systems and the Central Finance system,
making it necessary to define mapping between these identifiers. For example, in the source system a
customer could have the ID 4711 but in the Central Finance system the same customer could have the ID
8912. Therefore, if an invoice for this customer is to be posted into Central Finance, the system needs to
translate the customer ID in the document from 4711 to 8912. In addition, the systems may be configured
differently, so that (Customizing) codes are different and need to be mapped as well. For example the same
company might have different company codes in different systems.

For cost objects it is not only necessary to map identifiers, but it may also make sense to change the cost
object type. For example, the original accounting document may contain a reference to a production order.
However, production orders are too detailed for Central Finance and thus are not replicated. Therefore the
accounting document would contain a reference to a cost collector and the system has to map individual
production orders to individual cost collectors.

If you do not want to use this standard mapping functionality, you must implement your own mapping logic
via BAdI. For complex mapping operations, we recommend that you define the BAdI for a connection to
BRFplus, which should serve as a secondary rules engine.

Activities relating to mapping are carried out in Customizing of the Central Finance system under Financial
Accounting  Central Finance  Central Finance: Target System Settings  Mapping  Settings for
Mapping.

Further Settings
Define Mapping Actions for Mapping Entities

Note
In addition to being able to enhance and change the existing set of mapping entities, you have the option of
defining the mapping action of cost objects for the mapping entity. For example, if you set the mapping
action of the internal order mapping entity to Mapping Obligatory, then the system stops the document
replication and displays an error message if a cost object is not mapped.

In the Customizing activity Define Mapping Actions for Mapping Entities (under Central


Finance  Central Finance: Target System Settings  Mapping) you define the mapping action for each
mapping entity (for example, customer ID) and, if necessary for each source business system.
The following mapping actions are available:

• Keep Data: Field values of this kind are not mapped at all. The data from the source system is retained.

• Mapping Obligatory: The field values for all filled fields must be mapped (in mdg_km_maintain). If no
mapping data exists, an error is raised.

• Clear Data: Fields of this kind are always cleared.

• Map if Possible: The system tries to map any filled field. If no mapping data exists
(in mdg_km_maintain), no error is raised but the original data from the source system is retained.

Note
The default setting is that mapping entities that have no mapping action assigned (mapping action Keep
Data) are not mapped. Instead the value from the source system is carried forward.

In the Business System field you can enter the specific system for which you would like this configuration
to be applied. Or you can define standard settings for all business systems by leaving the Business
System field empty.

Note
Settings made for business systems override general settings.

You can implement the BAdI: Determine Mapping Action if you need to make the mapping action
dependent on the field value or on context information in the mapping structure.

Define Key Mapping (ID Mapping)

Identifiers for instances of business objects may be different in the source systems and the Central Finance
system, making it necessary to define mapping between these identifiers.

Create and Edit Key Mapping

With this activity you can maintain key mappings, choosing different business object types and object IDs.
For detailed information, see the system documentation for the Customizing activity.

Master Data Governance, Consolidation

Using Master Data Governance, Consolidation, it is also possible to analyze the existing master data in
your various source systems and see a proposal for an initial set of key mappings. Master Data
Governance, Consolidation can analyze existing master data in the various source systems and – based
on rules that can be configured – can come up with proposals for which master data in the source system
should be mapped to which master data in the Central Finance system. This functionality is available for
the following data domains: customer, supplier, business partner, and material, and can be individually
extended to include self-defined objects on a project basis. It is possible to use thresholds to automatically
process highly probable duplicates and to manually process other proposed matches. The record
mappings that have been identified are then transferred to the key mapping tables used by Central
Finance. In this process, a “golden” master data record (for instance the customer to be used in the Central
Finance system) is created.

Define Value Mapping (Code Mapping)

Source systems may be configured differently, so that (Customizing) codes are not identical and need to be
mapped. For this, value mapping can be maintained.
Assign Code Lists To Elements And Systems

To assign code lists to elements and systems choose Mapping  Define Value Mapping (Code
Mapping)  Assign Code Lists to Elements and Systems.

The setting is required for each global data type that is to be mapped.

An internal list ID is required for GDTs that have a context structure, for example MABER (with the context
BUKRS).

For each source system you must specify the following data:

• List ID

• List Agency ID

• List Version ID

Maintain Value Mapping

In the activity Maintain Value Mapping (under Financial Accounting  Central Finance  Central Finance:


Target System Settings  Mapping   Define Value Mapping (Code Mapping)), you can configure
mapping from system-internal code values to code values on external code lists. The mapping is
configured at field level.

A list of fields that support value mapping is delivered in standard. You can also add your own fields. These
fields also need to be defined in Customizing for Central Finance under Financial Accounting  Central
Finance  Central Finance: Target System Settings  Mapping  Advanced Settings  Define Mapping
Entities (Enhanced Configuration).

In the subview Define Mapped Fields (Customer) you can define the non-standard fields which you want
to map as a mapping entity.

Non-standard fields are fields which have been added to the accounting interface via customer
enhancements or are not mapped in the standard.

Note
When maintaining the data, choose Enter after you have entered the structure but before you enter the
field name, otherwise the input check for the field name will issue an error.

Choose the mapping entity you want the field to belong to. Enter the accounting interface structure to which
the field to be mapped belongs to. Define the field name of the field to be mapped. If required by the
underlying structure, you also have to specify the context fields 1 and 2.

Note that definitions made here override definitions delivered by SAP.

BAdIs: Central Finance

In cases where more complicated logic is necessary to derive certain entities (for example, post to
GL 113100 if profit center is PC_02 but post to GL 113001 if profit center is PC_05), this should be
implemented as an FI substitution in the Central system.

If for some reason an FI substitution cannot be used, we offer a BAdI for the Central Finance scenario,
where mappings of this type can be implemented.

For specific details about each of these BAdIs, see documentation available in the Central Finance system.
These BAdIs offer the customer the following options to control the processing of data:

• Only execute standard

• Only execute BAdI

• Conditional execution

The BAdIs logic follows this flow: Data Preparation > Data Mapping > Data Adjustments >Posting Interface.

Mapping Customer-Defined Fields


You can map customer-defined fields for the accounting interface.

Customize Business Objects for Key Mapping

In this Customizing activity (under Master Data Governance, Central Governance  General


Settings  Key Mapping  Customize Business Objects for Key Mapping), you customize business
objects so they can be used in key mapping.

Define Business Objects

In this Customizing activity (under Master Data Governance, Central Governance  General


Settings  Key Mapping  Enhance Key Mapping Content  Define Business Objects), you define
business objects to be used for key mapping.

Standard settings: In the standard system, key mapping entries for business objects are delivered. You can
only implement key mapping for the business objects that are assigned to the main context. The
assignments are specified in the Customizing activity Assign Business Object to Main Context .

You can also define your own business objects. The customer namespaces you use for these are Y* and
Z*.

Define Object Identifiers

In this Customizing activity (under Master Data Governance, Central Governance  General


Settings  Key Mapping  Enhance Key Mapping Content  Define Object Identifiers), you assign object
identifier types to business objects that are used in key mapping.

As a prerequisite, you must have defined an object node in the Customizing activity Define Object Nodes.

Assign Key Structures to Object Identifiers

In this Customizing activity (under Master Data Governance, Central Governance  General


Settings  Key Mapping  Enhance Key Mapping Content  Assign Key Structures to Object
Identifiers), you can assign a key structure to an object identifier type. Key structures make it possible to
break down concatenated keys into their constituent parts and are useful in key mapping. If the output field
length of any key component within a concatenated object ID type exceeds its internal field length, you
must define a delimiter.

Requirements: You have defined an Object Identifier Type in the Customizing activity Define Object
Identifiers.

Define Object Nodes


In this Customizing activity (under Master Data Governance, Central Governance  General
Settings  Key Mapping  Enhance Key Mapping Content  Define Object Nodes), you define business
object node types to be used in key mapping when defining the object identifiers. Each business object
must, at a minimum, have a root node holding the identifier or identifiers for the entire business object.

Transaction MDG_KM_MAINTAIN

The actual mapping of object identifiers (key mapping in SAP MDG) is either generated automatically as
part of master data replication in SAP MDG or can be maintained manually in the
transaction MDG_KM_MAINTAIN:

Under field Business Object Type you can find all entities that can be mapped between the source and
Central Finance systems. These are the entities that are supported by MDG, not necessarily all objects that
are available as mapping entities in the SAP standard for Central Finance business mapping. The list of
mappable business object ID types in Central Finance can be found in the IMG activity Define Mapping
Entities (Enhanced Configuration).

NoteThe COMPANY that you can map in mdg_km_maintain is not the usual company code (BUKRS) but
field VBUND. Company codes are mapped as the GDT BUKRS in the value mapping activity.
In the field Business System you can select the Central Finance system or the source system ID where
the entity exists so it can be mapped to the entity in the other system.

In the field Object ID Type/Object ID, you can enter the specific entity name or ID.

NoteIf the object ID comprises several fields, choose Enter Object ID to open the related input screen.
Most ID types are single-field IDs. An example of a composite ID is the General Ledger Account
Master ID which consists of the fields Chart of Account, Account Number and Company Code.

NoteWhen maintaining mappings for material IDs, you must choose the object ID type Material ID
(internal format) (S/4HANA ). The Central Finance mapping entity MATERIAL_ID only takes this
object ID type into account. Do not use the default object ID type Mapping 1 (Source) Entity to N (Central)
Entities (Key Mapping)Material ID (external format/ERP).

It is possible to map one entity from the source system to several entities in the Central Finance system.

Mapping 1 (Source) Entity to N (Central) Entities (Key) If this type of entry exists, the system will take the
first entry that was configured as a default.

In cases where more complicated logic is necessary (for example, post to GL 113100 if profit center
is PC_02 but post to GL 113001 if profit center is PC_05), this should be implemented as an FI substitution
in the Central Finance system.

If for some reason, FI substitution cannot be used, SAP offers a BAdI for the Central Finance scenario,
where mappings of this type can be implemented. For more information see the documentation of the BAdI:
Enhance Standard Processing of Posting Data.

Transaction MDG_ANALYSE_IDM

You can view all maintained mapped key values for one business object (for example, all mapped cost
centers) in transaction MDG_ANALYSE_IDM.

PreviousNext

You might also like