What is the impact 2LIS_03_BF first than 2LIS_03_BX?

[Former Member]

Hi,

During init of Inventory Cubes, two extractors are actively

involve (2LIS_03_BF and 2LIS_03_BX). But the question is are they interchangeable? Can BF go first then BX or it should be strictly BX first than BF???

--Jkyle

[Former Member · Accepted solution]

Hi Jkyle,

2LIS_03_BX replaces the function of datasource 2LIS_40_S278 and is used to extract the stock data from MM (and not from the tables MSEG or BSEG) for initialization to a BW system.

Instead, 2LIS_03_BF is used to extract the material movement data.

When you want to use both extractors (inventory management with non-cumulative KF), you have to start with the opening balance, that is with 2LIS_03_BX !

Take a look to the doc in www.service.sap.com/BW -> SAP BW InfoIndex -> How to... Handle inventory management scenarios in SAP BW 3.x (pdf) in which all stock init procedure(s) and scenarios are explained in detail.

Hope it helps !

Bye,

Roberto

[Former Member · Accepted solution]

Hi Roberto,

Thanks for the answer...Anyway, I have already read that PDF "How to Handle Inventory...". I followed them as instructed and it worked fine. I am just curious on whats the effect if I load BF first than BX because we are doing some testing in our DEV BW and it so happened that BF was processed/loaded first than BX. I have not checked the results yet but as you have said, its strictly BX before BF...

I'll give you 10 points for that...

I have another question. Can I run the BX Setup Tables (MCNB) process in parallel with Material Movements Setup (OLI1BW) in R/3? Do they share the same tables??? Will I extract wrong data if I do this???

Thanks a lot!

--Jkyle

[Former Member · Accepted solution]

Hi Jkyle,

MCNB and OLI1BW can run together without problem (as already mentioned, BX doesn't work on MSEG and BSEG tables...).

However, take a look to SELECT statements into ABAP programs behind setup transactions to have a better view of the entire process...

Hope it helps !

Bye,

Roberto

[Former Member]

Hello Jkyle,

the BX loads a SnapShot of a certain stock from R/3.

BF loads the movements.

BX can initialize the delta.

The delta is loaded after this via BF!

The V2/V3 booking needs to be stopped via loading the BX, so no movement can be created in R/3 to ensure the data quality.

This is the reason, why the BX should always loaded BEFORE BF!

Kind regards

Michael

[Former Member]

Hi Michael,

I am interested on your statement "BX can initialize the delta" ??? How? The only option that is available when loading BX is "Generate Initial Status"

Only BF has the DELTA Update Options...

Please enlighten me...

--Jkyle

[Former Member]

Jkyle,

I think that terminology used by Michael was not so correct, but I'm sure he was well-meaning...

BX 'initialize' stock balance and not the movement delta mechanism (that depends only from BF and related LBWE procedure)...

PDF document explains very well this scenario.

Bye,

Roberto

[Former Member]

Hi Roberto,

Glad your online. We have a different time its 5:00 PM here in the Philippines and I bet its early morning in Europe...

Good Morning to you...

Going back to this topic, I had a bad experience with the SETUP of SETUP TABLES of BF and BX. I have run them simultaneously and I ended up with BF extracting zero (0) records.

I dont know what happened. Are you sure you can run them simultaneously?

--Jkyle

[Former Member]

Good evening to you, Jkyle!

MCNB runs an ABAP program, RMCBINIT_BW, that extract data from S278, BF extractor doesn't refer to this table, but to material movements ones...I'm searching for any related documentation, but nothing...

if you have the possibility to test something, you can run MCNBV and see what locks system generates...

Bye,

Roberto

[Former Member]

Whilst the previous comments are all useful, my answer to the <b>original </b>question is that it doesn't actually matter in which sequence you do the BX and previous movements' BF loads, so long as you compress in the correct sequence and with the 'No marker Update' set correctly (set ON for prior movements, so that the marker is NOT set - be careful ) AND you stop movements (as mentioned).

So you MUST compress each load seperately, because you need different 'No marker settings' for each of the above.

I found it made sense to load these in parallel, to limit downtime.

Incidentally, I have found a problem with this method:

If a material has only movements prior to the cutoff date, and no stock, then there is no marker <b><i>IF</i></b> you use BX 'only transfer with stock'. A query only on this material will not return any results.

OSS is working on this and should be issuing a correction tool (I'm waiting .....)

[Former Member]

Hi Daniel,

Actually I already tried this; to load them in parallel. However, The BX Info Package issues a WARNING to me that the cube already contains data (because BF extraction is ongoing) and the warning seems to inform me that I am doing something wrong...With that experience, I decided to abort the loading process (since it is not the way described in the PDF document) and we might end up wasting the logn loading time...

--Jkyle

[Former Member]

Hi Daniel,

Another weird thing happened. As you have said, BF and BX can go inside the CUBE in any order. I tried loading BF. While it still loading, I load BX. Of course a WARNING popup saying the the cube is not empty....Now they are running in PARALLEL.

Of course BX will finish first than BF. I tried compressing the REQUEST for BF, guess what happened? The BF was also compressed even I specified the request number of BX.

Thanks for any advice...

--Jkyle

[Former Member]

You are right. I reread my procedures, sorry I was not precise.

You can <i>extract </i>in parallel, and <i>load </i>to the PSA in parallel. But you must load from the PSA to the cube and compresss (with the markers as I mentioned) ONE AT A TIME, to avoid what you noticed happening (or at least with the same 'no marker update' per run).

This is becasue the 'no marker update' flag is not a setting for each load, but is a setting that is fixed for the cube(you set/reset it each time you change it) that can also be transported (for example, if your system is non modifiable, you have to transport the setting). So any compression is done with the current setting.

I also found this out the hard way (which is why I'm pleased to write this to help you)!