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: 

Transaction SE16 in SOD ruleset?

Former Member
0 Kudos

Dear Experts,

Could you let me know whether do we still need to keep SE16 in SOD ruleset. With SAP Note 1420281, change access from SE16 is removed even if we have edit access for table auth group in S_TABU_DIS. Now it checks for SM30.

We have not assigned SM30 to business users. But change access for custom tables is present in business roles with SE16 access. Do you see this as a SOD issue if we exclude SE16 from the ruleset. Display access to tables is fine for our business and we don't have issue in providing display only access via SE16. But are there any other reasons to keep SE16 active in ruleset?

Thanks in advance!!!

1 ACCEPTED SOLUTION

Former Member
0 Kudos

The note relates to se16n in erp systems and not the basis transaction se16.

They are completely unrelated.

The only thing they have in common is that if the user has the correct authorizations for tables, then you have no real org. level control (it is the whole table..).

S_TCODE is mostly silly in an SoD rule set. Hardcoding tcode checks is more silly and mostly forces you to give the direct tcode access.

If I were you, i would think about the design and create parameter transactions.

If they (business users) really must use SE16N, then use object S_TABU_NAM instead to control the access at table name level.

Cheers, Julius

3 REPLIES 3

Former Member
0 Kudos

The note relates to se16n in erp systems and not the basis transaction se16.

They are completely unrelated.

The only thing they have in common is that if the user has the correct authorizations for tables, then you have no real org. level control (it is the whole table..).

S_TCODE is mostly silly in an SoD rule set. Hardcoding tcode checks is more silly and mostly forces you to give the direct tcode access.

If I were you, i would think about the design and create parameter transactions.

If they (business users) really must use SE16N, then use object S_TABU_NAM instead to control the access at table name level.

Cheers, Julius

m_coenjaerts
Explorer
0 Kudos

If indeed SE16 is restricted to display then i would not include it ithe SoD filterset. As display in general does not cause / contribute to - a SoD conflict.

Julius remarked that

".. S_TCODE is mostly silly in an SoD rule set. Hardcoding tcode checks is more silly and mostly forces you to give the direct tcode access. .. "

but we have S_TCODE as part of our SoD rule set, as the same object itself can be used in several transactions. For example V_VBAK_VKO is checked in several SD related transactions, without being only restricted for sales document maintenance. So if part of the SoD filterset is 'Maintain Sales Documents', we check not only for V_VBAK_VKO and V_VBAK_AAT but also for S_TCODE=VA01 or VA02.

Edited by: M. Coenjaerts on Oct 3, 2011 1:22 PM

0 Kudos

Note that some transactions have "hand made" views to the data. If you double-click the record, you jump into the transaction screen.

Some make checks. Others dont.

Cheers,

Julius