When a report is started, it's selection screen is presented, a screen which is build up using ABAP statements rather than the screen painter... The difference between screen painter screens and selection screens is sometimes hard to see because of the great number of options that are available building a selection screen.
Screens that are composed without using the screen painter are selection screens. These articles briefly describe what is possible.
What you should do and not do when designing a selection screen ...
- Do Pay serious attention to your selection screen - it should tell a clear tale on the functionality behind it
- Don't forget the message "No data found" - returning to a selection screen without results deserves a message (e.g.
A screen that has input fields differs from a screen used for reporting output... The screen with input fields has a setup with Process Before Output and Process After Input which both revolve around an actual screen object (identified by the screen number).
AbapcadabrA features something easy to use, easy to implement and something that will aid the use of your report application. Add a button - link it to one of the "BLINK" applications from AbapcadabrA and start using it. Even in the development phase, BLINKs can make a difference. BLINK is short for Button Link which can be made available in the selection screen of a report.
Interface reports eat files, or create files. Either way, checking the availability of files in a set directory or physical path is readily available on this blink. The blink application has an indicator for "directories", which also controls whether the end user can browse the system.
Table maintenance blink
The table (tables) that hold settings for your report should be accessible through the selection screen of that same report. Intuitive. This blink or button link caters for easy access to the
SM30 table maintenance transaction. Specify the table and specify whether editing the table is allowed.
Every batch job has at least one step, and such step is effectively a report call. The Batch Job blink is called with a report name and simply calls transaction
SM37 overview of Batch Jobs. The blink application defaults several time spans to select what the end user may need.
Business application logging is a typical interface matter. It tells the tale of an interface run. I personally like the option to only store the application logs that contain errors. Nobody is interested in logs that reveal no issues. The Business Application Log Blink can be set up to list only relevant logs. If there are any.
Most search helps (or matchcodes) offer this neat Personal preference or Personal Values list functionality, where the end user can place entries from the F4 results overview in his/her own personal list. The next time the F4 button is selected on the field, the shortlist of preferenced items is displayed. Of course there is always the option to revert back to the full values list.
Pressing the F4 button to get an overview of possible values is a real winner on any SAP screen: not only does is allow the end user to select from possible values - it also demonstrates what the field is for, which has this clarifying effect on how the system works. Supply in the F4 response for yourselves:
Need to help your end user to a PC file to be uploaded or downloaded ? Here's howThe same F4 processing rules apply, however, there is a function module that will allow the end user to browse through a directory structure to find his/her file, from Windows point of view: The selection screen:
If you need to select a filename from the server, function module
/SAPDMC/LSM_F4_SERVER_FILE can be used. It's output looks a bit outdated (output composed with
WRITEstatements) but it does the trick nicely. Considering that this is not a common user matter (chosing files at the back end shouldn't be) here's an example using a class:
Selection screens are generated from (abap) coding and generally sometimes need a little tweeking to make it do what you need it to do. This article is about such tweek: fetch information that has been typed on the screen, but the user has not pressed "enter" yet.
Selection screens also support listbox or dropdown list selection for parameters. If the number of parameter options is limited (<100) and the user is asked to select a single value (parameter value), the listbox can come in handy. It's all linked to DDIC values, unless you supply your own values. Here's how.
More advanced selection screens can respond to the input on the selection screen and make alternative fields available for input. When a selection screen becomes cluttered with fields that rely on other fields, the link can be made appearant by hiding the fields that are not needed, and making these fields available instantly when they become relevant. Here's how:
The menu that is presented on 99% of the reporting screens is one and the same menu. In the normal life-cycle or a report, it answers all our needs and it requires no changes. Can you think of a reason to change this menu ? If it is some extra functionality you need, simply add up to 5 dynamic buttons, or add as many buttons you like between the parameter fields. Not satisfied ? Read on...
A button on the selection screen or on the selection screen application bar can be "enriched" with an icon. Run the
SHOWICON report and take your pick. The button can also get "Quickinfo" information that is shown when the user hovers over the button with his/hes mouse. Here's how:
When a (any) report is called, information about the actual call can be picked up from your report with function module
RS_SUBMIT_INFO.. Was the report started via the selection screen or maybe as a background job ? Is the
EXPORT LIST TO MEMORY option used ? Is web-reporting active ?
Or would you like to report the values that were entered on the report selection screen ? There's functionality available for that too...