CFin BAdI Guide
CFin BAdI Guide
1.0
Overview ...................................................................................................................................................... 1
In this document, the most used BAdIs provided by SAP for the Central Finance scenario are explained.
These BAdIs can be categorized as follows:
The BAdI BADI_FIN_CFIN_DOCUMENT is mainly used to enhance different objects during initial load
and real time replication with custom fields in the source system. The custom fields are persisted only in CFIN
staging tables. The BAdI has different methods which are called in different processes. The below table gives a
high-level overview of the methods
FI_DOC_ENHANCE_INI- Enhance FI/CO document with custom fields during extraction from
TIAL_LOAD source system
FI_DOC_ENHANCE_ONGOING Enhance FI/CO document with custom fields during posting in the source
system
PCA_ENHANCE Enhance PCA document with custom fields during execution of steps –
“EC-PCA Simulation Tool”, “EC-PCA Execute Initial Load” and during
posting of PCA document in the source system
SKIP_COPA Skip the transfer of COPA attributes during initial load and real time repli-
cation of FI/CO documents and CO secondary postings
The below graphics explains which of the above methods are called for each process:
In order to enhance the historical FI/CO documents with custom fields during extraction step, the cus-
tom fields have to be created in the source system in the customer include CI_CFIN_ACCIT_APP_EXT. Same
fields have to be created in the Central Finance in one of the customer includes CI_COBL, INCL_EEW_ACDOC
or CI_CFIN_ACCIT_APP_EXT, depending what is the use case for the respective custom field in Central Finance
After the custom fields have been added in the structures, the BAdI method FI_DOC_ENHANCE_INI-
TIAL_LOAD can be implemented to populate the respective custom fields during extraction step. The below
graphic explains in more details how the BAdI is called during extraction step:
A – The extraction is triggered from Central Finance System - “CFINIMG->Central Finance: Target System
Settings-> Initial Load -> Initial Load Execution for Financial Accounting->Initial Load Execution for All Company
Codes -> Extract Data For Initial Load” or “CFINIMG->Central Finance: Target System Settings-> Initial Load -
> Initial Load Execution for Financial Accounting->Initial Load Execution for Selected Company Codes -> Exe-
cute Initial Load for Initial Load Group”. The system will call a function module from source system via method
CL_FINS_CFIN_MIG_EXTRACT->IF_FINS_MASS_DATA~GET_PACKAGES.
C – Based on the configuration settings and the defined scope, some package IDs are created for the FI/CO
documents in scope, in order to extract them using parallel processes
D – schedule N jobs in parallel to execute the extraction of FI/CO documents based on the package IDs created
in point C. The processing of package is done using method CL_FINS_CFIN_MIG_EXTRACT-
>IF_FINS_MASS_DATA~PROCESS
F – Based on the package ID, the corresponding document is extracted from the source system from FI tables
– BKPF, BSEG, etc.
G – the extracted data from source system is posted in the staging tables from Central Finance System. The
custom fields populated in point number 2 are saved in CFIN_ACCIT_APP table, if a field with same name exists
in this table.
2 – the custom fields added in the customer include CI_CFIN_ACCIT_APP_EXT can be populated using BAdI
method FI_DOC_ENHANCE_INITIAL_LOAD.
In order to enhance the new created FI/CO documents with custom fields during posting in the source
system, the custom fields have to be created in the source system in the customer include CI_CFIN_AC-
CIT_APP_EXT. Same fields have to be created in the Central Finance in one of the customer includes CI_COBL,
INCL_EEW_ACDOC or CI_CFIN_ACCIT_APP_EXT, depending what is the use case for the respective custom
field in Central Finance system. By adding the custom fields in the respective includes, it will automatically ex-
tend the staging table CFIN_ACCIT_APP in source/target system.
After the custom fields have been added in the structures, the BAdI method FI_DOC_ENHANCE_ON-
GOING can be implemented to populate the respective custom fields during posting in the source system. The
below graphic explains in more details how the BAdI is called during posting step:
B – When the FI/CO document is created in an SAP system, the corresponding Function Modules from table
TRWPR are executed dynamically by the Accounting Interface. These function modules are checking the con-
sistency of the document and it prepares it to be saved in the FI/CO tables, but also in the cFIN staging tables.
C – Function Module FIN_CFIN_RWIN_DOC_POST is responsible to prepare and save the FI/CO document in
the cFIN staging tables.
D – save FI/CO document in cFIN staging tables. The custom fields are saved in table CFIN_ACCIT_APP.
1 – if in the FI/CO document a profitability segment exists, then its corresponding CO-PA characteristics can
be saved in table CFIN_ACCPA_CHAR. Using the BAdI method SKIP_COPA, you can skip the saving of CO-PA
characteristics. In this case, nothing will be saved in CFIN_ACCPA_CHAR table in the source system.
2 – the custom fields added in the customer include CI_CFIN_ACCIT_APP_EXT can be populated using BAdI
method FI_DOC_ENHANCE_ONGOING.
In order to enhance the historical CO secondary documents with custom fields, the initial step is to
create the custom fields in the source system in the customer include CI_CFIN_CO_EXT. Same fields have to
be created in the Central Finance in the same include CI_CFIN_CO_EXT. By adding the custom fields in the
respective includes, it will automatically extend the staging table CFIN_CO_ADD in source system/target sys-
tem.
After the custom fields have been added in the structures, the BAdI method CO_DOC_ENHANCE can
be implemented to populate the respective custom fields during execution of “Prepare for Initial Load of CO
Postings”. The below graphic explains in more details how the BAdI is called during execution of this step:
A – The user triggers this step from Central Finance System - “CFINIMG->Central Finance: Target System Set-
tings-> Initial Load -> Initial Load Preparation for Management Accounting->Prepare for and Monitor the Initial
Load of CO Postings”.
C – the role of main job FIN_CFIN_CO_MAIN is to calculate the number of historical CO documents and to create
packages for parallel processing. For each package, a processing job is scheduled
D – the job which process the package is executing report RFIN_CFIN_CO_PREPARE. The purpose of this pro-
gram is to populate tables CFIN_COPA and CFIN_CO_ADD in the source system for the historical CO secondary
postings (based on the defined scope)
E – The documents from the package are selected from database tables COBK and COEP
F – The system prepares the standard content to be saved in CFIN_CO_ADD – example – add a corresponding
entry in CFIN_CO_ADD for each CO line item which contains a WBS. The WBS external number is saved in
CFIN_CO_ADD. Later on, in cFIN system, the WBS external number is used for mapping the WBS.
G – after the entries for CFIN_CO_ADD are prepared (point F and 2), these are inserted into CFIN_CO_ADD
table
1 – if in the CO document a profitability segment exists, then its corresponding CO-PA characteristics will be
saved into CFIN_COPA table. Using the BAdI method SKIP_COPA, you can skip the population of this table.
2 – the custom fields added in the customer include CI_CFIN_CO_EXT can be populated using BAdI method
CO_DOC_ENHANCE.
In order to enhance the new created CO documents with custom fields during posting in the source
system, the custom fields have to be created in the source system in the customer include CI_CFIN_CO_EXT.
Same fields have to be created in the Central Finance in the same customer include CI_CFIN_CO_EXT. By add-
ing the custom fields in the respective includes, it will automatically extend the staging table CFIN_CO_ADD in
source/target system.
After the custom fields have been added in the structures, the BAdI method CO_DOC_ENHANCE
(same as for historical CO documents) can be implemented to populate the respective custom fields during
posting in the source system. The below graphic explains in more details how the BAdI is called during posting
step:
B – When the CO document is created in an SAP system, the corresponding Function Modules from table
TRWPR are executed dynamically. These function modules are checking the consistency of the document and
it prepares it to be saved in the CO tables, but also it will save some data in the cFIN staging tables CFIN_COPA
and CFIN_CO_ADD.
C – Function Module FIN_CFIN_RWIN_SAVE_COPA is responsible to prepare and save the COPA characteris-
tics in CFIN_COPA table.
F - The system prepares the standard content to be saved in CFIN_CO_ADD – example – add a corresponding
entry in CFIN_CO_ADD for each CO line item which contains a WBS. The WBS external number is saved in
CFIN_CO_ADD. Later on, in cFIN system, the WBS external number is used for mapping the WBS.
G – after the entries for CFIN_CO_ADD are prepared (point F and 2), these are inserted into CFIN_CO_ADD
table
E – the replicated documents are processed in cFIN system. The custom fields transferred from the source
system can be processed in cFIN system only in case same fields have been created in cFIN system in the cus-
tomer include CI_CFIN_CO_EXT.
2 – the custom fields added in the customer include CI_CFIN_CO_EXT can be populated using BAdI method
CO_DOC_ENHANCE.
In order to enhance the historical Commitments with custom fields, the initial step is to create the cus-
tom fields in the source system in the customer include CI_CFIN_CMT_EXT. Same fields have to be created in
the Central Finance in the same include CI_CFIN_CMT_EXT. By adding the custom fields in the respective in-
cludes, it will automatically extend the staging table CFIN_CMT_I in source system/target system.
After the custom fields have been added in the structures, the BAdI method CMT_ENHANCE can be
implemented to populate the respective custom fields during execution of “Prepare for Initial Load of Commit-
ments”. The below graphic explains in more details how the BAdI is called during execution of this step:
A – The user triggers this step from Central Finance System - “CFINIMG->Central Finance: Target System Set-
tings-> Initial Load -> Initial Load Preparation for Management Accounting-> Prepare for Initial Load of Com-
mitments”.
B – the Function Module FIN_CFIN_CMT_TRIGGER_PREPARE from source system is executed. The main pur-
pose of this function module is to schedule the main job which executes the program FIN_CFIN_CMT_MAIN
C – the role of main job FIN_CFIN_CMT_MAIN is to calculate the number of historical commitments and to
create packages for parallel processing. For each package, a processing job is scheduled
E – The commitments from the package are selected from database tables EBAN (Purchase Requisition) and
EKPO (Purchase Order)
F – The system is calling the registered function modules from TRWPR table. FIN_CFIN_CMT_POST_PR_IL is
executed for Purchase Requisitions and FIN_CFIN_CMT_POST_PO_IL is executed for Purchase Orders
G – Based on the Purchase Requisition and Purchase Order information, the system prepares the data to be
saved in the staging tables CFIN_CMT_H and CFIN_CMT_I
H – after the entries for CFIN_CMT_H and CFIN_CMT_I am prepared (point G and 1), these are inserted into
database
1 – the custom fields added in the customer include CI_CFIN_CMT_EXT can be populated using BAdI method
CMT_ENHANCE.
In order to enhance the new created Commitments with custom fields, the initial step is to create the
custom fields in the source system in the customer include CI_CFIN_CMT_EXT. Same fields have to be created
in the Central Finance in the same include CI_CFIN_CMT_EXT. By adding the custom fields in the respective
includes, it will automatically extend the staging table CFIN_CMT_I in source system/target system.
After the custom fields have been added in the structures, the BAdI method CMT_ENHANCE (same as
for the historical commitments) can be implemented to populate the respective custom fields during posting
of purchase requisition or purchase order. The below graphic explains in more details how the BAdI is called
during posting step:
B – The system will call dynamically the corresponding function modules from TRWPR table
C – The system is calling the registered cFIN function modules from TRWPR table: FIN_CFIN_CMT_POST_PR
is executed for Purchase Requisitions and FIN_CFIN_CMT_POST_PO is executed for Purchase Orders
D – Based on the Purchase Requisition and Purchase Order information, the system prepares the data to be
saved in the staging tables CFIN_CMT_H and CFIN_CMT_I
E – after the entries for CFIN_CMT_H and CFIN_CMT_I are prepared (point D and 1), these are inserted into
database
F – the replicated commitment is processed in cFIN system. The custom fields transferred from the source
system can be processed in cFIN system only in case same fields have been created in cFIN system in the cus-
tomer include CI_CFIN_CMT_EXT.
1 – the custom fields added in the customer include CI_CFIN_CMT_EXT can be populated using BAdI method
CMT_ENHANCE.
In order to enhance the historical PCA documents with custom fields during simulation and initial load
steps, the custom fields have to be created in the source system in the customer include CI_CFIN_AC-
CIT_APP_EXT. Same fields have to be created in the Central Finance in one of the customer includes CI_COBL,
INCL_EEW_ACDOC or CI_CFIN_ACCIT_APP_EXT, depending what is the use case for the respective custom
field in Central Finance system. By adding the custom fields in the respective includes, it will automatically ex-
tend the staging table CFIN_ACCIT_APP in source/target system.
After the custom fields have been added in the structures, the BAdI method PCA_ENHANCE can be
implemented to populate the respective custom fields during simulation and initial load step. The below graphic
explains in more details how the BAdI is called during simulation and initial load steps:
C – The PCA documents are selected from database – GLPCA for PCA documents and GLPCT for PCA bal-
ances (CL_FIN_CFIN_PCA_INIT_LOAD)
D – the selected data is mapped to the staging tables structures (CFIN_ACCHD, CFIN_ACCIT, etc.).
E – the data is saved into staging tables based on the prepared information from point D and 1.
1 – the custom fields added in the customer include CI_CFIN_ACCIT_APP_EXT can be populated using BAdI
method PCA_ENHANCE.
In order to enhance the new created PCA documents with custom fields during posting in the source
system, the custom fields have to be created in the source system in the customer include CI_CFIN_AC-
CIT_APP_EXT. Same fields have to be created in the Central Finance in one of the customer includes CI_COBL,
INCL_EEW_ACDOC or CI_CFIN_ACCIT_APP_EXT, depending what is the use case for the respective custom
field in Central Finance system. By adding the custom fields in the respective includes, it will automatically ex-
tend the staging table CFIN_ACCIT_APP in source/target system.
A – The user triggers the creation of PCA document in the source system
B – after the consistency checks are performed for the PCA document, before saving it to database, the system
calls the Function Module FIN_CFIN_G_PCA_0_CAPTURE
C – The PCA document is mapped to the staging tables structures (CFIN_ACCHD, CFIN_ACCIT, etc.).
D – the data is saved into staging tables based on the prepared information from point C and 1.
F – the replicated PCA document is processed in cFIN system. The custom fields transferred from the source
system can be processed in cFIN system only in case same fields have been created in cFIN system in in one of
the customers includes CI_COBL, INCL_EEW_ACDOC or CI_CFIN_ACCIT_APP_EXT
1 – the custom fields added in the customer include CI_CFIN_ACCIT_APP_EXT can be populated using BAdI
method PCA_ENHANCE.
The BAdI BADI_FIN_CFIN_DFV can be used to enhance the standard selection from the source system
of the reconciliation reports provided by the Central Finance solution. It has multiple methods and some of them
are called only by specific reports. The below table provides an overview of the available methods:
GET_IMPLCLNAME The standard implementation class CL_FINS_CFIN_DFV, which contains the logic for
selection of data and comparison, can be replaced with a custom class which imple-
ments the interface IF_FINS_CFIN_DFV.
FILTER_BKPF Adjust the selection of FI document headers (delete/add entries or change selected
entries)
FILTER_BSEG Adjust the selection of FI document line items (delete/add entries or change selected
entries)
FILTER_COBK Adjust the selection of CO document headers (delete/add entries or change selected
entries)
FILTER_COEP Adjust the selection of CO document line items (delete/add entries or change se-
lected entries)
The below graphics explains which of the above methods are called for each reconciliation report:
C – the data from BKPF table is selected based on the filters from the selection screen
D – By standard, some of the selected FI documents are excluded (for example, if the user does not have the
authority for the respective company code, or the year end closing postings)
E – based on source system FI documents, select the corresponding entries from cFIN system from BKPF table
or from AIF tables
1 - the standard implementation class for comparison reports CL_FIN_CFIN_DFV can be replaced with a custom
class which implements the interface IF_FIN_CFIN_DFV. If this is done, it is the customer responsibility to im-
plement the method IF_FIN_CFIN_DFV -> COMPARE_ACC_DOC_HEADER to select the data from source sys-
tem. The points C, D and 2 will not be executed in this case.
2 – Using BAdI method, FILTER_BKPF, the selection can be adjusted – exclude selected documents, include
new documents or adjust information on selected documents.
C – the data from BKPF table is selected based on the filters from the selection screen
D – By standard, some of the selected FI documents are excluded (for example, if the user does not have the
authority for the respective company code, or the year end closing postings)
E – based on the FI headers, select the corresponding FI line items from BSEG table
F – based on source system FI documents, select the corresponding entries from cFIN system from BKPF table
and their corresponding line items from ACDOCA. If the corresponding entries do not exist in BKPF table, the
entries from AIF tables are selected.
1 - the standard implementation class for comparison reports CL_FIN_CFIN_DFV can be replaced with a custom
class which implements the interface IF_FIN_CFIN_DFV. If this is done, it is the customer responsibility to im-
plement the method IF_FIN_CFIN_DFV -> COMPARE_ACC_DOC_ITEMS to select the data from source system.
The points C, D, E and 2, 3 will not be executed in this case.
3 - Using BAdI method, FILTER_BSEG, the selection can be adjusted – exclude selected line items, include new
line items or adjust information on selected line items.
C – the balances are selected from GLT0(Classic-GL) or FAGLFLEXT(New-GL) tables based on the filters from
the selection screen
D – based on the source system balances, select the corresponding FI balances from cFIN system from BKPF
and ACDOCA tables
1 - the standard implementation class for comparison reports CL_FIN_CFIN_DFV can be replaced with a custom
class which implements the interface IF_FIN_CFIN_DFV. If this is done, it is the customer responsibility to im-
plement the method IF_FIN_CFIN_DFV -> COMPARE_ACC_ACCOUNT_BALANCE to select the data from
source system. The point C will not be executed in this case.
C – method CL_FIN_CFIN_DFV->GET_SUPPORTED_FUNC is executed. This will return some flags which de-
cides if the reconciliation can be executed.
F – the data from COBK table is selected based on the filters from the selection screen
G – based on source system CO documents, select the corresponding entries from cFIN system from COBK
table or from AIF tables
1 - the standard implementation class for comparison reports CL_FIN_CFIN_DFV can be replaced with a custom
class which implements the interface IF_FIN_CFIN_DFV. If this is done, it is the customer responsibility to im-
plement the methods IF_FIN_CFIN_DFV->GET_SUPPORTED_FUNC and IF_FIN_CFIN_DFV-
>GET_CO_DOC_HEADER to select the data from source system. The points C, F and 2 will not be executed in
this case.
C – method CL_FIN_CFIN_DFV->GET_SUPPORTED_FUNC is executed. This will return some flags which de-
cides if the reconciliation can be executed.
F – the data from COBK table is selected based on the filters from the selection screen
G – based on CO document headers, select the corresponding line items from COEP table
H – based on the source system CO documents and line items, get the corresponding CO documents from cFIN
from COBK and their corresponding line items from ACDOCA
2 – Using BAdI method, FILTER_COBK, the selection can be adjusted – exclude selected documents, include
new documents or adjust information on selected documents.
3 - Using BAdI method, FILTER_COEP, the selection can be adjusted – exclude selected line items, include new
line items or adjust information on selected line items.
C – method CL_FIN_CFIN_DFV->GET_SUPPORTED_FUNC is executed. This will return some flags which de-
cides if the reconciliation can be executed.
F – if on the selection screen, one of the following fields is populated – Order, Order Type, Order Group, Cost
Center, Cost Center Group – then the corresponding OBJNRs are determined for Cost Centers and Orders
H – based on the source system CO balances, get the corresponding CO balances from cFIN from COBK and
ACDOCA
1 - the standard implementation class for comparison reports CL_FIN_CFIN_DFV can be replaced with a custom
class which implements the interface IF_FIN_CFIN_DFV. If this is done, it is the customer responsibility to im-
plement the methods IF_FIN_CFIN_DFV->GET_SUPPORTED_FUNC and IF_FIN_CFIN_DFV->GET_CO_SUM to
select the data from source system. The points C, F, G and 2 will not be executed in this case.
2 - the standard implementation classes to determine the Objects numbers for Orders and Cost Centers -
CL_FIN_CFIN_DFV_ACCAS_OR and CL_FIN_CFIN_DFV_ACCAS_KS can be replaced with custom classes
which implements the interface IF_FIN_CFIN_DFV_ACCAS. If this is done, it is the customer responsibility to
implement the method IF_FIN_CFIN_DFV_ACCAS->GET_LIST_BY_SELOPT to select the corresponding Object
Numbers (OBJNR) for Cost Centers and Orders. The point F will not be executed in this case.
For the objects which are transferred from source system to Central Finance system, several cFIN
functions are applied firstly to the respective objects when these are processed in cFIN system, and in the end,
the standard API is called to post the objects. The BAdIs from this category are called during the execution of
cFIN functions (only for replicated objects). The BAdIs available in the standard API are also called (for repli-
cated objects and for created objects directly in cFIN system). For a better understanding, see the below ge-
neric figure:
When an FI/CO document is posted in an SAP system, the standard Accounting Interface is executed
– Function Module “AC_DOCUMENT_CREATE”. For the documents which are posted via a Central Finance Sce-
nario (documents which are coming from source system), several other Central Finance Specific steps are ex-
ecuted before the Accounting Interface is called.
This BAdI is called during initial load and real time replication of FI/CO documents. The below figure
gives an overview where the BAdI is called:
A more detailed graphic with the connection of standard code from cFIN functions and the BAdI meth-
ods is described below:
Central Finance specific functions (the ones listed here are the most important ones, in order to show
where exactly the BAdI methods are called):
A – CL_FINS_CFIN_AC_DOC_AGENT->PREPARE_DATA – adjust the data which is coming from the source (ex-
ample - the asset accounting fields are deleted because these are not supported by Central Finance – ANLN1,
ANLN2)
B – CL_FINS_CFIN_AC_DOC_AGENT->MAP_VALUES – the MDG Value Mapping and MDG Key Mapping are
applied to the FI/CO document fields.
2 – PREPARE_INPUT_DATA – this method can be used to adjust the data which is coming from the source
system (example – clear information which is not needed in cFIN).
3 – MAP_VALUES – this method can be used to adjust the FI/CO document after the MDG Mapping. The main
purpose of this method should be the mapping of different fields. However, it is recommended to check first if
mapping can be maintained in MDG or if BAdI BADI_FINS_CFIN_MAPPING_PROCESS can be used instead. Only
if none of these are possible, then the mapping logic can be implemented in this method.
4 – ADJUST_POSTING_DATA – this method can be used for final adjustments to the FI/CO document (custom
adjustments).
5 – CALL_AC_INTERFACE – this method is executed only if the control was taken in method GET_PRO-
CESS_CONTROL (otherwise, the standard method is executed). In this case, the developer should take care
about calling the Accounting Interface.
The FI/CO documents which are part of initial load are processed differently for the ones which are
part of real time replication scenario. The reason is that during initial load, the data is extracted from FI and from
CO tables from the source system, and in Central Finance, the system will try to merge this information to-
gether. In the real time replication scenario, the data is captured when the FI and CO are still merged in the
source system.
In the extraction step, the data from FI tables and CO tables is extracted from the source system and
stored in the staging tables from Central Finance system (CFIN_ACCHD, CFIN_ACCIT, etc.). The FI document
is stored in CFIN_ACCIT with “AWTYP” = “FIDO”, and the CO document is stored in CFIN_ACCIT with “AWTYP”
= “CODO”. The quantities from CO document are stored in FINS_CFIN_COQUAN table.
C – in case the BAdI was not implemented, the standard matching is executed
D – after the matching was done, the system continues to process the FI/CO document (apply the
remaining cFIN functions and then call the accounting interface)
1 – if the BAdI is implemented, the matching of FI and CO quantities is in total control of the customer.
For the replication of the CO documents, the process is similar as for FI/CO documents: when the
document reaches cFIN system, firstly the cFIN specific functions are executed and then the CO interface is
called.
The Central Finance specific function are marked with letters(green), and the BAdI methods are
marked with numbers(red).
Central Finance specific functions (the ones listed here are the most important ones, in order to show
where exactly the BAdI methods are called):
1 – GET_PROCESS_CONTROL – in this method the developer has the chance to set some flags which will be
used to skip/to not skip the standard methods listed above. If the values are set, then the standard method is
skipped in the respective step, and only the BAdI method is executed.
2 – PREPARE_INPUT_DATA – this method can be used to adjust the data which is coming from the source
system
3 – MAP_VALUES – this method can be used to populate fields after the MDG Mapping. The main purpose of
this method should be the mapping of different fields. However, it is recommended to check first if mapping can
be maintained in MDG or if BAdI BADI_FINS_CFIN_MAPPING_PROCESS can be used instead. Only if none of
these are possible, then the mapping logic can be implemented in this method.
4 – MAP_REPLACE_CO_POSTING_DATA – this method can be used to add new cost object types which can be
used during posting (except the ones which are already supported by standard – see point B)
5 – ADJUST_ DATA – this method can be used for final adjustments to the CO document (custom adjustments)
6 – POST_DATA – this method is executed after the execution of the CO interface and can be used to save
additional data (in a custom table for example).
The BAdI BADI_FINS_CFIN_CO_OBJECT_ASSIG can be used to enhance the cost objects which are
replicated from source system to Central Finance System. Here is an overview where the BAdI is called:
It is very important to know that this BAdI is strong connected with the Cost Object Mapping Frame-
work (COMF) functionalities, and its methods are called in specific places:
2 - Method GET_PROCESS_CONTROL of the BAdI is called. Here it is possible to set the flag to skip the standard
MDG Mapping process.
3 – Based on the flag set at point 2 in the BAdI, the system skips or not the standard MDG mapping
4 - Standard MDG Mapping is applied ONLY to the defined central characteristics which have the flag “Derive
from Local” from COMF
5 - The method MAP_ORDER_MASTER_DATA gives the possibility to add custom logic for the derivation of
different fields. But only the fields which are defined as Central Characteristics will be considered (see point 7).
The main purpose of this method should be the mapping of different fields. However, it is recommended to
check first if mapping can be maintained in MDG or if BAdI BADI_FINS_CFIN_MAPPING_PROCESS can be used
instead. Only if none of these are possible, then the mapping logic can be implemented in this method.
6 - Same as 5
8 - Create the order in Central Finance ONLY with Central Characteristics fields. In the end, the Mapping be-
tween source order ID and Central Finance order ID is stored in table FINS_CFINT_ASGMT.
When PS/WBS is replicated in Central Finance via IDOC, the system will first call the generic IDOC BAdI
– IDOC_DATA_MAPPER, and after the IDOC is saved in the DB, it will be processed and the cFIN BAdI
BADI_FINS_CFIN_PS is called.
In the IDOC_DATA_MAPPER is called before MDG Mapping and all the segments can be changed, in-
cluding hierarchy and statuses. The cFIN BAdI BADI_FINS_CFIN_PS is called after MDG Mapping and only the
PS/WBS information can be changed (hierarchy and statuses cannot be changed using this BAdI).
When an AIF message is restarted, the system will start the processing of PS/WBS based on the infor-
mation from the IDOC which is saved in DB – this means that IDOC_DATA_MAPPER will not be triggered once
again, as this is triggered before IDOC is saved in the DB.
The below picture gives an overview where this 2 BAdI’s are called during replication of PS/WBS:
A – The Key Mapping for Project System and WBS are read from the MDG Tables
➔ Mapping between source PS ID and target ID PS should be provided at this point in time
➔ If the mapping of PS ID existed before, but this was changed via BAdI, the new value set in the BAdI
will be ignored, and the one existing already in the MDG mapping will be used further
➔ 1:1 and N:1 mappings are allowed for PS, but 1: N is not allowed
Checks executed for WBS mapping:
➔ Mapping between source WBS ID and target WBS ID should be provided at this point in time, for
the new replicated WBS elements
➔ If the mapped value exists already in the PRPS table, and error will be raised
➔ 1: N and N:1 mappings are not supported, so errors will be raised in these cases
1 – method CREATE_NEW_ID of BAdI BADI_FINS_CFIN_PS allows you to assign target IDs for PS and WBS. If
the BAdI BADI_FINS_CFIN_PS is implemented, then this method should always take care about the ID map-
pings, otherwise errors will be raised in case of missing mappings at point E.
2 – method ADJUST_DATA of BAdI BADI_FINS_CFIN_PS can be used to adjust attributes of PS and WBS. The
statuses and hierarchy cannot be adjusted using this BAdI. This method is called after MDG Mapping. In case
mappings are required for a specific attribute, it is recommended to use MDG Mapping or BAdI
BADI_FINS_CFIN_MAPPING_PROCESS for this purpose. In case none of these can be used, the ADJUST_DATA
method can be used instead.
For the replication of the CO commitments, the process is similar as for FI/CO documents and CO
documents: when the commitment reaches cFIN system, firstly the cFIN specific functions are executed and
then the CO commitment interface is called.
Here is a big picture of CFIN Specific functions and where the BAdI methods are called:
Central Finance specific functions (the ones listed here are the most important ones, in order to show
where exactly the BAdI methods are called):
B – CL_FINS_CFIN_CMT_POSTING ->DO_MDG_MAPPING – the MDG Value Mapping and MDG Key Mapping
are applied to the CO commitment.
1 – GET_PROCESS_CONTROL – in this method the developer has the chance to set some flags which will be
used to skip/to not skip the standard methods listed above. If the values are set, then the standard method is
skipped in the respective step, and only the BAdI method is executed. The MDG Mapping and Currency trans-
lation can be skipped using the parameters of this method.
2 – PREPARE_INPUT_DATA – this method can be used to adjust the data which is coming from the source
system (example – clear information which is not needed in cFIN).
3 – MAP_VALUES – this method can be used to adjust the Co Commitment after the MDG Mapping. The main
purpose of this method should be the mapping of different fields. However, it is recommended to check first if
mapping can be maintained in MDG or if BAdI BADI_FINS_CFIN_MAPPING_PROCESS can be used instead. Only
if none of these are possible, then the mapping logic can be implemented in this method.
4 – ADJUST_POSTING_DATA – this method can be used for final adjustments to the Co commitment (custom
adjustments).
This BAdI is called whenever MDG Mapping is called for an entity, so it will apply for most of the Central
Finance scenarios:
B – not all the fields are subject to MDG mapping. The ones which are relevant for MDG Mapping are listed in
the CFINIMG->Central Finance->Central Finance: Target System Settings->Mapping->Advanced Settings-
>Define Mapping Entities (Enhanced Configuration). The ones which are not relevant for MDG Mapping will keep
the source value.
C – the standard mapping action for the respective entity is read, according to the configuration
1 – the BAdI method DETERMINE_RULE is called. Here the mapping action read from point C can be overwrit-
ten. This new value will be used by the system for the following points. The method has import parameters
which can be used to identify:
If the mapping action is “Mapping Obligatory” (D), the system will try to find the required mapping in
MDG tables(E). If the mapping is not found, an error will be raised(F), otherwise the mapping will be applied for
the respective field value(G).
If the mapping action is “Map If Possible” (H), the system will try to find the required mapping in MDG
tables(I). If the mapping is not found, the value from the source will be kept(K), otherwise the mapping will be
applied for the respective field value(J).
If the mapping action is “Clear Data” (L), then the respective field will be cleared in cFIN system(M).
The remaining option “Keep Value” will keep the value from the source system(N).
This BAdI is called whenever MDG Mapping is called for an entity, so it will apply for most of the Central
Finance scenarios:
Using this BAdI you can skip the standard MDG Mapping for a certain entity or you can apply your own
custom mapping logic for a certain entity. It is recommended to use this BAdI for custom mapping logic, as it is
called whenever a mapping is requested for a mapping entity, and it will be valid for all Central Finance Scenar-
ios. The BAdI is called for both – Key Mapping (via standard method CL_FINS_CFIN_MDG_GEN_KEY_MAP->
IF_FINS_CFIN_MDG_GEN_KEY_MAP~MAP_DATA) and Value Mapping( via standard method
CL_FINS_CFIN_CODE_MAPPING-> MAP_CODES_IN_STRUCTURE).
The execution of the BAdI is dependent on the standard mapping action and/or on the mapping action
set in BAdI BADI_FINS_CFIN_MAPPING_RULE. For a better understanding, the below figure shows where the
BAdI BADI_FINS_CFIN_MAPPING_PROCESS is positioned in relation with the mapping action:
1 – in the method GET_PROCESS_CONTROL of the BAdI you can set a flag to skip the standard MDG Mapping
for a certain mapping entity
2 – the BAdI method MAP_VALUE is called. Here you can add your own custom logic to map the corresponding
entity. You will have access to the source value
3 - the BAdI method MAP_VALUE is called. Here you can add your own custom logic to map the corresponding
entity. As the MDG Mapping was executed, you will have access to the source value but also to the mapped
value based on MDG Mapping.
Besides the mappings which can be maintained in the CO-PA mapping tool (technical mapping be-
tween source characteristic fields and target characteristic fields), SAP provides a BAdI which allows additional
mappings for the profitability analysis:
➔ technical mapping between source characteristic fields and target characteristic fields
➔ changes of the CO-PA characteristic values
This BAdI is executed for those scenarios where profitability analysis is involved:
The below figure explains in more detail how the BAdI can influence the CO-PA mapping:
A – the COPA characteristics are transferred from source system via staging table CFIN_ACCPA_CHAR (FI/CO
documents) and CFIN_COPA (CO documents). The structure of these table contains the characteristic filed
names and the corresponding characteristic values (according to the operating concern from the source sys-
tem)
B – the technical mapping maintained in the CO-PA mapping tool is executed here. So, the fieldnames of the
source characteristics are changed with the fieldnames of the target characteristics
1 – the BAdI method MAP_DATA can be used to adjust the fieldname of target characteristics or to change the
characteristic values. However, it is recommended to change the characteristic values using the MDG Mapping
or BAdI BADI_FINS_CFIN_MAPPING_PROCESS. Only if none of these are possible, then the mapping logic can
be implemented in this method.
The BAdI BADI_FINS_CFIN_DFV can be used to enhance the standard reconciliation reports provided
by the Central Finance solution. It has multiple methods and some of them are called only by specific reports.
The below table provides an overview of the available methods:
GET_EVENT_IM- The standard implementation classes which contains the logic for the events on
PLCLNAME the output ALV (double click, press on buttons, etc.) can be replaced with a cus-
tom class which implements a specific interface. The interfaces can be found us-
ing the pattern IF_FINS_CFIN_DFV_ALV_EV*. Depending on the report a specific
interface should be implemented. The standard implementation classes can be
found with the pattern CL_FINS_CFIN_DFV_ALV_EV_*.
CHANGE_OUTPUT_DATA Before displaying the data, the content can be manipulated using this method
GET_SO_DOCTYPE Using this method, you can set a filter based on the Document type
GET_ALLOWED_VRGNG Using this method, you can set a filter based on the CO Business Transaction
(COBK-VRGNG)
GET_ALLOWED_GLVOR Using this method, you can set a filter based on the Business Transaction
(BKPF-GLVOR)
GET_SYSTEM_DETAIL The source system details - clearing transfer status or 3rd party system flag –
can be adjusted
CHANGE_ALV_ATTRIB- Before the system displays the output in an ALV, you can adjust the ALV attrib-
UTES utes by changing the parameter IO_ALV of type CL_SALV_TABLE
CUR- The amounts from the source system for Document Currency, Company Code
RENCY_AMOUNT_BAPI_T currency and Group Currency can be adjusted in this method (for example – if
O_SAP currency keys have been mapped)
MAPPING_GET_CUR- The currency key for Document currency, Company Code currency and Group
RENCY_KEY Currency can be mapped using this method
TRG_CO_ITEM_GET_BUK
RS_SENDER
MAPPING_GET_LEDGER Get Ledger from which the data will be selected from ACDOCA
TRG_GET_COFI_BAL- The COFI balance calculated from CFIN system can be adjusted
ANCE
CONSIDER_PERI- In case special periods from cFIN system must be considered, this method can
ODS_FOR_BALANCES be implemented
The below graphics explains which of the above methods are called for each reconciliation report:
D – the Function Module FIN_CFIN_DFV_ACC_DOC_HEADER from source system is called. This selects the FI
documents from BKPF table and applies the filters from selection screen and from point 3 and 5. Additional
BAdIs are available also in the source system – please check chapter 2.2.1 of this guide.
E – based on the selected document from the source system, the corresponding documents are selected from
the Central Finance system from BKPF table, using LOGSYSTEM_SENDER, BUKRS_SENDER, BELNR_SENDER
and GJAHR_SENDER. The filter from point 4 is also applied. If a source document is not found in the BKPF table
from cFIN system, a selection from AIF table is done.
3 – the BAdI method GET_SO_DOCTYPE can be used to set a filter on the document type for the selection from
source system
4 – the BAdI method GET_SO_DOCTYPE can be used to set a filter on the document type for the selection from
target system
5 – the BAdI method GET_ALLOWED_GLVOR can be used to set a filter on business transaction (BKPF-GLVOR)
during selection from source system
6 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method
7 – the standard implementation class which handles different events on the ALV (double click, push of buttons)
- CL_FINS_CFIN_DFV_ALV_EV_FI_NUM – can be replaced by a custom class which implements the interfaces
IF_FINS_CFIN_DFV_ALV_EVENT and IF_FINS_CFIN_DFV_ALV_EV_NUM
8 – after the data from source and target are selected and prepared for output, you can still do adjustments
using BAdI method CHANGE_OUTPUT_DATA.
9 - Before the system displays the output in an ALV, you can adjust the ALV attributes by changing the param-
eter IO_ALV of type CL_SALV_TABLE
D – the Function Module FIN_CFIN_DFV_ACC_DOC_ITEM from source system is called. This selects the FI doc-
uments from BKPF table and their corresponding items from BSEG table and applies the filters from selection
screen and from point 3 and 5. Additional BAdIs are available also in the source system – please check chapter
2.2.1 of this guide.
1 – the standard implementation class from point B can be replaced with a custom class which implements the
interface IF_FINS_CFIN_DFV. If this is done, it is the customer responsibility to implement the method
IF_FINS_CFIN_DFV -> COMPARE_ACC_DOC_ITEMS to select the data from source and target system and to
prepare it for display. All the points until point 9 will not be executed by standard in this case.
3 – the BAdI method GET_SO_DOCTYPE can be used to set a filter on the document type for the selection from
source system
4 – the BAdI method GET_SO_DOCTYPE can be used to set a filter on the document type for the selection from
target system
5 – the BAdI method GET_ALLOWED_GLVOR can be used to set a filter on business transaction (BKPF-GLVOR)
during selection from source system
6 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method
7 – for each line item selected from the source system, a currency mapping can be executed using the BAdI
method MAPPING_GET_CURRENCY_KEY for Document currency, Company Code Currency and Group Cur-
rency. Additionally, their respective amounts can be converted using CURRENCY_AMOUNT_BAPI_TO_SAP
8 – using BAdI method MAPPING_GET_LEDGER you can change dynamically from which ledger the data will
be selected from ACDOCA (cFIN system)
9 – the standard implementation class which handles different events on the ALV (double click, push of buttons)
- CL_FINS_CFIN_DFV_ALV_EV_FI_DOC – can be replaced by a custom class which implements the interface
IF_FINS_CFIN_DFV_ALV_EVENT
11 - Before the system displays the output in an ALV, you can adjust the ALV attributes by changing the param-
eter IO_ALV of type CL_SALV_TABLE
D – the Function Module FIN_CFIN_DFV_ACC_BALANCE from source system is called. This selects the bal-
ances from GLT0 or FAGLFLEXT. Additional BAdIs are available also in the source system – please check chap-
ter 2.2.1 of this guide.
E – if the special periods will not be considered (depending on point 5), then the balances selected from source
system from special periods (MONAT > 12), will be added to the corresponding balances from period 12.
F – using the balances selected from source system, execute the selection to get the corresponding documents
(BKPF) and items (ACDOCA). The corresponding documents from cFIN system are found using BKPF-
LOGSYSTEM_SENDER, BKPF-BUKRS_SENDER, BKPF-GJAHR_SENDER, ACDOCA-RACCT_SENDER and AC-
DOCA-BUKRS_SENDER. Additionally, the filters on ledger set at point 6 and on document type set at point 7
are also considered. In case special periods are included on point 5, then the selection is done based on the
period from the selection screen. Otherwise, it is done based on posting date.
G - the COFI balance needs to be included in the selection from cFIN system for an accurate result. These bal-
ances are build based on a different selection – from COBK and ACDOCA.
H – call the standard MDG Mapping to map the company codes from source system balances
I – call the standard MDG Mapping to map the cost element from source system balances
J - using the balances selected from source system, get the corresponding balances (from COBK and ACDOCA)
using COBK-LOGSYSTEM_SENDER, ACDOCA-RACCT_SENDER and ACDOCA-BUKRS_SENDER. Additionally,
the filters on ledger set at point 6 and on CO business transaction set at point 3 are also considered. In case
special periods are included on point 5, then the selection is done based on the period from the selection screen.
Otherwise, it is done based on posting date.
K – starting from source balances, the system should match the corresponding target COFI balance (if any)
and FI balance. For this match, the mapping of source GL account is required, as for COFI balance, the ACDOCA-
RACCT_SENDER might be missing.
L – Try to match the balance from source system with the COFI balance, using the mapped GL account from
point K. Add to the target balance also the matched FI balance.
1 – the standard implementation class from point B can be replaced with a custom class which implements the
interface IF_FINS_CFIN_DFV. If this is done, it is the customer responsibility to implement the method
IF_FINS_CFIN_DFV -> COMPARE_ACC_ACCOUNT_BALANCE to select the data from source and target system
and to prepare it for display. All the points until point 12 will not be executed by standard in this case.
3 – the BAdI method GET_ALLOWED_VRGNG can be used to set a filter on CO business transaction (BKPF-
VRGNG) during selection from target system of COFI balance (point J)
4 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method
5 – in case special periods have to be considered in cFIN system, then the BAdI method CONSIDER_PERI-
ODS_FOR_BALANCES should return value “True”
6 – using this BAdI method, MAPPING_GET_LEDGER, you can specify the ledger from which the balances will
be read from cFIN system, if this is different from the one specified on the selection screen.
7 – the BAdI method GET_SO_DOCTYPE can be used to set a filter on the document type for the selection from
target system, when the target balances are calculated
8 – for each line item selected from the source system, a currency mapping can be executed using the BAdI
method MAPPING_GET_CURRENCY_KEY for Transaction currency, Company Code Currency and Group Cur-
rency. Additionally, their respective amounts can be converted using CURRENCY_AMOUNT_BAPI_TO_SAP
9 – the selection of COFI balances from cFIN system is based on the source system balances and tables COBK
and ACDOCA. In order to identify correctly the balances from target, a mapping of company code is required.
If MDG mapping is not enough (point H), the BAdI method MAPPING_GET_COMP_CODE can be used to per-
form custom mapping for company code.
10 – similar as for company code entity (point 9), a custom mapping for cost element can be implemented using
method MAPPING_GET_COST_ELEMENT
11 – after the source balance was matched with a COFI balance, the target COFI balance can be adjusted using
method TRG_GET_COFI_BALANCE
13 – after the data from source and target are selected and prepared for output, you can still do adjustments
using BAdI method CHANGE_OUTPUT_DATA.
14 - Before the system displays the output in an ALV, you can adjust the ALV attributes by changing the param-
eter IO_ALV of type CL_SALV_TABLE
E – the Function Module FIN_CFIN_DFV_CO_DOC_HEADER from source system is called. This selects the CO
documents from COBK table and applies the filters from selection screen and from point 4. Additional BAdIs
are available also in the source system – please check chapter 2.2.1 of this guide.
F – based on the selected documents from the source system, the corresponding documents are selected from
the Central Finance system from COBK table, using LOGSYSTEM_SENDER, KOKRS_SENDER,
BELNR_SENDER. If a source document is not found in the COBK table from cFIN system, a selection from AIF
table is done.
1 – the standard implementation class from point B can be replaced with a custom class which implements the
interface IF_FINS_CFIN_DFV. If this is done, it is the customer responsibility to implement the method
IF_FINS_CFIN_DFV -> COMPARE_CO_DOC_HEADER_COUNT to select the data from source and target system
and to prepare it for display. All the points until point 6 will not be executed by standard in this case.
3 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method. This RFC destination will be used for calling point D.
4 – the BAdI method GET_ALLOWED_VRGNG can be used to set a filter on CO business transaction (COBK-
VRGNG) during selection from source system
5 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method. This RFC destination will be used for calling point E.
6 – the standard implementation class which handles different events on the ALV (double click, push of buttons)
- CL_FINS_CFIN_DFV_ALV_EV_CO_NUM– can be replaced by a custom class which implements the interfaces
IF_FINS_CFIN_DFV_ALV_EVENT and IF_FINS_CFIN_DFV_ALV_EV_NUM
7 – after the data from source and target are selected and prepared for output, you can still do adjustments
using BAdI method CHANGE_OUTPUT_DATA.
8 - Before the system displays the output in an ALV, you can adjust the ALV attributes by changing the param-
eter IO_ALV of type CL_SALV_TABLE
D – the Function Module FIN_CFIN_DFV_SUPPORTED_FUNC from source system is executed – this return
“true” in case CO reconciliation is supported
H – get the corresponding CO documents from target system from COBK table, based on the selected source
system CO documents, using filter COBK-LOGSYSTEM_SENDER, COBK-BELNR_SENDER, COBK-
KOKRS_SENDER. Get the corresponding CO line items from ACDOCA table, using the ACDOCA-CO_BELNR
and ACDOCA-KOKRS as filters. Additionally, select only the line items which matches the RACCT_SENDER and
BUKRS_SENDER from source system. If these fields are empty, the selection is done using the mapped values
of company code and cost element for the fields ACDOCA-RBUKRS and ACDOCA-RACCT. The filters from
points 4 and 9 are also considered in the selection of target CO line items from ACDOCA table.
1 – the standard implementation class from point B can be replaced with a custom class which implements the
interface IF_FINS_CFIN_DFV. If this is done, it is the customer responsibility to implement the method
IF_FINS_CFIN_DFV -> COMPARE_CO_DOC_ITEMS to select the data from source and target system and to
prepare it for display. All the points until point 10 will not be executed by standard in this case.
3 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method. This RFC destination will be used for calling point D.
4 – the BAdI method GET_ALLOWED_VRGNG can be used to set a filter on CO business transaction (COBK-
VRGNG) during selection from source system
5 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method. This RFC destination will be used for calling point E.
6 – for each line item selected from the source system, a currency mapping can be executed using the BAdI
method MAPPING_GET_CURRENCY_KEY for Transaction currency, Object Currency and Controlling Area Cur-
rency. Additionally, their respective amounts can be converted using CURRENCY_AMOUNT_BAPI_TO_SAP
8 – if MDG mapping is not enough (point F), the BAdI method MAPPING_GET_COST_ELEMENT can be used to
perform custom mapping for cost element.
9 – using BAdI method MAPPING_GET_LEDGER you can change dynamically from which ledger the data will
be selected from ACDOCA (cFIN system)
10 – the standard implementation class which handles different events on the ALV (double click, push of but-
tons) - CL_FINS_CFIN_DFV_ALV_EV_CO_DOC – can be replaced by a custom class which implements the in-
terface IF_FINS_CFIN_DFV_ALV_EVENT
11 – after the data from source and target are selected and prepared for output, you can still do adjustments
using BAdI method CHANGE_OUTPUT_DATA.
12 - Before the system displays the output in an ALV, you can adjust the ALV attributes by changing the param-
eter IO_ALV of type CL_SALV_TABLE
D - the Function Module FIN_CFIN_DFV_SUPPORTED_FUNC from source system is executed – this return
“true” in case CO reconciliation is supported
F – if the special periods will not be considered (depending on point 6), then the balances selected from source
system from special periods (MONAT > 12), will be added to the corresponding balances from period 12.
G – call the standard MDG Mapping to map the company codes from source system balances
H – call the standard MDG Mapping to map the cost element from source system balances
I - using the balances selected from source system, get the corresponding balances (from COBK and ACDOCA)
using COBK-LOGSYSTEM_SENDER, ACDOCA-RACCT_SENDER and ACDOCA-BUKRS_SENDER. Additionally,
the filters on ledger set at point 7 and on CO business transaction set at point 4 are also considered. In case
special periods are included on point 6, then the selection is done based on the period from the selection screen.
Otherwise, it is done based on posting date.
1 – the standard implementation class from point B can be replaced with a custom class which implements the
interface IF_FINS_CFIN_DFV. If this is done, it is the customer responsibility to implement the method
IF_FINS_CFIN_DFV -> COMPARE_CO_SUM to select the data from source and target system and to prepare it
for display. All the points until point 11 will not be executed by standard in this case.
3 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method
4 – the BAdI method GET_ALLOWED_VRGNG can be used to set a filter on CO business transaction (COBK-
VRGNG) during selection from source and target system
5 – the RFC destination determined by standard from table FINS_CFIN_RFCUSE with RFC usage = ‘04’ can be
overwritten in the BAdI method
6 – in case special periods have to be considered in cFIN system, then the BAdI method CONSIDER_PERI-
ODS_FOR_BALANCES should return value “True”
8 – for each line item selected from the source system, a currency mapping can be executed using the BAdI
method MAPPING_GET_CURRENCY_KEY. Additionally, the respective amounts can be converted using CUR-
RENCY_AMOUNT_BAPI_TO_SAP
9 – if MDG mapping is not enough (point G), the BAdI method MAPPING_GET_COMP_CODE can be used to
perform custom mapping for company code.
10 – if MDG mapping is not enough (point H), the BAdI method MAPPING_GET_COST_ELEMENT can be used
to perform custom mapping for cost element.
11 – the standard implementation class which handles different events on the ALV (double click, push of but-
tons) - CL_FINS_CFIN_DFV_ALV_EV_CO_BAL – can be replaced by a custom class which implements the in-
terfaces IF_FINS_CFIN_DFV_ALV_EVENT and IF_FINS_CFIN_DFV_ALV_EV_BAL
12 – after the data from source and target are selected and prepared for output, you can still do adjustments
using BAdI method CHANGE_OUTPUT_DATA.
13 - Before the system displays the output in an ALV, you can adjust the ALV attributes by changing the param-
eter IO_ALV of type CL_SALV_TABLE
This BAdI is used to enhance the standard functionality of report “Central Finance: Manage Mappings”
(transaction FINS_CFIN_MAP_MANAGE). In standard, this report is used to display, upload, download MDG
Mappings. The BAdI helps you to:
➔ enhance the display, upload, download functionalities for the standard MDG Mapping entities
➔ enhance the display, upload, download functionalities for the custom MDG Mapping entities
➔ enhance the display, upload, download functionalities for the custom Mapping entities which are
not integrated with MDG tables (a custom table for example)
➔ implement different checks during upload of standard MDG Mapping entities, custom MDG Map-
ping entities or custom mapping entities which are not integrated with MDG
The implementation of the BAdI is required for the custom mapping entities which are not integrated
with MDG, but it is optional for standard MDG Mappings or custom MDG Mappings. For the standard and cus-
tom MDG Mappings a default implementation logic is applied for the integration with report “Central Finance:
Manage Mappings”. Only in case the logic has to be enhanced, then this BAdI can be used.
3) GET_CSV_SEPARATOR – with this method you can influence dynamically the separator from CSV file. The
method is called during upload, download and generate template functionalities.
The below graphics explain in more details when the BAdI methods and the methods of the returned clas-
ses (which implements IF_FINS_CFIN_MAPPING and IF_FINS_CFIN_MAP_CHECK) are called when the func-
tionalities of the report are executed:
A – the standard implementation class name is read – this class implements the interface IF_FINS_CFIN_MAP-
PING and takes care about the functionalities from the FINS_CFIN_MAP_MANAGE transaction.
1 – the standard class returned by point A can be replaced via this BAdI method with a custom class
2 – the GET_LIST_FROM_DB method is called, either from class of point A or from point 1. The method should
return the mappings from the DB.
A – the standard implementation class name is read – this class implements the interface IF_FINS_CFIN_MAP-
PING and takes care about the functionalities from the FINS_CFIN_MAP_MANAGE transaction.
B – Generate the template using the columns from point 2 and the separator from point 3
1 – the standard class returned by point A can be replaced via this BAdI method with a custom class
2 – The GENERATE_TEMPLATE method is called, either from class of point A or from point 1. It should return
the list of columns used in the template.
3 – the CSV separator from the template can be changed dynamically using this method. If this is not changed,
the separator maintain on the selection screen will be used.
A – the standard implementation class name is read – this class implements the interface IF_FINS_CFIN_MAP-
PING and takes care about the functionalities from the FINS_CFIN_MAP_MANAGE transaction.
B – Get standard implementation class names for each type of check. The classes implements the methods of
interface IF_FINS_CFIN_MAP_CHECK. The below standard classes are provided by SAP, and these are called
for specific entities and specific type of checks:
C – based on the returned value from point 5, the respective check will be executed or not
D - based on the returned value from point 5, the respective check will be executed or not
1 – the standard class returned by point A can be replaced via this BAdI method with a custom class
2 – the ADD_BY_EXTERNAL_LIST method is called, either from class of point A or from point 1. The method
should perform checks and add the entries to the DB
3 – the CSV separator from the selection screen can be changed dynamically using this method. If this is not
changed, the separator maintain on the selection screen will be used.
4 – for each type of check, the standard classes from point B can be replaced with custom classes which imple-
ments the interface IF_FINS_CFIN_MAP_CHECK
➔ Download Mappings
A – the standard implementation class name is read – this class implements the interface IF_FINS_CFIN_MAP-
PING and takes care about the functionalities from the FINS_CFIN_MAP_MANAGE transaction.
B – Generate the CSV file using the data from point 2 and the separator from point 3
1 – the standard class returned by point A can be replaced via this BAdI method with a custom class
3 – the CSV separator from the template can be changed dynamically using this method. If this is not changed,
the separator maintain on the selection screen will be used.
➔ Delete Mappings
B – Get standard implementation class names for each type of check. The classes implements the methods of
interface IF_FINS_CFIN_MAP_CHECK. The below standard classes are provided by SAP, and these are called
for specific entities and specific type of checks:
D - based on the returned value from point 5, the respective check will be executed or not
1 – the standard class returned by point A can be replaced via this BAdI method with a custom class
2 – the DELETE_BY_EXTERNAL_LIST method is called, either from class of point A or from point 1. The method
should perform checks and delete the entries from the DB
3 – the CSV separator from the selection screen can be changed dynamically using this method. If this is not
changed, the separator maintain on the selection screen will be used.
4 – for each type of check, the standard classes from point B can be replaced with custom classes which imple-
ments the interface IF_FINS_CFIN_MAP_CHECK
For each object replicated to Central Finance system which contains currency and currency
amounts(ex – FI/CO document, CO Document, Commitments, etc.), adjustments of currency decimals can be
performed by maintaining the customizing activity CFINIMG-> Central Finance: Target System Settings-> Set
Up Systems-> Define Decimal Places for Currencies in Source Systems. If this configuration is not enough for
your requirement, adjustments can be done using the BAdI BADI_FINS_CFIN_CURR_ADJ. The BAdI is called by
standard method CL_FINS_CFIN_CURR_ADJUST->CALCULATE_VALUES.
The below figure gives an overview where the BAdI is called (green bullet):
A more detailed graphic with the connection of standard code from cFIN functions and the BAdI meth-
ods is described below:
Central Finance specific functions (the ones listed here are the most important ones, in order to show
where exactly the BAdI methods are called):
1 – GET_ CONTROL – in this method the developer has the chance to set some flags which will be used to skip
the standard calculation for currency decimals adjustments. Parameter EV_OVERWRITE_ADJUSTMENT can
be set to skip standard calculation for currency decimals, while EV_OVERWRITE_CORRECTION can be set to
skip standard logic to adjust the balance.
2 – ADJUST_VALUES – currency amounts values can be adjusted via this method. This is called only in case
the parameter EV_OVERWRITE_ADJUSTMENT was set in GET_CONTROL method. The export parameter
EV_BALANCE_OK should be set if the balance is 0 after adjustment.
www.sap.com/contactsap
© 2020 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an affiliate company. The
information contained herein may be changed without prior notice.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifica-
tions may vary.
These materials are provided by SAP SE or an affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affili-
ate companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services
are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting
an additional warranty.
SAP and other SAP products and services mentioned herein as well as their respective logs are trademarks or registered trademarks of SAP SE (or an affiliate com-
pany) in Germany and other countries. All other products and services names mentioned are the trademarks or their respective companies.
Please see https://www.sap.com/about/legal/trademark.html for additional trademark information and notices.