SU25 - Step 2B Missing changes

[former_member218822]

Dear All,

We are upgrading our system from R/3 Enterprise to ECC6.0. After the upgrade in the development system, I have run SU25.

In Step 2B, the transaction SM59 was not showing in the list of affected transactions but during the testing we found out that it would require S_RFC_ADM which has proposal as yes and the object is start as well.

Need your help to find out ways of finding this kind of changes. Thanks for your help.

Regards,

Aswin

[Former Member]

It uses date and timestamps and the name of the modifier to add those new SAP proposals which do not interfere with your existing proposals (the ones you made).

These are added already in step 2A and in earlier releases this was actually automatically run during the upgrade programs so you cannot prevent it.

You can analyze these by checking the versions in SU22 which relate to your current upgrade, but SAP makes the assumption that you would accept everything which you had not maintained something else for yourself.

Cheers,

Julius

[former_member218822]

Hi Julius,

Thanks a lot for your time and wonderful explanation which resolved my doubt. I will compare the old(prior upgrade) and new(after upgred) USOBT tables for new assignments by SAP.

Thanks,

Aswin

P.S: I have marked the question as answered and awarded the points as well.

[Former Member]

Because of this, as you can imagine, SAP are very carefull with removing proposals.

You must put a lot of thought into adding proposals and often it is best to make some "mass decisions" locally in the implementation (in SU24 you can also choose the "authorization object" tab to perform mass maintenance - tip: document the ones you tune here as it is easier to do it here than in SU25 in some cases).

Unfortunately SAP GRC was to lazy to work out for themselves what all the transaction's capabilities are, so they bolted onto SU24 field values as a capability indicator. Very stupid decision in my opinion, as it forces SU24 to make field value proposals for a transaction where you actually want to make the decision in the role you are building.

Classic examples are SU01 and PFCG. They can also be used in display mode and many ABAP list reports offer navigation into them, but they propose excessive activities simply so that analysis works.

What I mean to say is that if SAP proposes something silly (such as activity fields for transactions which are multi-activity capable) then you should report it to SAP and ask them to remove it.

Probably they wont. but irritate them none-the-less because they know that you are correct...

Cheers,

Julius

ps: In your specific example this is coming from SE93 for SM59 (table TSTCA). You need to at least be able to display in SM59 otherwise starting the transaction does not make sense. But proposing actvt '03' makes no sense as it is not re-usable nor can the decision be made in the role anymore. On the other side of the coin, proposing '03' makes a '*' less likely. SU24 is an art-form....