Last Updated on January 10, 2023 by Pradeep


SAP S/4HANA Finance Architecture within SAP HANA

SAP S/4HANA Finance Architecture represents a streamlined data model of lightweight structure and compact build-up. It is an Ideal Architecture with aggregating line items that provides compatibility views and a single source of truth.

The purpose of this blog is to provide an overview of SAP HANA and S/4HANA Finance to understand the key ideas and concepts behind SAP HANA Finance.

architecture of houses representing sap s/4hana finance architecture - Skillstek

The Architecture of SAP HANA

The SAP S/4HANA Finance Architecture is inter-related with the Architecture of SAP HANA. So before starting learning SAP S/4HANA Finance, we will see how is the SAP HANA Architecture. Here we will first see the most important technology part of SAP HANA i.e. In-Memory Technology.

In-Memory Technology in SAP HANA

What it keeps

Today, a single enterprise-class server can hold terabytes of data in main memory. In addition, the main memory is the fastest storage medium that can hold a significant amount of data. This all is possible with SAP HANA In-Memory Database.

Benefits & Performance in SAP S/4HANA Finance Architecture

The benefit of keeping data in main memory is most obvious if we look at the storage hierarchy of the computer systems.

In terms of performance, two factors come into play when accessing data from a storage layer.

Firstly, the performance is related to the physical speed of the storage medium itself.

Second is the latency which is the time delay experienced by the system to load data from a storage medium until it is available in a CPU register.

Finally, in the end, every operation takes place inside the CPU and in turn, the data has to be in a register of the CPU in order to be processed.

Hard Disks

Hard disks are at the very bottom of the storage hierarchy. Because they are cheap, it is affordable to have a very large amount of storage at this level. It is not only the slowest medium but also (because there are typically four layers between the hard disk and CPU register) it has the highest potential.

Columnar Data Organization

Relational databases – Tables

Relational databases represent data in two-dimensional structures i.e Table. It has Row-based as well as column-based layouts.

To understand this, Let’s look at a simple example.

In this, we have some information related to the sales dept. of a business having its organizational structure.

Relational databases - Tables SAP

Row-based layout stores a table as a sequence of rows. Here you store the elements forming a row in contiguous memory locations.

Further, in the row-based layout, you can store all sets of values consecutively and sequentially in memory.

Row based Layout

Row based Layout in SAP HANA Tables

Since the SAP HANA supports both row-store and column store tables. Thus, you can achieve high performance when you can use the column-store tables in memory.

This also shows that workloads on enterprise databases are mostly read-oriented and dominated by set processing.

Column based Layout

Column based Layout in SAP HANA Tables

Parallel Execution in columnar Store

Column-based storage simplifies parallel execution by using multiple processor cores. In a column store, data is already vertically portioned. That also means that the parallelization can be achieved on different levels.

You can process the operations on different columns easily in parallel. If you need to search or aggregated multiple columns then you can assign each of these operations to a different processor core.

In addition, you can execute the operation of one column by different processor cores.

Simplifying the Core Data Model
Simplifying the Core Data Model (Image Credit: https://sap.com)

Enterprise applications in past needed to store data redundantly in order to meet the performance expectations of their users in view of limited database performance.

GL tables - infographic - SAP
(Image Credit: https://sap.com)

Old Data model in SAP ECC

In existing SAP ECC (ERP Financials)

  • Different level of details stored in respective components/tables
  • Secondly, Multiple BI extractors to analyze full data in BI
  • Also, Reconciliation needed for all components

Till now you get an idea of the SAP HANA Architecture. Now we discuss the architecture of SAP S/4HANA Finance that is obviously is related to SAP HANA.

SAP S/4HANA Finance Architecture

SAP S/4hana Finance Architecture - Skillstek
(Image Credit: https://sap.com)

Accounting Tables after new G/L Harmonization

Features of SAP S/4HANA Finance Architecture

SAP S/4 HANA Finance has some stunning methodologies.

Ideal Architecture with aggregating line items: First is the capability to aggregate hundreds of millions of line items of one table within seconds. Wouldn’t be able to write all detail that is needed by all components (G/L, CO, AA, ML, and COPA) into one single that constitute the ideal architecture.

Universal Journal: In SAP S4 HANA Finance 1909 combine the data structures of the different components into a single combined line item table-Universal Journal. This is a single source of truth that replaces the previously separate physical tables.

Compatibility Views: SAP S4 HANA Finance provides compatibility views that give transparent access to the obsolete individual tables, thus offering a no disruptive path to the innovative Universal Journal.

Also read: 3 Key New features of SAP New Asset Accounting in S/4HANA

Compatibility Views - SAP S/4HANA Finance Architecture - Skillstek
(Image Credit: https://sap.com)

Following tables are replaced by compatibility views in new architecture

  • Index Table Removed
  • BSIS- Index for G/L account
  • BSAS-Index for G/L accounts (cleared items)
  • BSID- Index for customers
  • BSAD- Index for customers (cleared items)
  • BSIK- Index for Vendors
  • BASAK- Index for Vendors (cleared items)
  • Aggregate Tables Removed
  • GLTO – General Ledger Totals
  • GLT3- Summary Data preparation for consolidation
  • KNC1- Customer Master (Transaction Figures)
  • LFC1- Vendor Master (Transaction Figures)
  • Other Tables Removed
  • COEP- cost Line Items
  • COSP- CO Total External Posting
  • COSS- CO Total Internal Posting
  • ANEP – Fixed Assets Line Items

Merging G/L Accounts and Cost Elements

Before the Universal Journal, we had G/L accounts and Secondary cost elements in CO mapped to those G/L accounts. Because the user always had to trace the mapping rules backward, this SAP S/4HANA Finance Architecture hindered navigation from FI to CO.

In the SAP HANA architecture, you use only one field in the Universal Journal entry to store both the G/L account and cost element. The trick is that you simply declare a cost element to be a special kind of G/L account.  You maintain the “new account” via one single UI.

Also Read: SAP Controlling and its Components

Compatibility Views

There are many programs in the system working with the data structures of specific components (for example with the table of controlling document line items, COEP).

Read access to this table is very common in these programs. So, how can you now change the underlying database table without having to rewrite the whole code?

Read operations in the ABAP code are redirected toward a view ( V_COEP) via a specific setting in the data dictionary definition of table COEP. This view then no longer reads the physical table COEP but the new Universal Journal. It now maps the data back to the structure of COEP.

Compatibility view for Table COEP in SAP S/4HANA Finance Architecture
Compatibility view for Table COEP (Image Credit: https://sap.com)

Read SAP S/4HANA Finance Architecture

SAP has transformed its S/4HANA Finance into a future-oriented ERP solution that is intelligent and friendlier. The consultants of SAP S/4HANA Finance should be well-equipped with the new architecture knowledge for a successful implementation of the SAP ERP into the system. Hence it is important to read the structure of SAP HANA and S/4HANA Finance in depth.

Watch Video: SAP HANA In-Memory Database by Pradeep Hota