Skip to Content

Rebuild PM Infostructures (LIS)


This subject is of a frequently asked nature and the documentation of knowledge I have on the subject, has been pending since long. When I rebuilt the first infostructure (S070) around 3years ago, my learning started on this.  As you know learning does not happen in a single event, it took considerable time to know about various aspects of LIS rebuilding. I had been replying to queries with the then knowledge I had. I delayed documenting of the same until now, with an objective of content enrichment. The stuff here answers the FAQ, most of our SAP-PM users / consultants ask about.

So the objective is to

Share my knowledge about how I rebuild SAP-PM infostructures whenever need arises.

I understood the LIS tables this way:

  • LIS, namely the Logistic Info Structure is a table having rows with aggregated values of data from regular tables.
  • Means, when users create Notifications, each Notification data is stored in tables such as QMEL, QMFE, QMSM, QMUR, QMMA and so on, as one row for each Notification. Similarly in case of Orders the data is filled in tables AUFK, AFIH, AFVC, AFRU and so on. These are the regular tables I am referring to as.
  • Now about how the LIS is related to these tables? For example my QMEL table is having 10,000 rows of Breakdown Notification, which were created on say 100 Equipments, then the related LIS namely S070 will be containing the summery data for these 100 Equipments month-wise. Means here the rows will far less than 10,000, because these give Equipment-wise totals for a period. Hope you could follow.
  • And then, how this LIS table is filled? Beginners often expect to see the data changes in LIS related tcodes (PMIS reports in our context) as soon as a Notification attains NOCO. But it does not happen so. A standard LIS update frequency is set via tcode OMOS which usually is Monthly. We can change it to as frequent as Daily in these settings. (But it is a rare practice to alter).
  • Here comes the need of Re-build.
    • Suppose there is a business requirement in the last days of a month to see the upto-date PMIS reports on Breakdowns like MCJB, MCJC, MCI4 etc. including the current month then, I would need to update the LIS S070 manually.
    • OR if I doubt inconsistencies in the data displayed by these PMIS tcodes then I would need to rebuild the corresponding LIS.

           In cases like these the present post helps.

  • And most importantly, the rows of a LIS with version value ‘000‘  only are considered for the PMIS reports. (This applies to LIS based reports of other modules also)

The Objects of Re-building Infostructure in SAP-PM:

The tcodes involved here are OLPM  and  OLIX .

Before we see what these tcodes are about, we see the LIS list relevant to SAP-PM. These are:


(Expecting not to receive any queries here on specific LIS of the above list, as this is not the present topic)


  • OLPM is a tcode used to set-up a version for PM Infostructures whose list is shown above. Now we see what is a version in LIS table:
  • A version is a 3char field in the LIS table. Rows with version value ‘000‘  are meant for reports. In the process of rebuilding, often we create temporary versions with values like ‘&(0‘ , &(1‘ .  I repeat here, for PMIS reports only the rows with version value ‘000’ matter. There is no role of rows with version values other than ‘000’  those are existing in the LIS table.
  • Coming back to OLPM tcode, it is a tool to set up a version –> A temporary version or a reports version (‘000’).


Then tcode OLIX is used to:

  • Delete a version from a Infostructure. (Option Delete version)
  • Copy a source version to a Target version. (Option Copy version)
  • Copy a source version to a Target version and at the same time delete the source version. (Option Copy + delete)


OLIX tcode is common across LIS of all SAP modules for the purpose of above listed functions, but OLPM is exclusively for SAP-PM and every LIS of other modules will have its own tcode equivalent to OLPM.

Now about How the LIS is re-built

Suppose I am in a situation already described as an example in the beginning, where I can not wait for OMOS scheduled update of LIS to happen and I need to do it manually say for LIS S070. (Another example situation can be an inconsistency in PMIS reports, which could force you to re-build the LIS).

Step1 OLPM

olpm best practice.JPG

  • Save under version : We gave temporary version name &(0 . In case rows already existing in LIS with this version value, system asks you whether to delete, you should accept this OR you should give a new version name such as &(1 .
  • Number of Parallel processes: Put value 1 here.
  • Block all documents : Better Tick this to prevent creation of more data by users during this re-build, which would not reflect in the PMIS reports. For example during this run with with this Tick, if you create any Notification it will be prevented from Saving by throwing an error message like this:


(It is a different mater that, such Notification numbers are lost forever. You will not find this Notification number in the system. And the next successful Notification number will be a number next to this number. )

  • Now Execute .

My experience here is that this step is the time consuming one. My system takes about 90 to 120 min for this task where the related tables have around 2000K records. Then it displays the information like this one.

olpm info.JPG

Step2 OLIX

Now you are ready with a Temporary version records to be copied to Final version namely ‘000’.

  • As a first step here, use the Delete version option > Give value ‘000’  in the field > Give value ‘000’ in the Source version and Execute. With this act you are deleting all ‘000’ rows from the LIS. If this is not done your present rebuild will double the statistics in the PMIS reports.
  • Now come back to the initial screen of OLIX and click on Copy + delete. In the next screen ensure that you have &(0 your temporary version in the Source version field and 000 in the Target version field. See this picture.

olix final.JPG

  • Now Execute .

This step will not take much time (under 5 min). You get information similar to the above picture in the case of OLPM.

That’s all, the Re-build is complete.


I have experimented the following way by reducing the role of OLIX.

  • First I deleted the version 000 using OLIX.
  • Then I executed OLPM in the same manner as explained above buy with Save under version as ‘000‘ . This means without creating a Temporary version and copying it to Target version ‘000’ in OLIX, we are creating ‘000’ directly using OLPM.
  • I found no issues.
  • But it is believed that above mentioned procedure of Temporary version Copying to ‘000’ version using OLIX is believed to be the Best practice.

I think the job is done and it is time to stop.  Hope members will be benefited with this write-up.

Here is a related post after knowing the above concepts:  Hierarchical Equipment Availability Calculations on F/Locns

Author’s other posts



Comments are closed.
  • Hi Sir,

    Your write-up's are always helpful, no doubt it will be beneficial to all members as need arises.The information what you shared on "rebuild SAP-PM info structures" is quite interesting and thanks a lot for the same.

    Warm Regards,

    PS R

  • Nice document sir.

    when i am running the last step that is copy+delete sysutem is asking for copy method. what kind of copy method should i assign there as there were no F4 help options.



    • Hello Sameer ,

      It was due to wrong option showing in the earlier OLIX screen-shot (last picture of the post)  where an unintentional mouse-click changed the option in the Transformation block. It was showing 'Automatic data enhancement' . But it should be the 'No copy method' which comes by default.

      I have corrected it. Thank you.



  • Dear Jogeswara..

    Thanks .. Straight and simple hitting nail to the point....

    While following your document line to line, word to word, i observed some typo error which i doubt have occured while writing the post. Kindly correct the same:

    * Delete a version from a infostructure. (Option Delete version)

    * Copy a source version to a Target version. (Option Copy Version)

    S070 LIS Rebuild.PNG



    S070 LIS Rebuild.PNG
    • Murad

      Thank you for the praise for the post. I appreciate your keenness in going through the post word to wrod. And thank you for noticing the typo and informing. I corrected it immediately.



      PS: You may Rate the post as well at 'My Rating'.

  • Dear Jogeshwara Sir,

    I had a doubt, Tcode OMOS - where we define update frequency, is it updating the Info Structure automatically or we have to run Tcode OLPM whenever we need to update LIS.

    Secondly, I want to find the program for the Info Structure, how can i find it as user wants to create batch job for updating data in info structure...


    • Hi Shubham

      • In the case of OMOS (standard setting with every implementation), you need not bother about Rebuilding (OLPM etc).
      • In the second query, you are asking about a program which updates the LIS. In our case it is the program which has the tcode OLPM. i.e., RIPMS001
      • In this connection, please go through  a post referred at the end of the this post,  which gives you an idea.



      • Thanks Jogeshwara Sir,

        If i check TCode OMOS, the User defined info structures has "Updates Carried out at  Posting Period" is selected. So it means that Info Structure data will be rebuild on every Period??

        Do we require any batch job for updating info structure separately??



        • Perhaps,

          We need to study it. My standard settings since beginning is Monthly. I observed that also.

          To study your case, take an Equipment and run the MCJB. Keep a screen-shot. Now create a Malfunction Notification on this Equipment and Tick the Breakdown indicator and fill Malfn End date time, and Save the Notifn.

          Now you run MCJB. See the difference. If the output has changed taking into account the newly created Notification, then it shows that it is updating instantaneously. In this case obviously Background job is not required.

          If it is not so, it has got different meaning which we need to understand (through research)



Comments are closed.