S 4 HANA Use Cases

#S4HANA use case series: 4b – increase

financial business performance (tech view)

In the previous use-case blog post #S4HANA use case series: 4a – increase financial business
performance (biz view) we explained how the transition in real-time in the production is essential to
address the new market needs. In the same way, the new area of big data provides larger and, in
terms of content, richer data sets – but the urgency to make decisions faster every in this context, the
real-time Finance has also a significant impact on the entire business process. Finance in real-time is
not just another modernized finance system, but it’s a paradigm shift in looking at and running the
financial processes.

Today´s blog will shed a light on what has changed with SAP S/4HANA from a technical point of view
to address the need concerning their business processes and their IT landscape.

Data model simplification

Enterprise applications in the past needed to store data in aggregate table in order to meet
performance expectations in view of limited database performance. Aggregate tables contain it´s by
nature redundant information. This makes the entire process memory intense and predisposed for
inconsistency conflicts. However, before the in-memory technology, aggregates and indexes were
required to map various requirements of the documents.

In parallel, if we analyze the data model of SAP ERP Financials, several instances of data
redundancy become apparent. The fundamental separation of different components (such as financial
accounting, controlling, profitability …) into separate table structures is a case of duplicate data.

Figure 1
The challenges of the architecture (see figure 1) before SAP S/4HANA was the huge reconciliation
efforts concerning the combined content of several tables. Data is the most important factor for
finance. If the data foundation is wrong, then everything else can easily be wrong and this combined
content of several tables represents “the truth”. The merge from separate components and data
models into a Universal Journal as the Single source of Truth enable radically new approaches to
finance, in addition to the usual benefits of a redundancy-free system.

Faced with millions or billions of accounting documents (headers, primarily stored in table BKPF) and
their line items (table BSEG) and slow disk-based performance, SAP ERP Financials needed
materialized views and materialized aggregates in order to provide sufficiently fast access to line
items with specific properties or aggregates values. For this reason, the classical core data model of
Financial Accounting (see Figure 2) contained, among others, six materialized views: three for open
line items (BSID – Accounts receivable table, BSIK – Accounts payable table, BSIS – G/L accounts
table) and three for cleared line items (BSAD, BSAK and BSAS) separated in the same tables. We
had also three materialized aggregates for corresponding totals (KNC1, LFC1 and GLT0).

Figure 2

Parallel posting

Removing materialized views and materialized aggregates from the financial accounting data model
has an immediate positive impact on the transactional throughput of the system.

In the case of SAP S/4HANA Simple Finance, posting an accounting document requires neither
inserting redundant duplicates into materialized views nor updating redundant aggregate values. The
corresponding effort and database operations to maintain consistency are no longer necessary.
Enterprise systems usually handle a lot of transactions in parallel. In the case of materialization, the
concurrent aggregate updates in particular can lead to contention, because materialized aggregates
have to be locked for updating. In the case, for example, heavily used G/L accounts, the database
system has to handle the otherwise parallel postings sequentially if they access the same G/L account
in order to consistently update the totals for this account. This unhappy situation con no longer occur
in SAP S/4HANA Simple Finance, as all transactions simply insert multiple into the database, which
does not require locks.

Single source of Truth: Universal Journal

The Universal Journal is the single source of truth and the holistic basis for next-generation
accounting in SAP S/4HANA Simple Finance. Technically, the new Universal Journal is a harmonized
and redundancy-free data store of actual data serving the

 General Ledger (G/L)

 Management Accounting/Controlling (CO)
 Asset Accounting (AA)
 And Material Ledger (ML) components.

The Universal Journal is one single physical table, and SAP HANA provide the necessary speed we
need to aggregate hundreds of millions of line items of one table within seconds!

Figure 3

The new journal entry consists of a header (table BKPF) and the respective items (table ACDOCA).
The table ACDOCA contains all fields needed for G/L, CO, AA, ML, PA and we have now 6 digit fields
for line item numbering (no longer the 999’ document lines limit).
Figure 4

Concerning the usage of Material Ledger for parallel currencies and parallel valuation purpose, the
contents of tables MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD, CKMI1, BSIM is now stored in
ACDOCA. MLHD data is stored in BKPF.

MLHD, MLIT, MLPP, MLCR still keep prima nota information, in case of manual price changes or
material debit/credit

Immediate Benefits of the new Model

The Universal Journal has all fields (columns) required by the business processes and the individual
components. Whereas the technical handling of a table with so many fields would have created
significant difficulties in the past, now we can dare to do thanks to SAP HANA’s superior compression
technologies and columnar layout. In addition, we have the following innovations:

 Significant coding changes (aka. Unified Journal)

 Merge the transactional tables for the General Ledger, Asset Accounting, Management
Accounting, CO-PA and Material Ledger into one
 Merge the account and cost element

Between FI and CO, in our new architecture we merge CO and FI so that real-time integration is
guaranteed by design. Users can natively drill down to the same line items from the key figures and
reports of both components.
#S4HANA use case series: 2b – next
generation inventory management (tech
view)
Why Is Inventory Management Important?

With the “Segment of One” approach (see the previous blog entry (#S4HANA use case series: 2a –
next generation inventory management (biz view) leading to a Unit of ONE and a Lotsize ONE, we
have seen that new market requirements need for all data the highest level of granularity (the level of
greatest detail).

The old way of design and thinking updates several aggregate tables in parallel to the original
document table. Multiple applications make use of the information coming from MM-IM but require
different levels of details. This results in high redundancy and software complexity managing the
consistency. The Aggregate-tables contain redundant data with a certain risk that inconsistencies
might occur.

Classical Database Structure

Up to ECC6 the material management inventory functionality stores the document data in two tables:
MKPF and MSEG. The first one is the header table and the second one is the line item table. The link
between MKPF and MSEG is established via MBLNR (Document No.) and MJAHR (Fiscal Year).

Today stock quantities are stored in up to 15 tables. Values and valuated quantities require further
tables: 3 out of the 15 stock tables are master data tables with additional fields containing stock
quantities. The remaining 11 tables are pure aggregate tables. Additionally, each aggregate table is
shadowed by a history table storing the aggregated stock quantities of previous periods (each entry in
the standard table is accompanied by an entry in the historical table for the previous period) (see
Figure below).
Innovations in SAP S/4HANA Enterprise management – Inventory Management

Aggregate tables contain it´s by nature redundant information because stock quantities are the sum of
a material movement document, stored in MKPF and MSEG. This makes the entire process memory
intense and predisposed for inconsistency conflicts. However, before the in-memory technology,
aggregates and indexes were required to map various requirements of the documents.

The Need for a new Inventory Data Model

The content of the aggregate tables cannot be calculated directly from the inventory data in MKPF
and MSEG alone. Further IMG tables are required to classify the stock type for example. All relevant
IMG tables need to be mapped into the calculations.

One of the locks is a quantity posting lock, the other is a value lock. The first one is set even if it is
required only for goods issued. It ensures that enough material quantity is on stock. The second lock
(value lock) manages materials with moving average price. Sequence of material movements has a
significant impact on the material price and requires a sequential material posting.

With the new SAP S/4HANA data model, the above issues are addressed. Build for in-memory, it
does not have to consider the concepts of relational database design any more. Separation of the
MKPF information and MSEG information in different tables becomes obsolete. Instead, the new data
model uses the advantage of in-memory columnar storage. In this concept, the system has one single
new table containing all previous data. The structure of this table is composed of

 technical key fields

 an attribute field to distinguish various content
 all fields from the
 all fields from the former item table MSEG
 a booked quantity and a booked value field where the sign is determined by the debit/credit
indicator
 many additional attributes for reporting and on-the-fly calculation of aggregate values.
With the previous achievement it was a logical step to also eliminate and reorganize the IMG table
structure.

In the columnar database systematic, the construction of data model allows to erase aggregates and
indexes. A single table (MATDOC) with almost all required attributes and views represents the data
for all business perspective. The structure is given by a combination of the existing material document
header and item table structure, a booked field for changing quantities and values. Other attributes
for rapid reporting based on VDM (Virtual data Models) or CDS (Core Data Services) views
complement the structure.

This single table structure allow high performance evaluations of inventory key figures. In various
POC´s (Proof of concepts) we have been able to demonstrate a reduction in Locking by 97% (Current
Lab Results) and up to 5x times faster (Current Lab Results) inventory movements.

This data model allows high performance OLTP transactions even during the posting procedure and
high performance OLAP reporting at a reduced memory footprint – without any redundant data
storage. Aggregates are created dynamically based on line item level on-the-fly.

Finally the simplified code eliminate the risk of inconsistency and allows easier system maintenance
The new data model will allow high performance evaluations of inventory key figures based on the
material document data. Deep analyzes of stock movements and further complex stock evaluations
are supported.

The MM-IM aggregate tables and the classical document tables will not be updated anymore and
aggregate tables will be replaced by new compatibility CDS views with the same semantics as their
corresponding table. These CDS views perform an on-the-fly calculation for aggregates.

The existing fields MBLNR and MJAHR of the table MKPF are not key fields any more, they are now
set to attributes. As a consequence, their uniqueness has to be ensured by the application. uplicates
from the Database do not apply any more going forward.