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).


Figure_01.png

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.

Looking forward meeting you at our next blog talking about Advanced available to promise.


Stay tuned for the next use cases and follow me via @SDenecken for latest news.


___________________________________________________________________________________________________________


Overview of SAP S/4HANA use cases: #S4HANA – the use case series – Overview


To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Alejandro Sensejl

    Hello Sven,

    thanks for your first hand information!

    Can you explain what does it mean for custom ABAPs when upgrading to S/4, please?

    If I unterstand correctly, all custom developments, that currently access e.g. MSEG and MKPF data, needs to be updated to fetch data from new HANA table MATDOC?

    Best regards,

    Alej

    (0) 

Leave a Reply