2LIS_03_BX

[Former Member]

Dear All,

Is there a solution to load the stock initialization from 2LIS_03_BX, if it is not possible to block the postings during this initialization (MCNB) ? Since there will be postings during this initialization the stock initialization might be wrong.

Hence wanted to know if its possible to write a custom extractor for the stock initialization, similar to 2LIS_03_BX, but which could have the posting date as one of the parameters, so that the stock could be initialized for a date in the past, so that we do not have to worry about the postings done during initialization.

Tried to go through the code for MCNB, but was quite complex. Hence wanted to know if someone has created such a custom extractor, or knows the steps to get the stock qty and value for a material on a certain date ?

Thanks.

[Former Member · Accepted solution]

Dear Dabre,

I suggest instead of creating a new extractor, create a ODS/DSO and load in overwrite mode. this way you can easily manage and good for any recovery later.

Or try loading using flat files...

For historic moments(using BF) also posting has to be stopped.

Or Instead of pulling BX and BF, you can pull only BF and compress with Marker update, you will get same result(try it out).

Hope it Helps

Srini

[Former Member · Accepted solution]

Hi Srini,

Thanks much for the reply.

I understood the approach that you propose, but in case the data in R3 is archived and hence we may not have all the historical material movements in SAP R3. Hence it might not be possible to initialize the stock using BF.

Hence needed an alternative approach to initialize the stock reading some of the R3 tables which hold the stock at the end of a period. But what are these tables and the logic in computing the stock qty and value using these ?

Best Regards.

[Former Member · Accepted solution]

If you can not access archived database, i suggest, using tcodes: MMBE, MB51, or MC.1, take dump of stock status by providing timeline and load using flat file. We can also access archived database(if data archived in different r/3 system or client).

I am not sure of snap shot status of R/3 tables. check BSEG & MSEG.

or try to debug above Tcodes.

Hope it Helps

Srini

[Former Member · Accepted solution]

Hi Srini,

Thanks again. Even if the material movements are not archived, the issue is loading all the history to initialize the stocks correctly. We have around 400 million records in MSEG and hence we would like to avoid the entire history if possible. Also flat file as well since it might be a bit difficult to maintain this from an administrator point of view.

Yes, inaddition to the transactions mentioned by you another transaction that i found was MB5B which gives the stock qty and value on a given posting day. But again the logic was a bit complex to follow in ABAP and hence thought of asking if anyone has done this before.

Best Regards.

[Former Member]

Hi,

For BX, try to load a plant in the middle of the night when transactions should be low to none. Also, if you have downtime for backups, system maintainance on weekends, see if you can extend the window to cover your initialization. If it still takes a long time, try initializating two or three plants at a time (it should be much faster that way).

For BF, you can pre-load all historical periods from 2 periods back (e.g., today = period 4/2008; load beginning of time up to 2/2008). You can do this on most systems since the current and previous periods are usually the only open periods (meaning you can no longer post a material document in a closed period). With the historical periods pre-loaded, you only need downtime for the current and previous periods. This will save you a major amount of time.

I once chanced a reinitialization over a weekend ... and got very lucky! No postings during a two-hour window. You can find your double postings by running a delta right after your initialization. Check that delta run against your initialization and see if any of the documents are duplicates.

Of course, since I do not know anything about your system, it is difficult to give specific help. Items that would help us out even more are: 1.) How long is too long? 2.) How many Plants? International/single country/single timezone/single plant? 3.) Continuous Operations (24/7) or 9-to-5? 4.) Approximate number of material docs created per month?

Brian

[Former Member]

Hi Brian,

Thanks for the detailed reply. The remark about the previous period postings was helpful.

This system is pretty huge, with live markets all over the world. Hence we are talking about postings 24/7. The last month we had around 16 million records from 2LIS_03_BF. Hence pretty large data volumes.

The issue is carrying out the initialization from 2LIS_03_BX even when there are postings in the system. How can we make sure that the documents used for determining the initialization by 2LIS_03_BX are not included in the delta with marker update. Because of the high data volumes the initializations run for a long time as well.

Best Regards.

[Former Member]

What you can do is identify the quietest time in the system .... say Saturday evening at 5:00pm PST ... and take your chances there or force quiet time.

The only other alternative is to get a mirrored configuration running (2 copies of the same system) which I doubt will happen.

I was very lucky one time over an Easter Weekend .... I chanced an initialization and successfully initialzed without any docs generated ... this definitely was the exception and not to be used as a rule.

You can always clear the LBWE extraction queue (the job that fills the delta queue), stop the extraction job, run the initialization (setup tables), initialize BW, turn on the extraction job.

Then check to see what ends up in the delta queue. Whatever is in there, you need to verify the quanties against what you initialized (Hopefully it isn't a bunch of 100 item material docs!). In other words, before moving the deltas to BW, figure out what material, plant and storage locations are in the delta queue and see if BW's values match R/3, if they don't then you didn't pick up some (or all) of the records in the delta queue. You need to go through this very carefully and identify which records are not needed (e.g., already counted in the initialization). Once Identified, load the delta to BW using the PSA only option. Then go into the PSA and delete those records. Further update into the data targets and then check the quantities again. They should match.

Brian

[Former Member]

Hi Brian,

Thanks for the reply.

Another option that we are currently looking at is to intialize the stocks for a period in the past. This would help in not worrying about the downtime and the backpostings.

Was trying to check the logic how the 2LIS_03_BX tries to get the current stock values. The code seems pretty complex, but does anyone have an idea on how this could be done. Or the logic in extracting the stock values at a given point in time.

Thanks.