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: 

Too many duplicate objects coming while adding Tcode through MENU

Former Member
0 Kudos

Hi All,

We r using SAP ERP central component 5.0.After adding any standard T-code from the SAP menu, i am getting so many open fields along with the existing objects.particular tcode picking up all the objects related to it.It is consuming lot of time to delete all the open objects before doing generation and user comparisions.If i don't adjust all the open objects, sometimes end user will be able to access delete acitivity as well.

can someone guide me how to avoid this duplicate object entries while adding tcode.

Pls do the needfull.

Thanks in advance.

Regds,

Gadde.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Gadde,

You can define what authorization objects need to be under "Maintained" or "Check and mentained". Those objects defined under "Check and maintained" status those will appear when you add a tcode.

Use SU24 to check objects for a tcode which are in which state. Those you dont want to maintain, remove check mark from "CM" and put check mark under "C"

You will find below 4 states in SU24 for a tcode:

U Test status not specified Checking authorization object (as in 'C')

N Authorization object not checked under transaction

C Authorization object checked under transaction

CM Authorization checked under transaction and

the specified field values are proposed in the Profile

Generator.

Thanks,

Sridhar M

29 REPLIES 29

Former Member
0 Kudos

Hi Gadde,

You can define what authorization objects need to be under "Maintained" or "Check and mentained". Those objects defined under "Check and maintained" status those will appear when you add a tcode.

Use SU24 to check objects for a tcode which are in which state. Those you dont want to maintain, remove check mark from "CM" and put check mark under "C"

You will find below 4 states in SU24 for a tcode:

U Test status not specified Checking authorization object (as in 'C')

N Authorization object not checked under transaction

C Authorization object checked under transaction

CM Authorization checked under transaction and

the specified field values are proposed in the Profile

Generator.

Thanks,

Sridhar M

0 Kudos

> Use SU24 to check objects for a tcode which are in which state. Those you dont want to maintain, remove check mark from "CM" and put check mark under "C"

Do NOT do this unless you know that those objects are not being checked in the code for the program/transaction.

You should maintain SU24 for the auths that are required for each transaction. Where there are values which can differ and need populating dependent on the role then leave them blank. If you do this properly then the number of blanks and duplicates will be massively reduced.

Former Member
0 Kudos

Gadde,

Maintain SU24 to pull through the correct default values (or blanks) for the transactions you are using. This will greatly reduce your maintenance burden & it generally accepted good practice for this (and other) reason.

Under one of the menu options in the authorisations maintenance screen there is the option to merge authorisations, this may help to reduce some of the duplicates, but until you maintain SU24 as recommended, you will always get this problem

Bernhard_SAP
Employee
Employee
0 Kudos

Hi,

I suggest, not to touch the SU24-settings unless you really know, what you are doing....

The behaviour of pfcg is described in detail in note #113290. When merging the authorization data, the t-codes of the role menue are compared with the SU24-settings and the existing authorizations in the profile of the role. Depending on the status of the authorizations (especially status standard and maintained) new&/additional authoriaztions may be added/removed automatically.

Please note, that if you simply delete these additional authorizations, which have been added during the merge-process. they will be re-added at the next merge-process (expert-mode->read old status and merge with new data, or automatically after a change in the menue has been performed).

If you want to avoid this re-adding, o NOT(!) delete these additional authorizations, but simply set them to inactive without changing them. The will then not be re-added, as they exist already (no matter of their inactive status). I know, that the note is not easy to understand, but the merge-process is quite complex and follows a bundle of rules to work consistently.... I hope this helps a bit to understand the 'strange' pfcg.... rgds, Bernhard

0 Kudos

Hi Bernhard,

Thanq very much for ur valuable suggestions.....and the note is also helpful...few points taken from it...

i agree with u regarding SU24....reason is honestly i have never user the same.....

i have simulated ur scenario in DEV box, its working fine.....but every time(while adding new Tcode on request of core user) if u keep on disable the newly added objects,there will be plenty of them....to which i guess takes much time to save and generate....is there any other possiblity to avoid this(not through SU24).....

u / anyone ' s feedback on this will be much more helpful and <removed_by_moderator>...

Rgds,

Gadde.

Edited by: Julius Bussche on Dec 30, 2007 8:21 PM

Rewarding points is entirely up to you. If you promise to reward points, then chances are good that you will get spammed with help.sap.com links by one or many of the "SDN robots"... we try to avoid that here in the Security forum

0 Kudos

Why keep om adding TRX to this role, just create a new one and give this to the users as well.

0 Kudos

It might be desirable for users to only have one role (in addition to a "common role for all users"). This way SoD analysis can concentrate on analyzing authorizations within single role designs, without the added complexity of doing role to role comparisons.

Just a thought.

Julius

0 Kudos

Julius

Although i mostly agree with you i do not see why keeping all TRX in one role makes it easier to analyse contents of roles on users. If the audit on SoD is done by people with the right knowledge of SAP that will not be an issue!

My main issue here was that someone has problems with a role, when adding TRX everytime and thus the question arises if it would not be better to split the role up, leave the troublesome role as it is and add any new TRX to an new role. Making maintanance easier.

If for whatever reason there is a need to make it one role again do this at the end of the process,

In the whole of the discussion i am also worried about the remark "every time i need to add a TRX on request of the core user" If so many changes are made in TRX assignment I do hope this is based upon a GOOD process description amd not ad-hoc (nice to have this TRX as well?).

Anyway this are my two pennys worth of thoughts about this issue.

0 Kudos

Hello Auke, Gadde and others,

This is not the first thread about role design and SU24. If you search for [hit AND by AND a AND bus|?] then you will see that folks have disagreed with me before... (correctly so)...

>

> Although i mostly agree with you i do not see why keeping all TRX in one role makes it easier to analyse contents of roles on users. If the audit on SoD is done by people with the right knowledge of SAP that will not be an issue!

I was an auditor for many years, and making sense of who has which access is hard enough (user analysis). Making sense of why they have this access is even more dificult (role design analysis). Changing it is the most difficult of these related tasks... Yes, with "the right knowledge" you can do almost anything, that does however not make it easily comprehendable for others to maintain and understand - which is more important for business process software platforms than what it is for Interpol, CIA, M15 and other protected processes...

>

> My main issue here was that someone has problems with a role, when adding TRX everytime and thus the question arises if it would not be better to split the role up, leave the troublesome role as it is and add any new TRX to an new role. Making maintanance easier.

There is no comment here about this being a troublesom role. On the contrary, a transaction added to the menu is pulling in (again!) activities which are not required.

My understanding of Bernhard's post is that if the original authorization had been inactivated, then those same authorization values would (when merged) have found that they are not desired, when merged on the authorizations tab of the same (single) role...

This also implies that the functionality of that transaction is already there in the role, however the user cannot access that transaction directly by entering the transaction in the ok-code field.

An alternate option would be to maintain that transaction as a value of object S_TCODE for the core transaction in SU24, but then it would not be in the role menu. Most likely the user does not need the transaction code anyway if the authorizations were already there... it might just be a training issue?

>

> If for whatever reason there is a need to make it one role again do this at the end of the process,

I assume that you are referring to composite roles. As an auditor I detested them, and many admins learn to do the same (sometimes as a result of audits). If the same (new or old) role is included in a multiple of composites, then an adjustment to it will be more complex, have a greater testing effort the likelyhood of unexpected loss of authorizations in other business processes is greater.

>

> In the whole of the discussion i am also worried about the remark "every time i need to add a TRX on request of the core user" If so many changes are made in TRX assignment I do hope this is based upon a GOOD process description amd not ad-hoc (nice to have this TRX as well?).

Personally, I think the business process which this role is enabling is at least equally, if not more important, than the authorizations process.

There is no doubt in my mind that the authorization contents and description of a single role is closer to the role owner's skills and the business process, than a conglomorate construction of single roles (possibly clubbed into a conglomorate of composite roles).

>

> Anyway this are my two pennys worth of thoughts about this issue.

I don't think that "right and wrong" designs are being questioned here... but I did over-exagerated your statements to make a point about adding more roles. So I raise you 2 more pennies and would like to see your cards

Kind regards,

Julius

0 Kudos

Julius

i am not a big fan of composite roles, but have learned to live with it as i worked with a number of clients that i started with after go-live so i had no choice. But I am also against BIG single roles (for maintenance reasons) and see other options than to go to the lengthly process of having to change this troublesome role over and over again:

1 never do a merge again on this kind of roles, only use the deactivate function on the yellow objects.

2 get the process finalised before ever changing the role again, so enter all missing TRX in one go.

3 create a new singel role add all new TRX in there and when finished create a new role adding all TRX of both roles and fill in as much values from the old roles as possible and only after that either deactivate the yellow objects or learn to live with open values.SAP will work both ways!

any other option i have forgotten??

I have always done audits based upon my own table downloads or making use of an official tool based upon table downloads, then it is very easy to compare all trx in all roles a singel user has!

And on the process: yes that is troublesome adding so many trx in a later stadium of the desgin process, one could only go back and tell the designers that you will not continue working on this role untlill they have come to a final design (read final list of TRX)!

so two more penny's spend.

0 Kudos

> 1 never do a merge again on this kind of roles, only use the deactivate function on the yellow objects.

I find merge can be useful when cleaning up junk roles, though no replacement for doing it properly from the start and maintaining SU24 etc.

0 Kudos

i do not know how to do this quoting-action-thing, so here goes manually:

Auke,

having only 1 (more or less) big role may be a part of a design which i actually appreciate. if using HR-ORG to show the organization and populating your users on level 'position' it's very transparent and clear if you have only one role attached to one position thus describing not only the authorizations within SAP but also the work required by the position.

Add a single Basis-Role which mostly contains SBWP and such and can be (again: using HR-ORG) derived over the whole structure(s) you are actually improving maintenance by legion!

Attach all of that to a CUA and let ALE rule and you will have as little maintenance as you could possibly wish for.

Edited by: Mylene Euridice Dorias on Jan 3, 2008 3:22 PM

0 Kudos

Mylene

I agree that it looks like less maintenance but consider this:

• Smaller roles can be used across multiple function thus limiting the total number of roles can have a dramatic impact on the total maintenance effort. When designed the right way.

• The discussion started with the question what to do about the large maintenance effort when a big role needs additional TRX.

I all of my experience I have never seen a situation where BIG roles were leading to less maintenance actually it was the other way around, small roles are easy to maintain and that effort is much more laborious that the user maintenance part regardless if you do it directly in SU01 or via HR.

If however you want only one role on a position (some companies do,but why???) you could go for composite roles leaving the singles small!

Edited by: Auke Visser on Jan 3, 2008 4:45 PM

0 Kudos

Auke,

again i'm too thick to find this quoting thing so:

[quote]

If however you want only one role on a position (some companies do,but why???) you could go for composite roles leaving the singles small!

[/quote]

a big role (per position) is avoiding redundancy of transactions in various smaller roles where they could easily have different values on object level. therefore IMHO they are much more transparent (to me).

0 Kudos

>

> a big role (per position) is avoiding redundancy of transactions in various smaller roles where they could easily have different values on object level. therefore IMHO they are much more transparent (to me).

particularly so, considering that...

>

> This also implies that the functionality of that transaction is already there in the role, however the user cannot access that transaction directly by entering the transaction in the ok-code field.

I agree that the transaction is better off in the same single role, as it does not sound to me as if it is adding access to new functionality. It is merely adding an additional (direct) navigation path for the users with the already existing and assigned role (with active and inactive authorizations already maintained - see Bernhard's post).

-


>

> again i'm too thick to find this quoting thing so:

There is a "tool bar" at the top of the "Plain Text Message" box with 6 buttons. Click on the far right button "Quote Original".

-


0 Kudos

Hello Mylene,

Thanks for ur reply..

As u said :

a big role (per position) is avoiding redundancy of transactions in various smaller roles where they could easily have different values on object level.

I totally agree with u.....actually i have faced few problems with small roles, which have different values at object level....

so in our company we made Z roles(we have removed 4.0B profiles as well) to make the auth. process easier....

above point is also one of the reason behind raising issue...

Regarding composite roles, we use only for ESS users only...

so for core/end users we r maintening one common role for all users and one Z* roles.....so in our scenario we have to maintain 2 roles along with ESS roles(if users were eligible)..

I can't create small roles everytime(to make process easier)...

In this earlier posts, i was suggested to disable to yellow objects with without deleting.Even i have simulated this scenario in DEV environment by keep on adding T-codes through MENU, the result is same...new objects again adding even with the disabled ones....

any suggestions r still welcome....

Thanks in advance to all....

Rgds,

Gadde.

0 Kudos

Gadde,

I still believe that when done the right way small roles are to be preferred. And when done right there should not be many different roles with the same TRX, only when functionality is to be different , but then you actually want different roles.

About your other remark, there is something wrong with your system, if as you say, when not removing the objects (deactivating or leave them open) you go in again and they appear again.

Pls test this. Go into the role (do not add TRX) deactivate the object with open values. Generate the role. Go out again and open the role, are any new object coming up?? If it does not happen now, but it only happens when you add TRX than it is normal behavior. And in that case the only solution is to stop adding TRX until the designers have made up their mind and finalized the design

0 Kudos

Hi Auke,

As per ur 1st paragraph , u may be right.But in our scenario we r not allowed to create too may roles.

As per ur 2nd paragraph , it happens only when i add new T-codes(including customized , Z*) through menu.

Rgds,

Gadde.

0 Kudos

Then it is normal, as this comes in via USOBT_C and you just will have to live with it. One thing you can do is check SU24 for each trx to be added before adding it to the role so you will have an idea what will change.

0 Kudos

>

> There is a "tool bar" at the top of the "Plain Text Message" box with 6 buttons. Click on the far right button "Quote Original".

> -


thanks Julius. sometimes i need a little more help than others

0 Kudos

>

{> I still believe that when done the right way small roles are to be preferred. And when done right there should not be many different roles with the same TRX, only when functionality is to be different , but then you actually want different roles.

>

Auke, you're always suggesting the 'done right' part. this is how it would ideally be but this does not compare to reality. so why not make things easier for even the ones who do not exactly know what they are doing and constrain them to a single role where a transaction code, entered a second time would do no harm.

as for this re-appearing 'insert objects' problem. there are various notes on that topic - this feature needed a lot of improvement. look at these 322817, 113290

(and yes, one day i'll find out how to insert hyperlinks )

0 Kudos

Mylene

I think one of the reasons for this forum is to hear from others how it can or should be done.

That is the goal of my advise, so if you need help in doing things better we are allways here to advise. If you could come to the SAP Courses there is a change you and i could meet as i am also a teacher with SAP.

Edited by: Auke Visser on Jan 4, 2008 5:04 PM

0 Kudos

>

> (and yes, one day i'll find out how to insert hyperlinks )

Fourth button from the left (three chain icon), enter the URL and the "Link Text title" then click "Insert link".

A nice weekend and happy 2008 to all!

Julius

0 Kudos

Auke, i do not think that i need help. i'm doing authorizations in SAP for 14 years now. started out with R/2 4.3G to 5.0B; did it in R/3 in 3.0F, 3.1I, 4.5A, 4.7 and now ECC 5.0. i saw composite profiles come and go as well as composite authorizations. i'm dearly fond of using one role per position, attaching it to HR-Org and running ALE scenarios with a CUA. this is one of the vastest improvements i would grant to SAP they have achieved. if ever asked for a concept, i would go for that again.

0 Kudos

Mylene

Sorry, i misunderstood what you were writing. We are on teh job for aprox the same period then.

I did not like a number of things also when it cam on (like the profile gernerator when it did not work in teh first version it was in), but i have learned to live with a lot of things wehn i was forced to work with it. Coming in to projects that were to far down the road to change them. (the customer would not want this) so i had to learn the good things of it all.

And i discovered that small roles and derived roles combined in composites could save a lot of time in the TCO.

0 Kudos

>

> Mylene

>

> Sorry, i misunderstood what you were writing. We are on teh job for aprox the same period then.

>

> I did not like a number of things also when it cam on (like the profile gernerator when it did not work in teh first version it was in), but i have learned to live with a lot of things wehn i was forced to work with it. Coming in to projects that were to far down the road to change them. (the customer would not want this) so i had to learn the good things of it all.

> And i discovered that small roles and derived roles combined in composites could save a lot of time in the TCO.

In my experience it saves time in ramp up at the expense of ongoing maintenance, administration and monitoring. That approach also fits the business process methodologies adopted by most consulting firms. It also reflects the common situation where clients have not spent time identifying the job requirements correctly and at point of golive need a flexible solution which can be quickly met by use of composites.

Personally I prefer to build at a high level but not necessarily 1 role for a position. Situations are different at every client so rigidly advocating one method as correct might not meet requirements.

0 Kudos

Happy new year and sympathies all round

I have not been around (in SAP) for as long as 14 years, but my first experiences were also in R/2 systems (back in the days when SAP was only a finance system and "auditors" were assumed to be the "Big 5" (since ~ release 6.40, the "Big 4").

Indeed, things have changed...

>

> It also reflects the common situation where clients have not spent time identifying the job requirements correctly and at point of golive need a flexible solution which can be quickly met by use of composites.

At all releases, a symptom of a (business process, including finance) maintenance mess are the "User Access Request forms"...

=> Manager 'A' requests a new user 'B' with "the same position (i.e. copy user...)" as colleague 'C', who started as a rotating apprentice back in R/2.

Go figure why some finance and logistics folks know so much about the system... Not necessarily a bad thing (not at all!), but if the role design and assignments (in the systems) are transparent and auditable (both for auditors, administrators and managers who own the roles) then the concept has a better chance of remaining intact during the post-implementation and -upgrade phases.

Former Member
0 Kudos

As a suggestion I'd say not to delete the objects but just disable them. This will keep them from being added in the future. The problem is if you delete the object and then edit the role in the future and choose the "change authorization data" button this will just read SU24 and pull all those objects into the role again.

If you disable the objects and choose "Expert mode for profile generation" instead you would then choose "read old status and merge with new data". Then the objects will not be pulled in again unless the new transaction brings them in.

Dave wood

Former Member
0 Kudos

Thanks to all for your valuable responses.