Skip to Content
Technical Articles

Avoid issues when using the MM-Inventory Management standard content model in SAP BW/4HANA

Latest Update: 15/06/2020

This blog targets all consultants who are on a SAP BW/4HANA implementation project covering MM-inventory management sourced from SAP ERP or SAP S/4HANA. The aim is to help you to get the standard content for SAP BW/4HANA for inventory management properly activated and loaded without further issues.

The information provided in this blog is based on analysis of support incidents related to inventory management in SAP BW/4HANA raised in the past.

About 90% of the incoming incidents could have been avoided by following the below mentioned check list:

Check that the following was properly done in SAP BW/4HANA:

BW-1 You have read thoroughly SAP Note 2678507, the First Guidance: Inventory Handling in SAP BW/4HANA and the SAP Online Documentation Inventory Management (SAP HANA-Optimized BW/4HANA Content).

BW-2 All necessary SAP Notes related to BW4-DM-TRFN identified by SAP Note 2603241 were implemented in your SAP BW/4HANA system BEFORE the content is being activated via RSORBCT. Otherwise implement the missing SAP Notes and reinstall the content (see Knowledge Base Article 2530596). -> Missing BW4-DM-TRFN correction can cause wrongly activated content artifacts and/or data load issues both potential resulting in incorrect data persisted in the DSOs used for reporting.

BW-3 After connecting the source system you have executed the step “Content Update” as explained in SAP Note 2433354. -> Missing this step will prevent the activation of so called source system dependent objects such as DataSoures and content Transformations with DataSources as source object.

BW-4 For a new connected source system you have maintained the 2-digit source system ID (see SAP Online Help -> Prerequisites -> Source System ID) and you have transferred the global settings (‘currencies’ and ‘unit of measurement’). -> Missing this step will lead into a data load issue while loading data from this source system for the first time.

BW-5 You have successfully activated the inventory management content artefacts in your SAP BW/4HANA system with transaction RSORBCT, e.g. by choosing the DataFlow object /IMO/DF_MMIM_01.

BW-6 You have created the DTP’s in your SAP BW/4HANA system with the correct settings (e.g. “Initial-Non-Cumulatives for Non-Cumulative Values” and “Historical Transactions” flag) as described in the SAP Online Help and shown in the diagrams below (BW-10). If you cannot create a DTP with “Initial-Non-Cumulatives for Non-Cumulative Values, check SAP Note 2310862. Note: DTPs are not delivered by the BW/4HANA Content. -> Wrong defined DTP’s will update the data records with wrong RECORDTP resulting in wrong data in the inventory DSO and reporting (see SAP Note 1548125).

BW-7 You have checked if any SAP Notes with component BW4-AE-CORE-NC are required for the DW4CORE support package that you are using. Install any required SAP Notes before any data is loaded into the inventory DSOs. -> Missing BW4-AE-CORE-NC corrections might impact data loads and query processing in BW and might lead therefore to wrong query results.

BW-8 You have checked if any relevant ‘Known issues for the BW/4HANA Content objects’ mentioned in SAP Note 2678507 section 1c are relevant and need to be fixed in your SAP BW/4HANA system.


Check that the following was properly carried out in the SAP ERP or SAP S/4HANA system:

SRC-1 Determine Industry Sector and MM Process Keys (SAP Note 1883701). -> Without these configurations the extractor will not fill the critical fields BWAPPLNM and BWVORG, with the result that most inventory key figures will be loaded with ‘0’ value into the inventory DSOs.

SRC-2 The Data Extraction is activated for 2LIS_03_BX, 2LIS_03_BF and – if applicable – 2LIS_03_UM in the Logistics Customizing Cockpit (see SAP Online Help). Be aware that update mode ‘unserialized V3-Update’ is not suitable for ODP extraction and therefore should not be used (SAP Note 2758147). ‘Queued Delta’ is therefore the general recommended update mode when loading into SAP BW/4HANA. -> Use of unserialized V3-Update can lead to missing data records in the data extract.

SRC-3 Before you start a new initialization ensure that all queues are fully empty: ODQMON plus TCode SM13 for update mode ‘Queued Delta’ (LBWQ for unserialized V3-Update should not be used as mentioned before). -> Missing this step, a record stuck in the queue might be updated as delta record even already included in the new initialization run and would lead to be double counted in the inventory DSO and reporting.

SRC-4 Before you start a new initialization also ensure that the setup table is deleted with TCode LBWG for application ’03’. -> If you run a new initialization without cleaning the setup table, you might most probably encounter double amounts for quantities and values in reporting.

SRC-5 You have run the initialization for 2LIS_03_BX (MCNB), 2LIS_03_BF (OLI1BW) and – if applicable – for 2LIS_03_UM (OLIZBW) (see SAP Online Help). It is very important that during the initialization runs the SAP ERP or SAP S/4HANA system is locked for all inventory related transactions (how to reduce downtime is explained in SAP Note 753654).


Check that the following two steps were done in the SAP BW/4HANA system:

BW-9 After the setup tables were filled (and before the system is unlocked again), run a DTP with setting “Init without data” for the DataSources 2LIS_03_BF and – if applicable – 2LIS_03_UM into the staging Delta DSOs. This will initialize the queues in the source system to capture the delta.

BW-10 You have loaded all data properly into the BW/4HANA data model for inventory management e.g. as documented and shown in the diagrams in the SAP Online Help and in the images shown below. -> As already mentioned in step BW-6 loading the data with properly defined DTP’s settings is crucial. Otherwise the data records would be updated with wrong RECORDTP resulting in wrong data in the inventory DSO and reporting (see SAP Note 1548125). In case no data is loaded for 2LIS_03_BX, check SAP Note 2589723.


Still issues with incorrect MM-inventory data observed in SAP BW/4HANA?

You have checked and cleared all items above but you still experience issues with wrong looking data?

In this case, please follow the step-by-step procedure explained in SAP Note 1548125 VI Analysis of Problems to detect in which layer (A – Analytical Engine / B – Transformation & Loading / C – Extraction ) the error occurs:

A) Query compared to information shown in LISTCUBE do not match or the query cannot be executed and no SAP Notes could be found for component BW4_AE_CORE_NC:

In this case please contact SAP support with reference to the component BW4-AE-CORE-NC providing with the technical name of the simplified query (see again SAP Note 1548125 how the simplified query should be defined) and the corresponding LISTCUBE report (see SAP Note 1479893).

!!! Frequent issue: There were some incidents raised where missing SID values for 0DATE caused several issues during query execution (e.g. zero stock quantities or values, empty result rest, or query is not executable at all). If you find missing entries e.g. in table /BI0/XDATE, rebuild the master data for the time characteristics as described in SAP Note 2608688. Also regenerating the analytical query sometimes does the trick…

B) The data in the staging DSOs (e.g. /IMO/CMMIM01) is correct but the data in LISTCUBE on the reporting DSO (e.g. /IMO/D_MMIM01) is incorrect.

In this case the data is wrongly transformed and/or loaded into the inventory DSO. Consider the following to find the root cause for the issue:

– A problem with BW4-DM-TRFN which might be already fixed following the central SAP Note 2603241.

– Check again the correct DTP settings paying especially attention to the ‘inital Non-cumulative for Non-cumulative Values’ and ‘Historical Transaction’ flag in the appropriate DTPs

– Check the validity table and the table storing the reference points

– Compare ‘D’ and ‘A’ version of the transformations to exclude content activation issues

C) The data in the staging DSO looks incorrect and therefore the data extract provided by the data source e.g. 2LIS_03_BF looks already wrong

  • Double check again that the Logistics Cockpit setup / initialization was executed properly
  • Check if there are any SAP Notes missing for your source system related to support component BW-BCT-MM-IM
  • Check that your assumptions about the expected data extract are correct and your scenario is supported as explained in SAP Note 2678507 chapters 3 and 4, e.g.
    • BW-Inventory data does NOT always reconcile against MB5B (SAP Note 745788)
    • Different handling of consumptions and goods receipts in CKM3 and BW-Inventory data
    • BW-Inventory data takes into account configuration for statistical relevance in TCode OMJJ, SAP Note 827178
    • For source systems with Industry Sector = ‘Retail’, the standard data model provided with BW/4HANA Content is not suitable.
    • Evaluations of cross company code stock transfer is not supported

If this all did not help to find and solve the issue, and you require to open a support incident, you can speed up the process by putting as much information into your support incident as possible, e.g.:

  • What have you already checked?
  • Where does the problem occur (A – Analytical Engine, B – Transformation & Loading or C – Extraction)?
  • Example of a data record for that the error can be observed and investigated.
  • And most important: Choose the right support component for your incident

I hope this blog could help you to avoid or solve issues when using the SAP BW/4HANA standard content for MM-inventory management.

You must be Logged on to comment or reply to a post.
  • Thanks for the post.

    I am implementing Inventory management on BW 7.5 and noticed few things.

    Even if LIS 03 data sources are active in LBWE, the material document collection(SM13 or LBWQ) doesn’t start until a delta is initialed on the data sources(BF or BX). Again, if the ADSO contents are deleted the collection stops.

    Can the standard content ADSO’s for Material Stock – Values & Material Stock – Quantities be copied and updated to have an overwrite in the transformations? This will limit the SAP system downtime for initialization only on MCNB(2LIS_03_BX) as the overwrite mode will overwrite(eliminate double counting?) any ADSO records already extracted in setup and again through the delta(when the initial setup was running)

    /IMO/D_MMIM10 – MM-IM: Material Movements (Documents) for 2LIS_03_BF is delivered with overwrite mode for transfromations.

    • Hi Lourdes,

      indeed the necessary downtime is painful. There are some blogs out that give ideas how to shorten the time needed in the productive ERP system (e.g.

      However, changing the key figure update mode to overwrite into the inventory DSOs would unfortunately not work, as the movements (BF) & revaluation (UM) data gets aggregated.

      It would only work if you would define the key of the stock DSOs with the document number – but this would blow up the data including the reference point table massively and cannot be recommended.

      Best regards,


      • Hello Andreas,

        Thanks for the feedback. I will check the links.

        I am also going to check if I can leverage corporate memory for full(/IMO/CMMMIMH1) and delta(/IMO/CMMMIM01) before I propagate it to Inventory ADSO’s.

        I believe, the corporate memory should contain the data in raw format and the same material document/item/year available in both full and delta cor. memory would indicate the postings that occurred during initialization in source system(S/4).


        • Hi Raj,

          no worries. And yes we definitely would recommend to use the staging / corporate memory DSOs. It is as you say, the data is stored there in raw format (data source field information) and it makes it easier to reconcile data within BW and if a change to the transformations is required, no need to undertake a costly new initialization in the source system.

          Maybe I misunderstand you, but the assumption that you will find the same record in the history and delta data would be not correct. It is as you say, the data captured by the initialization e.g. for the movements will be written into the setup table and from there you will extract it with FULL into the staging / corporate memory DSO that stores the Historical Transactions (/IMO/CMMMIMH1). But when loading the ‘Deltas’, make sure that you define the DTP with “Init without data” as shown in the diagrams above. You do not want the historical values from the setup tables being loaded again in the delta staging / corporate memory DSO /IMO/CMMMIM01 – only the movements that happened after the initialization was done, should be loaded here.

          Hope this helps to clarify your concerns?

          Best regards,


          • Hi Andreas,

            The scenario I am testing assumes a downtime for stock Initialization(MCNB – 2LIS_03_BX) but not for OLI1BW(2LIS_03_BF) and OLIZBW(2LIS_03_UM).

            OLI1BW and OLIZBW will need a significant downtime(depending on material document history) but stock Initialization(MCNB) doesn’t as it reads current state.

            Below is a high level overview

            1. Downtime starts – No material movement posting
            2. Initialize Deltas on  2LIS_03_BF and 2LIS_03_UM. This will start SM13 or LBWQ collections
            3. Run MCNB.
            4. After successful MCNB run – Downtime ends
            5. Start OLI1BW & OLIZBW- Since there is no downtime, a material document that can be posted in the source system maybe be captured in initial setup table as well as SM13 or LBWQ for deltas
            6. Start BW initialization – Full DTP for corporate memory & Full DTP with historical check for inventory ADSO
            7. Start Delta’s – Delta DTP- No historical check. Need to check if corporate memory ADSO picked up the material document posted during OLI1BW initialization. If so, can it be stopped from loading into inventory ADSO from corp memory. 

            Hope this clarifies. Fun stuff 🙂

          • Hi,

            to me this sounds rather like a risky approach. You really need to guarantee that records captured after the delta capture has been enabled will NOT be loaded also through as historical data.

            A possible option here – at least in theory – would be to use the deletion handling of the DataStore object itself, as follows:

            1. Change the set up of the CM DSO storing the historical data ( /IMO/CMMMIMH1) to be a standard DSO without change log (!) – defined by key that uniquely defines a material document item: MJAHR, MBLNR, ZEILE .
            2. Create a transformation from /IMO/CMMMIM01 into /IMO/CMMMIMH1. Update all fields 1:1 but set RECORDMODE to ‘D’. (This will mark for deletion those “historical” records in the corporate memory storing the historical data that are actually delta movements)
            3. After OLI1BW-run is complete, load & activate (!) the data via FULL into the historical data CM /IMO/CMMMIMH1,
            4. Run the Delta DTP into the delta CM /IMO/CMMIM01 (dependent on the delta method used in the source, ensure that no delta that was captured during the initialization run, is still stuck in any of the queues e.g. LBWQ or SM13).
            5. Load the data per DTP (one time!) from delta CM /IMO/CMMMIM01 into /IMO/CMMMH1. Activation of this request will wipe out the records which are semantically actually delta movements.
            6. Load the data from /IMO/CMMIMH1 from the active (!) table (DSO should not have a change log or load the data in FULL mode only – as we do not want to load the deletions) into the further data targets.
            7. Continue the load process e.g. Delta Load from /IMO/CMMIM01 into the stock quantity DSO /IMO/D_MMIM01

            Similiar approach for revaluation data.

            As said, in theory this might work, but as I cannot guarantee it, I would advise to test the entire process throughly in your test landscape.

            Would be great if you could share with the community if you were successful.

            Best regards,


          • Hi Andreas,

            Thanks for the update. I will test your option.

            I was comparing the data contents between /IMO/CMMMIMH1 and /IMO/CMMMIM01 and found some material document/year/item available in both /IMO/CMMMIMH1 & /IMO/CMMMIM01 and it lead to double counting.

            For my test purposes, I setup the delta DTP to /IMO/D_MMIM02 &  /IMO/D_MMIM02 sourcing from /IMO/CMMMIM01 to exclude those material documents. Once the documents were excluded from delta run, I was able to reconcile BW with source system material movements.

            I was planning on keeping on the data flow to corporate memory intact as it will he helpful for reconstruction purposes and control/change on how we move data from corp memory to /IMO/D_MMIM01 and /IMO/D_MMIM02


  • Hello Andreas,

    Thanks for the blog. I have a question related to inventory data reporting in BW.

    1. Inventory team loaded data in S4 HANA.
    2. BW Inventory relevant indicators were checked in S4 HANA
    3. Setup table data was deleted using LBWG (03)
    4. MCNB was executed to initialize stocks data. This was successful
    5. Using appropriate DTP setting, 2LIS_03_BX data was loaded into /IMO/D_MMIM01. Data is visible in reference points table. In the settings of this ADSO, ‘All characteristics are Key, Reporting on union of inbound and active table’ is enabled.
    6. Since data is in reference points table and not in active table, this data is not visible in the report. How to report on this data?
    7. Also, as per note 2708746 -/IMO/MMIM: Use of 0UPD_DATE in Inventory ADSOs (BICONT 757 < SP20 & BW4CONT < SP 8), it is recommended to remove UPD_DATE from the ADSOs. If we remove posting date and/or UPD_DATE, how can we report on Inventory snapshot by day?

    Please advise.



    • Hi Ram,

      as your ADSO is defined as an inventory DSO, it reads data not only from the inbound and active table but accesses data from the tables storing the reference points and validity ranges.

      Assuming that you are using SAP BW and not SAP BW/4HANA, you can find more information how this is achieved/calculated by the analytical engine in the document SAP First Guidance NetWeaver BW 7.40 / 7.50 powered by SAP HANA Inventory Handling and Non-Cumulative Key Figures and in SAP Note 1548125.

      In case the reference point table in your system is properly filled but the information is not taken into account when you execute a query, there might be a problem with the Analytical Engine that needs to be fixed. For the SAP BW you are using check if there are any relevant SAP Notes for component BW-BEX-OT-NC or BW4-AE-CORE-NC.

      Regarding 0UPD_DATE: This date is rather a technical information stamping when data was loaded into the ADSO. As mentioned in the SAP Note we do not recommend to use it in a inventory DSO as it will blow up the reference point table. This has nothing to do with the posting date. The posting date is updated into the field 0CALDAY of the stock ADSOs and can be used for reporting of stock for a particular date or timeframe.

      Hope this helps. Regards,


      • Hi Andreas,

        1. Thank you for the detailed response. Now stock initialization data is visible in the report and that confirmed to me that the report was reading data from reference point table as well. Due to some unknown reason, that was not available in the report initially.

        2. Based on one of the OSS notes, UPD_DATE was removed from both inventory ADSOs.

        One thing that I am not too clear about, though it may be little late to ask, and would like to get clarification is regarding update mode for inventory data in S4 HANA. Currently we are using          un-serialized V3 update instead of queued delta. We are almost on BW4HANA.

        Per this OSS note 2758147, un-serialized v3 will result in missing records.

        There was no recommendation of using one update over the other in the ‘First Guidance’ document. Can you please shed some light on this and let me know your thoughts?







        • Hi Ram,

          I double checked and yes, also for inventory management extractors 2LIS_03_BF and 2LIS_03_UM the delta method ‘unserialized V3-update’ is not suitable for ODP extraction as it may lead to missing records and therefore should not be used.

          Thanks for bringing this up, certainly something of importance that need to be updated in the documentation and SAP Notes.

          Thanks and regards,


          • Thanks Andreas for the confirmation.

            If stock initialization (MCNB) is done today morning, then all postings as of this morning (June 8) will get loaded into BW after executing 2LIS_03_BX -> /IMO/D_MMIM01 DTP which will include material movements as well.

            1. In the delta DTP from 2LIS_03_BF -> /IMO/CMMMIM01, if the filter is ‘Posting date > June 8’, will we not lose the records posted from afternoon through end of the day on June 8?
            2. Before filling setup tables, ‘Delta Init without data’ was checked for BF and UM DTPs and executed in order to create subscriptions in ODQMON. The same DTPs were changed FIVE HOURS LATER (unchecked ‘Delta Init without data’) and added a filter on Posting date (June 9, 2020 – December 31, 9999). These DTPs are failing with same errors.

            Operation open_delta_no_data could not be carried out for DTP Req XXXXXXXXX

            Access_ODP/EXTRACT19 Pointer

            Illegal changes to selections of 2LIS_03_BF. Reset the delta before continuing.


            If I delete the current ‘Delta Init without data’ DTP request/TSN from the ADSO and try to execute the DTP again with the same setting (i.e. ‘Delta Init without DTP), then my concern is the next delta DTP will possibly not extract postings made in the last few hours since the Init without data DTP was executed for the 1st time. Please advise.




          • Hi Ram,

            after you have run the initialization (MCNB for BX, OLI1BW for BF, OLIZBW for UM), the setup tables will store the following information:

            1. Table MC03BX0SETUP stores the initial stock balance as it was true at the time the initialization was executed
            2. Table MC03BF0SETUP stores ALL historical transactions (material movements) that happened before the initialization was executed and therefore are already contained in the initial stock balance.
            3. Table MC03UM0SETUP stores ALL historical transactions (revaluations)  that happened before the initialization was executed and therefore are already contained in the initial stock balance.

            Initializing the Delta queues for BF and UM by DTP “Init without data” before the system is opened again, will track all material movements and revaluations that happened after the initialization took place. To make it clear, all of these delta transactions are not contained in the initial stock balance.

            In other words, due to this initialization process you get a clear separation of BF and UM transactions that happened before (BF/UM setup tables = historical) and after (BF/UM delta queue = deltas) of the BX opening balance. Just keep in mind that during the initialization process the ERP system needs to be restricted so that no transaction can be executed that results in new material movement or revaluation, otherwise those transactions might get lost in the extract leading to wrong stock values.

            On BW/4 side, you just need to tell the system in the DTP that loads into the inventory DSO if the data you load are sourced

            • A) from the BF/UM setup tables (FULL extract from 2LIS_03_BF and 2LIS_03_UM) and therefore must be loaded with ‘historical transactions’ flag into the inventory DSOs or
            • B) from the delta queues (DELTA init without data (!otherwise you would extract from the setup table again!) and therefore must be loaded without “historical transactions’ flag into the inventory DSOs.

            Therefore there is no reason to define a DTP filter on posting date for the delta movements/revaluations.

            Hope I could clarify your concerns.

            All the best,


          • Hello Andreas,

            Thanks for taking time to explain things in detail. Few of my questions got clarified. In my case, ‘Init delta without data’ was executed before filling setup tables. Few hours after filling setup tables, the delta DTP with filter was executed which gave the errors. Per your suggestion, execution of DTP without filter worked fine.  Since ‘Init delta without data’ was executed before and not after filling setup tables, my suspicion was that the 1st delta would pickup all records from setup table. The good news was this did not happen. Please let me know your thoughts.

            Your screenshots clearly showed FULL/Delta loads.




          • Hi Ram,

            yes, pure delta DTP execution will never access the data in the setup table. Only FULL or the first delta (with init flag) does read from the setup table.

            Best regards,