Regarding matchcode

Question

hi to all experts,
                          my question is what are match code and matchcode id . what are the differences between search help and match codes.help me  very urgent.

Answer 1

Hi
Match codes and search helps both are same which are used as a search tool for getting the fields values from a table
Here is complete Overview of Match code with each and everypoint covered
Match Code
Matchcodes are an SAP technique to help users find information, normally in
connection with the F4 key on an input field. Information from one or more
tables can be combined and queried on using various search criteria: for
example, all companies whose name starts with "LEVI" and whose location is
"San Francisco."
<b>How are matchcodes implemented?</b>
Traditionally, matchcodes were implemented as redundant collections of data
in pool tables, as illustrated in the following:
Company header table     Company detail table       Matchcode pool table
     (TAB1)               (TAB2)               (M_POOL)
The advantage of the old pool matchcodes was a quick and easy search, as
long as the significant fields were entered by the end user (in this case,
company name and location). The disadvantage was that for every change in
the master tables, the system had to make redundant updates in the matchcode
tables. In addition, it was impossible to search in a pool matchcode for any
but the significant fields, i.e., it would have been very CPU intensive to
search for all companies in San Francisco.
This limitation led to the creation of matchcodes (more precisely, in SAP
terms, "matchcode IDs") for every possible query you could expect from end
users (one with company name as the significant field, one with location,
yet another with customer number, and so on). Customers with a very high
number of debitors, for example, soon found that their pool matchcode tables 
grew to unmanageable sizes.
As of release 2.1, it is now possible to define so-called transparent or
view matchcodes. Transparent matchcodes are implemented by defining a
database view for the information that should be queried. Database views are
not redundant containers of data, but are merely definitions of paths to
obtaining that data. In the example:
Company header table      Company detail table          Database view:
     (TAB1)               (TAB2)               (M_VIEW)
The advantage of this new technique is that it is no longer necessary to
maintain redundant matchcode data: a view takes only a small amount of
database dictionary space. Using this technique, the query is converted by
the database to a query against the original tables, so it becomes very
important that access be supported by the proper indexes.
Matchcode Customizing
When a transparent matchcode ID is activated, the system checks if an
appropriate index exists for the ID. Normally, such an index is necessary to
support the matchcode query. If such an index does not exist, there can be
major performance problems during matchcode selection. The system assumes
that the first field in the matchcode definition (for client-dependent match
codes the first field after the client field) is the relevant search field,
i.e., that the user will narrow down the search by entering a selection
criterion in this field.
An index is considered appropriate for the matchcode if it contains this
relevant matchcode field (or the client field followed by this field).
If no such index exists, a warning is given during the activation of the
matchcode ID. At this point, there are two possible courses of action:
1) If the matchcode view in the database covers less than 1,000 data
records, it is not necessary to create an index.
2) If the matchcode view will search more than 1,000 records, you should
create an index.
The first fields of an index to support matchcode selection should be
those that will be searched with equality (client, language or general
fields for which the get/set indicator has been set, i.e., the flag GP is
set for the field in the screen Update Matchcode ID Fields).
The index should have the following structure:
Client field - Fields for which the Get Parameter flag is set
Search fields - This index structure does not guarantee that the index will
be used by the underlying database system. Which index is used depends on
the database system's optimizer. You must verify that the index you have
created actually is used by the database.
Use the following method to determine whether the proper index is being used
to support the matchcode query:
Open a second session and choose System / Utilities / SQL Trace.
Select Trace on.
In your first session, do a search on your matchcode ID.
In your second session, choose Trace off and then List trace.
Search in your list for the first statement in which the matchcode view
occurs. Use the function Explain SQL to obtain information about how the
optimizer services the query. In particular, you can see which index is used.
Surplus matchcodes:
Before Release 3.0, surplus matchcode IDs should be deleted.
As of Release 3.0, surplus matchcodes IDs should be deactivated.
Deleting matchcode IDs (before Release 3.0)
Before you can delete a matchcode ID, you must check if it is a "system
matchcode." You can tell this by looking at the field System matchcode on
the screen Update Matchcode ID (Attributes). If this field is set, SAP uses
this matchcode ID. You should never delete a system matchcode ID!
Unfortunately, the dictionary transactions will allow you to delete system
matchcodes, so you should be extremely careful to check this flag and don't
delete a matchcode ID for which the flag is set.
If the flag System matchcode is not set, you must check which programs
use the matchcode. Use the general table display function (se16) and enter
the matchcode object and matchcode ID as the table name.
Deactivating matchcode IDs (as of Release 3.0)
The function Deactivate in the menu MC-Id of the screen Update Matchcode ID
(Attributes) allows you to reduce the load of unnecessary matchcode IDs.
Rather than deleting the ID, the dictionary definition remains available in
the ABAP/4 dictionary. If at some point the ID is needed again, it can
simply be reactivated.
The function Deactivate can only be used for active matchcode IDs. Before a
matchcode ID can be deactivated, the corresponding objects in the database
must be deleted (e.g., the view and possibly the index for IDs of update
type I).
Note that when you deactivate a matchcode ID of update type S, the matchcode
records will no longer be updated to keep up with application data. If you
reactivate a matchcode ID, you must re-create the matchcode records with the
matchcode utilities.
Note also that the deactivated matchcode IDs will not appear in F4 help.
Warning: Deactivation is a pure customizing function, i.e., not a
transportable characteristic.
If a deactivated matchcode ID is delivered again by SAP, it will be active
again after the upgrade.
Conversion to transparent matchcodes
Prerequisites for conversion
To convert a "physically stored" (pool) matchcode ID to transparent (view),
the following condition must be met:
All underlying tables of the ID must be transparent; no partial fields can
be used.
Note that when converting a program-controlled ID, you may need to adapt
the application programs.
Conversion procedure
To convert a physically stored matchcode ID (update type A, S or P) to
transparent (update type I), proceed as follows: Copy the ID you wish to
convert to the customer name range (IDs 0 to 9). Change the update type to
I and activate the ID.
If the original ID has the update type S, change the original to update type
A. This prevents unnecessary updates of the old ID. In Release 3.0, you
should simply deactivate the original ID.
Changes after the conversion
Searches are case sensitive
Queries on transparent matchcode IDs are case sensitive, i.e., when entering
a search argument in the text field, there is a distinction between upper
and lower case. The search string "hugo" would not match with the value
"Hugo" in the database. In some applications, there have been text fields
added to the original tables in which information is held redundantly in
upper case. If you use these fields in the matchcode ID, you can avoid this
problem of case sensitivity.
Sort order in output changes
For releases 2.1G to 2.1J, the output list is sorted by the index that the
optimizer chose for accessing the ID. As of 2.2E, the sort order depends on
the field order in the ID, i.e., the sort order will correspond to that of
the physical matchcode IDs. Transparent IDs that were not delivered with
2.2E must be activated again to have this new sort order.
Result set of a query can be smaller
The result set of a query on a transparent ID can be a real subset of the
results of an equivalent query on a physical matchcode ID. This is because
of the fact that transparent IDs are implemented with an inner join, whereas
the physical matchcodes are realized with an implicit outer join.
When searching with a transparent ID, records of a primary table that have
no corresponding entries in the foreign key fields of a secondary table will
not be found.
<b>Example:</b> An ID provides the search for an employee's personnel number using
name and department. The primary table contains the personnel number and
name. The secondary table contains departments and their employees.
Employees who have not been assigned to a department have no entry in the
secondary table. THose employees will not be found in a search with a
transparent matchcode with fields number, name and department. In a physical
matchcode ID with the same fields, those employees will be found.
Adapting partial fields
Partial fields in matchcodes are fields that you have defined so only a
portion of the original field is displayed and maintained in the matchcode.
You might want to show, for example, only the last six positions of SAP's
standard 16-character material number. If you defined partial fields for
the matchcode ID, their definitions must be removed to convert to a
transparent matchcode.
Further information
Issues especially for programmed matchcodes (update type P)
Programmed matchcodes are implemented physically, i.e., the matchcode data
is held redundantly in a separate table. The data is updated directly by
application programs, so that these application programs and other programs
always have access to the latest matchcode data. A function module is
generated during activation of the matchcode. The matchcode data is updated
when this function module is called. Conversion of programmed matchcodes to
transparent requires changes to the application programs that use the
function module. It is possible to just comment out the call to the function
module.
Adding tables to a matchcode object that contains a programmed matchcode ID
can lead to difficulties. Only one function module exists for all programmed
IDs in the object. This function module gets its information directly from
the matchcode object. For this reason, the function module interface should
be modified whenever the basis table of the object is changed, even if this
modification does not directly concern the programmed matchcode IDs.
Common problems with matchcode tables
Excessively large matchcode pool tables<Development Class [Save[Choose Sec. Tab. "presents candidate list
(&Tablename [Choose)... [Copy
[Fields
[Yes "Save before terminating Editing?
[Enter
(&Tablename [Choose Fields #Choosefields)..
[Save [Back [Activate
"Match Code Object is now created and activated.
<b>Or simply follow this</b>
SE11à Search Help àZmatchcode(Give ur name with starting Z) à F5(Create)
àShort Descriptionà Selection Method(Select your table or press F4 and select)
àDialog Type(Display Values Immediately,Dialog Depends on Set of Values, Dialog with restriction.)
*For present you can select Display Values Immediately*
Next goto Search Help Parameter declare your fields from table which already you had declared above. Then select both Import & Export Paramaters Give Lpos & Spos 1. Then check(Ctrl+F2) Then activate it.
Search Help
A search help is an object of the ABAP Dictionary with which input helps (F4 helps) can be defined.
There are the following types of search helps:
· Elementary search helps implement a search path for determining the possible entries.
· Collective search helps contain several elementary search helps. A collective search help therefore provides several alternative search paths for possible entries.
· Append search helps can be used to enhance collective search helps delivered by SAP with customer-specific search paths without requiring a modification.
The three components of the input help process described by a search help are the outer interface, the online behavior and the method of data collection.
The outer interface is defined by specifying the interface parameters They define the context information to be used in the input help process and the attributes to be sent to the screen by the input help.
The search help attachment defines the field contents for parametrizing an import parameter and the fields of the input template in which the contents of the export parameters should be returned.
The dialog behavior and data collection are defined differently for elementary search helps and collective search helps.
The behavior of a search help can be made more flexible than usual with search help exits
Elementary Search
An elementary search help is a search help that describes an input help process in which it is not possible to select one of a number of search paths.
The online behavior of an elementary search help is controlled by defining the dialog type and by specifying the fields to be displayed in the dialog box for restricting values or in the dialog box for displaying the hit list (including the order in these dialog boxes). These fields must be defined as parameters of the search help.
For data collection, a database table or a view is normally defined and the possible values are selected here. This table/view is called the selection method of the search help. If the selection method is a table, a text table can also be used for collecting data if one exists. In the selection, those fields of the selection method (and possibly of the text table) which have parameters with the same names in the search help are used.
If the standard options for describing the online behavior or data collection for the search help are not sufficient, you can define its behavior more flexibly by using a search help exit
Collective Search
A collective search help describes an input help process in which the user can choose one of several alternative search paths. Each alternative search path corresponds to an elementary search help i.e. a collective search help contains several elementary search helps.
Both elementary search helps and other collective search helps can be included in a collective search help. if a collective search help contains other collective search helps, they are resolved down to the level of the elementary search helps when the input help is called.
Like an elementary search help, a collective search help has an interface of import and export parametersThe data is exchanged between the screen template and the parameters of the elementary search helps contained in it using this interface. The parameters of the search helps included in a collective search help must be assigned to the parameters of the collective search help.
During the input help process, the collective search help only controls the user's selection of the required search path. The rest of the dialog and data collection is controlled by the selected elementary search help. If selection of the required elementary search help should be made flexible (e.g. with context-specific definition of the set of available search paths), the collective search help must be assigned a search help exit
Append Search
An append search help is used for modification-free enhancement of a collective search help (that is not the original in the current system) with further search help inclusions. This technique can be used for example in special developments and country versions, and by SAP partners and customers to add further search paths to a collective search help of the standard system.
An append search help has a fixed assignment to a collective search help (its appending object). This appending object is enhanced with the append search help.
The structure of an append search help corresponds to that of a collective search help, but the append search help takes on the parameters of its appending object so that it cannot be maintained separately any longer. Furthermore, an append search help cannot be assigned a search help exit.
An append search help is automatically included in its appending object. The parameters of the two search helps having the same name are assigned to each other.
Note: You can also hide modification-free search helps from a collective search help with an append search help. You have to insert the search help to be hidden in the append search help and then hide the inclusion there. The search path(s) defined by this search help are no longer offered in the appending search help. To cancel this, remove the hidden inclusion again from the append search help.
Note: Append search helps can also be used themselves to describe an input help. They are treated like collective search helps.
Note: If the parameters of the appending object change, this change is not automatically made in the append search help. Instead, you are informed that the parameters of the append search help should be adjusted. In this case you should check if you want to change the assignments between the parameters of the append search help and the search helps included in them.
Procedure: Proceed as follows to enhance a collective search help of the standard system with your own search paths:
1. For each search path, create an elementary search help in your namespace and activate these search helps.
2. In display mode, go to the maintenance screen for the collective search help and choose Goto -> Append search helps. Create the append search help in your namespace.
3. Include the elementary search help defined in the first step in the append search help. Maintain the parameter assignments between the parameters of the append search help and the parameters of the included search helps.
4. Activate the append search help. The append search help is automatically added to your appending object. The search paths inserted in the append search help are now available in the collective search help. They appear at the end of the list of available elementary search helps.
Search Help Exit
A search help exit is a function module for making the input help process described by the search help more flexible than possible with the standard version.
This function module must have the same interface as function module F4IF_SHLP_EXIT_EXAMPLE. The search help exit may also have further optional parameters (in particular any EXPORTING parameters).
A search help exit is called at certain timepoints in the input help process.
Note: The source text and long documentation of the above-specified function module (including the long documentation about the parameters) contain information about using search help exits.
Function modules are provided in the function library for operations that are frequently executed in search help exits. The names of these function modules begin with the prefix F4UT_. These function modules can either be used directly as search help exits or used within other search help exits. You can find precise instructions for use in the long documentation for the corresponding function module.
This module has been created as an example for the interface and design of Search help exits in Search help
All the interface parameters defined here are mandatory for a function module to be used as a search help exit, because the calling program does not know which parameters are actually used internally.
A search help exit is called repeatedly in connection with several
Events during the F4 process. The relevant step of the process is passed on in the CALLCONTROL step. If the module is intended to perform only a few modifications before the step, CALLCONTROL-STEP should remain unchanged.
However, if the step is performed completely by the module, the following step must be returned in CALLCONTROL-STEP.
For more detailed information please refer to the documentation describing the concept of the search help exit.
The module must react with an immediate EXIT to all steps that it does not know or does not want to handle.
During the input help process, a number of timepoints are defined that each define the beginning of an important operation of the input help process.
If the input help process is defined with a search help having a search help exit, this search help exit is called at each of these timepoints. If required, the search help exit can also influence the process and even determine that the process should be continued at a different timepoint.
The following timepoints are defined:</b></u>
1. <b>SELONE</b>
Call before selecting an elementary search help. The possible elementary search helps are already in SHLP_TAB. This timepoint can be used in a search help exit of a collective search help to restrict the selection possibilities for the elementary search helps.
Entries that are deleted from SHLP_TAB in this step are not offered in the elementary search help selection. If there is only one entry remaining in SHLP_TAB, the dialog box for selecting elementary search helps is skipped. You may not change the next timepoint.
The timepoint is not accessed again if another elementary search help is to be selected during the dialog.
2. <b>PRESEL1</b>
After selecting an elementary search help. Table INTERFACE has not yet been copied to table SELOPT at this timepoint in the definition of the search help (type SHLP_DESCR_T). This means that you can still influence the attachment of the search help to the screen here. (Table INTERFACE contains the information about how the search help parameters are related to the screen fields).
3.<b> PRESEL</b>
Before sending the dialog box for restricting values. This timepoint is suitable for predefining the value restriction or for completely suppressing or copying the dialog.
4. <b>SELECT</b>
Before selecting the values. If you do not want the default selection, you should copy this timepoint with a search help exit. DISP should be set as the next timepoint.
5. <b>DISP</b>
Before displaying the hit list. This timepoint is suitable for restricting the values to be displayed, e.g. depending on authorizations.
6.<b> RETURN</b> (usually as return value for the next timepoint)
The RETURN timepoint should be returned as the next step if a single hit was selected in a search help exit.
It can make sense to change the F4 flow at this timepoint if control of the process sequence of the Transaction should depend on the selected value (typical example: setting SET/GET parameters). However, you should note that the process will then depend on whether a value was entered manually or with an input help.
7.<b> RETTOP</b>
You only go to this timepoint if the input help is controlled by a collective search help. It directly follows the timepoint RETURN. The search help exit of the collective search help, however, is called at timepoint RETTOP.
8. <b>EXIT</b> (only for return as next timepoint)
The EXIT timepoint should be returned as the next step if the user had the opportunity to terminate the dialog within the search help exit.
9. <b>CREATE</b>
The CREATE timepoint is only accessed if the user selects the function "Create new values". This function is only available if field CUSTTAB of the control string CALLCONTROL was given a value not equal to SPACE earlier on.
The name of the (customizing) table to be maintained is normally entered there. The next step returned after CREATE should be SELECT so that the newly entered value can be selected and then displayed.
10. APP1, APP2, APP3
If further pushbuttons are introduced in the hit list with function module F4UT_LIST_EXIT, these timepoints are introduced. They are accessed when the user presses the corresponding pushbutton.
Note: If the F4 help is controlled by a collective search help, the search help exit of the collective search help is called at timepoints SELONE and RETTOP. (RETTOP only if the user selects a value.) At all other timepoints the search help exit of the selected elementary search help is called.
If the F4 help is controlled by an elementary search help, timepoint RETTOP is not executed. The search help exit of the elementary search help is called at timepoint SELONE (at the moment). This search help exit should not do anything at this timepoint. Any preparatory work should be carried out at timepoint PRESEL1.
<b>Standard Search Help Exit for Changing Hit List</b>
Functionality of F4UT_LIST_EXIT
With this module you can create another pushbutton in the hit list of an input help in addition to the standard pushbuttons. You can freely define the functionality behind this pushbutton .
To use this option, you must describe the input help process with a search help. You must write a search help exit for this search help and call this module in the search help exit at timepoint 'DISP'. Define the attributes of the pushbutton with IMPORT parameters NAME, ICON_TEXT, QUICKINFO and TEXT (see also the long documentation for these parameters).
Then assign a function code to the pushbutton in IMPORT parameter FCODE. It must have one of the following values: APP1, APP2, or APP3.
If the user presses the pushbutton defined in this way, the search help exit is called again. The function code defined previously in FCODE is passed as the timepoint.
Example
You can find an example of using this function module in the search help exit SAPBC_GLOBAL_F4_SFLIGHT_DISEDI of search help SFLIGHT_WITH_DISPLAY_AND_EDIT.
Notes· You can create up to three additional pushbuttons with the three possible function codes in the hit list by calling this module repeatedly.
· When handling the additional functions, you can use function module F4UT_LIST_EXIT_GET_INFO to get information about the status of the hit list.
· If the IMPORT parameter is set to REMOVE, the pushbutton is removed from the hit list with the function code defined by FCODE. Parameters NAME, ICON_TEXT, QUICKINFO and TEXT are meaningless in this case.
· The other parameters of this module must be defined as the parameters of the search help exit having the same name.
Functionality of F4UT_LIST_EXIT_GET_INFO
With this module you can obtain information about the status of the hit list when handling a self-defined supplementary function (see function module F4UT_LIST_EXIT) within a search help exit.
EXPORT parameter LINE contains the number of the line of the hit list where the cursor was when the function was triggered. This value is 0 if the cursor was in the column title or in the area of the constant columns removed from the list at this time.
EXPORT parameter PARAMETER contains the name of the search help parameter where the cursor was positioned when the function was triggered. Normally this means that the cursor was positioned in the corresponding column of the hit list. If the contents of the parameter, however, were removed from the list as constant value, the cursor was positioned in the corresponding line over the hit list.
EXPORT parameter MARK_TAB is only filled if the input help was called with multiple choice. In this case this parameter contains the list of line numbers that were marked in the hit list when the function was triggered.
Notes
· This module only works at timepoints APP1, APP2, APP3.
· The TABLES and CHANGING parameters of this module must be parametrized with the parameters of the search help exit having the same name.
Search Help Inclusion
The search help inclusion is the mechanism with which the alternative search paths defining the behavior can be assigned to a collective search help
In a search help inclusion, any other search help can be assigned to the including collective search help. Normally the included search help will be an elementary search help In this case the search path implemented by this search help will become one of the alternative search paths of the including search help. If the included search help is also a collective search help itself, all the elementary search helps contained in this collective search help will become alternative search paths of the including collective search help. In such a multi-level inclusion, however, you must note the following special features
Passing on the context information and returning the selected attributes on the screen is described by the assignment made between the parameters of the including search help and the interface parameters of the included search help.
The search help inclusion is a part of the definition of the including search help. A search help can be included in any number of search helps.
Note: An append search help is automatically included in its appending object. You may not include an append search help in other collective search helps.
When you include a collective search help I in a collective search help S, you should note the following features:
· When you display the search paths available in S, all the search helps contained in S are resolved to the level of the elementary search helps.
· If an elementary search help is contained more than once in a collective search help, e.g. because it is contained in more than one of the included search helps, it is offered only once in the dialog box for selecting the search path ( shadowing mechanism).
· If I has a search help exit, it is not taken into consideration in an input help process defined by S.
· Context information is transported to the input help process and from field contents from the input help process with the assignment for the parameters of I and S made during the inclusion.
· If parameter PAR of I is not an IMPORT parameter or if it was not assigned to a parameter of S in the inclusion, any existing default value of PAR is passed to all IMPORT parameters of included search helps that are linked with PAR.
· I may not contain S (or be the same as S).
Shadowing mechanism
If a collective search help S contains two search helps I and J which in turn contain a fourth search help U, a shadowing mechanism takes effect. If U is contained in I or J, it is shadowed (depending on which inclusion in S comes last). If J = U, however, J must precede I as otherwise the inclusion of J in S would be meaningless.
Default Value
A default value of the right type can be assigned to a parameter of a search help. The parameter is assigned this default value in the following cases when the input help is called:
1. If the parameter is not an IMPORT parameter.
2. If nothing is assigned to the parameter in the search help attachment with which the search help is attached to the screen field.
3. If in the search help attachment a field was assigned to the parameter that does not exist on the screen or in the flow logic (module pool) in the input help process.
4. If a search help is included in a collective search help and the parameter is not linked with any parameter of this collective search help.
There are the following options for the default values:
a) Constants enclosed in apostrophes ('). The constant must be specified in internal representation for parameters whose data type has an editing mask (e.g. date and time). For example the date 01.03.1998 must be defined as '19980301'.
b) System fields. These are fields of the DDIC structure SYST where the prefix SY- can be used instead of the prefix SYST-.
c) The ID of a GET parameter.
Set/Get parameter ID
A field can be filled with proposed values from SAP memory using a parameter ID.
Example
A user only has authorization for company code 0001. This company code is stored in memory at the beginning of a transaction under the corresponding parameter ID. Fields that refer to the data element are automatically filled with the value 001 in all subsequent screen templates.
Dependencies
A field in the screen template is only filled automatically with the value stored under the parameter ID of the data element if this was explicitly permitted in the Screen Painter.
Position in the hit list of an elementary search help
Position of the parameterin the hit list.
If the parameter should not appear in the hit list, leave this field empty. No position number may occur more than once in this column, but gaps are allowed. They do not affect the design of the hit list.
Example: An elementary search help contains parameters PAR1, PAR2, PAR3 and PAR4. Field LPos is defined as follows:
Parameter LPos
PAR1 3
PAR2 0 or ' '
PAR3 1
PAR4 7
Parameters PAR3, PAR1 und PAR4 appear in this order in the hit list.
Note: In an elementary search help, at least one parameter should appear in the hit list. The only exception to this rule is the elementary search help, in which the display of the hit list is entirely copied from a search help exit
Text table
Table A is the text table of table B if the key of A comprises the key of B and an additional language key field (field with data type LANG). Table A can therefore contain explanatory text in several languages for each key entry of B.
To link the key entries with the text, text table A must be linked with table B using a foreign key. Key fields of a text table must be selected for the type of foreign key fields.
Only one text table can be created for a table. When it is activated, the system checks whether another table already has a text foreign key for the specified table.
If a text table exists, it is used at different places in the system to show the text for the key entries in the logon language of the user automatically.
If for example table B is the check table of a field, the existing key entries of table B are displayed as possible input values when F4 is pressed. The explanatory text is also shown in the logon language of the user for each key value.
Selection method of an elementary search help
The possible entries for a field displayed in the hit list are determined at runtime by selection from the database. The selection method describes the database object from which the data is read. A database table or view can be defined as selection method.
To use a field of the selection method in the input help (as field in the dialog box for restricting values, as column in the hit list or as value returned to the screen), a parameter with the same name must be inserted in the search help.
Process On Value request
PROCESS ON VALUE-REQUEST.
Event in user-programmed help that occurs when the user presses F4 with the cursor positioned on a screen field. The modules specified in the subsequent FIELD statements are called instead of the SAP help system.
<b>Example</b>
FIELD XY MODULE XYZ
Module XYZ determines the value of field XY and places it in the input field on the screen.
VALUES
Definition of the valid input values:
FIELD field_name VALUES (list of values)
The list of values can define single values and/or intervals for input values that are allowed or not allowed. The values must be enclosed in apostrophes and separated with a comma.
('value') valid single value
(NOT 'value') invalid single value
(BETWEEN 'value' AND 'value') valid values in the interval
(NOT BETWEEN 'value' AND 'value') invalid values in the interval
SELECT
SQL interface  
SELECT * FROM  table name
         WHERE table-keyfield = inputfield
         and   ....
         INTO  fieldname
         WHENEVER  NOT FOUND          (or FOUND)
                   SEND ERRORMESSAGE  (or WARNING)
                        messagenumber
                        WITH  fieldname ...
You do not have to specify a message number and var. texts (WITH). If there is an error (FOUND or NOT FOUND), a standard message is output.
If the INTO ... statement is not defined, the table entry is not read in.
Check table
Table whose key fields are used to check the foreign key fields (see Foreign Keys). Only entries that are contained in the key fields of the check table can be contained in the foreign key fields.
The check table is used to check whether the input values are valid and for the input help (F4 help).
Foreign key
A foreign key creates a link between two tables T1 and T2. Every primary key field from T1 (check table) is assigned a field from table T2 (foreign key field). The fields from T2 assigned to primary key fields are marked as foreign key fields.
The most important function of the foreign key is the support of data integrity. The foreign key fields can only accept values which appear in the primary key of the check table. During input the values of the foreign key fields can thus be checked against the entries of the assigned key fields of the check table.
Foreign keys are also the foundation for defining lock objects, maintenance views and help views. These objects contain fields from several tables. All the tables used in such an object must be linked with foreign keys.
Dialog type
The dialog type defines the dialog steps executed for an input help.
There are the following dialog types:
· Immediate value display: The hit list is displayed immediately after the input help has been called. This option is advisable if the hit list usually contains only a few entries.
· Dialog with value restriction: The dialog box for restricting values is displayed immediately. Select this option if the list of possible entries is normally very large. Restricting the set of data to be processed increases the clarity of the hit list and reduces the system load during value selection.
· Dialog depends on value set: If the hit list contains less than 100 entries, it is displayed immediately. If the hit list contains more than 100 entries, the dialog box for restricting values is displayed.
Search Help Parameter
A search help parameter is a field for controlling the behavior of a search help.
There are the following roles for search help parameters, where a parameter can have more than one role:
1.
Import parameters: These are parameters with which context information can be copied to the input help process from the input template or from the module pool of the processed screen.
2. Export parameters: These are parameters with which values can be returned to the input template from the input help process.
3. Internal parameters: These are parameters used for the input help process. Further data can be applied in the input help process using parameters that appear in the dialog box for restricting values or that have a default value. Furthermore, all the fields displayed in the hit list are internal parameters of the search help.
Import and export parameters of the search help are also called their interface parameters.
The corresponding assignment of the search help attachment or search help inclusion control the field contents with which an import parameter is parametrized and the fields of the input template in which the contents of the export parameters should be returned. However, you should note that the values are not returned beyond the limits of a subscreen or a line of a step loop or table control
The fields of the selection method are assigned to the parameters of an elementary search help by equality of name. The non-key fields of a text table may also be specified.
Types must be defined for the parameters of a search help. The parameters of elementasry search helps normally take on the attributes of the fields of the selection method having the same name. The types are defined by assigning a data element to the parameter. This field or data element also defines the behavior of the parameter at the interface for parameters that also appear in one of the dialog boxes of the input help process.
Default Value
A default value of the right type can be assigned to a parameter of a search help. The parameter is assigned this default value in the following cases when the input help is called:
1. If the parameter is not an IMPORT parameter.
2. If nothing is assigned to the parameter in the search help attachment with which the search help is attached to the screen field.
3. If in the search help attachment a field was assigned to the parameter that does not exist on the screen or in the flow logic (module pool) in the input help process.
4. If a search help is included in a collective search help and the parameter is not linked with any parameter of this collective search help.
There are the following options for the default values:
a) Constants enclosed in apostrophes ('). The constant must be specified in internal representation for parameters whose data type has an editing mask (e.g. date and time). For example the date 01.03.1998 must be defined as '19980301'.
b) System fields. These are fields of the DDIC structure SYST where the prefix SY- can be used instead of the prefix SYST-.
c) The ID of a GET parameter.
Search Help Attachments
A search help attachment is an assignment of a search help to a table, structure or data element, causing the corresponding search help to be automatically used to describe the input help process at this field when an ABAP Dictionary field is used in a screen.
You can attach a search help as follows:
1. Attach a search help to a structure or table field: The attached search help is available for all screen fields that refer to the table or structure field. There must be an assignment between the interface parameters of the search help and the fields of the table or structure for this type of attachment. In the input help process, this assignment results in a value transport between the corresponding fields (if they are known at least to the module pool of the screen) and the search help parameters. As for the foreign key definition, you can assign nothing, a constant or any other field (which is then sought in the module pool) to indivdiual search help parameters.
2. Attach a search help to a table: The assigned search help is available for all screen fields for which the table is a check table There must also be an assignment between the search help parameters and the key fields of the table for this type of assignment.
3. Attach a search help to a data element: The attached search help is available for all screen fields that refer to the data element. If the search help is attached to a data element, an export parameter of the search help must be assigned to the data element. If the user chooses a row of the hit list in the input help, the contents of this parameter are returned in the corresponding screen field. More than one value is not returned when a search help is attached to a data element.
The described attachments only take effect if the field was not yet assigned an input help in the screen definition. Such an assignment can be made with the mechanism PROCESS ON VALUE-REQUEST in the flow logic or by attaching a search help to the screen field in the attribute maintenance screen. A F4 help can also be assigned to the field in the flow logic by using VALUES or SELECT In the latter case, the input help here behaves as if the table specified under SELECT were assigned to the field as check table.
If more than one of the described mechanisms compete in defining the input help method of a screen field, the first one named will take effect. If none of the described mechanisms is available, the domain fixed values of the field will be used for the input help if necessary. If the domain of the field has no fixed values but has data type DATS or TIMS, the input helps that are assigned to these types are used for the input help. Otherwise there will be no input help available for the field.
A search help attachment always belongs to the definition of the object to which the attachment is made (structure, table or data element). It is also maintained in the maintenance transaction for this object and transported with this object.
See the links:
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee38446011d189700000e8322d00/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee45446011d189700000e8322d00/content.htm
https://forums.sdn.sap.com/click.jspa?searchID=3173469&messageID=2176485
https://forums.sdn.sap.com/click.jspa?searchID=3173469&messageID=3601619
pls go through this for search help creation
http://help.sap.com/saphelp_nw2004s/helpdata/en/41/f6b237fec48c67e10000009b38f8cf/content.htm
Search Help Exits: 
++