Вы находитесь на странице: 1из 107

Central Finance

Large Landscape and reporting issues in Finance


CFIN- Architecture

Central Finance landscape architecture contains mainly 3 systems:


The first system is the SAP ERP as the source system where the main business
processes run and FI and CO documents are posted.
The second system is the SAP SLT as the integration platform which reads and
replicates the FI and CO documents.
The third system is the SAP Central Finance as the target system on S/4HANA where
the FI and CO documents are re-posted.
• Central Finance
• Note 2148893 - Central Finance: Implementation and Configuration →https://launchpad.support.sap.com/#/notes/2148893.
• Note 2184567 - Central Finance: Frequently Asked Questions (FAQ) →https://launchpad.support.sap.com/#/notes/2184567.
• Note 2027411 - Central Finance: Enable central finance scenario for COGS split → https://launchpad.support.sap.com/#/notes/2027411.
• Note 2234696 - Central Finance: Mapping of Cost Component Structure/ Cost Component for Cost of Goods Sold Split →https://launchpad.support.sap.com/#/notes/2234696.
• Rollover for more information
• AIF for Central Finance
• Note 2196783 - Central Finance: Error handling with AIF → Corrections→ https://launchpad.support.sap.com/#/notes/2196783.
• Note 2202650 - Central Finance: Error Handling in AIF for Replication of FI Documents → BC-Sets →https://launchpad.support.sap.com/#/notes/2202650.
• Note 2202691 - Central Finance: Error Handling in AIF for Replication of CO documents and Cost Objects → BC-Sets →https://launchpad.support.sap.com/#/notes/2202691.
• Note 2298936 - Central Finance: Error Handling in AIF for Simulation of Initial Load for CO Documents and Cost Object →https://launchpad.support.sap.com/#/notes/2298936.
• Note 1530212 - SAP Application Interface Framework FAQ →https://launchpad.support.sap.com/#/notes/1530212.
• Note 2179803 - Register Functions: Add Custom Specific Functions to views in /AIF/ERR →https://launchpad.support.sap.com/#/notes/2179803.
• SLT for Central Finance
• Note 2154420 - SAP LT Replication Server for SAP Central Finance→ https://launchpad.support.sap.com/#/notes/2154420.
• Special case: source system uses a 3rd party database with a runtime-database license.
• For this constellation "business integration" scenario in SLT must be used, which requires certain steps to be performed that are explained in the following.
• Note 2223621 - Central Finance: Interface for Business Integration →https://launchpad.support.sap.com/#/notes/2223621.
• Note 2223801 - SLT - Central Finance: Interface for Business Integration → https://launchpad.support.sap.com/#/notes/2223801.
• Note 2223808 - SLT remote - Central Finance: Interface for Business Integration → https://launchpad.support.sap.com/#/notes/2223808.
• Note 2234337 - Table Activation fails due to trigger for Central Finance Interface for Business Integration →https://launchpad.support.sap.com/#/notes/2234337.
• Note 2154420 - SAP LT Replication Server for SAP Central Finance→ https://launchpad.support.sap.com/#/notes/2154420.
• SLD for Central Finance
• Note 2225086 - Enabling Central Finance Business Mapping without the need to setup Systems Landscape Directory (SLD) →
https://launchpad.support.sap.com/#/notes/2225086.
From a technical point of view, any ERP system can be defined as a source system
for central finance. The figure outlines the available options for a central finance
environment. Integration of SAP S/4HANA and ECC 6.0 as source systems is
supported out of the box. However, ECC 6.0 source systems require additional
efforts, such as installing the central finance integration component via SAP
notes or upgrading to the latest service pack (SP).
• Important notes for source systems:
• 2323494 - Overview of notes relevant for source system →https://launchpad.support.sap.com/#/notes/2323494.
• 2111634 - Enable sender systems for a Central Finance Scenario →
https://launchpad.support.sap.com/#/notes/2111634.
• 2279674 - Central Finance: Source system (4.6c, 4.7, and 5.0) →
https://launchpad.support.sap.com/#/notes/2279674.
• 2292043 - Central Finance: Enable Clearing Transfer in Source System →
https://launchpad.support.sap.com/#/notes/2292043.
• 2274701 - CFIN: Downport preparation for document change transfer for 4.6c, 4.7, 5.0 →
https://launchpad.support.sap.com/#/notes/2274701.
• 2224363 - Repository Object required for note 2223621 →https://launchpad.support.sap.com/#/notes/2224363.
• 2228844 - Central Finance: Reversal of active invoice are not transferred →
https://launchpad.support.sap.com/#/notes/2228844.
• 2027411 - Enable central finance scenario for COGS split →https://launchpad.support.sap.com/#/notes/2027411.
• 2147776 - Central Finance: Source System enhancements needed for document change transfer →
https://launchpad.support.sap.com/#/notes/2147776.
• 2261648 - Create object FIN_CFIN_CO_SIMULATE →https://launchpad.support.sap.com/#/notes/2261648.
• 2256528 - Source System Data Provider for Cost Object and CO Document Simulation →
https://launchpad.support.sap.com/#/notes/2256528
Data Flow Architecture Guidance (Postings)

/1LT/CFIN_HEADER - header table


/1LT/CFIN_ITEM - item table
/1LT/CFIN_DEBITM - debitor items
/1LT/CFIN_CREDIT - creditor items
/1LT/CFIN_PRDTAX - product tax items
/1LT/CFIN_WIHTAX- withhold tax items
How it works:
SLT loads data from relevant source tables to SAP HANA.
If data is added, deleted or updated SLT detects the delta in the source system.
In real time, the delta information is replicated from SLT to the target system.
Two types of replication are supported: table-based replication and application-
based replication.
Central finance uses the application-based replication.
The SAP LT Replication Server uses a trigger-based replication approach to pass data in
real time, from the source system to the target system.
• Option 1: SLT is deployed on a separate instance This option is recommended.
• Advantages of option 1:
• Additional source systems can be integrated to SLT without impacting the other source systems and the Central Finance
system.
• It does not affected by any upgrade or update of the source systems and the Central Finance system.
• SLT can also be used for other integration scenario besides Central Finance.
• Disadvantages of option 1:
• SLT does not have direct access to the data neither in the source system nor in the Central Finance system.
• Any function or integration logic built based on additional data from the source system and the Central Finance system
requires additional replication.
• Option 2: SLT is deployed in the source system This option is only valid for supported ERP systems.
• Advantages of option 2:
• SLT has direct access to any data in the source system.
• Better performance on read, because there is no network connection required to the source system.
• Disadvantages of option 2:
• Other source systems which are connected to the SLT can impact the performance and stability of the source system with SLT.
• Upgrade and update of the source system with SLT impacts the replication of other source systems.
• Option 3: SLT is deployed in the central finance system
• Advantages of option 3:
• SLT has direct access to any data in the Central Finance system.
• Better performance on replication, because there is no network connection required to the Central Finance system.
• Disadvantages of option 3:
• SLT can have bad performance impact on the Central Finance system, as many source systems get connected.
Option 1This is facilitated by using a dedicated ERP system as a hub for MDG, in which
complete MDG processes (governance and consolidation) are managed in a separate.
Mapping information is stored in the MDG instance, but master data must be replicated
to the central finance system. Therefore, the central finance system must query key
mapping information from the MDG system. However, replication of value mapping,
which mainly consists of customizing settings, must be maintained in the central finance
instance.
Option 2: MDG is deployed on the same instance as the central finance system Consists
of deploying MDG on the central finance system, in which no query or replication is
required for key and value mapping. Nevertheless, master data is still required to be
replicated to the source systems.
AIF –Application Interface Framework

Relavant
AC_DOC/1 : only for accounting documents
CO_DOC/1 : only for controlling documents (internal)
CO_OBJ/1 : only for objects
• The main scenario of central finance is the real-time replication of accounting (FI) and controlling (CO) documents,
as well as cost objects.
• Data flow via SLT is applied not only to real-time replication, but also for the initial load of cost objects and CO
internal postings. The source system requires the central finance integration component for the SLT to read data.
This component can be installed via SAP notes, or by updating to the latest service pack of the release.
• Cost objects are read from the AUFK table and its dependent tables, whereas the CO internal posting is read from
COBK, COEP, and other dependent tables. The FI/CO posting is not read from the BKPF and BSEG tables, but from
CFIN_ACCHD and its dependent tables. This process is due to central finance using application-based replication,
in which data is not replicated table-to-table, but replicated (re-posted) via an accounting interface.
• The cost object and CO internal posting have the same/similar database table structures and interface. The FI/CO
posting has another interface structure as the database table structure.
• There are 3 runtime migration objects for the cost object, FI/CO posting, and CO internal posting in SLT. These
migration objects read the data from the source system and call central finance interfaces to replicate the data.
• The central finance interfaces are as follows:
• Replication of FI/CO postings: FINS_CFIN_AC_DOC_GENERATE
• Replication of CO-internal postings: FINS_CFIN_CO_CENTRAL_POSTING
• Replication of cost objects: FINS_CFIN_CO_OBJECT_ASSIGN
• These interfaces are implemented as part of AIF, in which it enables monitoring and error handling for replicated
data. When the data is passed to the central finance interface, it passes through different steps, in particular
prepare, map, adjust, and post. The steps are similar in all the three interfaces. The central finance BAdI also
provides opportunities to enhance the logic of the postings. The last step of the central finance interfaces calls SAP
standard functions to create cost object, or posting FI and CO documents. Any error occurring during the
replication (including the call of SAP standard functions) is logged in AIF and needs to be resolved.
• It is imperative to remember that all SLT-based replication in central finance passes through AIF, and will also be
monitored in AIF. Hence, AIF is the dedicated monitoring tool for SLT-based replication. The entire process is
triggered for SLT, by activating the configuration and starting the data provisioning.
Whereas SLT-based replication is for real-time replication, the initial load of accounting (FI) and
controlling documents (CO) uses a direct RFC connection to the source systems. The figure shows
the data flow for the FI/CO initial load. The same data flow is also used for the smoke test of cost
object replication and CO internal posting.
The central finance integration component, deployed in the source system, provides function
modules to extract the FI/CO postings from the source systems. This is based on configuration
settings, which contain specific information about the relevant objects (for example, company code,
fiscal year, and period), and also reconcile the initial load.
The initial load is started from the central finance system. The first initial load step is to extract data
from the source system into staging tables (CFIN_ACCxx) in the central finance system. Upon
extraction, the central finance system has all of the required initial load data for the posting. In a
subsequent step, the data is posted from the staging tables into the central finance interface.
• Whereas SLT-based replication is for real-time replication, the initial load of accounting
(FI) and controlling documents (CO) uses a direct RFC connection to the source
systems. The figure shows the data flow for the FI/CO initial load. The same data flow
is also used for the smoke test of cost object replication and CO internal posting.
• The central finance integration component, deployed in the source system, provides
function modules to extract the FI/CO postings from the source systems. This is based
on configuration settings, which contain specific information about the relevant
objects (for example, company code, fiscal year, and period), and also reconcile the
initial load.
• The initial load is started from the central finance system. The first initial load step is
to extract data from the source system into staging tables (CFIN_ACCxx) in the
central finance system. Upon extraction, the central finance system has all of the
required initial load data for the posting. In a subsequent step, the data is posted from
the staging tables into the central finance interface.
Central finance provides 3 main interfaces to replicate cost object, FI/CO posting,
and CO internal posting. All objects and postings in central finance go through these
interfaces. They process the data from source systems, so that they can be replicated
with harmonized data.
These are the interfaces, which are implemented as function modules:
Replication of FI/CO postings: FINS_CFIN_AC_DOC_GENERATE
Replication of CO-internal postings: FINS_CFIN_CO_CENTRAL_POSTING
Replication of cost objects: FINS_CFIN_CO_OBJECT_ASSIGN
One of the main objective of central finance is to harmonize the data across different
source systems.
The data harmonization is mainly project effort, because every customer has different
data from different source systems.
Central finance provides mapping functions for the following data:
Master Data
Handled by MDG key mapping (ID mapping)
Customizing Handled by MDG value mapping (code mapping)
Cost Object Handled by the cost object mapping framework
Central finance provides mapping capabilities to harmonize the replicated data.
There are 3 mapping capabilities:
MDG MappingMDG mapping is the main mapping repository, which handles the mapping for
master data and customizing. This is a reusable component from MDG foundation which is
used by central finance.
If MDG is used with central finance to create master data, the MDG process can automatically
generate the MDG mapping entries. However, this only applies for master data that is created
through MDG process.
Cost Object MappingThe cost object mapping framework is not only a mapping repository for
the cost object, but also a framework to define mapping scenarios and rules for cost objects.
Complex MappingComplex mapping is provided in the central finance via BAdI, where the
above, standard mapping can be overwritten or enhanced.
As this is implemented as ABAP coding, it has fully flexibility.
• q

This figure shows the setup if a customer has SAP Master Data Governance somewhere in their landscape. In
this case, if they are using SAP MDG, they have all the necessary mapping information already available.
This figure shows an example of what happens when a new customer needs to be created in a central finance
scenario:
The business user creates a new customer in the central master data governance system. The central, leading
SAP MDG system sends a notification to one of the source systems that a customer with certain attributes
needs to be created.
The sender system creates the customer using their own master data settings (number range), and replies with
the local number of the newly created customer.
SAP MDG stores this information in a table. If MDG is not in place, there is a very basic user interface, which
can be used in the simple finance add-on to store this information. In this case, MDG does not have to be
licensed.
When an FI document is posted in the source system (in this case, a receivables amount for customer
1000000), SLT pushes the posting in through the central finance accounting Interface. It then pushes it through
the business mapping rules, where it is mapped to CUST_CENT, and posted.
The MDG mapping repository contains key mapping for master data, and value mapping for
customizing.
Central finance provides an MDG upload mapping tool, which can do mass upload and
deletion. Currently, this only supports the key mapping.
MDG standard provides a WebDynpro application to maintain key mapping one by one.
MDG standard provides an SAPGUI transaction to maintain the value mapping one by one.
If the MDG process is used, key mapping can be generated during the activation of master
data from the MDG table into the ERP table.
However, this only applies to mapping entities supported in the MDG process, such as
customer, vendor, and material.
After MDG mapping has been maintained, the central finance replication process can use it
to harmonize the replicated postings.
• However, other objects exist for less than a day (for example, production orders in the food industry or maintenance orders for
small tasks). Alternatively, the objects may be created in the source system because that is where the relevant processes take
place (for example, production orders, quality orders, maintenance orders, WBS elements, and so on). It would not make sense
to create the objects in a central system, and then wait for these objects to be distributed to the source systems.
• In the central finance approach, we continue to create these objects in local source systems. We replicate them into the central
system, and note the relevant mapping (cost object in source system and cost object in central system) using the cost object
mapping framework. When there is a posting that affects the local source system, the mapping will ensure that the centrally
mapped cost object is also updated.
• In the central finance system, you also have the option to maintain a different level of granularity. It may make sense in the
central finance system to have a central product cost collector (like in figure above), to which multiple source-system production
orders are mapped during the replication process.
• Example:
• Production orders of the same order type behave as cost objects in the local system. However, in the central system, it's
unnecessary to have all production order information. Instead, we can map all similar production orders to a central cost object:
product cost collector. During reposting, we can use this central product cost collector to collect costs from production orders.
• A cost object is created in the local system and replicated to the central system.
• You can customize how a cost object in the source system is mapped to a cost object in the central system.
• Cost objects in the central system can be generated automatically according to customizing.
• Mapping information, between cost objects in the source system and the central system, is kept in the central system.
• When an FI/CO document gets replicated, the cost object in the source document is automatically replaced by the
corresponding cost object in the central system.
The main responsibility of cost object replication is to create new cost objects and generate cost
object mapping.
The cost object replication process is as follows:
It checks whether any cost object mapping scenario is defined — this is the cost object to be
replicated (i.e. mapping scenario from IO to IO).
The cost object is passed through the mapping rule, if there is no matched mapping rule defined,
the replication fails.
If there is a matched mapping rule, it will apply the mapping rule (i.e. clear or derived from local
characteristic) and apply the MDG mapping.
The cost object and the cost object assignment (mapping of cost object from source-to-target) will
be created.
The FI/CO replication reads the cost object assignment, so as to replace the cost object in the
Central finance splits the process of data replication into 2 parts:
The first part is the initial load (or “load" in SLT term).
This step loads/replicates existing data only in the source system.
The second part is the real-time replication (or “replication" in SLT term).
This step replicates all newly created data, and also changes existing data in the source system.
The initial load has to be executed in the right order:
First, load the cost objects.
These are required for the FI/CO and CO internal posting in the central finance system.
Perform the initial load of FI/CO posting.
Make sure that all the postings are successfully replicated in the central finance system.
Start the initial load of CO internal posting.
The initial load of cost object and CO internal posting, uses SLT to load and replicate data. This means the selection happens via SLT.
All data in central finance that is replicated by SLT goes through AIF. This means that AIF is the monitoring and error handling tool, for SLT-
based replicated data in central finance.
The initial load of FI/CO posting uses MDF (Mass Data Framework). MDF uses RFC connection to read data from the source system.
Not all data in central finance, that has been replicated via MDG, goes through AIF. This means the monitoring and error handling tool is the
application log of MDF.
There are 2 tools to test and simulate the initial load of cost objects:
Smoke Test of Cost Object
The smoke test of a cost object is an ABAP report in central finance.
It reads the cost object directly from the source system, via RFC.
This tool also tests the creation of a cost object without commit, so no cost object will be persisted in the
central finance system.
This activity should be distinguished from the simulation for initial load, which is used for simulation of initial
load data with high data volume. This activity is not intended for initial load and handles a relatively small
number of records (999 maximum).
Simulation of Cost Object
The simulation of cost object is a tool to replicate cost objects, via SLT and through AIF.
It simulates the complete replication process, without any commit, and it is recommended for high volume
data.
These two tools are optional, but it is recommended to test and simulate before doing the real initial load.
The initial load of FI/CO posting is a completely different process to the initial load of cost
object and CO internal posting.
The initial load of FI/CO posting does not use SLT. It uses MDF (Mass Data Framework).
The process is completely triggered from the central finance system:
Extract data for the initial load of FI/CO posting.
This step reads the historical FI/CO posting from the source systems, and persists them in
the staging table of the central finance system. After this step, all required data for the
initial load of FI/CO posting is in the central finance system.
Simulate posting of FI/CO documents.
This steps simulates the posting of FI/CO documents, which are read from the staging
table.
If the simulation of posting is successful, the initial load data can be posted.
This step performs the posting of FI/CO documents.
There are 2 tools to test and simulate the Initial Load of CO internal posting:
Smoke Test of CO Internal Posting
The smoke test of CO internal posting is an ABAP report in central finance.
It reads the CO internal posting directly from the source system, via RFC.
It tests the posting of CO internal document without commit, so no posting will be persisted in the central
finance system.
This activity should be distinguished from simulation for initial load, which is used for the simulation of initial
load data with high data volume. This activity is not intended for initial load and handles a relatively small
number of records (999 maximum).
Simulation Initial Load of CO Internal Posting
The simulation initial load of CO internal posting is a tool to replicate cost objects, via SLT and through AIF.
This simulates the complete replication process without any commit.
Please use it to do a high-volume test, instead of the smoke test of cost object
These two tools are optional, but it is recommended to test and simulate before doing the real initial load.
Once FI/CO documents are stored in the database, database triggers are written into log tables in the source system.
SAP SLT can collect data from the posted documents in the source system in real-time, and feed it into the corresponding
interfaces that central finance offers.
The replication of CO secondary posting documents, relies on the table COBK as a header table and its sub-tables (such as COEP).
For FI documents, the document header table and its sub tables (BKPF, BSEG, etc.) are not sufficient. Some other information
needed for document posting is no longer available once the document is posted. However, to properly post a document into the
central finance system, the information is required.
That's why the information needed for document posting is stored in tables (with CFIN_ACCHD being the header table). This
information is replicated, via the SAP LT replication server, to the central finance system.
The cleanup-program RFIN_CFIN_CLEANUP, which needs to be scheduled regularly (for example, once each month), can delete the
temporary information from tables.
In order to temporarily store this information in these tables, several notes must be applied. See the Administrator's guide for
more information.
Assign authorizations for SLT users.
The SAP LT replication server is used for the ongoing replication of
data to central finance, for both FI and CO postings. For the initial
load of data, the SAP LT replication server is used to transfer CO
postings. The initial load of FI data is managed via customizing
activities in the central finance system.
• Prerequisites
• Ensure that the central system contains harmonized organizational data, and master data, for all the accounting entities
that you intend to include in your accounting document.
• Configuration and Customizing
• Before you start the initial load, you must carry out the necessary settings for central finance in your SAP source
systems. These settings can be performed in customizing, using transaction CFINIMG, or directly in the
VCFIN_SOURCE_SET view, using transaction SM30.
• For each company code you want to transfer data from, you must define the following:
• The level of detail of data that you want to transfer to the central finance system. If you do not need a high level of
detail, you can choose to transfer balances only. If you need more detailed information, you can also choose to transfer
FI documents, starting with a specific fiscal year and period. You can also combine these two approaches so that you
have balances only for one time frame, typically for older data, and individual documents for more recent data.
• If replication of CO postings is enabled, GL reconciliation postings will be transferred via CO. You should only set the GL
Reconciliation Postings Transferred checkbox, if the replication of CO postings has not been enabled.
• Flag for initial load once the initial load is complete. It is recommended that this flag is set only after all postings are
100% successful.
• The package size. For performance reasons, the default is 50. If you have accounting documents with only a small
number of lines items, you can enter a larger package size.
• For postings relating to multiple company codes that you want to transfer from the source system to the central finance
system, all company codes must be mapped in the target system. Therefore, you must ensure that you make
configuration settings here for all relevant company codes.
The glue that holds the various systems together in the central finance scenario is SAP Landscape
Transformation. This is, essentially, a server that collects postings from the local system and routes them to the
central system. SLT works at the table level, and uses an initial load object and a replication object for each table
to be transferred.
The initial load of FI/CO documents uses Mass Data Framework, which extracts the data from the source system,
via RFC function modules, and re-posts the extracted data as FI/CO documents in the central finance system.
The initial load of cost objects and CO internal documents uses SLT.
The delta replication (real-time replication) of all three objects uses SLT.

SAP source with runtime license (CFIN_PI application must be used


when creating the configuration). More, relevant notes for business
integration scenario must be applied in all systems.
SAP is not allowed to provide any function to extract data from non-SAP system
(competitors).
Therefore, SAP works together with SAP partner to integrate non-SAP system to
central finance.
Data harmonization is a key prerequisite for a successful central finance
project.
Additionally, it is important to define upfront what the objective is for having
central finance landscape.
Reporting, non-transactional.
Hybrid, reporting and transactional with central processes.
Path to S/4HANA, decommissioning legacy systems.
• The following activities are carried out in Customizing for Central Finance under Financial Accounting (New) > Central
Finance > General Settings:
• Activate the central finance business function.
• The business function central finance (FINS_CFIN) must be activated. If the business function has not been activated,
activate it in the switch framework (transaction SFW5).
• Set up RFC destination for the source system.
• In this activity, you define technical parameters for RFC destinations. These parameters are used for remote function
calls (RFC) to other systems. RFC destinations are needed for the initial load of posting data, from the connected source
systems to central finance, and to navigate to accounting documents in the source system.
• Define a logical system for source system.
• In this activity, you define one logical system for the connected source system client, and one logical system for the
receiving central finance client. A logical system identifies the client of the connected source systems in the accounting
documents. The name of the logical system must be the same in the source system and the central finance system.
• The recommended naming convention for logical systems is as follows:
• <System ID> CLNT <Client Number>, for example Q91CLNT800
• Assign an RFC destination to the logical system of source system.
• In this activity, you assign RFC destinations to logical systems for each connected source system.
• Check the logical system assignment for central finance client.
• In this activity, you check the logical system assignment for the central finance system client.
• These settings cannot be transported. When a new system is being set up, these settings must be made after the system
installation has been completed.
• Configure decimal places for the currencies.
• For any currencies with differing numbers of decimal places, enter the number of decimal places as defined in the
source system. For currencies that have the same number of decimals in the source systems and the central finance
systems, you do not need to make any entries.
• Special Configurations
• For support with postings whose currencies that have a mismatched number of decimals configured in the source and target system, see the following SAP
Notes:
• 2318183 - Central Finance: Wrong number of decimals for amounts in replicated documentshttps://launchpad.support.sap.com/#/notes/2318183
• 2325587 - Central Finance: Wrong number of decimals for amounts in replicated CO documentshttps://launchpad.support.sap.com/#/notes/2325587
• 2217711 - Currency Handling Fix of CO Posting in Central Finance:https://launchpad.support.sap.com /#/notes/2217711
• Use
• To set the number of decimal places for currencies in the source system, if they are defined differently than in the central finance system.
• Requirements
• The number of decimal places for currencies, in both the source and central finance systems, is maintained in the IMG activity: Set Decimal Places for
Currencies. This activity is usually part of the general setup of the system.
• You have compared the number of decimal places in all currencies in use in your systems, and identified any currencies with differing numbers of decimals.
• Standard settings
• In the standard setup, this activity contains no settings. This means that all currencies are assumed to have the same number of decimal places in both the
source system and the central finance system.
• Activities
• For any currencies with differing numbers of decimal places, enter the number of decimal places as defined in the source system. For currencies that have
the same number of decimals in the source and central finance systems, you do not need to make any entries.
• Example
• In a source system (logical system Q7QCLNT002), the currency KWD (Kuwait-Dinar) is set to 2 decimal places. However, in the central finance system this
currency is set to no decimal places.
• Make the following entry:
• Logical System Currency Decimals Q7QCLNT002 KWD 2
• Note: Even though the definition of the logical system includes the client in the source system, the corresponding setting is client-independent in the
source system. This means that the settings must be equal for different clients of the same source system.
• If the currency in central finance has fewer decimals than the sender system,
the rounding differences have to be handled and distributed to other
document items.
• "Round half up" is applied if required:
• If the last digit is ≤ 4, the amount is rounded down.
• If the last digit is ≥ 5, the amount is rounded up.
• The rounding difference is added to or subtracted from the first non-
automatically generated G/L account, material, or asset account item,
depending on the +/- sign in the document. The amount of a vendor line
item, or customer line item, is only changed if special prerequisites are met
(for example, if the document contains no G/L line item or only lines with
small amounts). This is because the previous application is supposed to
display the same amounts for business partners as the ones that are posted
in financial accounting.
• \
• When accounting documents are posted in central finance, business mapping is used to harmonize the master data in the
documents. Identifiers and codes in the documents must be mapped, that is, the relationship between an identifier or
code used in the source system, and one used in Central Finance, must have been defined. This is necessary because
sometimes different identifier or codes are used for the same entity. For example, in the source system, a customer may
have the ID 28900, whereas in the central finance system, the same customer has the ID 13700. Codes and identifiers may
also be different across the various systems of your existing system landscape.
• Mapping must be defined for the following categories:
• Mapping for business object identifiers (for example, customer ID, vendor ID, or material ID).
• This is done using MDG key mapping functions.
• Mapping for codes (for example, company code, business area, or country code).
• This is done using MDG value mapping functions.
• Central finance business mapping uses MDG mapping functions and its data repository. This does not mean that MDG
master data governance processes have to be set up. It is sufficient to maintain the relevant mapping data in the central
finance system. An extra license for MDG is not required if you only want to use the mapping functions, and not the
master data distribution functions.
• Mapping for short-living cost objects (for example, production order or internal order).
• This is done in customizing in central finance.
• 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.
• For the mapping of characteristics used in data that is transferred from the source systems to the central finance system, the
following frameworks are used:
• Define key mapping (ID mapping)
• Identifiers for instances of business objects may be different in the sender systems and the central finance system, making it
necessary to define mapping between these identifiers. Create and edit key mapping in this activity. Maintain key mappings, choosing
different business object types, and object IDs.
• Key mappings can be entered either manually, one by one, via a WebDynpro UI (transactionMDG_KM_MAINTAIN).
• In either case, you need to know:
– Business object type and object identifier type of the respective entity.
– Business system of the source system and the central finance system.
– Context (key) structure.
– The values of all fields of the context structure, in the source system and in the central finance system (from-to-values).
– Helpful — program to display already existing key mappings: transaction MDG_ANALYSE_IDM(program RMDG_ANALYSE_KEY_MAPPING).
– Helpful, but dangerous — program to delete ALL key mappings for one given BO type.
• Value 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 (New) → Central Finance → Advanced Settings → Define
Mapping Entities (Enhanced Configuration).
• In the Define Mapped Fields (Customer) subview, you can define the non-standard fields which you want to map as a mapping entity.
• Non-standard fields are fields that have been added to the accounting interface, via customer enhancements or are not mapped in
the standard.

To define mapping actions for mapping entities, go to: Central Finance → Mapping → Define Mapping
Actions for Mapping Entities.
• In this customizing activity, you define the mapping action for each mapping entity (for example, customer
ID) and, if necessary, for each sender business system.
• The following mapping actions are available:
• Keep DataField values of this kind are not mapped at all. The data from the sending system is retained.
• Mapping ObligatoryThe field values for all filled fields must be mapped (in mdg_km_maintain). If no
mapping data exists, an error is raised.
• Map if PossibleThe 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 sending system is retained (mix between "keep data" and
"mapping obligatory").
• Clear DataFields of this kind are always cleared (this means those fields won't be replicated at all in the
central finance system, nor used.
• Whether an entity will be handled by the MDG key, or by value mapping, can be seen in the IMG activity:
Define Mapping Entities (Enhanced Configuration). With the central finance IMG:
• Entities subject to key mapping have an assigned Object ID, ID Field Name, and, if applicable, contexts.
• Entities subject to value mapping have an assigned Type and Global Data Type.
• In the IMG activity Assign Code Lists to Elements and Systems, list IDs can be assigned
freely. However, for two entries in the same GDT, the list IDs must be different. This means
that the list ID must be unique for each entry.
• In the same activity, multiple entries must be maintained for entities that have
superordinate characteristics. This means one entry for each combination of
superordinate characteristics values.
• Internal refers to the target system (central finance). External refers to the source system.
• Entity values can be cleared by creating own mapping entities (in customer namespace).
• Unlike MDG key mappings, value mappings are stored in customizing tables. Therefore, a
larger number of value mappings (for entities such as Tax Code) can be uploaded easily, if
the table structure and the logic of the settings are well understood. Caution and due
diligence must be applied. Don’t forget to trigger transport of settings after upload.

Оценить