[423] in SAPr3-news
Re: Authority objects and transactions
daemon@ATHENA.MIT.EDU (@netcom.com@bloom-beacon.MIT.EDU)
Wed Jul 26 11:57:24 1995
To: sapr3-news@MIT.EDU
Date: Wed, 26 Jul 1995 00:18:28 GMT
From: @netcom.com@bloom-beacon.MIT.EDU
Reply-To: @netcom.com@bloom-beacon.MIT.EDU
In <3v3ob2$fnd$1@mhade.production.compuserve.com>, Scott Barden <100632.1334@CompuServe.COM> writes:
>I think we are sometimes too hard on SAP. I mean how can we
>expect SAP to deliver the R/3 system with the security system
>already set up, they have no idea on your companies structure,
>decentralised or centralised management, cost centre hierarchies
>etc. All they can do is to provide guides like the
>pre-configured profiles.
>
>I will admit that they could provide clearer pointers to the
>authorisation objects that each transaction uses.
>
>As for the trace being time consuming (which is true) I still
>believe that this would be quicker than running SU53, when done
>with a user with full security. Why? Because one trace will
>pick up all the auth. objects tested to complete some transaction
>whereas (if I interpret correctly) SU53 should only give you the
>one auth. object which failed the authorisation check, fine if
>there's only one object in the transaction (yeah right!).
>
>Regards, Scott Barden.
I believe that the best place to start to unravel this situation is the implementation
guide. If you open the complete version, there will be a environment section in
each application area. After you have addressed the authorizations in each section,
you will need to build a seperate section for basis (there is very little help in the
basis area). Start with business function profiles and roll them together with
the basis stuff into composite job profiles. Then assign people to job profiles.
/Wayne
