Since SAP announced the release of SAP S/4HANA Finance (then called SAP Simple Finance) in early 2014, there has been a lot of confusion on what this product was all about. Most people, including those who were SAP customers, thought that it was a Financial Accounting and Controlling (FI/CO) sub-module that was in some way simpler to configure than the effort currently required in the ERP suite.
Having encountered the confusion around SAP S/4HANA Finance, I decided to put together a summary of what SAP S/4HANA Finance means from a business perspective. First, to understand what SAP S/4HANA Finance is, it is essential to understand SAP’s journey with SAP HANA, as SAP HANA is inextricably linked to not only SAP S/4HANA Finance but also SAP’s DNA.
What Is SAP S/4HANA Finance?
Before I answer this question, let me explain what SAP S/4HANA is. It is the SAP ERP 6.0 suite that is fully capable of running on an SAP HANA database. SAP S4/HANA Finance takes that a step further. Certain key components of the former FI/CO suite have been recoded so that they can take full advantage of SAP HANA’s potential. SAP Simple Finance (version 1.0) that was released in 2014 was the add-on SAP HANA-optimized version for the Financial Accounting module in SAP Business Suite. In comparison, SAP Simple Finance 2.0 is part of the SAP S/4HANA product that was released in 2015. SAP Simple Finance 2.0 is the redesigned and recoded successor of SAP Simple Finance 1.0.
(Note: Today SAP S/4HANA Finance is available as both on-premise and cloud versions. The cloud version is continuously enhanced in approximately quarterly releases. The 1503 release was followed by 1505, 1508, and 1511. [For those of you who have not figured this out yet, in the new numbering convention the first two digits are for the year, 2015 in this case, and the last two digits pertain to the month of the year. The on-premise version is enhanced on a yearly basis. As of September 2015, the term SAP Simple Finance is obsolete. It has been replaced with the term SAP S/4HANA Finance. For the rest of the article, I use the term SAP S/4HANA Finance and focus on the SAP S/4HANA Finance on-premise version, in particular the 1503 release formerly known as Simple Finance 2.0].)
Since SAP S4/HANA Finance is part of the SAP S/4HANA suite, it is important to understand what SAP S/4HANA consists of. SAP S/4HANA consists of four components:
- The functional/core component: SAP provides the various finance capabilities and enhancements as part of the functional/core component. You need to be on at least SAP NetWeaver 7.4, SAP ERP Central Component (ECC) 6.0 Enhancement Package 7, and SAP HANA version 1.0 to be able to consider a migration or upgrade to SAP S/4HANA. A migration to SAP S/4HANA from ECC 6.0 is a functional upgrade that involves the migration of transactional tables.
- The presentation/user experience (UX) component: This SAP Fiori-based GUI component helps you interact with the core component through the user-friendly Fiori screens. It requires SAP NetWeaver 7.4 and SAP Gateway version 2.0. Note that this is an optional component and you can continue with your existing SAP GUI or NetWeaver Business Client as your user interface.
- The reporting/analytics component: This component enables real-time reporting and analytics using pre-packaged HANA Live views. The prerequisites for installation are SAP HANA Live 1.0 for SAP ERP and SAP HANA. This too is an optional component.
- App component: This component is a collection of analytical applications in the Financials suite for key financial decision-makers in an enterprise.
Let us now look at some of the key SAP S/4HANA facts.
Fact 1: SAP S/4HANA represents what can be called the power of one. To me, the introduction of the universal journal (table ACDOCA) moves SAP closer to a single accounting transaction repository. It means that the posting to various individual ledgers, such as the material ledger, Asset Accounting (FI-AA), and CO, has been replaced by posting to one unified journal. In operational terms, every business transaction in the SAP General Ledger or classic General Ledger, CO (except costing-based profitability analysis), FI-AA, and the price determination component of the material ledger generates a journal entry in table ACDOCA. Figure 1 displays a partial view of table ACDOCA.
A partial view of table ACDOCA
Why is this a big deal? With one fell swoop, SAP has reduced the numerous instances of data redundancy and duplication across all FI modules. For those of you who are thinking what this does to the coding block, do not despair. ACDOCA can be extended to include the coding block. One of the most painful aspects of implementing FI/CO in any organization has been the (delayed and manual) reconciliation of CO postings to FI. This is now instantaneous and automatic.
Figure 2 provides you with an idea of the FI-AA fields that are included in table ACDOCA in SAP S/4HANA Finance.
The FI-AA segment in table ACDOCA
Fact 2: SAP S/4HANA has alleviated one big pain point – real-time reporting or analytics. The delayed reporting and analysis due to Extraction, Transformation, and Loading (ETL) to connected data warehousing systems (typically SAP Business Warehouse [SAP BW]) has been a bane. With SAP S/4HANA Finance you can transact and report all at the same time because within your SAP HANA system that houses SAP S/4HANA lurks a full-blown SAP BW system. This eliminates the need for offloading the reporting and analytics to your SAP BW system. In other words, there is no ETL needed to your separate SAP BW instance and therefore no delays in reporting. You are now able to do real-time reporting that combines transactional and historical data and allows you to make both strategic and tactical decisions based on the most recent data. Figure 3 displays a partial screen-print of the SAP S/4HANA Finance business content in the SAP BW system that resides inside your SAP S/4HANA Finance system.
SAP S/4HANA Finance business content
These are pre-configured SAP HANA Live views on SAP HANA tables (i.e., the database for your SAP S/4HANA Finance applications) that serve data to the user in real time by virtual access to the relevant tables.
Fact 3: SAP S/4HANA Finance has considerably simplified the overall data flow in your FI modules. Those of us who have been involved with FI/CO for many years will readily agree that there were too many tables that were being updated behind the scenes for every single financial transaction that was posted. For example, FI postings would generally involve updates to a lot of tables (known as secondary indexes). All these tables (such as BSIK and BSAK) have been eliminated. This has reduced the complexity of the overall data model. There is enough information available in the public domain on the tables that have been eliminated in SAP S/4HANA Finance, so I do not list them here.
Fact 4: Although SAP Fiori was not the presentation layer for SFIN 1.0, with the release of SAP S/4HANA, Fiori plays a far more prominent role. Although it’s optional for the on-premise version, Fiori is your user interface for the cloud version. What this means for you as a user is that you have an interface that takes out the complexity and clutter of SAP GUI-based screens. Furthermore, Fiori provides you with the same interface across all devices whether it is your laptop or a mobile device. Fiori uses both SAP HANA Live Content as well as SAP S/4HANA embedded analytics. SAP S/4HANA comes built with more than 500 role-based applications that include finance-specific roles. One category of these applications is analytical applications that provide users with real-time visibility into key performance indicators (KPIs).
New Asset Accounting: An Overview
To understand pre-requisites for running new FI-AA (as part of SAP S/4HANA), carefully read the official documentation on SAP’s Help website at http://help.sap.com/saphelp_sfin100/helpdata/en/35/64d652bc8fbe66e10000000a441470/content.htm.
Additional advantages of migrating to new FI-AA in SAP S/4 HANA are listed below:
- Due to the streamlined model, depreciation postings and runs complete a lot faster.
- Data redundancy has been reduced and you have to use fewer FI-AA tables. Actuals are stored in the universal journal (ACDOCA) instead of in a variety of tables (including ANEP, ANEK, ANLC, ANLP, and ANEA). Plan and statistical data are stored in individual tables.
- You can choose between the accounts and the ledger approach for asset postings. In the accounts approach, different valuations on different accounts are reflected in the same ledger. In comparison, if you use the ledger approach, different valuations or different accounting principles are reflected in relevant separate ledgers. The two approaches have many similarities, such as separate documents are created for each accounting principle or valuation and for each valuation, there is only one depreciation area that posts to the G/L in real time, and valuation is based on one or more depreciation areas.
- Since the posting of actual values of the leading valuation and values of the parallel valuation occur in an instantaneous manner, delta depreciation areas are no longer needed.
- In classic FI-AA, it was necessary to restrict postings related to valuations by mapping appropriate transaction types to depreciation areas. This is not required in the new FI-AA. Why? Because you can now specify in a transaction to which depreciation area or accounting principle (ledger or accounts) you are posting. This means that you do not need to go through the hassle of maintaining transaction types as an intermediate step. Since the concept of transaction types for depreciation areas is made redundant, the maintenance overhead for these transaction types is eliminated. Note that transaction types in standard or traditional FI-AA identify the type of asset transaction such as depreciation or down payments.
- Due to the improved design and tighter integration among the various FI components, you are now able to post to FI-AA directly from other modules such as a production order or a goods receipt or an invoice directly to an asset. Consider this example. In Figure 4, I am in the process of posting a purchase order (PO) to an asset.
A purchase order assigned to an asset
After I post this document, I create a goods receipt with reference to this PO. The goods receipt document generates two accounting documents in table ACDOCA (Figure 5). As you might know, the value of RMWE in the BTTYPE field is the activity indicator for the original goods receipt.
Goods receipt postings in table ACDOCA
Preparing for Migrating to New Asset Accounting
To use the new FI-AA module, you must have the SAP General Ledger activated and running in your SAP system. Other than the activation, no configuration is necessary because all the SAP General Ledger scenarios are active by default. The only exceptions are document splitting or adding a ledger. Also, you do not need to make any changes to your master data. Master data from your classic FI-AA is leveraged per se by the new FI-AA.
I mention this as there is a perception in the industry that you can jump from the classic General Ledger directly to SAP S/4HANA Finance. I have also encountered the perception that migration involves making changes to your asset master data or that the master data is affected in some way. These are incorrect perceptions.
Figure 6 displays the list of activities you need to carry out to prepare for and migrate to new FI-AA. The activities at a high-level are:
- Preparation activities
- Migration activities including charts of depreciation migration, execution of additional manual activities as applicable, and checking prerequisites for activating the new FI-AA
- Activating the new FI-AA
- Adjustments activities
Activities in the IMG for migrating to the new FI-AA
Before you start your preparation for migration, you first need to check the global settings (step 1), make the appropriate changes if needed such as the creation of the necessary ledgers and ledger groups, and then carry out the preparation and migration activities (step 2). This is shown in Figure 7.
Sequencing your FI-AA migration activities
If you are migrating from classic FI-AA to the new FI-AA, you need to execute the migration activities that are relevant to your enterprise. I recommend that you read the documentation in the “Prepare for New Asset Accounting” step in the IMG as shown in Figure 7. The document lists in detail all the steps that are needed to be carried out prior to starting your migration into the new FI-AA. I also recommend that you carefully read the documentation for “Perform Additional Manual Activities.” Depending on your particular situation, some of these manual activities could be relevant to your enterprise.
What actually happens after you migrate? Your FI-AA transaction data is moved to the universal journal ledger (ACDOCA) from the existing FI-AA tables. As you start posting into the new FI-AA, documents post directly to ACDOCA and no postings are made to certain existing FI-AA tables (as mentioned earlier). You can identify these documents by checking for the posting key (technical field name BSCHL). Debit postings to an asset account have a value of 70, and a credit posting has a value of 75. Figure 8 displays a few relevant asset documents from table ACDOCA.
Asset postings in table ACDOCA
(Note: There is a useful feature in IMG activity menu called Overview for Experts. You can see this in Figure 7. If you are an experienced FI-AA configuration person, you will find it convenient to navigate to this node and check important FI-AA configuration activities such as depreciation areas, asset classes, and account assignments. These activities are already available under relevant individual nodes elsewhere, but for the configuration experts, this is the place to go to for ensuring whether these key activities have been carried out and if not, you can execute directly from this activity.)