Rebuild PM Infostructures (LIS)

[jogeswararao_kavala]

Friends,

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

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

OLIX

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)

NOTE:

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

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

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.

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

Note:

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

jogeswararao.kavala/content

Regards

KJogeswaraRao