You might be faced with the task to create a really comprehensive user listing for a SAP system with several productive clients – even including 000 and 066.
This is usually a boring task, as you have to log in to every client… gather the list… proceed to the next client… and so on…
Apart from dying of boredom you might run into the problem of not having access to all clients (e.g. 066). 😕
Write a report like this:
REPORT. TABLES: usr02. SELECT * FROM usr02 CLIENT SPECIFIED ORDER BY mandt. WRITE: / usr02-mandt, usr02-bname. ENDSELECT.
Pro: Easy, simple, fast.
Con: Has to be transported, protected… and using "CLIENT SPECIFIED" is considered bad code by many companies!
Use the report RSUVM005, which is intended for system measurement: it gives you a list of (almost!) all users on the clients you specify on the selection screen.
Still the list is missing a few users, because SAP quite rightly considers them irrelevant for licensing — they are automatically filtered out by the report (or more specifically: by the function module SLIM_EXCLUDE_USER):
|SAP client||Excluded user|
|( all other clients )||ALEREMOTE|
To get the comprehensive user listing, we just need a cross-client selection for those excluded user names in addition.
Fortunately you can simply achieve this via tcode SM21 and (mis-)use the "User" field to check for the existence of the missing users on other clients.
Now you can compile the cross-client user listing from within one client…
let's have a look at a very handy system parameter, which is nevertheless not checked as frequently as others in audits — the tp parameter VERS_AT_IMP.
In a default installation this parameter is set to »NEVER«, which means that no new version is created when transporting a program to a target system; the code is simply overwritten there.
If the parameter is set to »ALWAYS« (which is the only other valid option), a version history is maintained analogous to the development system.
Btw.: not only reports are affected by this, but actually all workbench objects that support versioning.
Why does that matter?
The legal codes of many (all?) countries prescribe a duty to preserve records, which is also relevant for program code – the German HGB (Handelsgesetzbuch) for instance. Therefore it is a risk to allow old program versions to be deleted (due to a lack of knowledge – or on purpose).
Developers are usually allowed to execute all reports on a development system, which also includes RSVCAD03 and RSVCAD04. These reports allow the deletion of a program's version history (they're NOT assigned to any program authorization group
and the program code does NOT contain any AUTHORITY-CHECKs ← read comments below).
Update: Meanwhile SAP has added an authorization check for S_CTS_ADMI with value TABL to both programs. Anyway, this authorization is checked in many places and chances are high that a number of users have (and need) this authorization for other purposes. So this does not change the general recommendation of this article…
So your options are:
- if you want to keep the version history on the development system: do whatever it takes to secure RSVCAD03 and RSVCAD04 (just removing S_CTS_ADMI from all roles will not work, especially on non-productive systems) and be careful when restoring the system; you might lose versions (think of reinstallations)
- set VERS_AT_IMP to »ALWAYS« on the productive system and keep your version history there (of course the above reports have to be secured as well)
As you probably guessed, the second option is favorable, because:
- authorizations on production are much more limited, so protecting the reports RSVCAD03/04 is much easier there
- the continuity of a productive system can be ensured, while this is not true for a development system
Where to check it?
Start report RSTMSTPP, enter the productive system's SID and go for it.
Where to set it?
Go to STMS → System Overview. Then double-click in your productive system and switch to the "Transport Tool" tab.
If the parameter does not appear there, it is set to the default value »NEVER«!
Update: Effect on installation of support packages
Switching the parameter to ALWAYS has no automatic effect on transaction SPAM. In other words: installing support packages does not lead numerous (useless) versions of SAP standard objects.
The simple reason is that SPAM allows you to choose whether to create versions of the objects in support packages or not (→ disabled per default).
To enable it, setting VERS_AT_IMP to ALWAYS is a prerequisite — check out SPAM → Extras → Setting → Import queue → Create object versions during import — but be aware that this might have an impact on performance and database size.