Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Re-purposing user master fields in ABAP systems

Former Member
0 Kudos

We are considering a change to our user master data creation process for the PROD clients. Most of the user master data fields are populated by our (non SAP) IdM solution, which has left some fields unused on the address and logon data tabs. We would like to reconfigure the IdM solution interface to populate some of these heretofore unused fields (such as building, accounting number or cost center) with some additional information that is already in IdM, to identify the user by site and company code for reporting purposes. Has anyone done something like this and had a bad repercussion? I can't think of any reason why such a plan would backfire on us, but I've been asked to put the question out there to see if anyone has had a bad outcome or can warn us of a potential pitfall with such a plan.

Thanks,

Gretchen

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Gretchen,

I also do this from time to time, but have a few golden rules which I recommend following:

- Be sure that the field will not be needed for read (address) data values in future.

- The field must at least be populatable by the BAPI import parameter structures.

- Bad sign if BAPI_USER_GET_LIST does not support it.

- Give preference to those suppported by the SUIM ALV grid layouts as well.

- Check whether the field might confuse someone in HR or BP views of the address data.

- If you are going to use any special characters in values, then check the field type first.

- Steer wide of telephone and fax numbers...  🙂

There are many more fields than those displayed in SU01. They can sometimes also be usefull so that it does not look like a flea market on the address data tab.

Another option (if you want the user to maintain it themselves... ) is to use PIDs instead. They can do that via SU3  - but the values in thise case should NOT be security relevant, as they will be able to influence them.

You mention "reporting purposes". Do you mean BW AA auths generated from these values? There is a better way to do that.

Cheers,

Julius

5 REPLIES 5

Former Member
0 Kudos

Hi Gretchen,

I also do this from time to time, but have a few golden rules which I recommend following:

- Be sure that the field will not be needed for read (address) data values in future.

- The field must at least be populatable by the BAPI import parameter structures.

- Bad sign if BAPI_USER_GET_LIST does not support it.

- Give preference to those suppported by the SUIM ALV grid layouts as well.

- Check whether the field might confuse someone in HR or BP views of the address data.

- If you are going to use any special characters in values, then check the field type first.

- Steer wide of telephone and fax numbers...  🙂

There are many more fields than those displayed in SU01. They can sometimes also be usefull so that it does not look like a flea market on the address data tab.

Another option (if you want the user to maintain it themselves... ) is to use PIDs instead. They can do that via SU3  - but the values in thise case should NOT be security relevant, as they will be able to influence them.

You mention "reporting purposes". Do you mean BW AA auths generated from these values? There is a better way to do that.

Cheers,

Julius

0 Kudos

Julius,

Thank you for the tips and suggestions. No, this has nothing to do with BW analysis authorizations or reporting; it is just some internal reporting of user counts by location and business unit, and we can't utilize HR data because contractor users do not have HR records. We would just as soon not have the users maintain it themselves, which is why we hit upon the idea of pulling in their site record from the IdM system.

Thanks again and regards,

Gretchen

0 Kudos

Hi Gretchen,

That sounds like a bit of a "piece meal" use of an IDM system.

Implementations which approach this topic with enough intellect normally try to tap into the HR events for such data and many have externals maintained in HR as well. You need to identify the "leading system" for such events and make sure the pot is maintained centrally and not redundantly.

For example, what about Infotype 0027 if you are using address data for reporting? It will never tie up if you have even one admin assistant or consultant working somewhere in the mornings and somewhere else in the afternoons...

I would seriously reconsider maintaining all entities (also externals) as HR records and trigger the basic provisioning from there (Directory server groups, badges, unique IDs, address data...). They might even have a different contract type or rate from 12:00 onwards... 🙂

Cheers,

Julius

0 Kudos

Julius,

I agree completely that HR would be a more reliable source of this data and more elegant solution than an external interface, but as I said, the contractor users do not have HR records, and there are a lot of them. I had already suggested to management that it would be helpful for all SAP users to have HR records, but up to this point, the "powers that be" seemed disinclined to go that route, apparently for some reason of legality/ regulations. I appreciate your well reasoned suggestions and will certainly share your recommendations; perhaps coming from an outside consultant, your confirmation of what I had already suggested will get it some further consideration.

Cheers,

Gretchen

0 Kudos

You are welcome to show them this discussion thread and participate even, instead of hovering around in the shadows of current project restraints and "intellectually renewable" historical project planning...  🙂

Cheers,

Julius