Spro full authorization without sap_all and sap_new

Question

Hi Friends,
Can u suggest me how to give spro full authorization without sap_all and sap_new profile.
Thanks & Regards,
Tarun

Answer 1

Hi Gowrinadh,
This is an interesting discussion. I don't mean to take shots at your concept, but I have some concerns about it as a solution.
> I have prepared a role 8 months back, we passed 2 patch upgrade cycles and I can confirm that this role will work even after the next version of ECC upgrade.
Sometimes the symptoms only make themselves visible later, and we don't know what is coming in the next version of ECC. Of course it should be largely compatable, but there will be new stuff. You can be sure of that.
> If there are any modules or new functionalities required, then customer has to request for it in addition.
My understand is that the customer requests a full and working SPRO role for each release. They will not find the tcodes for you and do not want to play ping-pong via support tickets either with it.
So each time you bill your customer for the 20 or 40 hours work for maintaining these tcodes manually in ranges? Appart from being error-prone, this solution is not scalable for when SAP might introduce another 20000 tcodes into the SPRO. Or someone convinces SAP to introduce an S_TCODE check for every line of code the whole system... (this is something which some people seem to believe in...), which would introduce several billion new tcodes for you...
> For which we can build separate role.
That is different. The question here (and certainly your solution) is to have them in the same role without duplicates but still including all SPRO access.
If you build them as seperate roles, then you can merge them as projects into one composite and live with the duplicates while checking for any known objects which should not be included.
I would agree with you. That is in my opinion a better solution, but it is not what you have been describing earlier.
> We can plan for authorizations and build roles based on the inputs for today and tomorrow received from customer.
That is the whole point in having maintainable roles and scalable processes. Manually maintaining 20k tcodes is incompatable with such requirements.
> By the way, the max no of consultants and business process owners having this role is not more than 40.
I don't think that assigning the role to less people will make it more usefull, nor that assigning it to more people will bring down it's per user cost of maintenance.
There is some old code posted here already which does what you have described in less than 1 minute. You can find it via the tables I have mentioned above, and will recognize it (and it's age)  by the header lines it uses for internal tables. But it still works, since about release 3 point something...
Cheers,
Julius