Where-used list in PFCG

[Former Member]

Hi,

I have a question about  where-used list for authorization objects in PFCG.

I have a transaction that in SU24 it shows some authoriztion objects (for ex F-02), but when I do enter the tcode into the role it adds  some authorization objects which do not are part of the tcode in SU24 (F_BKPF_BED.  However if I click on the object where-used list its shows that belong to that tcode (F-02) but with FB05 in the colum of Original.  What exactly this does mean?  Should the I do add the value of FB05 in the user profile or should I inactivate the object.

Please some help,

Many many thanks,

Yolanda

[Private_Member_69416]

Hi Yolanda

In your example F-02 and FB05 are connected to the same program but different screens.

You can safely deactivate all default authorizations objects you don't need in role.

Standard tools like SU53  or ST01 will help to see if you were right.

Regards

Przemek

[Former Member]

Are you sure about this...?

Don't you think it might rather have something to do with parameter transaction inheritance, or magic? (I have not tested the magic yet either).

Cheers,

Julius

[Private_Member_69416]

Hmm About what?

If transactions are connected to the same program there is always some inheritance.

or

Deactivation unneeded/wide default authorization objects is good start for working with authorizations.

Fact -  I'm not sure if defaults should be taken from other transactions (even related)  but magic can be explained as error.

Regards

Przemek

[Former Member]

Actually both seem a bit magical to me..  🙂

There are 105 transactions which all start program SAPMF05A in SAP (FB01, FB02, FB03 etc etc), but they each have their own proposals in SU24 and there is no inheritance.

If the proposals of a transaction is obviously incorrect or incomplete, it should be adjusted in SU24 and not deactivated in each role while keeping an eye on SU53. That is not scalable and looking for trouble with users.

The origin of the field original in the where-used-list is that parameter type transactions (those with an entry in table TSTCP) will pull their own SU24 proposals as usual, but additionally they pull the proposals of the "original" parameterised transaction as well if the parameter transaction does not have a proposal of it's own.

This is for example why all parameter transactions in SPRO using SM30 as "original" to call the view, will propose open fields for S_TABU_DIS until you maintain the correct value for the parameter transaction (which then overrides the "original" from SM30). Also here, deactivating the open proposal of S_TABU_DIS in all roles is not the correct solution.

Cheers,

Julius

[Private_Member_69416]

Thanks for explaining original field.

If you fill SU24 you will lack of some flexibility and have more effort with change management rules in your corporation. So I will go my path.

Deactivating give you the way to tell the system I don't need another proposals for object default filled like this.

Do a test for SPRO and SM30 and S_TABU_DIS deactivation.

Regards

Przemek

[Former Member]

Przemyslaw Gapinski wrote:

Deactivating give you the way to tell the system I don't need another proposals for object default filled like this.

That is true.

But when it makes sense to maintain SU24 then it should be done. There is plenty of room for such sense in SU24 and it makes the roles more robust and you have where-used-list in the first place.

But I agree that it is a matter of methodology and best practices. SU02 and SU03 also still work (on the other end of the scalability spectrum).

Cheers,

Julius

[Former Member]

Hi Premylsaw and Julius,

Many thanks for your comments.

Since we are in the testing phase of the singles roles, and during the testing the tcode did not use those 'inheritance objets' we decided to leave them inactive in the rôle.

Many thanks Julius for your clarification about the parameter transaction inheritance.

Cheers,

Yolanda.

[Former Member]

Hi Julius,

Could you tell me why did you mentioned SU02 and SU03?

Thanks,

Yolanda

[Former Member]

I have one more clarification about this.

In another tests the same tcode called for others 'ineheritance objects', then I just think that is a matter of testing ans see how the tcode/program behave.

Many many thanks,

Cheers,

Yolanda.

[Former Member]

What I meant is that SU02 + 3 are very far removed from best practices, but they are still there and used by some folks.

Cheers,

Julius

[Former Member]

Przemyslaw Gapinski wrote:

Do a test for SPRO and SM30 and S_TABU_DIS deactivation.

But then the parameter transaction won't work as it need S_TABU* authorization.

The trick is that the parameter transaction knows which parameter it is passing -> SU24.

Then you only have "originals" for "common stock" objects and can do it centrally via the core "original" transaction to scale it.

I normally maintain SE16, Sm30, Sm34 etc with a "dummy" proposal to signal in the role that a parameter passed is missing in Su24. Set S_TABU_DIS to dummy for '03'. S_TABU_NAM for dummy to '02'. You will find then (or they are okay and not needed - no need to deactivate. Works for me.

Once you have mastered Su24, and maintained it well, it becomes very easy to build and maintain roles.

Cheers,

Julius