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

How to add new field in Standard Search help?

How to add new field in Standard Search help?

Ex: We go to Se11> Press F4> Give Package name, it will provide a standard Search Help name > We click on Include Search helps tab-> Double click on Standard Serach help and add new field with data element.

Is this is the way we add new field in Standard Search help?

I had also seen Search Help exit...Can anybody explain me abt this..

Can any one explain me with an example(Not report programming) .....Plz

Have a great day!

Regards,

Krishna Chaitanya

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 Mar 31, 2008 at 07:49 PM

    The input help (F4 help) is a standard function of the R/3 System. It permits the user to display a list of possible values for a screen field. A value can be directly copied to an input field by list selection.

    The fields having an input help are shown in the R/3 System by the input help key to the right of the field. This key appears as soon as the cursor is positioned on the corresponding screen field. The help can be started either by clicking on this screen element or with function key F4.

    If the number of possible entries for a field is very large, you can limit the set of displayed values by entering further restrictions.

    The display of the possible entries is enhanced with further useful information about the displayed values. This feature is especially useful if the field requires the entry of a formal key.

    Since the input help is a standard function, it should look and behave the same throughout the entire R/3 System. The development environment therefore provides tools for assigning a standardized input help to a screen field.

    The precise description of the input help for a field is usually defined by its semantics. For this reason, the input help for a field is normally defined in the ABAP Dictionary.

    A number of requirements must be met for the input help of a screen field (search field):

    Information (about the context) known to the system must be taken into consideration in the input help. This includes entries the user already made in the current input template as well as information obtained in previous dialog steps. Normally the input help uses the context to limit the set of possible values.

    The input help must determine the values that can be offered to the user for selection. The data to be displayed as supplementary information in the list of possible values must also be determined. When the possible values are determined, the restrictions resulting from the context and from further search conditions specified by the user must also be taken into consideration.

    The input help must hold a dialog with the user. This dialog always contains the presentation of the possible values (with supplementary information) in list form and the possibility to select a value from this list. A search template in which the user can define conditions for the values to be displayed is also sometimes required .

    If the user selects a value, the input help must return it to the search field. The input template often contains more fields (often only display fields) containing further explanatory information about the search field. The input help should also update the contents of these fields in this case.

    The ABAP Dictionary object search help is used to describe an input help. The definition of a search help contains the information the system needs to satisfy the described requirements.

    The interface of the search help controls the data transfer from the input template to the F4 help and back. The interface defines the context data to be used and the data to be returned to the input template when a value is selected.

    The internal behavior of the search help describes the F4 process itself. This includes the selection method with which the values to be displayed should be determined as well as the dialog behavior describing the interaction with the user.

    As with a function module, search helps distinguish between the interface with which it exchanges data with other software components and the internal behavior (for function modules, the latter is defined by the source text).

    It only makes sense to define a search help if there is a mechanism available with which the search help can be accessed from a screen. This mechanism is called the search help attachment and will be described later.

    Like the editor for function modules, the editor for search helps also enables you to test an object. You can thus test the behavior of a search help without assigning it to a screen field.

    The possible values displayed for a field by the input help are determined at runtime by a selection from the database. When a search help is defined, you must define the database object from which the data should be selected by specifying a table or a view as the selection method.

    It makes sense to use a view as selection method if the data about the possible values that is relevant for the input help is distributed on several tables. If this data is all in one table or in the corresponding text table, you can use the table as a selection method. The system automatically ensures that the text of the text table is used in the user's logon language.

    If there is not yet a view that combines the data that is relevant for an input help, you must first create it in the ABAP Dictionary.

    Maintenance views may not be used as the selection method for search helps. Normally a database view is used. However, you should note that database views (in the R/3 System) are always created with an inner join. As a result, only those values having an entry in each of the tables involved are offered in the input help. Sometimes the values should be determined with an outer join. In this case you should choose a help view as the selection method.

    If the selection method of a search help is client-dependent, the possible values are only selected in the user's logon client.

    The possible values are presented in the dialog box for displaying the hit list and the user can select values from here. If the possible values are formal keys, further information should also be displayed.

    If the hit list is very large, the user should be able to define further restrictions for the attributes of the entry. Restricting the set of data in this way both increases the clarity of the list and reduces the system load. Additional conditions can be entered in a further dialog window, the dialog box for restricting values.

    The dialog type of a search help defines whether the dialog box for restricting values should be displayed before determining the hit list.

    You must define the characteristics to appear on either (or both) of the dialog boxes as parameters in the search help. You can use all the fields of the selection method (with the exception of the client field) and the non-key fields of your text table as parameters.

    You define which parameter should appear in which dialog box (in what order) by assigning the parameters positions in the two dialog boxes. You can thus use different parameters (or different orders) in the two dialog boxes.

    Types must be defined for search help parameters with data elements. These define the display in the two dialog boxes. If nothing else is defined, a parameter uses the data element of the corresponding field of the selection method.

    When you define a parameter of a search help, you must also define whether it should be used to copy data to the input help (IMPORT parameter) or whether to return data from the input help (EXPORT parameter).

    The IMPORT and EXPORT parameters of a search help together make up your interface. (This is also analogous to function modules.)

    You can also define interface parameters that do not appear in either the dialog box for displaying the hit list or the dialog box for restricting values. This is useful for example when screen fields that do not appear on either of the two dialog boxes are to be updated when you select a value.

    The location from which the IMPORT parameters of a search help get their values and the screen fields in which the contents of the EXPORT parameters of the search help are returned are defined in the search help attachment.

    The search field is a special case. Its contents are only used in the input help if it is a search string (that is, if it contains a ´´ or a ´+´) and the parameter linked with the search field is an IMPORT parameter.*

    Parameters that only contain additional information about the search field should not be defined as IMPORT parameters since the user must otherwise empty the corresponding screen fields each time before he can define a new value with the input help.

    A search help describes the flow of an input help. The search help can only take effect using a mechanism that assigns the search help to this field. This mechanism is called the search help attachment to the field.

    Attaching a search help to a field has an effect on the field's behavior. It is therefore considered to be part of the field definition.

    The semantic and technical attributes of a screen field (type, length, F1 help, ...) are not normally defined directly when the input template is defined. On the contrary, only a reference to an ABAP Dictionary field (usually with the same name) is specified in the Screen Painter. The screen field takes on the attributes of this field from the ABAP Dictionary.

    The same principle is also used to define the input help of a screen field. The search help is thus attached to the ABAP Dictionary search field and not to the screen field.

    In the search help attachment, the interface parameters of the search help and the screen fields providing data for the input help or getting data from the input help are assigned to one another. The search field must be assigned to an EXPORT parameter of the search help at this time. This parameter should also be an IMPORT parameter so that the user can take advantage of search patterns that are already entered.

    Fields that do not have a search help attachment can also have an input help since further mechanisms (e.g. domain fixed values) are also used for the F4 help.

    There are three mechanisms for attaching a search help to a field of the ABAP Dictionary.

    A search help can be attached directly to a field of a structure or table. The definition of this attachment is analogous to that of a foreign key. You have to define an assignment (between the interface parameters of the search help and the fields of the structure) for which the system makes a proposal.

    If a field has a check table, its contents are automatically offered as possible values in the input help. The key fields of the check table are displayed. If a check table has a text table, its first character-like non-key field is displayed.

    If you are not satisfied with the described standard display of the data of the check table, you can attach a search help to the check table. This search help is used for all the fields that have this table as check table. You have to define an assignment between the interface of the search help and the key of the check table when you define the attachment.

    The semantics of a field and its possible values are defined by its data element. You can therefore attach a search help to a data element. The search help is then available for all the fields that refer to this data element. In the attachment you must define an EXPORT parameter of the search help for the data transfer.

    Attaching a search help to a check table (or a data element) can result in a high degree of reusability. However, there are restrictions on passing further values via the interface of the search help.

    In order to be able to offer a meaningful input help for as many screen fields as possible, the R/3 System uses a number of mechanisms. If there is more than one such mechanism available for a field, the one that is furthest left or at the top of the above hierarchy is used.

    In addition to the options described above for defining the input help of a field in the ABAP Dictionary, you can also define it in the screen field. The disadvantage, however, is that there is no automatic reuse.

    With the screen event POV you can program the input help of a field by yourself. You can adjust the design of the help to the standard help using the function modules

    F4IF_FIELD_VALUE_REQUEST or F4IF_INT_TABLE_VALUE_REQUEST.

    However, you should check to see if the part of the input help that you programmed yourself should be implemented as a search help exit instead (see appendix).

    You can also attach a search help to a screen field in the Screen Painter. There are some functional restrictions on this kind of attachment as compared with attachment in the Dictionary.

    You should no longer use the input checks defined directly in the flow logic of the screen, from which it is also possible to derive input helps.

    The function Technical info is offered in the hit list in the menu of the right mouse key. It can be used to find out which of the specified mechanisms is being used.

    You sometimes have to search a large amount of data with an input help. This means that you might have to wait a long time for the possible entries to be displayed, and can also result in a significant increase in the load on the system.

    When you define a search help, you should therefore check whether you should take measures to optimize the accessing behavior for the selection method. This is especially true if the selection uses a view and thus more than one physical table.

    If the number of entries in the selection method is very large, you should restrict the hit list with further conditions. This also increases the clarity of the hit list. The additional conditions can directly result from the context, or can be entered in the dialog box for restricting values by the user. The performance of the input help can frequently be significantly improved by creating an index on the fields used to formulate the restrictions.

    If the number of entries in the selection method is relatively small, you should always check whether the selection method can be buffered.

    In the relational data model, entities are usually represented by formal keys. In real life, however, these entities are often identified by one or more of their attributes. For example, the key for a person is the personnel number. A person will generally describe another with his name and possibly his address.

    The attributes used to identify an entity can differ from one user to the next and from situation to situation. A user wants to use these attributes in an input help to define a value for a field that requires that a formal key be entered.

    We therefore need search paths permitting access to the data using non-key fields. Several different search paths should be possible for one field.

    A search path for a field can be implemented with a search help having the form described above. To describe an input help with more than one alternative search path, a set of search helps can be combined into a new object in the R/3 System. Since this object is the description of the input help for a field, it is also calle d a search help.

    In contrast to the elementary search helps described above, the search helps that combine several search paths are called collective search helps .

    Collective search helps are sometimes used to map the distribution of the possible entries for a field into several (disjunct) datasets.

    Like an elementary search help, a collective search help has an interface of IMPORT and EXPORT parameters with which it exchanges data. Using this interface, the collective search help can be attached to fields, tables and data elements exactly like an elementary search help. Only one search help can be attached to a field, table or data element. Several search paths are therefore attached with a collective search help.

    You can omit the components for describing the dialog behavior and data selection when you define a collective search help. The included search helps are listed here. You must assign the parameters of the collective search help to the interface parameters of the included search help for each inclusion.

    A search help can also be included in several collective search helps and at the same time itself be attached to fields, tables and data elements. A collective search help can also be included in another collective search help.

    When you use a collective search help, you are offered the elementary search helps contained in the collective search help as parallel tab pages. If you repeatedly use a collective search help, the tab page that was last used is automatically active. This is because most users always use the same search path.

    The set of search paths that are meaningful for an object greatly depends on the particular circumstances of the SAP customer. The customer often would like to enhance the standard SAP collective search helps with his own elementary search helps. Release 4.6 provides an append technique that permits the enhancement of collective search helps without modifications.

    An append search help is a collective search help that is assigned to another collective search help (its appending object) and that enhances it with the search helps it includes. The append search help uses the interface of its appending objects.

    The append search help lies in the customer namespace. Normally the search helps included in the append search help are also created by the customer and lie in the customer's namespace. However, the required elementary search help might already be provided by SAP, in which case the customer only has to add it to his own append search help.

    Append search helps are used with SAP to improve component separation. Some SAP collective search helps therefore already have one or more append search helps in the standard search help. Customer enhancements should always be made by creating a separate append search help.

    SAP collective search helps often contain elementary search helps that are not required by all customers. The search helps you do not need can be hidden using an append search help. To do this, the corresponding search help must be included in the append search help and the hidden flag must be set.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Mar 28, 2008 at 05:51 PM

    hi chaitanya,

    use append structures.....

    Append Structures

    Append structures are used for enhancements that are not included in the standard. This includes special developments, country versions and adding customer fields to any tables or structures.

    An append structure is a structure that is assigned to exactly one table or structure. There can be more than one append structure for a table or structure.

    The following enhancements can be made to a table or structure TAB with an append structure:

    · Insert new fields in TAB,

    · Define foreign keys for fields of TAB that already exist,

    · Attach search helps to fields of TAB that already exist,

    These enhancements are part of the append structure, i.e. they must always be changed and transported with the append structure.

    When a table or structure is activated, all the append structures of the table are searched and the fields of these append structures are added to the table or structure. Foreign keys and search help attachments added using the append structure are also added to the table. If an append structure is created or changed, the table or structure assigned to it is also adjusted to these changes when the append structure is activated.

    Since the order of the fields in the ABAP Dictionary can differ from the order of the fields on the database, adding append structures or inserting fields in such append structures does not result in a table conversion.

    The customer creates append structures in the customer namespace. The append structure is thus protected against overwriting during an upgrade. The fields in the append structure should also reside in the customer namespace, that is the field names should begin with ZZ or YY. This prevents name conflicts with fields inserted in the table by SAP.

    If you create an append structure for a table or structure, only those enhancements are allowed that are consistent with the enhancement category of the enhanced table or structure. For more information, see Structure Enhancements.

    The new versions of the standard tables are imported after an upgrade, and the fields, foreign key definitions and search help attachments contained in the append structures are added to the new standard tables at activation.

    A standard table contains the fields Field 1, Field 2 and Field 3. An append structure containing the fields ZZA and ZZB is defined for this table. After activating the table, the corresponding database table contains fields Field 1, Field 2, Field 3, ZZA and ZZB.

    Further Remarks:

    · An append structure can only be assigned to exactly one table or structure. If you want to append the same fields to several tables or structures, you can store these fields in an include structure. In this case you must create an append structure for each of these tables or structures and include the include structure there.

    · Adding an append structure to an SAP standard table is supported by the Modification Assistant.

    · If you want to insert a field that is to be delivered with the standard in the next Release in the customer system in advance, you must include it in the table itself as a repair. If you include such a field in an append structure for the table, it will occur twice when the new standard table is imported. This will result in an activation error.

    · No append structures may be added to tables with long fields (data types VARC, LCHR or LRAW). This is because a long field must always be the last field in the table. However, structures with long fields can be enhanced with append structures.

    · If a table or structure with an append structure is copied, the fields of the append structure become fields of the target table. Foreign key definitions and search help attachments appended with the append structure are copied to the target table.

    · Foreign keys for the appended fields must be defined within the append structure. Fields of the table or structure assigned to the append structure may be defined when assigning the key field and foreign key field.

    · Indexes on the appended fields must be defined in the original table.

    · A table or structure TAB can only be enhanced with new foreign keys or search help attachments using an append structure. You therefore cannot change an existing foreign key definition or search help attachment for a field of TAB with the append structure

    How To Add New Fields To Field Catalog

    For adding field into Field catalog:

    I shall give an example. But you should first identify the field for Profit Center (Design ID) and then do as follows:

    For example if you want to use field PSTYV (’Sales document item category’) that is included in structure KOMP (’Pricing Communication Item’) as a key for a condition table.

    When you create a condition table (Transaction V/03), however, the system does not propose the field in the field catalog.

    Prerequisites:

    For technical reasons, field PSTYV was included in structure KOMP, however, not in structure KOMG (’Allowed Fields for Condition Structures’).

    To solve the problem, proceed as follows:

    1. Call up the ABAP Dictionary (Transaction SE11) and create data type ZZPSTYV. Choose PSTYV as a domain.As a short text, you can use, for example, ‘ZZ - sales document item category’ and as a field label, you can use the field labels of PSTYV.Save, check and activate your entries.

    2. Call up structure KOMPAZ in the ABAP Dictionary (Transaction SE11) in the change mode and make the following entry:

    Component Component type

    ZZPSTYV ZZPSTYV

    Save, check and activate the change you made.

    3. Note:Because of the change in structure KOMPAZ, field ZZPSTYV is now known in structures KOMG and KOMP because structure KOMPAZ is included in both structures.

    4. Call up Transaction SPRO. Navigate to ‘Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control’ and execute ‘Define Condition Tables’. Choose ‘Conditions: Allowed fields’ and include ZZPSTYV as a new entry.

    5. Note:Now you can use field ZZPSTYV as a key field when you create a condition table Axxx.

    6. Supply the new field you defined by including the following source code line in USEREXIT_PRICING_PREPARE_TKOMP:

    MOVE xxxx-PSTYV TO TKOMP-ZZPSTYV.

    In order processing you find the user exit in Include MV45AFZZ, and in billing document processing you find it in Include RV60AFZZ.

    Consider that you can also use this note as a help if you want to use other customer-specific fields as key fields in a condition table.For header fields, use structure

    KOMKAZ instead of structure KOMPAZ and USEREXIT_PRICING_PREPARE_TKOMK instead of USEREXIT_PRICING_PREPARE_TKOMP.

    For more information, see Transaction SPRO via the path ‘Sales and Distribution -> System Modifications -> Create New Fields (Using Condition

    Technique) -> New Fields for Pricing’ and Note 21040.

    For creating a condition Table:

    1) There are almost all the regularly used Conditon Table predefined in the system from 001 to 500.

    See what best you can use the Standard Tables to avoid further errors.

    2) In case you should define the new condtion Table,

    a) Goto TCode: V/03

    b) Give a Table any number from 501-999

    Press execute and reach to next screen.

    c) Check up whether the field you are looking is already added in Field catalogue.

    d) Double click on the fields you want to make a Table..one by one. Note that the sequence here is important in higher hierarchical to lower..

    Eample : Sales Org, DC, Division, Customer and then Material etc..,

    e) After selecting, click on the Techincal View buttin (redone) and reach to next screen.

    7) Check which key should be in header and which key should be footer. Use check and uncheck functionalities there..

    <! ><! >Once you are through with all the above steps ..click on generate button.

    Check the Table is generated or not.

    You can check it at V/04 or V/05 or in SE11

    thanks

    karthik

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Apr 06, 2008 at 03:37 PM

    Hello KARTIKEYA PRASAD and RAVI,

    I am very sorry for the late response...

    Thank you for your response!

    The response that u had provided was helpful.

    Points are rewarded......

    Have a great day!

    Regards,

    Krishna Chaitanya

    Edited by: Krishna Chaitanya on Apr 6, 2008 5:38 PM

    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.