How to get when SAP object last used or not used

[nirmal15joshi]

Hello All,

Our business want to delete the RICEF object which are not used from last 6 year or not usable and set as a dead object like FM include.

Can any one tell me how we can identify that type of object or can create custome report to identify that type of object.

[horst_keller]

I think, there are no timestamps for development object usage. I'm afraid, you have to use the coverage analyzer SCOV.

https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abendead_code_guidl.htm

[matt]

In a productive environment, you use UPL (aka SCOV-Lite) for object usage. The statistics from STAD are not safe to use as a basis for decommissioning.

[Jelena]

This question has already been asked many times on SCN before. Google -> how to identify unused code site:sap.com

Other than what Horst said there are very limited options.

As a side note - why 6 years? If something has not been used for more than a year then it's most likely dead weight. There could be some annual reports that run literally once a year. Anything else would be used more frequently, if at all.

[matt]

To determine use of development objects in production, you use UPL which is a kind of SCOV-lite. This creates data that is extracted into cubes on SOLMAN, where there are various standard queries and reports.

What you need to look at is Legacy Custom Code Management Cockpit in SOLMAN. It's well documented. Start here for example.

I have succeessfully and safely removed thousands of unused objects from client systems using these tools. It is the only workable solution. Solutions based on the statistics in STAD are not safe.

You cannot, however, determine objects that haven't been used for six years until you've been running UPL on that system for... six years. There is no possibility of retrospective analysis.

[kiran_k8]

Matt,

Thanks for confirming that you used it and it works.

Your confirmation carries a lot of weight.

K.Kiran.

[matt]

I built an entire tool set for removing objects from a supplied list in excel. It also had options for backing up the objects before deleting, just in case they needed to be brought back in a hurry.

One of the problems I encountered is that a program change might be on its way to production, for a program that hasn't been used for over 14 months. If that's the case, you don't want to remove it. There are ways of mitigating the risk.

[pokrakam]

Instead of removing, add

ASSERT 1 = 0.  "Todo: Obsolete? 28.06.2018

Leave for a nice long time.

No dumps -> Delete.

[Jelena]

"Sometimes it's easier to ask for forgiveness than for permission". 🙂 I've removed some unused objects without any SOLMAN or SCOV, just asked around and used common sense. If it turns out to be needed just put it back. So far I've been wrong maybe 1-2 times in 10 years. That's not a worse score than any technology-based tool.

[matt]

Unless usage data has been gathered for six years, there's no chance,