During one of the workshops when presenting a new solution a following question was asked by one of the key users
Is it possible to restrict visible screen variants for a specific user to a fixed set, when we have lists and radio buttons? Or even better the data screens in the ALV presented afterwards?
That was the first time someone asked me this question or have I ever thought about it. Such simple, yet important functionality especially when you have more than one group of users. However knowing that nothing is to be taken for granted in SAP I couldn’t reply straightaway and went on another learning journey.
I started my research from a standard and a well known point – sap blogs. Here the answer was clear in most of the posts, there is no such functionality in standard SAP. Some people here would say “Hold up a minute, there is SHD0 or S_ALV_LAYR authorization object which may be used in those cases.”, unfortunately both of those have some limitation which in my problem would make the useless. In case of SHD0 it is that we can’t set radio buttons or the subscreen variants [1], while the S_ALV_LAYR would allow us only to stop users from editing/accessing variants in general [3] not exactly letting us pick what should they see as a part of some defined group. However we need to remember that not every requirement presented has to be done the way it is first envisioned. That’s why especially SHD0 shouldn’t be completely crossed out, even in this case if we resort to implementing some additional abap conditions.
Still if we are already into abap and not only configuration play field there are more possible option to achieve what we need. First one is the standard parameter sy-slset [5] which contains the name of variant that was used. With that knowledge + the transaction variant we could do literally everything during start-of-selection, both authorization and data presenting in alv wise. However this would most likely only work in Z report that we have total control of so is there any other possibility? It turns out there might be a quicker way and easier to modify along the way method to get the results if we turn to abap. Every report in SAP can be used with the statement “SUBMIT” [6], for which we can dynamically post a selection screen variant based on additional configuration table. Moreover other data that would’ve been provided by user, could be used to alter the results and present them in ALV as we see fit.
However is that all? After thinking about this topic for so long I actually came up with another idea that I still haven’t tested, so this post might be updated someday. If the standard transaction is just a report that we want to filter we could do the SQ01. It would require from the user to have a little knowledge about the data that is being used and there shouldn’t be any complicated calculations. Such reports could be shared with group of users giving them the set of data they call for, without a need to code a thing. Yet if it is more of an “advance” topic, CDS view could be created for every “variant” that would require proper authorization objects behind it. What’s more both of those can also be called from the abap code in Zreport, giving us another opportunity to reuse them, for example for extracting data to another system if needed. Unfortunately if the transaction have more logic behind, than the data presentation those ideas wont help. That leaves us with last of them, which is writing an enhancement to a standard report with any previously mentioned method to sort the data and hide the fields from structures as we see it fit. However we need to remember that such interference in standard is always tricky when it comes to patches and upgrades to the system, while also being hard to debug afterwards if we run into problems. I believe it should be a last resort method, since it’s not worth the risk behind it, but it could work in my initial requirement.
Conclusion
In the end I didn’t manage to find out a simple configuration way to achieve the outcome that was stated in the beginning of this post. Surly some cases could’ve been modified to fit the standard solutions with SHD0, which would allow us to limit how users interact with the transaction or by giving them some SQ01 reports. Still it looks like there is no better solution than writing, a good old Zreport that would act as an overlay for a standard functionality.
Sources:
- https://launchpad.support.sap.com/#/notes/331360
- Learning SHD0 with Example | SAP Blogs
- https://launchpad.support.sap.com/#/notes/1667238
- Transaction Variants | SAP Help Portal
- https://help.sap.com/doc/saphelp_erp60_sp/6.0/en-US/7b/fb96c8882811d295a90000e8353423/content.htm?no_cache=true
- https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abapsubmit.htm
