Passing data between selection screens

[maqsood_ahmed]

Hi all,

I have created 2 selection screens in 2 different Report programs. I figured out that the possible ways to access data between them is by using abap memory . Now if i want to avoid this , how can i achieve the same?

I do not want to have 2 reports. I am just looking for possible solutions.

Thanks,

Maqsood

[Former Member]

TVARVC is designed to contain this kind of data.  That's my first thought.

Neal

[Former Member]

Hi Maqsood,

My sugg.

ABAP Memory - Export and Import Statements

or

Use SET and GET parameter IDs.

BR.

[Former Member]

It depends on what you want to achieve. Do you want to call report 2 from report 1, and skip the selection screen? Or you want to access data from report 1 in report 2?

There are several solutions. You can use a CALL TRANSACTION .... AND SKIP FIRST SCREEN..

using a BDC table with pre-filled parameters.

Or use a SUBMIT (calling a abap program).

Another way is to make a class, and store data in its attributes. This data you can then access from both programs.

Also, the SET and GET parameters are a valid option.

[Former Member]

  Use SUBMIT with selscreen_options.

When using SUBMIT, you can fill the selection screen of the destination
report:

SUBMIT
{rep|(name)} [selscreen_options]

                    [list_options]

                    [job_options]

                    [AND
RETURN].

Use the :

... [USING
SELECTION-SET variant]

    [USING SELECTION-SETS OF PROGRAM
prog]

    [WITH SELECTION-TABLE rspar]

    [WITH expr_syntax1 WITH expr_syntax2
...]

    [WITH FREE SELECTIONS texpr] ... .

See all on the F1 help.

[maqsood_ahmed]

How about if i

• make a subscreen area in a main screen
• initially embed the selection screen1 in subscreen area  
• when the user tries to goto next screen(say F8 in application toolbar ) i will replace the  subscreen area  with selection screen2

This way i do not have to worry about data transport between 2 selection screens and can have both selection screens defined in the main screen as subscreens. Kindly let me know if this will have any future implications . Customers would add more fields to the selection screens based on customization settings dynamically.

[Former Member]

Hi,

If I have understood properly, you have got two selection screens.

The first one will be filled and then depending on this you need to go to another screen which will also have a defined set of parameters.

For the first screen, you can have the normal selection screen, with the parameter and select options screen fields.

Then in the start of selection, you need to call another screen.

call screen 100 ( will be displayed as new screen)

or call screen 100 STARTING AT 1 1 (will be displayed as a subscreen).

Double click on 100 to create this screen using SE51. Here you can add all the selection fields in the second screen. The results of the first selection screen will be available in the PBO of the screen, since its the same program.

Dont forget to set PF-STATUS in PBO with the BACK or EXIT function code enabled. 

In the PAI of the screen, on addition of the following code, you can go back to the initial selection screen.

case gv_okcode.
     when: 'BACK'.
       leave to screen 0.

[Former Member]

Hi Maqsood,

Here are the multiple ways to go about it.

1) Use SUBMIT rep WITH SELECTION-TABLE rsparams AND RETURN command

     In submit, you will set the values in RSPARAMS and

2) Call transaction with parameters (If Tcode is created)

2) Setting Paramer IDs of the fields use in the called report

[maqsood_ahmed]

Hi ,

Thanks you for the idea, it solves the problem but it always has a downside. On using this i will not get Variant feature even though my second screen is selection screen. Any thoughts?

[Former Member]

Hi Masqood,

You mean you want to fill give default values in the second screen?

You can do that by passing the values to screen fields in the PBO of the second screen.  You will achieve something similar to variants in selection screen.

Else if you want proper variants in the screen build with module pool program, that is also possible.

Check this document, which shows the steps in doing so.

http://scn.sap.com/docs/DOC-27331

Regards,

Susmitha

[Former Member]

So to extend Susmitha statement...

You can write code to create and fill a variant in the second screen and then call the second screen with the variant.

You could store the values in tvarvc and have a variant that gets it's values from tvarvc.

As for passing the values to a second screen of an independent program, I'm having trouble coming up with a way to do that without either importing them, or a write to a ztable and read in the second screen. But that is basically what an export/import pair does...

Neal