Hi Jitendra
As mentioned, you will not get that in a report as security cannot be easily calculated that way. You would need to develop your own repository of what constitutues the access as ACTVT is not the only indicator.
I've mentioned this above: Transactions will call programs, tables, etc. Within each, there will be underlying code that will contain the authorisation check. Some of these will contain multiple checks - several objects required with ACTVT and other fields to grant the access.
At best - this is complete fuzzy logic - you could try the following. This would be (again at best) an indicator of access but will contain false positives and you may also miss other scenarios.
- TSTCT - Transaction Listings Tables
- TSTCA - SE93 additional check for transactions
- USOBT_C and UBOX_C for Check and/or Check Maintain - SU24 data
- Combine the above 3 tables to use as the baseline for the potential minimum access to execute transactions
- UST* tables mentioned before for user access - compare the tables combined against the above. to see if user has access
Problems with this approach:
- You are relying on consistent and correct maintenance of SU24 data in your analysis
- You are relying on all change access being based on transaction driven. Therefore, you will not get
- Call Transaction Scenarios
- Access via Menus (e.g. go into transaction ME23N for display purchase order and switch to Change or Create - takes you into ME21N or ME22n if you have the underlying authorisation)
- Access to transactions via SE38, SE37, etc - other ways to access
- Webdynpro access or RFC calls
- Your report results will be multiple results for each transaction definition. This would make it difficult in Query to compare transaction information against user authorisation information.
What you are trying to produce is not achievable via direct tables querying without adding context to it. By producing such a query (which even if you were going to attempt, I'd be looking at a program for performance and access restrictions) for audit you are going to imply this is an accurate report.
A better alternative would be to look at GRC Risk Analysis and Remediation (or similar product) to configure rule sets that you can run analysis again. If not, look at the critical authorisation configuration to build up your own checks
But as I have now said several times, you cannot accurately create a report via tables joins of Transaction Code, ACTVT and User ID. SAP authorisation concept does not work that way.
Regards
Colleen