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.

Submit a report from a report. The SUBMIT statement executes a report. Do note the following: when SUBMITting a report that has a parameter and/or select-options screen, you have to indicate that this screen should be used. Add the option VIA SELECTION-SCREEN. to give the end-user the possibility to fill in the selection screen because all selections are dealt with as "filled in already" without this addition.

An example report that will be submitted from another report:

REPORT ZZZZZZZZ NO STANDARD PAGE HEADING.
TABLES MARA.

PARAMETERS CREATOR LIKE MARA-ERNAM.
SELECT-OPTIONS MATERIAL FOR MARA-MATNR.

The report that calls the above report:

REPORT ZZZZZZZX.
RANGES: MATERIAL_NUMBERS FOR MARA-MATNR

MATERIAL_NUMBERS-SIGN = 'I'.           "Including
MATERIAL_NUMBERS-OPTION = 'BT'.        "Between
MATERIAL_NUMBERS-LOW = '000000000000000453'.
MATERIAL_NUMBERS-HIGH = '000000000000000568'.
APPEND MATERIAL_NUMBERS.

MATERIAL_NUMBERS-SIGN = 'E'.           "Excluding
MATERIAL_NUMBERS-OPTION = 'EQ'.        "Equal
MATERIAL_NUMBERS-LOW = '000000000000000462'.
APPEND MATERIAL_NUMBERS.

SUBMIT ZZZZZZZZ
  WITH CREATOR EQ SY-UNAME
  WITH MATERIAL IN MATERIAL_NUMBERS
  VIA SELECTION-SCREEN
  AND RETURN.

Also, if you want your end user to be returned to your program after the SUBMITAND RETURN. Would you like to see the selection screen of the report that is being called ? Option VIA SELECTION-SCREEN.

Call transaction

Call a transaction Using the CALL TRANSACTION statement usually implies "making good use of standard SAP functionality" which should be welcomed. A few nice features on the CALL TRANSACTION statement can be very useful. When calling a transaction, usually some of the information in the screens must/can be filled in advance. E.g. calling the transaction to display vendor information on the vendor number from your report.

There's different ways of handing over information to a transaction:

• Use parameter fields, by setting the system parameter field for e.g. the vendor number, the transaction will pick it up. You could then use the option ... AND SKIP FIRST SCREEN. (which is the reverse of VIA SELECTION-SCREEN on a SUBMIT).
• You could also set up a batch input map that fills in the necessary fields for the selection screen and any other screen that would follow. The internal table that holds the batch input map could then be passed on to the transaction using CALL TRANSACTION xxxx USING bdc_internal_table. This is usually done if there's more to prepare than just skipping the selection screen. Note the possible batch input map MODE's.

When using the batch input map table, the developer could even stop the end user from seeing anything in the called transaction. Storing and leaving could be part of the batch input map too. A new problem that arises is the actual transaction response, it could very well be that something has gone wrong, or that some data from a message that is generated by the transaction is important for you. Retrieving the last message that the transaction has issued is not too hard, the system variables for messages can be used for that (SY-MSGNO, SY-MSGV1, etc.). If that would not be enough, use the addition MESSAGES INTO internal_message_table. This table would hold the full list of messages that were issued during the transaction run. How convenient !

• Prev
• Next