I have created three reports with related three transactions but I need now to join all these transactions into one transaction code.
How can I achieve that and What steps should I follow ?
You can create a routing report with pushbuttons and process user-command on button click.
REPORT ZTEST1.
SELECTION-SCREEN PUSHBUTTON 3(10) TCODE1
USER-COMMAND TCODE1.
SELECTION-SCREEN SKIP 1.
SELECTION-SCREEN PUSHBUTTON 3(10) TCODE2
USER-COMMAND TCODE2.
INITIALIZATION.
TCODE1 = 'SU01D'.
TCODE2 = 'SU53'.
AT SELECTION-SCREEN.
CASE SY-UCOMM.
WHEN 'TCODE1'.
CALL TRANSACTION 'SU01D'.
WHEN 'TCODE2'.
CALL TRANSACTION 'SU53'.
ENDCASE.
Related
When setting up a selection screen with dynamic visibility of the controls I ran into an unexpected runtime error DYNP_TOO_MANY_RADIOBUTTONS_ON. Reduced sample code to the following reproducible example:
REPORT ztest1.
SELECTION-SCREEN BEGIN OF BLOCK category.
PARAMETER:
rb_cata RADIOBUTTON GROUP cat USER-COMMAND selection_changed DEFAULT 'X',
rb_catb RADIOBUTTON GROUP cat.
SELECTION-SCREEN END OF BLOCK category.
SELECTION-SCREEN BEGIN OF BLOCK action.
PARAMETER:
rb_act1 RADIOBUTTON GROUP act USER-COMMAND selection_changed DEFAULT 'X' MODIF ID act,
rb_act2 RADIOBUTTON GROUP act.
SELECTION-SCREEN END OF BLOCK action.
AT SELECTION-SCREEN OUTPUT.
LOOP AT SCREEN.
CASE screen-group1.
WHEN 'ACT'.
screen-invisible = COND #( WHEN rb_cata = abap_true THEN 0 ELSE 1 ).
WHEN OTHERS.
ENDCASE.
MODIFY SCREEN.
ENDLOOP.
When selecting rb_catb and then re-selecting the first radiobuttion I get the runtime error DYNP_TOO_MANY_RADIOBUTTONS_ON with comment:
In a group of radio buttons, exactly one of the fields must be set -
meaning that must have the value 'X'. If this is not the case, one of
the following situations occurs:
- Multiple radio buttons of the group are set at the same time. This error causes the appplication to terminated and triggers the short
dump that you are currently reading.
But I'm only changing the visibility of the buttons, why am I getting an error relating to the actual active status?
The reason for this is a failure to set the exact same MODIF ID on all buttons in the radiobutton group. While the precise screen processing logic is hard to get at, it appears that all elements in the radiobutton group (RBG) need to be changed at the same time to avoid processing issues. So in the above example:
rb_act1 RADIOBUTTON GROUP act USER-COMMAND selection_changed DEFAULT 'X' MODIF ID act,
rb_act2 RADIOBUTTON GROUP act MODIF ID act.
I initially suspected issues with the ACTIVE or INVISIBLE attributes conflict but those appear unrelated. The actual reason these controls need to change in lockstep is unknown without being able to look at the screen processing logic that's likely hidden in the kernel. Note that the MODIF ID has to be the exact same, any mixing of these IDs within a single RBG will result in this runtime error.
I have a program with a selection screen that produces an alv grid. The ALV grid has a hotspot which sends the user to a new screen which allows users to edit data based on their selection in the alv grid.
This program has a report type screen (selection screen) and dialog screen (the third screen), which type of transaction should i create (report or dialog). Since my starting screen is a default selection screen, should it be a report transaction? Or should i create a screen and make the selection screen a sub screen (if yes, can you please suggest how i do this and create an alv grid with this).
This program "has a report type", you mean it's an "executable program" AKA "report", so use a "report" transaction, so as you probably tried, what happens?
Only the first screen is of some interest for choosing the type of a transaction.
If it's a selection screen, use a "report" transaction.
If it's a general screen, use a "dialog" transaction.
First Program Report Type
It should be report transaction. You can also create dialog transaction.
If you write dialog transaction for the first ABAP program then you can declare selection screen as subscreen.
Following is the example of selection screen as subscreen.
SELECTION-SCREEN : BEGIN OF SCREEN 1010 AS SUBSCREEN.
SELECTION-SCREEN : BEGIN OF BLOCK a WITH FRAME TITLE text-001.
PARAMETERS: rdb1 RADIOBUTTON GROUP rad1 DEFAULT 'X'.
SELECTION-SCREEN BEGIN OF LINE.
PARAMETERS: rdb2 RADIOBUTTON GROUP rad1,
p_data TYPE c LENGTH 35 DEFAULT 'Reporting / Maintenance Data'.
SELECTION-SCREEN END OF LINE.
PARAMETERS rdb3 RADIOBUTTON GROUP rad1.
PARAMETERS rdb4 RADIOBUTTON GROUP rad1. " Membership Expiry Report
SELECTION-SCREEN :END OF BLOCK a.
SELECTION-SCREEN: END OF SCREEN 1010.
Second ABAP Program Dialog/Report
Second ABAP program can be dialog program or report program for editable ALV.If you create dialog program then you have to create transaction.Report ABAP program you can call directly.
regards,
Umar Abdullah
To keep it simple:
if the first line of code in your program logic starts with 'REPORT' go for a "Report" transaction; if not choose a dialog transaction type.
The type of transaction you create should not really matter in this case as long as the screen number of the transaction refers to the selection screen (this is '1000' by default).
As far as the type of program (module pool/dialog or report) goes, both are possible options for your requirement.
I suggest you use a dialog program if you haven't already since they allow for more flexibility and it's generally best practice and easier to stick with these for more complex programs with multiple screens.
Reports vs. Module Pools/Dialog Programs
Reports are generally used for displaying/analyzing data from the database, whilst dialog programs are used when data has to be updated.
Another difference is that reports can be run directly and dialog programs can only be executed via a transaction code.
Once I leave the selection screen in ABAP e.g. by write: How to rewrite cancel button behavior? In my shortened code below, each time I click execute and then cancel, I'm back at the selection screen :( Instead of this behavior I want to leave the program entirely when clicking in write output the red button.
PARAMETERS p_output AS CHECKBOX DEFAULT ' '.
SELECTION-SCREEN BEGIN OF SCREEN 101 AS SUBSCREEN.
SELECTION-SCREEN BEGIN OF BLOCK such WITH FRAME TITLE text-001.
"...
SELECTION-SCREEN END OF BLOCK such.
SELECTION-SCREEN END OF SCREEN 101.
SELECTION-SCREEN BEGIN OF SCREEN 102 AS SUBSCREEN.
SELECTION-SCREEN BEGIN OF BLOCK such2 WITH FRAME TITLE text-002.
"...
SELECTION-SCREEN END OF BLOCK such2.
SELECTION-SCREEN END OF SCREEN 102.
SELECTION-SCREEN BEGIN OF TABBED BLOCK searchtab FOR 20 LINES.
SELECTION-SCREEN TAB (15) expert USER-COMMAND ucomm1
DEFAULT SCREEN 101.
SELECTION-SCREEN TAB (17) common USER-COMMAND ucomm2
DEFAULT SCREEN 102.
SELECTION-SCREEN END OF BLOCK searchtab.
INITIALIZATION.
expert = text-001.
common = text-002.
searchtab-prog = sy-repid.
searchtab-dynnr = 101.
searchtab-activetab = 'EXPERT_SEARCH'.
"...
AT SELECTION-SCREEN ON EXIT-COMMAND.
CASE sy-dynnr.
WHEN 1000."main screen number
CASE sy-ucomm.
WHEN 'ECAN'.
LEAVE PROGRAM.
WHEN 'DBAC' OR 'ENDE'. "execute go back
LEAVE TO SCREEN 1000." SELECTION-SCREEN 1000.
WHEN 'UCOMM1'.
searchtab-dynnr = 101."subscreen number 1
searchtab-activetab = 'EXPERT'.
WHEN 'UCOMM2'.
searchtab-dynnr = 102."subscreen number 2
searchtab-activetab = 'COMMON'.
ENDCASE.
WHEN Others.
CASE sy-ucomm.
WHEN 'ECAN'.
LEAVE PROGRAM.
WHEN 'DBAC' OR 'ENDE'. "execute go back
LEAVE TO SCREEN 1000." SELECTION-SCREEN 1000.
ENDCASE.
ENDCASE.
START-OF-SELECTION.
PERFORM say_hello.
FORM say_hello .
WRITE: 'from the write output screen I want to navigate by Cancel button or key f12',
'not back to selection screen but leave the program entirely.'.
ENDFORM. " SAY_HELLO
Here is what works, it's not pretty.
Copy GUI status INLI from program SAPMSSY0 to your own program
Change the OK code for the cancel button. To work with your example code, change it to ECAN. Also change the one in the Edit menu to be complete
As the first command in your START-OF-SELECTION use
SET PF-STATUS 'INLI'. This is assuming you named it the same
Change the AT SELECTION-SCREEN to AT USER-COMMAND
Activate, test and be amazed
This works because it removes the standard behavior for lists and replaces it with your own, only for the cancel button mind you. Without changing the OK code for cancel the standard SAP code will take over and you have no control over the behavior.
I have the following program.
REPORT zz_tab_strip_obligatory.
SELECTION-SCREEN BEGIN OF TABBED BLOCK tab FOR 20 LINES.
SELECTION-SCREEN TAB (54) tab1 USER-COMMAND tab1 DEFAULT SCREEN 100.
SELECTION-SCREEN TAB (54) tab2 USER-COMMAND tab2 DEFAULT SCREEN 200.
SELECTION-SCREEN END OF BLOCK tab.
SELECTION-SCREEN BEGIN OF SCREEN 100 AS SUBSCREEN.
PARAMETERS:
p1 TYPE i.
SELECTION-SCREEN END OF SCREEN 100.
SELECTION-SCREEN BEGIN OF SCREEN 200 AS SUBSCREEN.
PARAMETERS:
p2 TYPE i OBLIGATORY.
SELECTION-SCREEN END OF SCREEN 200.
INITIALIZATION.
tab1 = 'Tab1'.
tab2 = 'Tab2'.
The first tab has no obligatory fields. The second one on the other hand does.
The problem I am having is that if the user does not go to the second tab and instead of it starts the program immediately with F8 then the obligatory check for the parameters p2 is not performed at all. It looks like all of the events like AT SELECTION-SCREEN are executed only for the current tab ergo for the displayed subscreen.
Is there any way to work around it? My current solution right now is sadly getting rid of OBLIGATORY keywords and making the checks after START-OF-SELECTION (my real program has many tabs).
I do not think there is a direct solution to the selection screen obligatory issue. Here is a similar topic. However, you can store all the obligatory parameters in an internal table. At the Start-of-selection, loop through them and check them.
DATA: BEGIN OF gt_obl_fields OCCURS 0,
fname TYPE char10,
ftext type char50,
END OF gt_obl_fields.
INITIALIZATION.
tab1 = 'Tab1'.
tab2 = 'Tab2'.
gt_obl_fields-fname = 'P2'.
gt_obl_fields-ftext = text-001.
APPEND gt_obl_fields.
"...
START-OF-SELECTION.
LOOP AT gt_obl_fields .
ASSIGN (gt_obl_fields-fname) TO FIELD-SYMBOL(<fs_field>).
IF <fs_field> IS ASSIGNED AND <fs_field> IS INITIAL..
CONCATENATE gt_obl_fields-ftext 'field must be filled!' INTO data(lv_message).
MESSAGE lv_message TYPE 'E'.
ENDIF.
ENDLOOP.
Suppose I have a selection-screen block with two parameters. I want to dynamically fill the second parameter based on what the user inputs in the first, for instance by querying a table to find the expected value for the key field in parameter 1.
As an example, say I have a program that does something for a combination of order number (p_aufnr) and WBS element (p_wbs). Instead of asking the user to provide both, I can determine one of them from the PSPEL field on the AUFK table. However, I still want to show this field to the user after he inputs his order number so he can verify that the WBS element is correct.
I've managed to do this by using the AT SELECTION SCREEN ON p_aufnr event to assign a value to p_wbs. This event is processed when the user presses enter. However, I can only ever get it to work once. So if the user enters an order number, realises from the retrieved WBS element that he made a mistake and changes it, the second parameter never changes. Even though the AT SELECTION SCREEN event is processed in the debugger, the parameter is not updated.
Am I not supposed to use this event for my scenario? If so, how would I then implement this sort of dynamic selection screen?
Forgot to add a code sample. The following report illustrates my issue: after entering a value in p_netw and pressing enter, p_wbs is filled with the value 1. However, if you press enter again the AT SELECTION-SCREEN ON routine is processed but the value for p_wbs is not updated, while lv_count is.
DATA: lv_count TYPE i.
SELECTION-SCREEN BEGIN OF BLOCK main.
PARAMETERS: p_netw TYPE aufnr OBLIGATORY MODIF ID auf.
PARAMETERS: p_wbs TYPE i MODIF ID psp.
SELECTION-SCREEN END OF BLOCK main.
AT SELECTION-SCREEN ON p_netw.
ADD 1 TO lv_count.
p_wbs = lv_count.
START-OF-SELECTION.
PERFORM main.
FORM main.
WRITE: 'The value reached ', lv_count.
ENDFORM.
Apparently the data is not written back to the screen if you update the field in the field-specific block. If you move the field update from AT SELECTION-SCREEN ON p_netw to the global AT SELECTION-SCREEN event, it works. Don't ask me why, though - this seems to a case of undocumented system behaviour...
DATA: lv_count TYPE i.
SELECTION-SCREEN BEGIN OF BLOCK main.
PARAMETERS: p_netw TYPE aufnr OBLIGATORY MODIF ID auf.
PARAMETERS: p_wbs TYPE i MODIF ID psp.
SELECTION-SCREEN END OF BLOCK main.
AT SELECTION-SCREEN ON p_netw.
ADD 1 TO lv_count.
AT SELECTION-SCREEN.
p_wbs = lv_count.
You need to use a PAI (process after input) module on your screen which then takes the new p_aufnr and finds the appropriate p_wbs - probably exactly like your at selection screen event. You will then CALL SCREEN ### <-- your screen number to display the data on your screen. Without any code to work off thats all i can help with.