[426] in SAPr3-news
Re: Authority objects and transactions
daemon@ATHENA.MIT.EDU (Wayne Kidd)
Wed Jul 26 18:37:41 1995
To: sapr3-news@MIT.EDU
Date: Wed, 26 Jul 1995 04:18:39 GMT
From: wkidd@netcom.com (Wayne Kidd)
Reply-To: wkidd@netcom.com (Wayne Kidd)
In <nntpuserDCArIs.6zA@netcom.com>, @netcom.com writes:
>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
>
My return address was omitted from my prior message.
/Wayne
