Create Substitute Users in SAP ECC 6.0

[Former Member]

Dear Gurus,

Can someone guide on how to create a temporary user Substitute User) in SAP ECC 6.0. This is a user who will only use the SAP system for a short period while the substantive user is away on leave such that the system should lock the substitute user automatically when the leave preiod expires.

regards,

Chansa

[Former Member]

Hi,

If I understand you query properly you want to create a user in the system who will be using it for short time only and you want the ID to be disabled after some time. If thats the case then when you create the user in SU01 then under Logon Data tab you have option to provide the valid from and through date for a user which will allow the user to use the system during the mentioned in there. User will not be able to login to system after the valid through date expires.

Regards,

Sharath

[Former Member]

Consider the actual user

User - 1

and the substitute user

Sub -1

User transaction Su01

fill in User-1

copy it to Sub-1

change necessary attributes ( like last , first etc... )

put the validity end date ( after this date sub-user will not be able login )

[Former Member]

Hi

If I understood the question correctly you need somebody to 'fill in' for another person whilst they are away or on holiday?

There is the option to use reference users in SU01 - see the roles tab for the field reference user (above the roles entry fields).

To make this work the person 'away' has their user master set to user type 'Reference' which disables their logon should they come back so you need to account for this in the process. Once you have set the absent user to Reference go to the covering user ID and, in the role tab, enter the away user ID.

The covering user picks up all of the accesses that the absent user has as well as their own accesses. This is good and bad - the covering user now has two sets of access/roles and most probably thousands of SoD conflicts but it does the job if absolutely necessary.

If you have GRC RAR then you will need to set the checkbox for Reference User to YES in order to report on the combined accesses.

Another (preferred) option, if you have GRC and SPM activated is to set up a 'firefighter' user ID instead which will log (except for table entries) the transactions processed whilst logged on as a firefighter.

[Former Member]

The advantage of the reference user here is that it can encapsulate all sorts of spagetti roles and manual profiles into one unit for you to assign, and it does this without loosing the user ID context of the substitute so there are no loss of variants, PIDs, break-points, check tables and validations, queries, scheduled jobs, spool access, QA step approvals,dual check on sensitive master data fields, etc, etc...

All in all, you should not have more SOD conflicts this way and at least know exactly what you are adding without having to make an admin out of the user ...

I will be presenting a session on exactly this topic at the TechEd 2010 in Berlin, if you are there and interested.

Cheers and welcome to SDN,

Julius

[Former Member]

Hi Julius

Very valid points on the PID's etc - hadn't thought of those!. One thing I did notice about the covering user performing tasks on behalf of the away user is that some postings/printed forms (i.e. purchase or sales orders) were showing the away user ID as the person creating the entries.

Seems that, if the covering user doesn't have the authorisations in their UMR and has to fall back on the reference user's roles, it shows the reference user ID instead. I'm not really sure if there''s a way around this as it may cause some questions internally but may benefit the business as the supplier/vendor etc think they are still dealing with their original contact.

For small user groups, when one person is covering for another absent user in their user group then there shouldn't be any increased SoD figures (as long as reporting on org levels hasn't been activated in RAR) but we have found many instances where the covering user is either a team leader or similar which tends to increase SoD. I've just checked on transaction SM20N which I didn't know about until reading a thread on SDN yesterday - knew the flakey ST* transactions - looks very nice as it shows used tcodes per user when filtered. Pity it doesn't seem to work by user group but not bad at all...

Can't make the Berlin conference unfortunately but thank you for the welcome to SDN.

Kind regards

David

[Former Member]

> Very valid points on the PID's etc - hadn't thought of those!.

A lot of things are easily overlooked when designing substitution or emergency user procedures.

> Seems that, if the covering user doesn't have the authorisations in their UMR and has to fall back on the reference user's roles, it shows the reference user ID instead.

This would be very application specific and is not "mainstream". Where you can use it is with WAPIs (Workflow Application Program Interfaces) and BatchInput has been much the same for decades already.

> I'm not really sure if there''s a way around this as it may cause some questions internally but may benefit the business as the supplier/vendor etc think they are still dealing with their original contact.

On the backend you still have the created by and posted by fields for many application documents (all else being the same - which I would not rely on...).

> For small user groups, when one person is covering for another absent user in their user group then there shouldn't be any increased SoD figures (as long as reporting on org levels hasn't been activated in RAR) but we have found many instances where the covering user is either a team leader or similar which tends to increase SoD.

This is often because the user ID is changed (to a service user) when entering the "special mode". So access other user's (namely back to your own) spools, jobs, variants, layouts, work items, queries, office messages, etc etc is needed, and these are generally protected by strong administrator authority-checks. These will in combination provide many SoD conflicts or usually over-riding system admin access which makes the application restriction pretty weak in comparison.

> Pity it (SM20N) doesn't seem to work by user group but not bad at all...

It does via naming conventions, but is backward compatible for those already logging SAP* user and expecting no entries, which would then become all users starting with the name SAP... See Rz11 param rsau/user_selection (default is "off").

> Can't make the Berlin conference unfortunately but thank you for the welcome to SDN.

You can keep an eye out for "SDN Hacker Lunch" in the news streams. After the event, I normally put the infos and discussions together into a blog on SDN.

Cheers,

Julius