Introduction and General Information
ECC Data Model Issues
The data model for inventory management in ERP 6.0 (also known as ECC) 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.
S/HANA Data Model Solution
In order to solve those limitations from 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 only. With 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 S/4HANA, the biggest challenge is 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.
This 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.
ECC vs S/4HANA MM-IM Data Model
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 CDS 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 stands for Core Data Service View and it 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 Ecipse, 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:
- Access MARD to get the storage location material master data entities.
- Perform the aggregations on table MATDOC_EXTRACT to get the actual stock level.
- Join both results.