Skip to Content
author's profile photo Former Member
Former Member

Passing value to search help from UI

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...

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Apr 06, 2008 at 12:33 PM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Apr 08, 2008 at 12:23 PM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Apr 08, 2008 at 04:41 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.