Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Passing value to search help from UI

Former Member
0 Kudos

Hi ABAPers,

I have UI(ABAP screen programming) with many input fields.

One input field is the F4 help where I have created & assigned a search help.

Now when i click F4 on this search help, I need to know

1) How to pass value to exit function module in search help. Value should be passed from another input field(in UI)

2) How should the function module in search help will accept this input parameter.

Thanks in advance,

Arvind...

1 ACCEPTED SOLUTION

Former Member
0 Kudos

hi,

i have faced the same problem before and created a material fwith detailed solution.hope this helps.

reward if useful.

[http://www.esnips.com/doc/c1c96c2e-88e2-4da5-8d2e-0b12571c62c8/Dynamic-F4-Help-for-ABAP-Type1]

In our example ,we would restrict ourselves to populating the first field only.The next field would be populating using the same logic only there would be some restrictions while fetching data from tables using the select statements.

[Note : In our example, fields like campus id wont work unless the previous entry(workplace indicator ) is populated using the F4 button only and not by manual entry. This is because the fields are populated in different modules in Process on Value Request].

In the module pool, we add the section Process on value request . For reports we will be using the AT SELECTION-SCREEN ON VALUE-REQUEST FOR parameter.

Inside this module we would be writing our subroutine.

We would be calling a function module which would be processing the F4 values. Before that we have to populate 3 structures.

Those are :

DSELC.(Fields FLDNAME and DYFLDNAME)

DFIES.(Fields :TABNAME and FIELDNAME)

This would be our return table structure for display.

Other than that we have to pass the return field (in the previous example its the workplace indicator),the screen-name and screen-number and the value table which has all the values to populate cell by cell.

This is the table we would be using for the first part :

Let’s move on to the coding part:

*Local Constants

CONSTANTS:

l_c_tabname TYPE cc_field VALUE 'ZWORKLOC_CODE',

l_c_fldname TYPE cc_field VALUE 'ZWORKLOC_TEXT',

l_c_tab TYPE cc_field VALUE 'ZTPWORK_IND'.

*local internal tables and work areas

DATA: l_i_values TYPE STANDARD TABLE OF char128,

l_i_map TYPE STANDARD TABLE OF dselc,

l_i_field_tab TYPE STANDARD TABLE OF dfies,

l_i_ddshretval TYPE STANDARD TABLE OF ddshretval,

l_i_dynpread TYPE TABLE OF dynpread,

lst_ddshretval TYPE ddshretval,

lst_field_tab TYPE dfies,

lst_map TYPE dselc,

lst_dynpread TYPE dynpread.

We create internal tables for DSELC,DFIES and DDSHREVTAL.

Next we populate the value_tab using the l_i_values.

SELECT zworkloc_code

zworkloc_text

FROM ztpwork_ind

INTO

TABLE li_wpin.

IF sy-subrc = 0.

*-append values to value table

LOOP AT li_wpin[] ASSIGNING <l_fs_wpin_values>.

APPEND <l_fs_wpin_values>-zworkloc_code TO l_i_values.

APPEND <l_fs_wpin_values>-zworkloc_text TO l_i_values.

ENDLOOP.

Next we populate the fieldname and dynfldname fields of DSELC.

*-append fields to map table

lst_map-fldname = l_c_fldname.

lst_map-dyfldname = l_c_fldname.

APPEND lst_map TO l_i_map.

lst_map-fldname = l_c_tabname.

lst_map-dyfldname = l_c_tabname.

APPEND lst_map TO l_i_map.

Then we populate the Tabname and fieldname fields of DFIES.

lst_field_tab-tabname = l_c_tab.

lst_field_tab-fieldname = l_c_tabname.

APPEND lst_field_tab TO l_i_field_tab.

lst_field_tab-fieldname = l_c_fldname.

APPEND lst_field_tab TO l_i_field_tab.

After that we call the function module passing the 4 internal tables and return field name and screen name and number.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

retfield = c_zwpin

dynpprog = sy-repid

dynpnr = sy-dynnr

stepl = 0

TABLES

value_tab = l_i_values

field_tab = l_i_field_tab

return_tab = l_i_ddshretval

dynpfld_mapping = l_i_map

EXCEPTIONS

parameter_error = 1

no_values_found = 2

OTHERS = 3.

IF sy-subrc <> 0.

EXIT.

ENDIF.

If no exception occurs , we will have a populated search help table.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 1

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_fname_zwpin.

**Assign the value to the parameter

p_wp = lst_ddshretval-fieldval.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 2

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_workind_text.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

After this we make the internal table ready for transport to the PAI screen using FM 'DYNP_VALUES_UPDATE'.

CALL FUNCTION 'DYNP_VALUES_UPDATE'

EXPORTING

dyname = sy-repid

dynumb = sy-dynnr

TABLES

dynpfields = l_i_dynpread

EXCEPTIONS

invalid_abapworkarea = 1

invalid_dynprofield = 2

invalid_dynproname = 3

invalid_dynpronummer = 4

invalid_request = 5

no_fielddescription = 6

undefind_error = 7

OTHERS = 8.

IF sy-subrc EQ 0.

*-no need to check sy-subrc.

ENDIF.

ENDIF.

Here is a report program made from one of the subroutines used for the module pool. Hope this helps.

*&----


**& Report ZDYNAMIC_F4_HELP

**&

*&----


**&

**& Dynamic F4 Help

**& Soumya Bhattacharya (16.2.2008)

*&----


*

REPORT zdynamic_f4_help.

PARAMETERS : p_wp TYPE ztp_wind.

*----


*--


Constants--


CONSTANTS :

c_workind_text TYPE char14

VALUE 'G_WORKIND_TEXT',

c_zwpin TYPE dfies-fieldname

VALUE 'P0032-ZWPIN',

c_fname_zwpin TYPE dynfnam

VALUE 'P0032-ZWPIN',

l_c_tabname TYPE cc_field

VALUE 'ZWORKLOC_CODE',

l_c_fldname TYPE cc_field

VALUE 'ZWORKLOC_TEXT',

l_c_tab TYPE cc_field

VALUE 'ZTPWORK_IND'.

*

*workplace indicator fields

*Structures for Workplace indicators

TYPES: BEGIN OF ty_wpin,

zworkloc_code TYPE ztp_wind,

zworkloc_text TYPE ztp_text,

END OF ty_wpin,

ty_i_wpin TYPE STANDARD TABLE OF ty_wpin.

*Structures for Workplace Campus ID

TYPES: BEGIN OF ty_reso,

reso_campusid TYPE ztp_reso_campusidentifier,

reso_countrycode TYPE ztp_reso_countrycode,

reso_campusname TYPE ztp_reso_campusname,

reso_affiliatedl TYPE ztp_reso_affiliated_ibm_worklo,

END OF ty_reso,

ty_reso_t TYPE STANDARD TABLE OF ty_reso.

*Structures for Building

TYPES : BEGIN OF ty_reso_bldg,

reso_campusid TYPE ztp_reso_campusidentifier,

reso_buildingid TYPE ztp_reso_buildingidentifier,

reso_bldgname TYPE ztp_reso_buildingname,

END OF ty_reso_bldg.

*Variable declaration

DATA : g_work_ind TYPE c, "Workindicator code

li_wpin TYPE ty_i_wpin, "Work Area for workplace indicator

l_i_values TYPE STANDARD TABLE OF char128,

l_i_map TYPE STANDARD TABLE OF dselc,

l_i_field_tab TYPE STANDARD TABLE OF dfies,

l_i_ddshretval TYPE STANDARD TABLE OF ddshretval,

l_i_dynpread TYPE TABLE OF dynpread,

lst_ddshretval TYPE ddshretval,

lst_field_tab TYPE dfies,

lst_map TYPE dselc,

lst_dynpread TYPE dynpread.

FIELD-SYMBOLS: <l_fs_wpin_values> TYPE ty_wpin.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_wp.

SELECT zworkloc_code

zworkloc_text

FROM ztpwork_ind

INTO

TABLE li_wpin.

IF sy-subrc = 0.

*-append values to value table

LOOP AT li_wpin[] ASSIGNING <l_fs_wpin_values>.

APPEND <l_fs_wpin_values>-zworkloc_code TO l_i_values.

APPEND <l_fs_wpin_values>-zworkloc_text TO l_i_values.

ENDLOOP.

lst_field_tab-tabname = l_c_tab.

lst_field_tab-fieldname = l_c_tabname.

APPEND lst_field_tab TO l_i_field_tab.

lst_field_tab-fieldname = l_c_fldname.

APPEND lst_field_tab TO l_i_field_tab.

*-append fields to map table

lst_map-fldname = l_c_fldname.

lst_map-dyfldname = l_c_fldname.

APPEND lst_map TO l_i_map.

lst_map-fldname = l_c_tabname.

lst_map-dyfldname = l_c_tabname.

APPEND lst_map TO l_i_map.

*-do F4 help

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

retfield = c_zwpin

dynpprog = sy-repid

dynpnr = sy-dynnr

stepl = 0

TABLES

value_tab = l_i_values

field_tab = l_i_field_tab

return_tab = l_i_ddshretval

dynpfld_mapping = l_i_map

EXCEPTIONS

parameter_error = 1

no_values_found = 2

OTHERS = 3.

IF sy-subrc <> 0.

EXIT.

ENDIF.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 1

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_fname_zwpin.

p_wp = lst_ddshretval-fieldval.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

  • l_wa_dynpread-stepl = 0.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 2

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_workind_text.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

  • l_wa_dynpread-stepl = 0.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

CALL FUNCTION 'DYNP_VALUES_UPDATE'

EXPORTING

dyname = sy-repid

dynumb = sy-dynnr

TABLES

dynpfields = l_i_dynpread

EXCEPTIONS

invalid_abapworkarea = 1

invalid_dynprofield = 2

invalid_dynproname = 3

invalid_dynpronummer = 4

invalid_request = 5

no_fielddescription = 6

undefind_error = 7

OTHERS = 8.

IF sy-subrc EQ 0.

*-no need to check sy-subrc.

ENDIF.

clear:l_i_values ,

l_i_map ,

l_i_field_tab,

l_i_ddshretval ,

l_i_dynpread .

ENDIF.

3 REPLIES 3

Former Member
0 Kudos

hi,

i have faced the same problem before and created a material fwith detailed solution.hope this helps.

reward if useful.

[http://www.esnips.com/doc/c1c96c2e-88e2-4da5-8d2e-0b12571c62c8/Dynamic-F4-Help-for-ABAP-Type1]

In our example ,we would restrict ourselves to populating the first field only.The next field would be populating using the same logic only there would be some restrictions while fetching data from tables using the select statements.

[Note : In our example, fields like campus id wont work unless the previous entry(workplace indicator ) is populated using the F4 button only and not by manual entry. This is because the fields are populated in different modules in Process on Value Request].

In the module pool, we add the section Process on value request . For reports we will be using the AT SELECTION-SCREEN ON VALUE-REQUEST FOR parameter.

Inside this module we would be writing our subroutine.

We would be calling a function module which would be processing the F4 values. Before that we have to populate 3 structures.

Those are :

DSELC.(Fields FLDNAME and DYFLDNAME)

DFIES.(Fields :TABNAME and FIELDNAME)

This would be our return table structure for display.

Other than that we have to pass the return field (in the previous example its the workplace indicator),the screen-name and screen-number and the value table which has all the values to populate cell by cell.

This is the table we would be using for the first part :

Let’s move on to the coding part:

*Local Constants

CONSTANTS:

l_c_tabname TYPE cc_field VALUE 'ZWORKLOC_CODE',

l_c_fldname TYPE cc_field VALUE 'ZWORKLOC_TEXT',

l_c_tab TYPE cc_field VALUE 'ZTPWORK_IND'.

*local internal tables and work areas

DATA: l_i_values TYPE STANDARD TABLE OF char128,

l_i_map TYPE STANDARD TABLE OF dselc,

l_i_field_tab TYPE STANDARD TABLE OF dfies,

l_i_ddshretval TYPE STANDARD TABLE OF ddshretval,

l_i_dynpread TYPE TABLE OF dynpread,

lst_ddshretval TYPE ddshretval,

lst_field_tab TYPE dfies,

lst_map TYPE dselc,

lst_dynpread TYPE dynpread.

We create internal tables for DSELC,DFIES and DDSHREVTAL.

Next we populate the value_tab using the l_i_values.

SELECT zworkloc_code

zworkloc_text

FROM ztpwork_ind

INTO

TABLE li_wpin.

IF sy-subrc = 0.

*-append values to value table

LOOP AT li_wpin[] ASSIGNING <l_fs_wpin_values>.

APPEND <l_fs_wpin_values>-zworkloc_code TO l_i_values.

APPEND <l_fs_wpin_values>-zworkloc_text TO l_i_values.

ENDLOOP.

Next we populate the fieldname and dynfldname fields of DSELC.

*-append fields to map table

lst_map-fldname = l_c_fldname.

lst_map-dyfldname = l_c_fldname.

APPEND lst_map TO l_i_map.

lst_map-fldname = l_c_tabname.

lst_map-dyfldname = l_c_tabname.

APPEND lst_map TO l_i_map.

Then we populate the Tabname and fieldname fields of DFIES.

lst_field_tab-tabname = l_c_tab.

lst_field_tab-fieldname = l_c_tabname.

APPEND lst_field_tab TO l_i_field_tab.

lst_field_tab-fieldname = l_c_fldname.

APPEND lst_field_tab TO l_i_field_tab.

After that we call the function module passing the 4 internal tables and return field name and screen name and number.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

retfield = c_zwpin

dynpprog = sy-repid

dynpnr = sy-dynnr

stepl = 0

TABLES

value_tab = l_i_values

field_tab = l_i_field_tab

return_tab = l_i_ddshretval

dynpfld_mapping = l_i_map

EXCEPTIONS

parameter_error = 1

no_values_found = 2

OTHERS = 3.

IF sy-subrc <> 0.

EXIT.

ENDIF.

If no exception occurs , we will have a populated search help table.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 1

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_fname_zwpin.

**Assign the value to the parameter

p_wp = lst_ddshretval-fieldval.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 2

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_workind_text.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

After this we make the internal table ready for transport to the PAI screen using FM 'DYNP_VALUES_UPDATE'.

CALL FUNCTION 'DYNP_VALUES_UPDATE'

EXPORTING

dyname = sy-repid

dynumb = sy-dynnr

TABLES

dynpfields = l_i_dynpread

EXCEPTIONS

invalid_abapworkarea = 1

invalid_dynprofield = 2

invalid_dynproname = 3

invalid_dynpronummer = 4

invalid_request = 5

no_fielddescription = 6

undefind_error = 7

OTHERS = 8.

IF sy-subrc EQ 0.

*-no need to check sy-subrc.

ENDIF.

ENDIF.

Here is a report program made from one of the subroutines used for the module pool. Hope this helps.

*&----


**& Report ZDYNAMIC_F4_HELP

**&

*&----


**&

**& Dynamic F4 Help

**& Soumya Bhattacharya (16.2.2008)

*&----


*

REPORT zdynamic_f4_help.

PARAMETERS : p_wp TYPE ztp_wind.

*----


*--


Constants--


CONSTANTS :

c_workind_text TYPE char14

VALUE 'G_WORKIND_TEXT',

c_zwpin TYPE dfies-fieldname

VALUE 'P0032-ZWPIN',

c_fname_zwpin TYPE dynfnam

VALUE 'P0032-ZWPIN',

l_c_tabname TYPE cc_field

VALUE 'ZWORKLOC_CODE',

l_c_fldname TYPE cc_field

VALUE 'ZWORKLOC_TEXT',

l_c_tab TYPE cc_field

VALUE 'ZTPWORK_IND'.

*

*workplace indicator fields

*Structures for Workplace indicators

TYPES: BEGIN OF ty_wpin,

zworkloc_code TYPE ztp_wind,

zworkloc_text TYPE ztp_text,

END OF ty_wpin,

ty_i_wpin TYPE STANDARD TABLE OF ty_wpin.

*Structures for Workplace Campus ID

TYPES: BEGIN OF ty_reso,

reso_campusid TYPE ztp_reso_campusidentifier,

reso_countrycode TYPE ztp_reso_countrycode,

reso_campusname TYPE ztp_reso_campusname,

reso_affiliatedl TYPE ztp_reso_affiliated_ibm_worklo,

END OF ty_reso,

ty_reso_t TYPE STANDARD TABLE OF ty_reso.

*Structures for Building

TYPES : BEGIN OF ty_reso_bldg,

reso_campusid TYPE ztp_reso_campusidentifier,

reso_buildingid TYPE ztp_reso_buildingidentifier,

reso_bldgname TYPE ztp_reso_buildingname,

END OF ty_reso_bldg.

*Variable declaration

DATA : g_work_ind TYPE c, "Workindicator code

li_wpin TYPE ty_i_wpin, "Work Area for workplace indicator

l_i_values TYPE STANDARD TABLE OF char128,

l_i_map TYPE STANDARD TABLE OF dselc,

l_i_field_tab TYPE STANDARD TABLE OF dfies,

l_i_ddshretval TYPE STANDARD TABLE OF ddshretval,

l_i_dynpread TYPE TABLE OF dynpread,

lst_ddshretval TYPE ddshretval,

lst_field_tab TYPE dfies,

lst_map TYPE dselc,

lst_dynpread TYPE dynpread.

FIELD-SYMBOLS: <l_fs_wpin_values> TYPE ty_wpin.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_wp.

SELECT zworkloc_code

zworkloc_text

FROM ztpwork_ind

INTO

TABLE li_wpin.

IF sy-subrc = 0.

*-append values to value table

LOOP AT li_wpin[] ASSIGNING <l_fs_wpin_values>.

APPEND <l_fs_wpin_values>-zworkloc_code TO l_i_values.

APPEND <l_fs_wpin_values>-zworkloc_text TO l_i_values.

ENDLOOP.

lst_field_tab-tabname = l_c_tab.

lst_field_tab-fieldname = l_c_tabname.

APPEND lst_field_tab TO l_i_field_tab.

lst_field_tab-fieldname = l_c_fldname.

APPEND lst_field_tab TO l_i_field_tab.

*-append fields to map table

lst_map-fldname = l_c_fldname.

lst_map-dyfldname = l_c_fldname.

APPEND lst_map TO l_i_map.

lst_map-fldname = l_c_tabname.

lst_map-dyfldname = l_c_tabname.

APPEND lst_map TO l_i_map.

*-do F4 help

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

retfield = c_zwpin

dynpprog = sy-repid

dynpnr = sy-dynnr

stepl = 0

TABLES

value_tab = l_i_values

field_tab = l_i_field_tab

return_tab = l_i_ddshretval

dynpfld_mapping = l_i_map

EXCEPTIONS

parameter_error = 1

no_values_found = 2

OTHERS = 3.

IF sy-subrc <> 0.

EXIT.

ENDIF.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 1

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_fname_zwpin.

p_wp = lst_ddshretval-fieldval.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

  • l_wa_dynpread-stepl = 0.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

READ TABLE l_i_ddshretval

INTO lst_ddshretval INDEX 2

TRANSPORTING fieldval.

IF sy-subrc = 0.

lst_dynpread-fieldname = c_workind_text.

lst_dynpread-fieldvalue = lst_ddshretval-fieldval.

  • l_wa_dynpread-stepl = 0.

APPEND lst_dynpread TO l_i_dynpread.

ENDIF.

CALL FUNCTION 'DYNP_VALUES_UPDATE'

EXPORTING

dyname = sy-repid

dynumb = sy-dynnr

TABLES

dynpfields = l_i_dynpread

EXCEPTIONS

invalid_abapworkarea = 1

invalid_dynprofield = 2

invalid_dynproname = 3

invalid_dynpronummer = 4

invalid_request = 5

no_fielddescription = 6

undefind_error = 7

OTHERS = 8.

IF sy-subrc EQ 0.

*-no need to check sy-subrc.

ENDIF.

clear:l_i_values ,

l_i_map ,

l_i_field_tab,

l_i_ddshretval ,

l_i_dynpread .

ENDIF.

Former Member
0 Kudos

Hi Aravind,

In one of my project I got similar requirement where in we need to provide the Material Groups 1 through 4 as F4 help based on Vendor assigned to a PR line item. For this I have used the concept of POV (Process on Value-Request).

I'll give you a sample example using which you can achieve your requirement instead of creating a Search Help, Search Help Exit & so on.

1. Create a 'Z' table with some fields say MANDT, LIFNR and MATNR and maintain the table entries

2. Create a module pool program with these two fields on the screen.

3. Create the following modules accordingly.

PBO.

MODULE INIT.

PAI.

MODULE CANCEL AT EXIT-COMMAND..

POV.

FIELD MATNR MODULE GET_F4_HELP.

4. In the module program in SE38 copy the following code and paste.

TABLES: lfa1, mara.

TYPES: BEGIN OF VALUES,

lifnr TYPE lfa1-lifnr,

matnr TYPE mara-matnr,

END OF VALUES.

DATA: PROGNAME LIKE SY-REPID,

DYNNUM LIKE SY-DYNNR,

DYNPRO_VALUES TYPE TABLE OF DYNPREAD,

FIELD_VALUE LIKE LINE OF DYNPRO_VALUES,

VALUES_TAB TYPE TABLE OF VALUES.

*&----


**& Module get_f4_help INPUT

*&----


  • * text

----


MODULE get_f4_help INPUT.

DATA: L_LIFNR TYPE LFA1-LIFNR.

CALL FUNCTION 'DYNP_VALUES_READ'

EXPORTING

DYNAME = PROGNAME

DYNUMB = DYNNUM

TRANSLATE_TO_UPPER = 'X'

TABLES

DYNPFIELDS = DYNPRO_VALUES.

READ TABLE DYNPRO_VALUES INDEX 1 INTO FIELD_VALUE.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING

INPUT = FIELD_VALUE-FIELDVALUE

IMPORTING

OUTPUT = L_LIFNR.

SELECT lifnr matnr from zui_test INTO CORRESPONDING FIELDS OF TABLE values_tab

WHERE lifnr = L_LIFNR.

IF sy-subrc = 0.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

RETFIELD = 'MATNR'

DYNPPROG = PROGNAME

DYNPNR = DYNNUM

DYNPROFIELD = 'MATNR'

VALUE_ORG = 'S'

TABLES

VALUE_TAB = VALUES_TAB.

ENDIF.

ENDMODULE. " get_f4_help INPUT

*&----


**& Module INIT OUTPUT

*&----


    • text

*----


MODULE INIT OUTPUT.

PROGNAME = SY-REPID.

DYNNUM = SY-DYNNR.

CLEAR: FIELD_VALUE, DYNPRO_VALUES.

FIELD_VALUE-FIELDNAME = 'LIFNR'.

APPEND FIELD_VALUE TO DYNPRO_VALUES.

ENDMODULE. " INIT OUTPUT

*&----


**& Module CANCEL INPUT

*&----


    • text

*----


MODULE CANCEL INPUT.

LEAVE PROGRAM.

ENDMODULE. " CANCEL INPUT

5. Now Activate the program and the associated screens.

6. Create a TCode and execute.

Here you go input the Vendor number and go to Material field and press F4.

You'll get the values related to the entered vendor number. Hope this is a simple way to achieve your requirement.

Reward if useful.

Thanks and Regards,

Maddineni Bharath.

Former Member
0 Kudos

hi arvind,

Programming User Interfaces in the De-Coupled Framework

Purpose

The de-coupled framework primarily consists of two areas – one area that relates to the back-end business logic of an infotype, and a second area that enables the infotype to be displayed, and if necessary edited, in the user interface.

The business logic area of the de-coupled framework covers a number of requirements, including:

&#9679; checking the consistency of infotype data,

&#9679; handling time constraints,

&#9679; triggering retrocalculations (where necessary), and

&#9679; storing infotype data on the database.

However, if the infotype is to be displayed on the screen, and if the user should be able to maintain it, then additional requirements arise. The user interface area of the de-coupled framework covers these requirements, including:

&#9679; the display of specific values via input help.

&#9679; the display of additional, read-only information. (For example, you may wish to display the age of an employee derived from his or her date of birth.)

&#9679; the display of descriptive texts for key values stored in the infotype. {For example, when the employee gender is displayed as Male or Female instead of (or in addition to) the technical values of 1 and 2 that are ultimately stored in the database.}

&#9679; dividing the value of one infotype field into several fields shown on the user interface, or vice versa.

&#9679; performing any kind of calculation that converts values entered on the user interface to values that are to be stored in the infotype, or vice versa.

&#9679; setting metadata based on values entered – for example, mandatory, read-only, and so on.

In short, the de-coupled framework requires programmers to consider the business logic of an infotype separately from its user interface. The division of (back-end) business logic from (front-end) user interfaces makes each area independent and therefore ultimately simplifies the manner in which the user interface is presented by various applications.

Prerequisites

In the de-coupled framework for creating infotypes, the existence of de-coupled business logic is a prerequisite for the creation of de-coupled user interfaces. Thus, if you wish to create a new Personnel Administration infotype in the de-coupled framework and program its user interface accordingly, you are required to have created the corresponding business logic already.

To this end, we recommend that you consult the Business Logic Guidelines for Creating and Migrating Infotypes, which describe aspects of this process in detail.

Process Flow

In the de-coupled framework, for any infotype that is to be displayed (or edited) in the user interface, the following entities must exist:

&#9679; A Data Dictionary structure (known as a screen structure), which contains all of the infotype fields that should be part of the user interface.

&#9679; An ABAP-OO class (known as a conversion class), which defines the conversion of the infotype fields from their representation in the back end to their representation on the user interface.

&#9679; An entry in the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS), which defines the conversion class that the system will apply to the corresponding screen structure, and which thereby governs the assignment of conversion classes to screen structures.

As stated above, the screen structure contains all of the infotype fields that should be part of the user interface. The fields defined therein include editable fields, read-only fields, and descriptive texts. Everything that is related to the infotype and that should be presented on its user interface requires the explicit definition of a corresponding component within the screen structure.

To support the country-specific requirements of Personnel Administration infotypes, screen structures themselves are defined to be either international or country-specific. If a screen structure is defined to be international, then that screen structure will only contain fields that are country-independent. In contrast, if a screen structure is defined to be country-specific, then it will contain fields that are valid for the country version in question. For additional information, consult the Screen Structures topic.

The conversion class converts infotype data from the back end for representation on the user interface. Conversion classes therefore convert data that is stored for the corresponding Pnnnn structure into data for the screen structure, and vice versa. Output conversion denotes the conversion of Pnnnn structure data into screen structure data, while the conversion of screen structure data into Pnnnn structure data is called input conversion.

In addition to converting data, conversion classes also provide field attribute information, as well as input help, for the user interface fields. To this end, conversion classes not only specify whether a particular field is mandatory, read-only or hidden, but also furnish the supported field values to populate drop-down list boxes or input help on the user interface. For additional information, refer to the Conversion Classes topic.

As stated above, an entry in the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS) is required to establish the link between a screen structure and the corresponding conversion class. The entries in this view enable the de-coupled framework to call the correct conversion class when processing a particular screen structure. For additional information, review the Assigning Conversion Classes to Screen Structures topic.

In the event that the infotype in question lacks specific user interface requirements, then it is not necessary to assign a dedicated conversion class to it. In such cases, the default conversion class – CL_HRPA_UI_CONVERT_BASIC – can be assigned instead, as described in the topic referenced immediately above. For a description of this default conversion class, consult the topic Conversion Classes.

To simplify the programming of user interfaces in the de-coupled framework, the standard system features many types of generic functionality, which users can activate by performing the corresponding Customizing. This functionality includes a generic approach to provide input help values, the automatic retrieval of descriptive texts for fields that hold key values and the automatic handling of repeat fields. For additional information on any aspect of this functionality, choose the corresponding link.

Finally, when you have finished creating a new Personnel Administration infotype in the de-coupled framework, you can execute the Test Interface for ITF Conversion Classes transaction (transaction code PUIT_UI) to ensure that the user interface of your infotype functions properly. For additional information on this test tool, review the documentation provided with it.

In summary, the process of displaying and editing an infotype in the user interface consists of the following phases.

&#9679; Output Conversion

During output conversion, back-end data is converted into screen structure data, which in turn is displayed – and, if necessary, edited – on the user interface.

&#9675; If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used, all user interface fields that bear the same technical names in the back end are automatically filled.

&#9675; Assuming that the corresponding Customizing has been performed, generic functionality to provide input help values is applied; input help automatically becomes available for all fields.

&#9675; Assuming that the corresponding Customizing has been performed, the automatic retrieval of descriptive texts is applied; descriptive texts for fields that hold key values are automatically displayed.

&#9675; Based on the metadata defined for the back-end fields, field attribute information (for example, mandatory, read-only, and so on) is automatically provided.

If additional processing is required for the infotype in question, then the default conversion class cannot be applied. Rather, a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. In practice, the OUTPUT_CONVERSION method of the corresponding conversion class therefore must be implemented.

&#9679; Input Conversion

Screen structure data – which has been displayed (and, if necessary, edited) on the user interface – is converted into back-end data for subsequent database storage.

&#9675; If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used, all back-end fields that bear the same technical names on the user interface are automatically filled.

&#9675; No action is required for input help values; these values are only relevant when the infotype is maintained in the user interface.

&#9675; No action is required for descriptive texts; these texts are read-only by default, and therefore require no conversion for storage in the database.

&#9675; No action is required for field attribute information, as this information is already defined in the database.

If additional processing is required for the infotype in question, then the default conversion class cannot be applied. Rather, a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. In practice, the INPUT_CONVERSION method of the corresponding conversion class therefore must be implemented.

For infotypes that contain repeat fields, a generic approach is also provided; for additional information, see Repeat Field Screen Structures (Type LINE). If the generic approach for repeat fields is insufficient, then a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS, and the OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION methods of that conversion class must be implemented.

Example

Suppose that you wish to create the user interface for infotype 9001, an international customer-specific infotype that is to be processed in the de-coupled framework and whose structure (P9001) consists of the fields shown below.

Subsequent examples in the present guidelines may refer to the customer-specific infotype (9001) introduced below.

P9001 Structure Fields

Field Name

Short Description

NACHN

Last Name

VORNA

First Name

GBDAT

Date of Birth

GBPAS

Date of Birth According to Passport

NCHMC

Last Name (Field for Search Help)

ANRED

Form-of-Address Key

Because Infotype 9001 is to be processed in the de-coupled framework, a corresponding screen structure must be created. It therefore is incumbent on the programmer to decide which fields are to become part of the user interface and will consequently require representation within the screen structure.

&#9679; Field NCHMC is considered to be strictly technical; therefore, it is not needed in the user interface, and will not require corresponding representation within the screen structure.

&#9679; Field GBPAS is considered to be relevant for certain countries, but not for others. Because the screen structure to be created corresponds to an international (rather than country-specific) infotype, this field also is not needed in the user interface, and also will not require screen structure representation.

&#9679; All other fields – NACHN, VORNA, GBDAT and ANRED – are considered to be relevant for the user interface. Therefore, these fields require corresponding representation in the screen structure, where they are defined, to facilitate processing, with the same technical names.

Using the same technical names provides a distinct advantage, because it enables the programmer to use the default conversion class – CL_HRPA_UI_CONVERT_BASIC – if desired. This class simply uses a MOVE-CORRESPONDING statement to pass the field values to the screen structure. (Even if a dedicated conversion class is required, the same statement can be used to simplify programming.) Moreover, using the same technical names ensures that the relationship between infotype fields and screen structure fields remain transparent.

In addition to the fields from structure P9001, suppose that the following fields are required on the user interface:

&#9679; FULL_NAME

This field should provide a concatenation of the first and last name of the employee. With this field, users should be able to enter the full employee name in a single user interface field.

&#9679; AGE

This field should display the current age of the employee.

&#9679; FORM_OF_ADDRESS_TEXT

This field should display the descriptive text for field ANRED (Form-of-Address Key). In other words, in addition to the key (numerical) values that are stored in field ANRED, the corresponding descriptive text (Mr., Ms., Dr., and so on) should be displayed on the user interface.

In summary, the screen structure should contain the following fields:

Screen Structure Fields for Infotype 9001

Field Name

Short Description

NACHN

Last Name

VORNA

First Name

FULL_NAME

First and Last Name in One Line

GBDAT

Date of Birth

AGE

Employee Age

ANRED

Form-of-Address Key

FORM_OF_ADDRESS_TEXT

Form-of-Address Description

Because of the screen structure fields FULL_NAME and AGE, specific requirements exist for this infotype, and the default conversion class CL_HRPA_UI_CONVERT_BASIC cannot be used. Therefore, a dedicated conversion class for this screen structure is required, and the programmer must implement methods OUTPUT_CONVERSION and INPUT_CONVERSION therein. However, for field FORM_OF_ADDRESS_TEXT, the automatic retrieval of descriptive texts can be applied,

or else pls see the link

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=passingvaluetosearchhelpfromUI+&cat=sdn_all&start=11

regards

karthik