Transactions for display roles -opinions?

[Former Member]

Hi,

I'm currently designing display roles with following requirements:

- 1 display role per module (FI,CO,SD,MM,PP)

- display rights should be as broad as possible

So far I've listed all transactions TCD's for FI that clearly indicate "display" activity (e.g. FAGLB03 - Display Balaces (New)).

In addition to these TCD's there are quite a few reporting transactions (S_ALR..) that could be categorized under display

(e.g. TCD's under Accounting > Fin. Accounting > General Ledger > Information System)

Do these S_ALR transactions pose any security threats that should be considered?

Any opinions about including these S_ALR transactions under Information System to display roles? Any experiences and comments are greatly appriciated.

[Former Member]

Some of them are entry points to very powerfull functionality. Generally there are more powerfull checks AFTER having started the transaction.

I guess your real question is whether you can do this: S_ALR*

?

Cheers,

Julius

[Former Member]

Hi,

S_ALR*...that's probably the basic question, although I would still like to pick the transactions individually -> so no need to include e.g. unnecessary country-specific reports in the display role.

For testing purposes I assigned TCD S_PL0_86000030 - G/L Account Balances (New) to a testuser and noticed that one needs quite extensive FI authorizations to be able to use it.

Then the question could be: should these kind of transactions be placed in a display role in the first place if users with limited authorizations are not able to use them?

Or if user can start the transaction, but not execute it any further due to missing authorizations, would there be any harm? This would need to be probably tested in combination with transactional roles.

I'm trying to keep this as simple and straightforward as possible, as I have a feeling that I'm not going to get much support when taking the design to transaction level..

So I would rather have one display role for FI than separate display roles for GL, AP and AR although not all transactions would be useful for all the users.

Edited by: Viljam on Jan 11, 2010 12:43 PM

[Former Member]

Good.

> For testing purposes I assigned TCD S_PL0_86000030 - G/L Account Balances (New) to a testuser and noticed that one needs quite extensive FI authorizations to be able to use it.

Some transactions will need a lot of authorizations to use, but only propose (su24) a subset of these.

My interpretation of this is that they are not meant to be used "on their own" but rather in combination with another or a set of related transactions.

> Or if user can start the transaction, but not execute it any further due to missing authorizations, would there be any harm? This would need to be probably tested in combination with transactional roles.

Try to keep the menu and the authorizations in the same role if you can for ease of maintenance and identifying where the authority is coming from (and needed for).

If the tcode is in the menu but should not be used, then you will confuse the user and will be in a "catch 22" in SU24 at some stage.

Cheers,

Julius

[Former Member]

Thanks for helpful answers, Julius!

My interpretation of this is that they are not meant to be used "on their own" but rather in combination with another or a set of related transactions.

Yes, seems to be so.

Try to keep the menu and the authorizations in the same role if you can for ease of maintenance and identifying where the authority is coming from (and needed for).
If the tcode is in the menu but should not be used, then you will confuse the user and will be in a "catch 22" in SU24 at some stage.

This makes a lot of sense.

I'll move the S_ALR/PL0/AC0.. transactions under corresponding functional roles (GL, AP, AR) for now, keep only the designated display transaction codes (document, account balance & master data display) in the FI display role, start from there and see/test how that plays out.

Design is still at "excel"-stage, so role scope changes are easily made

Just out of curiosity (and a bit for benchmarking), what would you Julius and other experts include in e.g. FI-display role if you had free hands? If I remember correctly Alex was talking about "display role per function" in Role Design sticky.

Not looking for a list of transactions, but in more general terms if it is possible e.g. would this "display role per function" include S_ALR/PL0 transactions?

This is my first role design assignment, therefore elementary-level questions... Thanks in advance for any input!

[Former Member]

Yes, you certainly can include S_ALR* transactions in a display role if you want to. Many of them can be launched from the menus of other transactions anyway.

I have 20 of these in my FI key user role here, but not all are visible in the menu (Add transaction). The not visible ones are either pulled in from the SU24 proposals for the transaction (this will cover some of the requirement and is best practice IMO for those which you always want) or added as tcodes to be started from report trees (in PFCG use the "Authorization Defaults" option) which adds them to S_TCODE but not visible in the menu.

If they are special ones to be started from outside of the report tree, then add them to the menu.

This is the general rule I stick to.

For "display only" you should anyway be concentrating more on the application objects than the tcodes for the user. Make sure those tcodes don't pull in more than you want, because then the proposals are either too strong (or emtpy) or your choice of transaction is doubtfull.

Cheers,

Julius

[Former Member]

>

> Just out of curiosity (and a bit for benchmarking), what would you Julius and other experts include in e.g. FI-display role if you had free hands? If I remember correctly Alex was talking about "display role per function" in Role Design sticky. 
> Not looking for a list of transactions, but in more general terms if it is possible e.g. would this "display role per function" include S_ALR/PL0 transactions?

Hi Viljam,

As a latecomer to this interesting thread everything I would say has already been said

A display role per function is one way of doing it, in that respect it can contain all reporting required out of R/3 - that includes relevant S_ transactions (which aren't always display). It really depends on the data and how sensitive it is and also how the business is aligned. Some companies work in very silo'd (is that a real word?) environments along the lines of modules, others work on a process area (e.g. Order to Cash) that run across multiple modules. If your design supports giving wide display access then how you build it will align with how the company is organised.

Good luck!

[Former Member]

Thanks again Julius!

"The not visible ones are either pulled in from the SU24 proposals for the transaction -- or added as tcodes to be started from report trees (in PFCG use the "Authorization Defaults" option) which adds them to S_TCODE but not visible in the menu

So, if (S_ALR or other?) transaction can be executed through another t-code, it is ok to have it as "not visible". If t-code is pulled in from SU24 proposals I don't need to add it in the role's menu tree (best practice), otherwise t-code can be added (as not visible) to menu tree with "Authorization Defaults" option.

A few questions:

- How/where can I assess which t-codes can be executed through other transactions and therefore can be made not visible?

- And further, how to check which t-codes are pulled in from SU24 proposals and which are not?

- Could you give me an example as I'm not sure I understood this correctly?

For "display only" you should anyway be concentrating more on the application objects than the tcodes for the user. Make sure those tcodes don't pull in more than you want, because then the proposals are either too strong (or emtpy) or your choice of transaction is doubtfull.

I'll intend to do that, but I'll have to determine first the transactional scope of the role. If this role can be given to other than FI users as well, then I'll have to exclude the S_ALR* transactions from it and keep them in FI-functional roles.

Then one more general design question:

- Is it common practice to assign e.g. FI-display role to users of other modules? Or will I run into problems with authorization objects?

[Former Member]

You are starting to loose me a bit here in what you are building over there..

But a well known example would be transaction SUIM. It pulls in about 50 other tranactions.

Another one is ME22N. You cannot use CALL TRANSACTION variants for it without granting the ME22N itself - so some folks "hide" it as an authorization default within the role and then skip maintaining the SU24 proposals for the variant transaction.

Cheers,

Julius

[Former Member]

Thanks for examples!

I'll try to clarify (to myself as well) what I'm after.

Aiming to build simple functional and display roles:

- High-level functional roles for FI, CO, SD, MM and PP

- Display roles for each of the modules above

Scope of functional transactions is quite well defined, but I started to mull over the contents of display roles. And FI-display role was as far as I got.

I think the basic question now is:

- Do I want /is it good and common practice to assign display roles across modules e.g. to give FI-display role to MM users?

This could effect the design of display roles as:

1. If display roles are assigned across modules, then probably don't want to include e.g. FI -related S_ALR* t-codes to FI-display as users without strong FI authorizations cannot really use of them. Therefore display role would include only designated display transactions.

2. If it is common to have FI-display only for FI-users, then I could include at least some e.g. FI -related S_ALR* t-codes in the FI-display role.

Does this make any sense?

[Former Member]

>

> Thanks for examples!

>

> I'll try to clarify (to myself as well) what I'm after.

>

> Aiming to build simple functional and display roles:

> - High-level functional roles for FI, CO, SD, MM and PP

> - Display roles for each of the modules above

>

> Scope of functional transactions is quite well defined, but I started to mull over the contents of display roles. And FI-display role was as far as I got.

Hi,

In my opinion there is nothing like a high-level role and a lo-level role, so i would first forget about describing the role and think on the content

For a start, there is no easy way to build a role that covers a complete module other than trying to include node strucutres and make a judicial judgment (with some hit and trial tests) to make sure the role does what it should do.

If you have a specific set of transactions on the different domains (FI,CO,SD.....) build the functional roles and i would prefer to build seperate reporting roles. Reporting role for FI, Reporting role for CO, Reporting role for SD..........

coming to the content of the reporting role, as i mentioned functional inputs and judicial judegement are important, you can build a reporting role for displaying G/L Accounts (thats fair) but you might not want to incude the Cash flow (S_ALR_*) transactions in it, thats for you and the functional team (the stakeholders as a whole) to decide

Coming to the tricky part - printing of documents could be considered to be a normal job (or) it could be looked at as a critical task based on what you want to print. So including all S_ALR_* transactions in a reporting role might not be a good option - you can print cheques and cheque books with the access

I wont put my head on the block - but the SD and MM reporting roles can be a relatively easier job than the FI and CO ones

In any case, time and effort on the machine are crucial, design on excel can take us only .......so far

Good luck and do let us know when you build the roles, could be a good learning for all of us

[Former Member]

If you want to build high level roles for functions (people) within a process then forget about "modules" and "object classes" for authorizations. They needs to model their process and tell you which transactions they want the functions to be able to start, or have to start otherwise they don't get paid

They must provide this information to you, together with which behaviour the different functions are to expect after having started the transaction or navigated further from an report list, etc etc. Some might be display all behaviour for certain objects (like masterdata) and others more complex with various activities for combinations of fields (e.g. S_ARCHIVE) and will take you longer. But they are all in the same role, needed for function to be able to support their part of a business process.

Now... if you do not have the time and they do not have the patience to give you this information and together you cannot have productive project meetings (which is sometimes the case...) then build roles per module in activity layers (e.g. FI display reporting, SD post transaction data, MM maintain master data, HR config key-user, BC admin guru etc) and mix them into composite roles to assign to the users. Add a cup full of "delta roles" for spice and a dash of manual profiles to round off the bitterness.

Voila! Role flambée...

Some companies even offer "out of the box" roles, with SOD and GRC jargon. You can go that route as well, but it means that some brainstorming session about transactions in a workshop far away is dictating your business processes to you. Personally, I am sceptical about this. User experience is not good, at the expense of keeping "out of the box" auditors happy...

Cheers,

Julius

Edited by: Julius Bussche on Jan 13, 2010 8:20 PM

[Former Member]

Hi Shekar and thanks for input.

What I meant with "high-level" roles is that I'm going to build bigger singles and not composites. So, I would have "GL Accountant" as a single role instead of having Task role1 + Task role 2 + Task role 3 + Task role x = GL accountant.

If you have a specific set of transactions on the different domains (FI,CO,SD.....) build the functional roles and i would prefer to build seperate reporting roles. Reporting role for FI, Reporting role for CO, Reporting role for SD

You mentioned you prefer to build separate reporting roles. Would you include display t-codes in your reporting roles or have separate roles for displaying?

I would like to combine "reporting" and "displaying" to one role, so that role combination for company's "Bookkeeper" = "GL Accountant" + "FI-display".

You also mentioned critical tasks such as printing of cheques. I wouldn't include all S_ALR* t-codes in my FI-display role, but e.g. relevant transactions from Information System nodes of GL, AR, AP (e.g. AR > Info system > Reports for AR > Customers: Items). The reports identified as critical could be placed in proper functional roles.

I wont put my head on the block - but the SD and MM reporting roles can be a relatively easier job than the FI and CO ones

I surely hope so

In any case, time and effort on the machine are crucial, design on excel can take us only .......so far 

You are right about this. However, I would like to have some sort of plan on paper before I start.

[Former Member]

>

> Hi Shekar and thanks for input.
> 
> What I meant with "high-level" roles is that I'm going to build bigger singles and not composites. So, I would have "GL Accountant" as a single role instead of having Task role1 + Task role 2 + Task role 3 + Task role x = GL accountant.
Hi Viljam,
Thats exactly how i have in "our" environment
> You mentioned you prefer to build separate reporting roles. Would you include display t-codes in your reporting roles or have separate roles for displaying?
This is again a matter of choice and to be honest i have reporting roles that have display transactions, my role design was more by trial and error and one that was learnt (am still learning) on the way. The problem that could be is in convincing the stake holders and the auditors to make them understand that the information system roles are not ALL about S_ALR_ transactions but also do include display transaction because of a few dependencies......ex: Vendor reporting role could always have FBL1N transaction, logically it makes sense and if it showcased with conviction, i am sure it should be ok.
> I would like to combine "reporting" and "displaying" to one role, so that role combination for company's "Bookkeeper" = "GL Accountant" + "FI-display".
that is exactly what i do 
> You also mentioned critical tasks such as printing of cheques. I wouldn't include all S_ALR* t-codes in my FI-display role, but e.g.  relevant transactions from Information System nodes of GL, AR, AP (e.g. AR > Info system > Reports for AR > Customers: Items). The reports identified as critical could be placed in proper functional roles.  
That should be a good start and the way to go.....
> You are right about this. However, I would like to have some sort of plan on paper before I start.

Now that you have a plan, just build a role for Bank information system .......creating roles is fun .......so have some fun & share it with us - Good Luck

I couldnt manage to format it properly, so excuse me for that

Edited by: Shekar.J on Jan 13, 2010 11:00 AM

[Former Member]

If you want to build high level roles for functions (people) within a process then forget about "modules" and "object classes" for authorizations.

Yes, high level roles for functions is what I'm trying to build, so I'm not worried about giving cross-module authorizations when needed. (e.g. FI accountants need to check "stock in transit" from MM).

They needs to model their process and tell you which transactions they want the functions to be able to start, or have to start otherwise they don't get paid 
They must provide this information to you, together with which behaviour the different functions are to expect after having started the transaction or navigated further from an report list, etc etc. Some might be display all behaviour for certain objects (like masterdata) and others more complex with various activities for combinations of fields (e.g. S_ARCHIVE) and will take you longer. But they are all in the same role, needed for function to be able to support their part of a business process.

Now this is more problematic. Processes have been mapped to some extent, but specific information about t-codes and wanted behaviour after t-code is started is not provided. I'll have to rely on functional consultants' suggestions which may not always reflect the real needs of the end-users.

=> I think the design/build is going to be such that the goal is to build roles for functions, but as there is no time/input for more detailed design, t-codes for roles have to be assigned more loosely (only critical functions separated). Composites are out of question already.

[Former Member]

A display role per function is one way of doing it, in that respect it can contain all reporting required out of R/3 - that includes relevant S_ transactions (which aren't always display). It really depends on the data and how sensitive it is and also how the business is aligned. Some companies work in very silo'd (is that a real word?) environments along the lines of modules, others work on a process area (e.g. Order to Cash) that run across multiple modules. If your design supports giving wide display access then how you build it will align with how the company is organised.

Only some of the data is classified as sensitive (prices, margins), so wide display rights are no problem. I would say that the organization is not strictly "silo'd", so cross-module activities are done.

What I'm still wondering is this:

I build e.g. FI-display role that contains also all non-critical S_* t-codes (from GL, AR, AP) and because display rights can be wide I can assign it to all Finance people without problems.

Also as most of the data is not classified as sensitive, Sales personnel would like to be able to display some FI-AR reports, e.g. customer's payment history. But, because they're lacking needed FI authorizations, they're able to start the transaction but not go further.

So, is it common that users use only reports they get from their "main" module?

Or if sales people feel that FI-AR reports would be useful, but lack authorizations, how should these be cases be handled?

I think the design of roles/functions is already quite process-like, but these display-dilemmas keep throwing me off.

Maybe/hopefully this problem is related mainly to FI-reports..

Julius, Shekar and Alex, thanks for the dialogue so far, it has been most helpful!

Edited by: Viljam on Jan 14, 2010 9:09 AM