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.
MESSAGE s085(v2).)
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.
Most reports have brothers and sisters - which cover a similar task. The Inventory blink is an easy way to compose a group of related reports. A button link will bring the end user to an overview of up to 20 reports.
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.
The personal value list, that is available on most Search Help screens, is a very useful bit of functionality. Use this freely downloadable tool to manage Personal Value List settings for other users too.
Making a selection screen field obligatory, setting a default value, inserting a blank line... Available options listed...
Your selection screen can also be build up with several "views" or subscreens, which can be accessed via a tab strip...
A selection screen has Process Before Output, Process After Input, Process On Value Request and Process On Help Request... This is an overview of processing events that apply to selection screens, in time sequence:
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:
When using a SELECT-OPTIONS, a button appears leading to a popup with lists of single values, ranges, exclusions etc. This popup can be manipulated... It's not vey likely to be useful, but you never know.
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:
Interactive reports are often set up to support someone's daily job, taking your end user to where he or she needs to go by calling the right transaction, or submitting a report.
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...
There are 2 main ways to create (and respond to) buttons on a selection screen and using SET PF-STATUS is NOT one of them...
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...