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 still exist, but they only hold master data information. All stock information displayed during a select on those tables is calculated on the fly.
- 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 exists and still return some stock figures. However, those figures are calculated on the fly using the CDS views created with the new data model.
- This can be checked with an SQL trace for a select in MARD made in SE16 transaction:
- CDS View = Core Data Service View.
- The CDS Views are written in DDL SQL script language that stands for Data Definition Language.
- With MB80 transaction or ABAP Developer Tools in Eclipse. We can check the DDL file that points to a view created in SE11 in the ABAP catalog.
- This means that the CDS View for MARD, for example, is composed by:
- NSDM_DDL_MARD: Data Definition file
- NSDM_V_MARD: Dictionary View
- NSDM_E_MARD: Database entity (at the database level, only referenced by the DDL)
- An update in MARD stock figure fields (e.g. LABST) has no effect in reporting because this field is not used anymore, all stock figures are calculated based on MATDOC_EXTRACT data. This prevent inconsistencies because is more difficult for the customer to manipulate the stock.
- If no stock information is required, an SELECT that fetches only the master data information can be used. The special views V_Mxxx_MD where created for this (e.g. V_MARD_MD).
- A SELECT * FROM MARD now does the following:
- Access table MARD to get the storage location material master data entities
- Perform aggregations on table MATDOC_EXTRACT to get the actual stock level
- Join both results