Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
Showing results for 
Search instead for 
Did you mean: 
The new data model in MM-IM with tables MATDOC and MATDOC_EXTRACT has been around for a while but there's still some questions about how both still co-exist with the old tables (MKPF, MSEG, MARD, etc.). This blog post is to clarify how the compatibility was maintained after the migration to this new data model.

Introduction and General Information

SAP ECC Data Model Issues

The data model for inventory management in SAP ERP Central Component was built based on material document, hybrid, aggregate and history tables. Hybrid, aggregate and history tables had redundant information as the sum of the data stored in the material document tables could return the same information, without having it saved on the database.

This large number of tables in the data model would often result in low performance in stock reporting due to the amount of information that had to be evaluated in order to display the stock figures. On top of that, locks on database due to UPDATE operations along with another locks from business operations could occur when working with the tables of the old data model.

SAP S/4HANA Data Model Solution

In order to solve those limitations from SAP ECC, a new simplified data model (NSDM) was designed based on the following premise: All stock data will be calculated from material document information stored in a single table that is managed using INSERT operations onlyWith the stock information calculated on the fly, the redundancy issue is solved. With a single material document table, the low performance issue for reporting is solved. With the use of only INSERT operations in the material document table, the lock issues are solved.

Targeting those changes in SAP S/4HANA®, the biggest challenge was how to ensure compatibility for consumers in higher layers, partner and customer solutions. To ensure that, the following solutions were proposed and implemented:

  • Use of proxy objects in the form of CDS views. Used to calculate stock figures on the fly and join the master data results contained in the hybrid tables.

  • If a given hybrid table has a proxy assigned to it. The SELECT statement to the table will be redirected in the database interface layer to the assigned CDS view.

The on the fly calculation is slower than fetching already aggregated data. So the performance of the calculation of the stock figures is proportional to the number of records in the material documents table. To solve this performance issue, a second table that works as a sub set of MATDOC table was used. The MATDOC_EXTRACT.


MATDOC table now contains both header and item data for material documents. Hybrid tables (e.g. MARC, MARD, etc.) still exist, but they only hold master data information. All stock information displayed during a select on those tables is calculated on the fly. The MATDOC_EXTRACT table is used to speed up the summarization of MATDOC table during the on-the-fly calculation of stock figures:

Hybrid Tables in the New Data Model

Hybrid tables like MARD still exist and still return stock figures. However, those figures are calculated on the fly using the Core Data Services Views created with the new data model. This can be seen with an SQL trace for a select in MARD made in SE16 transaction:

The CDS View is an ABAP entity written in DDL (Data Definition Language) SQL script. They are used in this scope to aggregate data from various sources into a single top view.

Using MB80 transaction (provided by SAP Note 2542130) or ABAP Developer Tools in Eclipse, it is possible to check the DDL file that points to a view created in SE11 in the ABAP Catalog. For example, the CDS View for MARD is composed by:

  • A Data Definition file: NSDM_DDL_MARD

  • A Dictionary View: NSDM_V_MARD

  • A Database Entity (at database level, only referenced by the DDL): NSDM_E_MARD

The stock data in hybrid tables are redundant because the sum of all material document information returns the same data. For example, the quantity displayed in MARD-LABST for Unrestricted-Use Stock is now a result from the sum of all the material documents related to the data selected and calculated through the use of the NSDM_V_MARD view whenever the LABST field is consulted in MARD. If no stock information is required from those tables, a SELECT that fetches only master data information can be used with the special view V_Mxxx_MD created for this (e.g. V_MARD_MD).

In summary, a SELECT * FROM MARD now performs the following steps:

  1. Access MARD to get the storage location material master data entities.

  2. Perform the aggregations on table MATDOC_EXTRACT to get the actual stock level.

  3. Join both results.

Views and Definitions (MARD used as example)

The CDS View stack will depend on the reference in each view and DDL file, to confirm the stack for MARD, we can navigate by accessing each DDL file joined as an entity in a previous DDL file (the shortcut 'Navigate To (F3)' in ADT in Eclipse can be used when the entity is selected):






The new MATDOC table can be read considering its vertical structure (include structures in SE11), horizontal structure (based on the RECORD_TYPE field) and suffixes:

  • Vertical Structure:

    • NSDM_S_STOCK_ID: Warehouse stock identifier (MATBF, WERKS, LGORT_SID, etc.)

    • NSDM_S_UNITS_AND_KEY_FIGURES: Units and Key figures (DMBTR, MENGE, STOCK_QTY, etc.)

    • NSDM_S_HEADER: Fields of the former header table (BLART, BLAUM, USNAM, etc.)

    • NSDM_S_ITEM: Fields of the former item table (BWART, MATNR, LGORT, CHARG, etc.)

    • […]

  • Horizontal Structure:

    • MDOC: Corresponds to the entries stored in the former header and item tables.

    • MDOC_CP: Complementary postings. Similar to XAUTO entries in former MSEG table (e.g. 101 for Stock in Transit). Are used to help the on the fly calculation of the stock figures.

    • MIG_DELTA: Created by migration to compensate the quantity differences between the MATDOC_EXTRACT and the old MARD-LABST quantity after migration due to archived documents.

    • ARC_DELTA: Created to represent material documents archived that are not in MATDOC anymore.

    • AG_MDOC_CF: Represents the quantity of the stock that was aged in MATDOC and moved to the cold stock (data aging).

  • Sufixes:

    • *_SID: Stock Identifier.

    • *_CID: Complementary Stock Identifier

    • *_CG: Complementary Group


The MATDOC_EXTRACT table is a condensated MATDOC table created to improve performance when fetching the date for on the fly calculation.

The records are inserted in MATDOC_EXTRACT at the same time they are inserted in MATDOC and a pre-compacting process is executed automatically with the period closing in MMPV transaction. This pre-compacting process reduces the data in MATDOC_EXTRACT table keeping only the information needed for the calculation of stock figures.

The pre-compacting can also be started manually using NSDM_MTDCSA_PRECOMP report.

Further Information

I hope this post helps to understand the current MM-IM data structure, for more in-depth information, please refer to SAP Note 2206980 - Material Inventory Managment: change of data model in S/4HANA.