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

[AndreasTenholte]

Latest Update: 15/09/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 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 LBWQ for update mode 'Queued Delta' (SM13 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 SAP BW/4HANA Content standard data model for inventory management is not suitable. There is a Retail starter pack service available that delivers BW objects and data flows for retail-specific Inventory Management Reporting, SAP Note 2944418
  
  
  • 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.

[SudhanshuSurma]

Thanks for a very detailed blog Andreas. I can’t wait to do an inventory implementation on my BW4 client soon ?

[Hima_Paluri]

Thanks for the post.

[AndreasTenholte]

You are welcome Sudhanshu, and wish your little dream will come true! 😉

[lourdes_raj3]

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.

[ramtadepalli]

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.

Thanks.

[AndreasTenholte]

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. https://blogs.sap.com/2012/08/20/re-initialization-of-the-material-stocksmovements-cube-0icc03-with-...)

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,

Andreas

[AndreasTenholte]

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-Cumulativ... 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,

Andreas

[lourdes_raj3]

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

Thanks.

[AndreasTenholte]

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,

Andreas

[lourdes_raj3]

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 ?

[AndreasTenholte]

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,

Andreas

[lourdes_raj3]

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

[ramtadepalli]

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?

Regards,

Ram

 

 

 

 

[AndreasTenholte]

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,

Andreas

[ramtadepalli]

Thanks Andreas for the confirmation.

If stock initialization (MCNB) is done today morning, then all postings as of this morning (June 😎 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.

 

Regards.

 

[AndreasTenholte]

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,

Andreas

[ramtadepalli]

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.

 

Regards

Ram

[AndreasTenholte]

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,

Andreas

[ramtadepalli]

Thanks a lot Andreas for your detailed responses. They were very helpful. Much Appreciated!

 

Best Regards,

Ram

[AEG]

Well done Andreas!! This is very helpful!

 

[ffialho]

Hi Andreas, thanks for this very detailed post. But I still have a few of doubts.

A) Can I have scenario without Corporate Memory ADSOs?

B) If so, after filling BX, BF and UM setup tables what should be the DTP loading sequence for a first load.

C) My client will keep old BW live for a parallel operation for a couple of months clean e fill setup tables can have any impact in the old BW (not OPD)?

 

Kind regards,

Fábio

[ffialho]

Hi Andreas, I forgot one more question the costumer has 11 years of movements could I bring only the last 2 or 3? what would be the procedure for that?

Kind regards,

Fábio

[AndreasTenholte]

Hi Fabio,

shortly my answers:

A) Can I have scenario without Corporate Memory ADSOs?

Yes, it is possible to load the data directly from the data source into the DSOs used for reporting - but if you skip these first layer DSOs and in case you need to reload the data through the transformation logic, a new initialization in the ERP / S/4 system is needed.

Additionally the data from the datasource 2LIS_03_BF is loaded into all three DSOs. Having the first layer DSO, allows to extract the data from the source only once and distribute the data from there.  If you skip the first layer DSOs would mean that you have multiple DTPs extracting the data from ODQ.

B) If so, after filling BX, BF and UM setup tables what should be the DTP loading sequence for a first load.

Same as shown above, each of the Delta DTPs loading from ODQ into the DSOs used for reporting need to be executed with "Init without Delta".

The one time full loads for the historical data into /IMO/D_MMIM01 and /IMO/D_MMIM02 would need to be loaded with the "Historical Transaction" Flag.

C) My client will keep old BW live for a parallel operation for a couple of months clean e fill setup tables can have any impact in the old BW (not OPD)?

There should not be an impact as for the "old" BW system should be only loaded by delta DTPs in the daily uploads. The data in the setup tables is however only read by a full load or delta with init run. The delta for the 2LIS_03_* datasources can also feed two parallel target BW systems without any problem - regardless if classic S-API extraction or ODP is used.

Best regards,

Andreas

[AndreasTenholte]

Hi Fabio,

that’s not a problem. Obviously in this case, you will be able to report only the last 3 years as well in BW.

The procedure is as mentioned above, you just need to restrict the data accordingly when executing the initialization runs (OLI1BW, …).

Best regards,

Andreas

[ffialho]

Hi Andreas many thanks for your clarification. But I am still with one more doubt.

Since BX, BF and UM load common ADSO can you confirm the load sequence:

1. Lock ECC


2. Reset and fill Setup Tables


3. BX for both ADSOs with the the DTP in Extraction mode "Initial Non-Cumulative for Non-Cumulative Values"


4. BF with "Ïnit without data" for all 3 ADSOs


5. BF Full Load for all 3 ADOs


6. A last BF delta with data for all 3 ADSOs (should bring 0 records)


7. UM with "Ïnit without data" for the single ADSO


8. UM Full load for the single ADSO


9. A last UM delta with data for the single ADSO (should bring 0 records)


10. Free ECC

[AndreasTenholte]

Hi Fabio,

to shorten the system lockdown for ECC try this:

1. Lock ECC


2. Reset and fill Setup Tables


3. BF with “Ïnit without data” for all 3 ADSOs


4. UM with “Ïnit without data” for the single ADSO


5. Free ECC


6. BX for both ADSOs with the the DTP in Extraction mode “Initial Non-Cumulative for Non-Cumulative Values”


7. BF Full Load with "historical transaction flag" for all 3 ADOs


8. UM Full load with "historical transaction flag" for the single ADSO


9. Then you can schedule the Delta DTPs for BF and UM.

The step "A last BF delta with data for all 3 ADSOs (should bring 0 records)" - I cannot see why this needs to be done.

Best regards,

Andreas

[ffialho]

Hi Andreas, many thanks again.

The step that should bring 0 records it is something i just always did following recommendation fo other BW-LO friends, I've always been much more a FI/CO guy.

I just found another situation that you may give some more help.

The cutomer has implemented user-exits for BF and UM, but not for BX, can this birng inconsistnces? Should I recommend them to implement the same functional requirements  on BX user-exit?

Once there is an user-exit in place, when Setup Tables are filled the user-exit is called, or it is called onlty by the when the extraction itself is tirggered by the DTP?

Best regards,

Fábio

[AEG]

Hi Andreas

Unfortunately we cannot anymore add the Job in LBWE, says the is an error. Should i make an OSS?

Thx a lot.

 

Kind regards,

 

Adrian

[former_member149470]

Hi Andreas, you said that for BX,BF and UM "update mode ‘unserialized V3-Update’ is not suitable for ODP extraction and therefore should not be used". Can I just switch to ‘Queued Delta’, following Note 2758147, and my extractions for the old BW7.0 (S-API) and for BW/4Hana 2.0 (ODP) will keep working properly, or do I need any checklist of activities in order to achieve this scenario of one ECC feeding 2 BW's (one 7.0 and one BW/4Hana 2.0)?

 

Kind regards, Fábio

[AndreasTenholte]

Hi Fabio,

from my knowledge switching from ‚V3 update’ to ‚queued delta‘ requires a lock of the system transactions in the source system, for a short period of time.

Reason: The Delta Queue in SM13 for the application needs to be totally empty and no new transactions should be written while switching over the queue.

Suggested procedure (needs to be tested):

1) Lock system transactions.

2) Clean delta queues by triggering the data load process twice (including program(s) RMBWV3nn  that transfer data from V3 queue SM13 into BW delta queues (RSA7 and ODQMON).

3) Check that delta queues are full empty.

4) Import transport with switch to „queued delta“ and schedule job.

5) Unlock system transactions again.

From now on the transactions will update LBWQ instead of SM13. Loading procedure can be commenced to the BW system(s).

Best regards,

Andreas

[AndreasTenholte]

Hi Adrian,

I am not aware of any change to the LBWE job scheduler.
After adding the schedule parameters for start date and spool (both must have ‚green light), scheduling the job should work.

Could you double check?

All the best for your project,

Andreas

[hari_dw01]

Hi Andreas ,

Thanks for putting all the info in one place.Have one query .

In BW4HANA business content  ,we could see transformations only for valuated stock & consignment stock and suggesting to take account based on approach for special stocks to save memory & simplified transformations .Achieving special stocks in bex with restrictions ( can impact performance by little Snote -24333354) .

do we have any snote for reference for special stocks mapping in transformation in case we want to implement in keyfigure model itself .

Thanks in advance .

Hari

[AndreasTenholte]

Hi Hari,

there is no SAP Note, but you can find the logic applied for the restricted key figures in the Online Help for the Inventory Management CompositeProvider /IMO/V_MMIM01.

Example for blocked stock (standard only):

Blocked Stock	/IMO/V_MMIM01_BLOCKEDSTOCK	Key figure: 0TOTALSTCK with relevant restriction for blocked stock (0STOCKCAT “#”, “E”, “M”, “Q”, “U” and 0STOCKTYPE “D”)
Received Quantity: Blocked Stock	/IMO/V_MMIM01_BLOCKEDSTOCK_REC	Key figure: 0RECTOTSTCK with relevant restriction for blocked stock
Issued Quantity: Blocked Stock	/IMO/V_MMIM01_BLOCKEDSTOCK_ISS	Key figure: 0ISSTOTSTCK with relevant restriction for blocked stock

If you really want to use the key figure model, you would need to apply the above logic in addition to the transformation logic of key figures 0ISSTOTSTCK and 0RECTOTSTCK when loading into the additional key figures for blocked received/issued quantity.

Best regards,

Andreas

[former_member149470]

Hi Andreas, really need your expert view on a problem with initialization I just had. Here is teh sequence of what happened:

1. Lock ECC ==> Started on November 6 at 19:00


2. Reset and fill Setup Tables ==> Last until November 8 at 23:00


3. BF with “Ïnit without data” for all 3 ADSOs==> For some reason only for ADSO /IMO/D_MMIM10 was successful, and I only verified this today, due to lots of non-technical reasons i could only star the delta loads today.


4. UM with “Ïnit without data” for the single ADSO ==> OK


5. Free ECC ==> OK


6. BX for both ADSOs with the the DTP in Extraction mode “Initial Non-Cumulative for Non-Cumulative Values”==> OK with ADSO records activation


7. BF Full Load with “historical transaction flag” for all 3 ADOs==> OK with ADSO records activation


8. UM Full load with “historical transaction flag” for the single ADSO==> OK with ADSO records activation


9. Then you can schedule the Delta DTPs for BF and UM.==> When I ran the delta DTPs for ADSOs /IMO/D_MMIM02 and /IMO/D_MMIM01 6 Million records came a little bit more than the full loads, for ADSO /IMO/D_MMIM10 only 24k records. (did not activate the requests)

If I do the following steps:

1. Delete the non-active requests from the ADSOs,


2. Lock ECC and delete setup tables


3. Fill setup tables from Nov,6


4. Run the "init.deltas without data",


5. Free ECC,


6. Execute the delta DTPs

Would it solve my problem? si this the best solution? Do I need to include UM the process also? Or do need to begin everything from the scratch? Is there any way to avoid an almost full weekend downtime on ECC?

Really appreciate some guidance on this,
Kind regards, Fábio

[former_member8860]

Hi Experts,

Can you please advise how to fill the setup table in S/4HANA related to inventory?

We got a best practice client system and nothing is maintained, Recently the functional team is posted some data in all the areas. Now I am trying to activate and fill the setup table related to MM standard data source by using (    MCNB, OLI1BW, and OLIZBW   ).  The system is throwing an error not able to fill.

Please advise.

Thanks

Narayana

setup table filling issue

 

[lourdes_raj3]

The delta DTP’s for 2LIS_03_BF and 2LIS_03_UM needs to initialized(Delta init without data) in BW in order to execute transactions OLI1BW and OLIZBW for full load(initial setup)

[AndreasTenholte]

Hi Narayana,

yes indeed, at least one subscription should be active, check SAP Note 2386514.

Best regards,

Andreas

[mehsan92]

apply SAP NOTE 2386514

 

Thanks,

Muhammad

[ramtadepalli]

Hello Andreas,

We are on BW4HANA 2.0. I have an inventory query based on a composite provider (union of '/IMO/D_MMIM01', '/IMO/D_MMIM02' and '/IMO/D_MMIM10') in which I want to show data for 'Valuated Stock Qty' and 'Valuated Stock Value'. There are no restrictions on these key figures.

For some reason, data is not showing up in 'Valuated Stock Value' column. 'Valuated Stock Qty' column looks good. In /IMO/D_MMIM02, data is available for both 'Value received into valuated stock' and 'Value issued from valuated stock' key figures but am not sure as to why the 'Valuated Stock Value' is not showing any data in the query.

In the 'Non-cumulative' tab of 'Valuated Stock Value' infoobject, Inflow has 'Value received into valuated stock' and Outflow has 'Value issued from valuated stock'.

For testing purposes, 'Value received into valuated stock' and 'Value issued from valuated stock' key figures were added to the query. Data is showing up for both these key figures.

Can you think of any reason?

 

Regards,

Ram

[former_member683296]

Hi,

can i use aDSO-Corpore-Memory between source 2LIS_03_BX and Target /IMO/D_MMIM01/02? i tried that, but i cant put a flag "Initial Non-Cumulative" on DTP. Some Approach i should reload from History without ECC-Init.

Thanks

[AndreasTenholte]

Hi Albat,

 

this is possible, you just would need to define this aDSO itself as a inventory DSO - which just stores the data from BX.

Then create a transformation between this inventory DSO holding BX data into the two target inventory DSO (hint: this transformation must be direct, no InfoSource in between).

The DTP execution would then automatically process the BX-entries with appropriate RECORDTP = 1 to the target inventory DSO.

This approach is briefly mentioned in SAP Note 2310862

"Another option is to create an advanced DSO with inventory flag that stores only the 'raw' stock initialization data (0RECORDTP = 1) sourced from 2LIS_03_BX with DTP option 'Initial-Non-Cumulative for Non-Cumulative Values'. You can use this advanced DSO as kind of a corporate memory substitute."

Best regards,

Andreas

[rahul_panchal]

Hello Andreas,

 

We would like to show Customer Consignment Stock at each customer level similar to what is shown in MB58 in SAP ECC. Currently in our stock report, we get correct quantity of Consignment Stock at Plant and Material Level, but as soon as we drill down customer, it says no applicable data found. Do you know how we can achieve this ?

 

Thanks in Advance.

[former_member668575]

Hello Andreas,

 

To avoid stopping the ECC for a long time and duplicity of data between historic and delta, what do you think about the stop on the change of day, for example:

I need to load history since 01/01/2023.

1 - Day 23/08/2023 at 23:00 block the ECC
2 - Run MCNB
3 - Run OLI1BW (BF) - 01/01/2023 to 23/08/2023
4 - Run OLIZBW (UM) - 01/01/2023 to 23/08/2023
5 - Run Delta DTPs w/ Flag Init No Data on 24/08/2023 at 0:00
6 - ECC Free
7 - DTP BX "Initial Non-Cumulative for non-cumulative values"
8 - Historical DTP "Historical Transaction"
9 - DTP Deltas

[yi]

It is so sad to see just "former member" instead of the name of the actual person who did a wonderful job with this blog, helped a lot of people, worked very hard for community and now his name is erased. It happened before and it will happen again. That is one of the reasons why I am reluctant to share anything significant on SAP forums.