The following information is based on a presentation for the Organisation, Mastering SAP (Australia) and includes Central Finance ( CFIN ) functionality up until Version 2022. The Diagrams give a visual representation of CFIN functionality.
The blog focusses on SAP Systems as the Source Systems. Magnitude software is required if the Source System is non-SAP. Magnitude handles the Source processes for CFIN due to the Source being proprietary software and the SAP software cannot directly access non-SAP Systems data/tables. Apart from the Source the process is substantially the same (i.e. SLT and S/4HANA).
For more information on Magnitude, please see SAP note 3281943
Expert Tip: Please read SAP note 2863836 - Allowed Currency Configuration Settings in Central Finance very carefully when setting up currencies in FI and CO. Leaving Group Currency in FI second currency blank (old transaction OB22 - new transaction FINSC_LEDGER) will cause potential issue with Asset Accounting and Material Ledger when the Target System is used as the 'System of Record'. Assuming you want to use Group Reporting currency (30). See exception 1 for setting that may cause future issue.
The solution is corrected in SAP v2023 Private Cloud where different currency settings between Source and Target can be configured for the FI currencies.
The Path to S/4HANA - Implementation Approaches – Central Finance (CFIN)
S/4HANA Finance innovations are realised via technical migration of existing SAP ERP systems or through a non-disruptive ‘side-car’ approach using Central Finance. 'Side-car' is often misinterpreted and is the full S/4HANA System with the CFIN functionality switched on used as a 'System of Report' (i.e. to the side of the source ERP systems).
Depending on requirements, the S/4HANA system is used as a 'System of Report' for a defined period (Phase I) and then converted to a 'System of Record' using additional Central Finance functionality such as Central (CPAY) Payments (AP/AR/Banking) when the Business is ready (Phase II). This phasing is often referred to as Finance First.
The approach helps reduce risk and complexity although there is no reason that the S/4HANA System cannot be used as a 'System of Record' immediately. This is especially relevant if some parts/functionality of the Business remain in the Source System (e.g. Company Code(s), Real Estate).
If only Finance is involved, Phase I is the larger Project as it requires setting up S/4HANA in the Cloud and configuring S/4HANA Finance based on the agreed design. Phase II is the additional functionality required to convert to a 'System of Record' for Finance. Phase II is a larger Project if Logistics, SCM, Plant Maintenance etc is implemented.
Diagram 1: S/4HANA Implementation Approaches
The top section of Diagram 1 represents a 'Brown field' upgrade approach. The Source ERP SAP System(s) is upgraded and moved to the Cloud during the Go-Live Cutover period (e.g. weekend).
The bottom section of Diagram 1 represents the 'Central Finance' upgrade approach and shows multiple Source ERP Systems (SAP and Non-SAP) are replicating Journal Entries (Entry View) to the Target S/4HANA CFIN enabled System.
For information on the Entry View and CFIN see SAP Note 2184567 - Central Finance: Frequently Asked Questions (FAQ).
The 'Cloud' picture in the bottom section of Diagram 1 represents the S/4HANA instance (i.e. the right hand box) is in the Cloud and not On-Premise.
There are 2 additional approaches to transition to S/4HANA not shown in Diagram 1:
- 'Green field' - setup of S/4HANA System in the Cloud without taking over existing System structures. Start from new. In essence the 'Central Finance' approach is a variant of the 'Green field' approach.
- 'Blue Field' - select historical data is converted from the Source ERP System to the new S/4HANA System in the Cloud.
Central Finance Overview – System Architecture with Project Skill Mix example
Yellow: Typical roles for a S/4HANA implementation with full Finance functionality including Master Data Governance (MDG). MDG is optional functionality for CFIN as MDG lite functionality is available (at time of writing) without MDG licences.
Orange: Additional skill sets or roles required for a Central Finance implementation
Red: Basic Roles required if some Logistics reporting is included (e.g. Logistics ALV) although a FICO Consultant could handle. SAP UXC/Fiori roles normally required but not specifically for CFIN. CFIN has a few Fiori Apps for AIF otherwise all of the CFIN functionality is incorporated into the relevant standard Fiori Apps (e.g. Document Display Fiori allows drill back to Source Document).
Non-FICO functionality implementation (Logistics/Supply Chain/Production Planning/Plant Maintenance, etc) is not represented in Diagram 2. Add as required.
Diagram 2: Central Finance System Architecture with Project Skill Mix - Finance Focused
SLT: System Landscape Transformation is represented as a separate instance in Diagram 2. SAP recommends this approach.
As another option SLT can be implemented (switched on) as part of the S/4HANA instance (i.e. not a separate instance).
SLT has functionality monitoring/polling the Source Systems Central Finance tables that are populated when the relevant CFIN object (e.g. Journal, Cost Object, Commitments, Activity Types, etc) is created/changed and triggers the information to be transferred to the S/4HANA CFIN functionality where mapping/transformation and creation occurs. Remote Function Call (RFC) functionality is used for the transfer based on Finance style table structures.
SLT is a SAP product and not specifically for CFIN. For more information see link SAP SLT
Central Finance Accounting Interface: Includes all of the structures (e.g. Header, Lines items, Tax, Splitting, Clearing information etc) and programs including BAdI's required for receiving and mapping/converting the journal information and master data from the Source Systems.
Business Mapping: MDG tables (some specific to CFIN) that are populated either in the MDG instance or in the S/4HANA instance using MDG-F/MDG Lite with the Key Mapping (Master Data) for the journals (e.g. GL, Cost Centre, Profit Centre, WBSE, etc).
Application Interface Framework: Is a standard module in SAP used to develop, run and monitor all the application interfaces your business needs. For CFIN, AIF shows the journals and master data that are 'In Error', 'In Process', 'Processed', 'Cancelled' based on the result of the FICO posting interface in S/4HANA Finance. 'In Error' messages are able to be reprocessed and adjusted if necessary from AIF once the error is rectified (e.g. missing mapping).
FICO Internal (RWIN) Interface: The standard interface that the FI and CO modules of SAP use to post journals from the SAP GUI, Fiori, standard interfaces (e.g. SD, MM), programs including BAPI's (e.g. Uploads, interfaces etc). The CFIN interface passes to this interface once the mapping and conversion has occurred.
BRF+: Business Rules Framework. SAP functionality that provides a comprehensive application programming interface (API) and user interface (UI) for defining and processing business rules. It allows you to model rules in an intuitive way and to reuse these rules in different applications. A use case for BRF is the replacement of Z tables used in SAP enhancements.
Can be used in CFIN for non-standard mapping via the CFIN BAdI's rather than Z tables. Would be within the Business Mapping box in Diagram 2.
DSM: Offers solutions to overcome some of the limitations on SAP’s ABAP based rule engine, Business Rule Framework plus (BRFplus). It is designed as a separate add-on to an SAP NetWeaver system, extending the capabilities of BRFplus, The purpose of DSM is to let you model the rules and generate the source code for the rule objects in an up-to-date design time system, and then to deploy the generated code to your productive systems.
Central Finance Overview - Functional with Technical Aspects
In the following Diagrams, for simplicity one box - 'SAP Menu: Application Interface Framework (AIF error handling)' represents AIF and the Central Finance Accounting Interface (see Diagram 2 for details).
Replication Interface: Cost Object and Other Relevant Master Data
Before journals are replicated or posted as part of the Initial Load all of the relevant open Cost Objects and certain master data must be created in S/4HANA via the CFIN interface and map to the Source. For Cost Objects, CFIN configuration in S/4HANA tells the system what type of Cost Object to create and map to.
Once replication is running the system will automatically create or update the S/4HANA Cost Object and relevant master data including future changes based on creation/change in the Source System(s). An example of change being replicated for a Cost Object is its status (Released, Complete, Locked, Closed) .
Note that if you use the MDG Lite functionality, Cost and Profit Centres are manually setup in S/4HANA as part of the S/4HANA implementation as these objects are normally long term reporting objects with a specific design in the Target System and are not handled as part of automated creation via CFIN.
A task as part of the CFIN Project is to upload the relevant initial CFIN mapping for Cost Centre and Profit Centre (i.e. Key Mapping). The same logic applies for GL and Business Partners.
MDG Lite (purple oval) is part of the S/4HANA Instance in Diagram 3.
Alternatively, MDG-F functionality automatically handles the creation and mapping of Cost Centre. Profit Centre, GL, Business Partner. In Diagram 3 the MDG functionality is shown as the Purple Circle (top right) where MDG is a separate instance. MDG may be implemented as part of the S/4HANA instance if required.
Diagram 3 shows a visual of the 'types' and 'how' Cost Objects and other master data is replicated as part of CFIN. This Master Data is created in S/4HANA and mapping tables updated automatically with the required mapping.
The replication process occurs where SLT polls the Source System(s) for creation/change of the Cost Object or master data and triggers sending via SLT using RFC to the S/4HANA CFIN Interface. There is one exception where replication is not via SLT and that is for Central Projects/WBSE where IDOCs are used.
All of the fields in the Source Cost Objects/Master Data are either configuration or master data related and these fields are mapped as part of the CFIN Project (e.g. configuration and initial master data) or ongoing (new master data) once live with CFIN.
AIF runs and monitors the interface for Success, In Process, and Errors. AIF allows reprocessing of errors after correction of the underlying issue.
Diagram 3: Cost Object Master Data Replication
Cost Objects: The listed Cost Objects are covered by CFIN functionality. There can be 1:1 or n:1 cardinality.
Example: Source Production Orders are mapped to a Product Cost Collector in S/4HANA (i.e. n:1 cardinality). Creating and mapping a Production Order in Source to a Production Order in Target is not supported. The Product Cost Collector must be used in the Target System.
The standard configuration allows the mapping as per Table 1. Certain non-standard mapping via configuration can be implemented such as mapping to an Internal Order in the Target CFIN System.
See SAP note for standard and non-standard Cost Object mapping options.
2180924 - Supported scenarios in cost object mapping framework
| Scenario | Cost Object in Source | Cost Object in Central System | Cardinality |
SAP001 | Production Order | Product Cost Collector | N : 1 |
SAP002 | Product Cost Collector | Product Cost Collector | 1 : 1 |
SAP003 | Internal Order | Internal Order | 1 : 1 |
SAP004 | Service Order | Service Order | N : 1 |
SAP005 | QM Order | QM Order | N : 1 |
Table 1: Standard Cost Object Mapping rules
Material Cost Estimates (MCE): MCE is required for the Production process to cost out your Finished and Semi-Finished Materials.
The additional master data listed against '***' in Diagram 3 is required in the S/4HANA System as per standard to enable the use of the replicated MCE. This master data will be created as per the normal SAP S/4HANA implementation or ongoing by using Master Data Governance for the Materials (MDG-M).
CO Activity Types/Rates: Output of the Cost Centres.
Up until S/4HANA version 2020 activity rates could only be replicated from Source Systems to S/4HANA. From v2020 activity rates are able to be entered centrally in S/4HANA and CFIN functionality will replicate back to the Source System(s) if required (i.e. entered once centrally and replicated back to Source System(s)).
Project/WBSE: The work breakdown structure (WBS) is a model of the project that organises project tasks into a hierarchy. The WBS links to the Project level (top).
Only implement if Central Projects is the required functionality. Replication is not via SLT. IDOC functionality is used with AIF to monitor.
Central Projects is normally only used for the 'System of Report' scenario in CFIN. The reason is that if the S/4HANA System was to convert to 'System of Record' in future then the replicated Project/WBSE master data cannot be adjusted or changed in the S/4HANA CFIN System (Project/WBSE tables contain a Logical System field = Source). This is due to the Central Project functionality and change of this behaviour is not supported by SAP.
If S/4HANA is to be used as a 'System of Record' in the future, the advice is to create an interface for Projects/WBSE as part of the CFIN Project with all the controls required.
The controls (authorisations) are so that Users cannot change Project/WBSE in S/4HANA when S/4HANA is a 'System of Report'. Instead the changes must be replicated from the Source System(s) so that the Source and Target Systems are aligned.
When the Target CFIN System is to be used as a System of Record, the controls are removed and the Project/WBSE interface (IDOCs) discontinued. Creation and change of the Project/WBSE now occurs in the Target CFIN System.
Key Mapping: The mapping (Source to Target) for all of the Master Data required for CFIN (Cost and Profit Centre, GL, Business Partners, Cost Elements, Projects/WBSE). Normally updated by responsible Users with the required SAP authorisations. See MDG-F or MDG Lite in Diagram 3 (Purple).
Value Mapping: The mapping of the Enterprise Structure (e.g. Company Codes, Controlling Area, Plants, etc) and configuration (e.g. Document Types, Chart of Accounts, Transaction Types, posting keys, tax codes, etc). Value mapping is completed as part of the CFIN Project and transported through the SAP Landscape to Production.
Key and Value mapping is required for the Cost Object, Project/WBSE, and Journal interface to map the relevant fields to the new S/4HANA Design.
The Key and Value mapping have mapping actions defined in the CFIN configuration as follows:
- Map if possible
The system tries to map any filled field. If no mapping data exists, no error is raised but the original data from the sending system is retained. Used if the Source and Target field entries are the same (i.e. configuration or master data numbering). In this case if there is no mapping the transaction will error in AIF due to failure in the creation/change interface.
- Keep data
Field values of this kind are not mapped at all. The data from the sending system is retained. A variation of bullet 1 where mapping is not required at all and the Source and Target field entries are the same.
- Mapping obligatory
The field values for all filled fields must be mapped. If no mapping data exists an error is raised which is to be corrected using AIF.
- Clear data
Fields of the kind are always cleared. Used when Source System functionality is not used in the Target S/4HANA System (e.g. Business Areas).
The concept/functionality of Key and Value Mapping with mapping actions for Cost Objects and Master Data described is the same for Journals.
Initial Load of FI and CO
Initial Load: FI Trial Balance, FI Documents & CO Documents
Central Finance has 2 setup phases after the Source and Target (S/4HANA) Systems have been prepared and linked via SLT. This Section discusses the Initial Load first phase.
- Initial Load (Phase 1)
- Load the starting Finance (statutory) trial balance and monthly movements up until the individual detail journal phase (bullet 3) with the offset entry against 'take-on' GL account(s)
- Load the Open Items (Customer/Vendor/GL) that are part of the initial trial balance (i.e. uncleared open items) up until the individual detail journal phase (bullet 3) with the offset entry against 'take-on' GL account(s). Note there is configuration that posts the Open Item Balances to substitution GL accounts which is part of the COA's that reflects the AP/AR/GL Open Item balance movements for the monthly movement period above. The final monthly movement period before the next bullet (detailed initial load journals) has the actual Open Items for AP/AR/GL posted to the last day of that month as a normal Open Item. This allows any clearing/reversal during the detailed initial load journal phase to operate as normal as there are AP/AR/GL Open Items to clear against.
- Load the individual journals including Open Items after the starting trial balance periods (i.e. after Bullet 1 periods) up until 'Replication' commences (no 'take-on' GL account(s) needed as the full journal is extracted)
- Load the Controlling Internal (within the CO Module) journals (e.g. Settlements) via SLT using a date filter for the starting date. Usually the same start date as Finance Statutory Trial Balance (Bullet 1)
- Replication (Phase 2) - starts after the Initial Load is complete (not shown in Diagram 4)
Diagram 4: Initial Load of FI and CO
The Initial Load programs extract the Phase 1 information from the Source Systems by Company Code and RFCs the information to the Target S/4HANA Finance System CFIN Tables.
At the completion of Initial Load extraction the CFIN functionality in Source knows the date/time stamp of the Initial Load extraction and starts recording any Source System journals for FI into the CFIN* tables (CFIN* shown in Diagram 4 but no arrow from FI as Diagram is only for Initial Load - See Diagram 6 for replication) in the Source System ready for SLT to replicate to the Target S/4HANA CFIN System once replication in SLT is switched on. This ensures continuity and reconciliation between the Source and Target Systems.
Once extraction is complete the Mass Data Framework (MDF) tool is used to:
- Simulate Mapping of the extracted journals against the CFIN Key and Value Mapping - errors in mapping are to be fixed before proceeding
- Simulate Posting of the extracted journals - errors in postings to be fixed
- Post Initial Load Journals (*) via the standard FICO interface once mapping and posting errors have been corrected
* The extracted data is based on the 'Entry View' of the journal from the Source System.
The following detail refers to the Configuration that controls the functionality described thus far in this Section. Specifically Diagram 5.
Carry Forward and Balances
In the configuration the starting Fiscal Year for Balances is entered. The Initial Load extraction programs extract the Carry Forward and Balance Movements for each Period up until the Period where the detailed individual journals are extracted.
The Carry Forward Trial Balance is posted in the last Period (last day) of the prior Fiscal Year to what has been entered in the configuration.
The monthly movements are posted in each month up until the detailed individual journals are to be posted as per the Month/Fiscal Year configuration (see - Configuration Section).
There is configuration that posts the Open Item Balances to substitution GL accounts which is part of the COA that reflects the AP/AR/GL Open Item balance movements for the monthly movement period above. If this is not done the Trial Balance would not balance.
Open Customer/Vendor/GL Open Items part of Carry Forward and Balances
As per the Carry Forward and Balances, all of the Open Item lines for Customers/Vendors/GL are extracted for each Period up until the Period where the detailed individual journals are extracted.
Each of these Open Item lines are posted on the 'last day' of last 'Balances' period with the balancing posting against the 'Take-on' GL accounts as defined in the configuration. All of the Open Items that are still open on the last day of the Balances period (above section - Open Items could be open for many years) are posted as normal AP/AR/GL Open Items with the offset posting to the take-on 'Substitution' GL account defined in the configuration. This balances the Trial Balance for the final balance period and allows any clearing/reversal during the detailed initial load journal phase to operate as normal as there are AP/AR/GL Open Items to clear against.
If New GL Splitting is not active in Source and Active in Target these Open Items will not split as per the Source System because the splitting characteristics (e.g. Profit Centre) on the offset GL accounts (i.e. P&L) are not extracted and used for the postings on the 'Take-on' GL account.
A BAdI can be used to achieve the outcome but is not supported by SAP.
Please note the supported scenarios and restrictions for New GL Splitting functionality in the following SAP notes:
2842551 - Central Finance: Document Splitting is active in Central Finance but not active in the sou...
2184567 - Central Finance: Frequently Asked Questions (FAQ)
In summary the splitting configuration in Target must be the same as Source. There are specific split scenarios that may cause issue if this is not the case.
FI Journals (Historic)
Once the Carry Forward and Balances including the relevant Open Items are posted, the detailed journals post from the Period and Fiscal Year in the Initial Load configuration. As these are the fully balanced journals no 'Take-on' GL is involved.
CO Journals (Initial Load)
The Controlling Internal (within the CO Module) journals (e.g. Settlements) are replicated via SLT using a date filter for the starting date. Usually the same start date as Finance Statutory Trial Balance (Bullet 1).
SLT has 2 phases for the CO (internal) journals:
- Initial Load
- Replication
When the SLT CO interface is started the Initial Load phase commences based on the filter date entered in the SLT configuration. Initially a calculation job is started in the Source System to determine the appropriate size and packages for the CO documents to be processed through SLT.
Depending on the required Initial Load history length, the calculation can take a long time. If the data set is large due to the time period (e.g. 1 year) and the Business size means there are high volumes of settlements then the calculation can take over 10 hours. Once the calculation is optimised by the Technical Team (i.e. lessons learned during testing) that timing drops to 4 - 6 hours.
The Project will get an exact indication based on the cutovers and Initial Loads performed as the functionality is implemented through the SAP landscape (i.e. DEV/QAS/Pre-PROD). The recommendation is to test the Initial Load on a copy of PROD as soon as possible in the CFIN Project.
Once the calculation is completed the CO Initial Load documents are replicated via SLT to the Target S/4HANA System.
When the CO Initial Load replication is complete, SLT automatically switches to replication mode for any new CO journals entered by the User or System in the Source System(s).
Basic Configuration Overview for Initial Load and Replication
Configuration is entered in the Source System(s) for each Company Code to set rules for the dates (time period) for the following accounting data:
- Initial Load
- This step is the same task as Consultants would do for a Greenfield SAP implementation except it is automated with a few steps in the IMG
- Initial Balance Load (Opening Trial Balance) as part of the Initial Load.
- Open Items that are part of the Opening Trial Balance and the periods until the individual detail journal phase. In other words these are Open Items that are included in the Initial Load period where only balances are loaded before the next step. The Open Items are posted on the last day of the last period defined in the previous bullet (Initial Balance Load)
- Journal transactions (complete journal documents including Open Items) as part of the Initial Load as defined in the Initial Load configuration.
- This step is the same task as Consultants would do for a Greenfield SAP implementation except it is automated with a few steps in the IMG
- Replication
- Journal transactions (complete journal documents including Open Items) as part of ongoing replication
This Section discusses Initial Load (Bullet 1) but the concepts of Replication for FI (white box on right) and CO internal documents (dark grey and white box on right) are included for completeness.
Note that the relevant date to start CO Internal Journal (within CO Module such as Settlements) initial load/replication is not part of this (FI) configuration. The CO internal journals are handled via SLT (expert function) configuration using a date filter (i.e. date >= first day of fiscal year) for COBK replication. See next Section for details. Diagram 4 includes the CO documents for visual representation against the relevant timings for Initial Load.
Diagram 5: Initial Load Configuration - July/June Fiscal Year
The following information in this Section is based on Company Code IT01 in Diagram 5 which has a July/June Fiscal Year.
Initial Balance Load including Historic Open Items
The 'Start - Balances' column indicates the fiscal year to start extracting balances and historic open items from the Source System - Company Code IT01. The entry is compared to the 'Start-Documents' and 'Period - Documents' column entries to determine the periods to post balances and historic open items in S/4HANA Finance.
In this example, the starting period to be extracted from Source are the Carry-Forward balances (Period 0, 2020) into Period 12 (June), fiscal year 2019 in S/4HANA Finance which becomes the Opening Balance for fiscal year 2020 (i.e. Period 0, 2020). The carry forward balances are posted in Period 12, 2019 (i.e. posting date 30 June, 2019) as a journal in the S/4HANA CFIN System.
Each period movements plus historic open items until period 10 [April] (i.e. period 9 - March is the last period for balances) is calculated and extracted.
CFIN functionality calculates (using tables shown in Diagram 4 depending on SAP version), extracts these balances from the Source System and transfers to the relevant CFIN* tables in the Target S/4HANA System using Remote Function Call (RFC) functionality.
Details are already explained in Diagram 4 in the previous Section.
Initial Load Journal Transactions
'Start-Documents' and 'Period - Documents' column entries indicate the Fiscal Year and Period to start extracting the full 'Entry View' of the Source System journals.
In the example, all documents from Period 10 inclusive (April) onward up until the Initial Load extraction Date/Time (t0) are extracted from Source.
The mechanism for extraction is as per 'Initial Balance Load' above (i.e. RFC).
Details are already explained in Diagram 4 in the previous Section.
The recommendation is that Initial Load extraction is executed during Production downtime as the programs are memory intensive due to data volumes. This is one of the reasons that SAP recommends to keep the historical time period as short as possible.
An example of run time for the extract is 8-12 hours - the data set for Journal Transactions in this estimate were approximately 1.2 million journals/month for 8 months. Run-times can be improved based on technical settings. This is an extreme example.
Ongoing Replication Journal Transactions
This phase is not part of the Initial Load but is included in Diagram 5 for completeness.
The CFIN functionality knows the Date/Time when the Initial Load extract has been executed. The Source System(s) automatically start recording in the Source CFIN* Tables (see Diagram 6) any documents posted since the Initial Load Date/Time extraction is completed.
The Initial Load extraction involves 2 steps to ensure completeness and reconciliation:
- Initial Extraction - Initial Load data (balances/journals) up until the day before the extraction in executed. This is the longer task due to volumes.
- Delta Extraction - Initial Load data (journals) on the day of the extraction. Program execution is shorter due to the smaller data set and eliminates the risk of journals being missed before replication is switched on.
When replication via SLT is switched on after Initial Load has been posted in Target, all of the entries that have been accumulating in the Source CFIN* tables (see Diagram 6) are processed and replicated (posted) to the Target S/4HANA System.
See Diagram 6 for the replication process details.
Replication of FI and CO
Replication of the FI journals is manually started in SLT once the Initial Load posting is complete in the Target SAP S/4HANA system. SLT functionality polls the Source System(s) for any FI entries in the Source CFIN* Tables that have accumulated since the Initial Load extract was completed and replicates the journals. For new journals entered by Users or programs, SLT replicates in near real time.
If the Source System(s) is non-SAP and Magnitude is used then the CFIN* tables are located in the SLT System (green circle, Diagram 6) and SLT replicates the journals from there to the Target S/4HANA System.
Normally the Go-Live Cutover is executed on a weekend where Users are locked out of the PROD Source System(s) and batch jobs/interfaces have been stopped. This reduces the risk of reconciliation issues and minimises the number of journals that need to be replicated after Initial Load.
For some Industries this is not an option due to number/location of Source Systems, size of the Business, or 24/7 operation. As per the Initial Load and Replication functionality/timings discussed minimal downtime can be accommodated ensuring adequate planning.
Diagram 6 shows the replication process with AIF and the CFIN interface now processing both the FI and CO journals.
The Mass Data Framework (MDF) is no longer required as the tool is used only for Initial Load of FI documents.
Diagram 6 shows the CO Initial Load document process for completeness as it uses the SLT process rather than MDF.
If the Source System is non-SAP and Magnitude is used the CFIN* Source tables are located in SLT (green circle).
Diagram 6: Replication of FI and CO
Initial Load and Replication of Journals - Together
Merging Diagram 4 and 6 shows the Initial Load and Replication of Journals in one diagram.
Central Payments - Converting to 'System of Record'
The blog started off by giving an overview of the paths to S/4HANA. Central Finance is one of the paths to S/4HANA and Central Payments (CPAY) functionality is required for the S/4HANA System to operate as a 'System of Record'.
CPAY functionality released in SAP version 1709 centrally controls where certain processes are performed in the System Production Landscape (i.e. Target and not Source Production Systems).
Please be aware of the restrictions for CPAY in SAP note 2827364 - Central Payment for SAP Central Finance
The controlled processes are all the follow on processes from the original journal such as payments, receipts, reversals and banking. CPAY allows replicated Open Item line items that have a Source System recorded to be post processed in the Target S/4HANA System.
Once the Target System is the system of record, other processes are centralised such as credit checks, collections, disputes, banking and cash control.
CPAY achieves control by technically clearing all open items in the source system defined in the CPAY configuration. The open items in focus for CPAY are:
- Business Partners (Customers and Vendors)
- Bank Reconciliation Open Item GL Accounts
- Other Open Item GL Accounts as required by the Business
The Source Open Items are technically cleared by putting the posting date in the Clearing Date field and ALE-Extern in the Clearing Document field. See Diagram 7.
This means that the payment, receipting and banking no longer functions in the Source System for the designated Company Codes in the CPAY configuration. All Open Item follow on functionality has to be executed in the Target S/4HANA Finance System.
Functionality called Cross System Process Control (CSPC) checks the Target System to determine whether an Open Item can be reversed in the Source System(s).
For example, if a replicated Open Item for a Vendor (Invoice) has been paid in the Target S/4HANA System and the linked document in the Source System is being reversed by a User or program, CSPC functionality will not allow the reversal as the Target S/4HANA Open Item is already cleared.
The User must unclear the Open Item (Invoice) in the Target S/4HANA System (i.e. Uncleared Open Item and payment on account now exist) before reversing the Source System Vendor (Invoice) document.
Diagram 7: CPAY Functionality
Before the target S/4HANA System can be used as a System of Record please note the restrictions listed in SAP notes:
2184567 - Central Finance: Frequently Asked Questions (FAQ)
2643282 - Central Finance: Restrictions regarding Extended Amount Length
Central Assets
One of the biggest decision when converting the S/4HANA CFIN System to a System of Record is with Asset functionality and accounting.
Asset journals are replicated by CFIN to Target without the asset numbers or asset journal requirements (e.g. transaction type). CFIN strips out and/or replaces the asset relevant fields and posts as a General Journal. Therefore the Balances and line items match/reconcile between Source and Target but Asset Accounting cannot be performed in the Target S/4HANA System until the System of Record Go-Live.
Often Clients add the asset number to a text field using one of the CFIN BAdI's to assist with reconciliation.
As part of the cutover to the System of Record the balances in the mapped Asset Target GL would be used as the take-on GL for Assets and balance to nil once asset take-on is complete. This is the cleanest scenario where all assets are taken on in the Target S/4HANA CFIN System at Go-Live.
Due to the integrated nature of Asset functionality in SAP where upstream processes from different modules such as Plant Maintenance integrate by settling to the asset or linking other master data such as equipment, a partial migration of assets does not make sense.
Consider the following theoretical scenario - if the same asset was in Target and Source the following questions have to be answered:
- Where will asset related purchasing occur - PO and Direct purchasing?
- Where will AuC be handled - Projects?
- Which asset, equipment and functional locations will Maintenance processes use?
- How to account for follow on Financial processes such as Depreciation, Revaluation, Scrapping, and Sale occur for the asset(s)?
SAP has introduced the following functionality to enable upstream asset processes (e.g. Purchase Orders for assets) to stay in the Source System(s) and the asset function finalised in the Target System (CFIN):
- Central Projects (v2020 FPS01 backward compatibility to FPS0) - Asset Settlement Scenario
The Central Projects functionality is being used where a project (WBSE) is being created and edit in the source system and replicated to the Central Finance system.
- Central Asset Accounting (v2021 FPS01)
- Initial Asset take-on in Target (CFIN)
- Cross-System Processes - Asset Acquisition/Capitalisation
- Asset acquisition with a clearing account
- Central settlement from an order to a fixed asset
- Central settlement of Assets under Construction (AuC)
Central Projects - Asset Settlement Scenario
The functionality is focused on the one process. The functionality is required for those Customers that have implemented Central Projects, are not discontinuing its use, and want to handle the asset processes in the Target (CFIN) System.
The assumption is that all of the other asset processes are being cut-over to the Target System.
The pre-requisite for this functionality is to finalise the AuC processes (e.g. settle) and ensure no AuC master data is automatically created in the Source System(s).
The Investment Profile configuration assigned to the Project Profile of the Project/WBSE structures in the Source System(s) needs to be adjusted to ensure the Asset under Construction (AuC) is not automatically created.
This is achieved by changing the Investment Profile to have the 'Manage AuC' configuration setting unchecked. This setting change is only relevant for newly created Projects. Consider creating new Project Profiles in the Source System to reduce risk.
The Project Profile from Source is mapped to the Project Profile in Target that has the Investment Profile attached and the 'Manage AuC' configuration setting checked.
The outcome is that the AuC is automatically created in the Target CFIN System when the Project/WBSE master data and structure is replicated via the Central Projects functionality.
Diagram 8 visually shows the process and setup described. Replicated journal postings from Source can now be settled to AuC and Asset(s) in Target.
Diagram 8: Central Asset CFIN Functionality
Central Asset Accounting: Cross-System Processes - Asset Acquisition/Capitalisation
Asset Acquisition with a Clearing Account
This process involves a 2-step manual process starting in Source and finalised in Target.
Step 1 involves manually entering the Vendor invoice in Source via transaction FB60 (or the relevant Fiori App) against a Clearing GL account specifically for the asset process so that it replicates to the Target S/4HNA CFIN System.
The Clearing GL Account in Source is mapped to a Clearing GL Account in Target.
The process uses different transactions for Step 2 in Target depending on whether the target GL Account is Open Item managed or not.
Step 1: non-Open Item Scenario
Pre-requisites:
- In the Central Finance system, you have defined a clearing account for non-integrated asset acquisition (KTANSG), which is not open item managed. You can do this in transaction SPRO: Financial Accounting>Asset Accounting Integration with the General Ledger Accounting>Assign G/L Accounts.
- In the source system, you have defined a clearing account as the offsetting account which is used to create the vendor invoice. This clearing account should either have the same setting as the clearing account defined in the Central Finance system, or is mapped to the target clearing account.
In the Central Finance system, post the asset acquisition in transaction ABZON. This vendor invoice is also posted against the clearing account for the non-integrated asset acquisition.
Step 2: Open Item Scenario
Pre-requisites:
- In the Central Finance system, you have defined the ACI account (technical clearing account for the integrated asset acquisitions) as asset reconciliation account. You can do this in transaction SPRO: Financial Accounting>Asset Accounting>Integration with the General Ledger Accounting>Technical Clearing Account for Integrated Asset Acquisition>Define Technical Clearing Account for Integrated Asset Acquisition.
- In the source system, you have defined a clearing account with open item management. And the clearing account has been set as technically cleared in the source system. To do so, maintain the account in the Customizing activity in transaction CFINIMG under Central Finance: Source System Settings>Settings for Central Management of Open Items in General Ledger>Define G/L Accounts for Technical Clearing.
In the Central Finance system, post the asset acquisition in transaction F-91. Select the Transfer posting with clearing option and enter the asset line firstly.
For the offsetting item, select the open-item-managed clearing account you have defined. The replicated vendor invoice is also posted against the clearing account which is therefore cleared in the Central Finance system.
Central Settlement from an Order to a Fixed Asset
In Central Asset Accounting, you can post supplier invoices or collect costs to the internal order, or maintenance order (for value-enhancing repairs) in the source system, and then settle the costs from the order to the fixed asset in the Central Finance system.
This process is almost identical to the 'Central Projects - Asset Settlement Scenario' except that an Internal Order or Maintenance Order is used instead of a WBSE and Central Assets functionality is active to allow the settlement in the Target S/4HANA CFIN System. See Diagram 8. In this Order scenario the AuC configuration is not involved and the settlement rule has to be entered manually in the Target.
Process steps:
- Create an order in the source system. The order is then transferred to the Central Finance system.
- Create the asset master data in the Central Finance system if the data does not exist yet.
- Maintain the settlement rule for the replicated order in the Central Finance system and enter the fixed asset as the settlement receiver.
- Post the supplier invoices or costs to the order in the source system. The relevant FI documents and the costs on the order are replicated to the Central Finance system.
- Settle the costs from the replicated internal order or maintenance order to the corresponding fixed asset in the Central Finance system.
Central Settlement of AuC
This process is the same as 'Central Settlement from an Order to a Fixed Asset' but uses the Investment Measure and AuC process as per the 'Central Projects - Asset Settlement Scenario'.
The SAP help refers to the Central Projects - Asset Settlement Scenario if a Project/WBSE is to be used. The point to understand is that the restrictions for Central Projects (Target Projects/WBSE cannot be changed) matter depending on the Customers requirements to convert the S/4HANA CFIN System to a 'System of Record'.
If the Customer wants to be able to update/change the Target projects/WBSEs then Central Projects restrictions are a problem. The Project/WBSE interface needs to be built as part of the SAP Implementation Project to meet the Customer requirements. See previous discussion in this Blog.
Process Steps:
- Create an internal order without investment profile in the source system, then replicate the internal order to the Central Finance system as an investment order, assigned with the investment profile where you have defined the asset class to be used when the accompanying asset under construction is created and other parameters.
- The asset under construction will be created automatically in the Central Finance system when the investment order is created.
- Maintain the settlement rule for the replicated investment order in the Central Finance system and enter the asset under construction as the settlement receiver.
- Post the costs to the internal order in the source system, then the relevant FI document is replicated to the Central Finance system.
- Settle the investment order to asset under construction in the Central Finance system.
- Create a fixed asset in the Central Finance system if this is not already existing.
- Settle the asset under construction to the final fixed asset in the Central Finance system.
Be sure to plan carefully in advance for Assets when converting to a System of Record.
Final Comments
The purpose of the blog is to give the reader a solid base and understanding of the CFIN functionality including conversion from 'System of Report' to 'System of Record'. 5 Diagrams have been used to give the overview of CFIN with the other diagrams covering additional functionality. Once the diagrams are understood the comprehension of the vast amount of documentation in SAP help is easier.
There is more functionality in CFIN and CPAY not mentioned in this blog:
- Central Budgeting
- Central Tax Reporting
- Joint Venture Accounting
- Comparison/Reconciliation Reports
- Using Costing Based COPA with CFIN
- Side Panels - Displaying the Target or Source Journal with mapping/clearing details depending on whether you are logged into the Target or Source System.
- SD and MM Down Payments
- Retriggering Source Documents
- Reset Initial Load
- Tax customising checks
- Integration to Accrual Engine
- Profit Centre Accounting replication - old PCA functionality (Ledger 8A)
- Accounting View of Logistics (MM and SD) replication
- Commitment replication
Diagram 9 shows all the replication scenarios for Central Finance. Most have looked at a similar diagram before when researching CFIN.
The blue arrows in Diagram 9 show the additional replication scenarios that were lightly or not discussed at all.
Diagram 9: Replication Processes
- SAP Managed Tags:
4 Comments
