Thanks for your inquiry. Before going into the detailed answers, some general remarks: The roles delivered with Snow Optimizer are sample roles, designed to enable quick implementations and not restricting certain functionalities of the product - as the suffix _ALL also implies. If a customer wants to restrict the functionalities or limit them to be used by specific users only, he will need to create his own authorization roles, as it it also the case with SAP standard functionalities.

• S_B TCH_ADM with value Y (should only be assigned to Basis Administrators) Why is this needed?

To be able to schedule batch jobs is an important requirement for a lot of functions in the Snow Optimizer. In addition to that, we offer

the so-called Master Job feature which requires, at least for an admin-type user, the mentioned authorization.  

• S_GUI with value 04, 60, 61 (04 is never used. 60/61 can´t be restricted to certain files so would apply to all files in the system = risk)  Why is this needed?

 Certain functionalities in the Snow Optimizer require up- and download of files from/to the PC desktop.

• S_ALV_LAYO with value 23 (this allows you to maintain global lay-outs) Why is this needed?

 Most reports in the Snow Optimizer use ALV screens. We didn't want to restrict the ability to create layouts for other users.

• S_DEVELOP act 03 for object type SUSO (authorization objects) Why is this needed?

 You will notice that this authorization is automatically included if transaction SU53 is assigned (which is part of our role /DYNAM/MASTER_ALL). It can be regarded as uncritical.

• S_RFC: please provide function modules, not function groups so we know exactly which RFCs are being executed.

We don't do this because in the course of development of the product we often need to add or remove function modules called by RFC. Using function groups instead of individual function modules in the authorization role greatly reduces the need for customers to update the satellite authorization roles with every update of the product. We have customers with hundreds of connected satellite systems - for them this would be unacceptable. If you absolutely need to avoid the use of function groups, we can support you, but we don't recommend this approach.

• S_TABU_CLI: should not be used as it allows cross client maintenance. Why is this needed?

 Snow Optimizer needs to read some client-independent system configuration data. 

• S_TABU_DIS: we will only use S_TABU_NAM so please provide table names, not groups.

 The same argument as for S_RFC applies here.

• Role DYNAM/SATELLITE_DATA_LOAD allows user maintenance. Please clarify why this is needed. What kind of users are in scope of this?

The mentioned role doesn't allow user maintenance, only displaying user data (activity = 03) is authorized. However, the role /DYNAM/SATELLITE_UPDATE allows the change of user master data. This is mainly needed to update the license type of the users to support SAP license audits, but also to maintain some others relevant user master data fields for licensing purposes. BTW, we support restricting the changeable fields by our own authorization checks.

• Role DYNAM/SATELLITE_LAW_CENTRAL_RFC: please clarify what the LAW system is and what kind of data are you transmitting between SNOW optimizer and the LAW system.

 LAW is the "License Administration Workbench" transaction from SAP. This is to support the regular license measurement from SAP.