Overview of Central Finance Architecture
Why we need central finance:
Earlier customers who have multiple system landscape load financial data from their system into various data warehouses. This is the only way to report on the figures of the entire company. To load data into the data warehouse, we need long-running batch jobs and regularly scheduled to extract data and transform it. This has multiple challenges like:
- Not happening in real-time but rather once a day or week.
- The data that a customer is looking at the data warehouse is never up to date.
- Require high reconciliation efforts.
- Data warehouse accepts data without checking whether it is correct or not
Many companies have a legacy of both SAP, and non-SAP, ERP systems. These systems have different release levels, different customizing specifications, and some even have different charts of accounts. To see all our consolidated reports in one system and it should be in real time. We must have central finance in place to get consolidated reports.
What is central finance:
SAP S/4HANA for central finance is an SAP S/4HANA system, receiving financial accounting transaction through real time replication from SAP or non-SAP ERP source system. Central finance replicates only financial transaction which covers financial accounting transaction, Controlling posting and cost objects. central finance establishes a central reporting platform for FI/CO with the option of creating a common reporting structure.
Business benefits of central finance:
The benefits offered by central finance are over with various options. They are namely as:
- Real time replication of all banks related open items into central fiancé provides global bank balances and cash positions as on date.
- Central finance offers the ability to drill down information to the source systems and provides full traceability of postings.
- The universal journal entry of central finance is a single dataset, across multiple applications. As a result, the time and effort required for reconciliation is reduced to zero. Data is available for instant reporting.
- Central finance as an integration point, instead of performing a full logistic and financial migration, simplifies the integration of new entities, while offering agility and flexibility.
Central Finance 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 SAP S/4HANA where the FI and CO documents are re-posted.
- Central Finance is also able to replicate cost objects as pre-requisite for the FI and CO postings.
CFIN ARCHITECTURE
Source System:
Any ERP system can be defined as a source system for central finance.
Integration of SAP S/4HANA and ECC 6.0 as source systems: it is supported out of the box. However, applying some SAP notes or upgrading to the latest service pack (SP)
Integrate out-of-maintenance SAP releases (for example, 4.6, 4.7 and 5.0): Additional effort required in the form of project work as source systems with central finance system. This approach is commonly referred to as “downporting”.
Other Sap ERP: Technically, integration of other SAP ERP (SAP ByDesign and SAP Business One) is currently only possible through the interface staging table in SLT. The same applies also for any non-SAP ERP system.
On the SOURCE system, there are some other components, i.e., DB Triggers, Logging Table, read engine, Mapping and Transformation engine, write engine and Staging table, which are explained now.
DB Triggers:
Monitors for any events like insert, delete, modify, and update that takes place in the source system application table. DB triggers will be created on the source system.
Logging Table:
If DB triggers, then logging tables will store triggered data, which is modified data in Application table. Logging tables will be created on Source System
Read Engine:
Read engine will be responsible for reading the data from logging table and passing to SAP SLT Replication server.
Staging Table:
The staging area is used to connect various legacy systems that have different data models than SAP central finance system. SAP provides preconfigured content for loading data from simplified staging areas, which facilitates loading and replicating of data from legacy systems (non-SAP) to a central finance system. Extracting and loading the data to the staging area depends on the data structure of the legacy system.
SAP Landscape Transformation:
- SLT loads data from relevant source tables to SAP S/4HANA.
- 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 replications 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.
- There are three technical options to deploy SLT for central finance integration. They are as: 1. SLT deployed on a separate instance, 2. SLT is deployed in the source system and 3. SLT is deployed in the central finance system
- Though we have three deployment options, SAP recommends to go with SLT deployment of separated instance.
On the SAP landscape transformation, which can be separate system, there are some other components, i.e., technical mapping and transformation engine and write engine, which are explained now.
Mapping and Transformation Engine:
This will be responsible for structured transformation of data as per target SAP S/4HANA DB format.
Write engine:
Write Engine will be responsible for writing the data into SAP S/4HANA DB from SAP SLT Replication server.
Central Finance System:
On the SAP S/4HANA system, which is the Central Finance system, there are some other components, i.e., Central Finance Interface, Business Mapping, AIF, Universal Journal, which are explained now.
Central finance Interface:
When the data is passed to the central finance interface, it passes through different steps, prepare, map, adjust, and post. The steps are similar in all the three interfaces. 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.
Business Mapping:
SAP Master Data Governance (MDG) provides domain-specific master data governance to centrally create, change, and distribute master data for your complete enterprise system landscape.
It can be deployed in the central finance system or as a master hub.
It provides consolidation standard processes for business partner (customer or vendor), material, and custom object in MDG 9.0.
Central finance uses SAP MDG foundation function to maintain and perform business mapping.
Application Interface Framework Monitor:
- Single place for error handling of all central finance replication scenario.
- It provides (interface name, document number, error message number, replication date, etc.
- Central finance uses AIF to define 3 main interfaces for cost object replication, FI/CO posting replication and CO internal posting replication
- Error message can be rephrased if a message text is not meaningful.
- Messages can be assigned to SAP-transaction codes (for example, IMG activities), which allows users to navigate to the place where the error can be resolved.
- Emergency correction mode available, which requires special authorization, means that posting data fields can be corrected by entering the correct value.
Internal accounting Interface: If no errors, it will post in internal accounting interface and moves posting to the ACDOCA table.
Central Finance Data Replication:
Central finance splits the process of data replication into 2 parts:
The first part is the initial load. This step loads/replicates existing data only in the source system.
The second part is the real-time replication. This step replicates all newly created data, and also changes existing data in the source system.
Initial Load:
The initial load must 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.
Posting excluded in Initial load:
The below posting cannot be transferred as part of the initial load and ongoing replication.
- Postings to CO-FI reconciliation ledger (GL Reconciliation Postings).
- Clearings are not transferred as part of the initial load, but you can activate the transfer of clearings via ongoing replication. For more information see Handling of Open Items
- Clearing resets are not transferred as part of the initial load but you can activate the transfer of clearing resets via ongoing replication. For more information see Handling of Open Items
- Noted items (apart from down payment requests and payment requests)
- Parked documents
- Balance carryforward items
Real-Time Replication in Central Finance:
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.
Conclusion:
Central Finance represents a new approach to finance, it is based on a new set of technologies in a central ERP system. It enables consolidated transaction execution, business planning, and group consolidation. In this blog post I explained about Central Finance architecture and its two parts of data replication. I hope that it would provide some useful information on central finance. In my next blog post, I will try to explain about configuration in source system and central finance, business mapping and central payments in details. I would appreciate your feedback and comments on the document, which will help me to enhance further.
Reference: S4F61-Implementing Central Finance in SAP S/4HANA.
Okumaya devam et...