Search helps usually have a filter option so that the result list can be restricted to only certain values. These filter values often originate from another field on the screen. Similarly, some search helps are capable of returning more than one field value from the selected item.
When search helps for custom fields are used in a Personas 3.0 flavor, currently there is no option to utilize either of these features. The search help will display the full set of available records (no filtering) and if the selected entry returns multiple values, only the field directly tied to the search help gets populated.
Until the search help implementation in Personas provides this functionality, the following method can be used to achieve the same result.
With a little scripting, all of this is doable, although the solution I’ll demonstrate is not perfect. It also requires at least SAP Screen Personas 3.0 SP03 since it relies on a feature, which became available with SP03.
In the demo use case, let us assume a scenario posting a material document, where we have two fields, both equipped with search helps. The first one (movement type) should restrict the possible values for the second field (movement reason). In addition, when a movement reason is picked from the list of available values, the selected entry for movement reason should populate both of the input fields. Finally, we also want to get the description of the selected movement reason (which the search help also provides) and place it into a field on the screen.
So let’s create a flavor for the Easy Access Menu (transaction SMEN) with these fields:
![SH1.jpg]()
The movement reason description will go into a label, which is indicated above with the underscores for easier visibility, but in a regular scenario, we would leave the label empty of course.
The movement type is a regular F4-help input, for instance via table BAPI2017_GM_ITEM_02, field MOVE_TYPE so we can simply whitelist this. For the movement reason field however, a scripted help assignment is used. This will take care of opening the search help dialog. What we need is the search help H_T157D. This allows restricting the movement reason selection list by movement type and returns the values we are looking for. It is important to mention that the search help must have the corresponding EXPort flags set for all values we need, otherwise this solution will not work. So if the value you are looking for is part of a search help value list but it is not returned as a result (EXP not checked for the field), then you have to look for another search help or create your own where this requirement is fulfilled.
To call this search help, there are multiple ways. I will show one of them but alternate methods are also possible, depending on the actual scenario. You will have to decide what fits the particular flavor.
In this example, we can take advantage of a standard function module F4_SHLP_SIMULATION. By specifying the search help name, it will invoke the search help dialog, starting with a screen that allows entering our filter value for the movement type. After selection, it passes back the selected values into the same intermediate screen, where we will pick them up and write them into our target fields in the flavor. Sounds simple enough J
As the first step, since we want to call the function module for search help simulation, we have to use it as an RFC. However, this function module is not remote-enabled, so we can either create a wrapper function module or copy the standard, with remote-enabled processing type. Let’s call this Z_ F4_SHLP_SIMULATION and make sure the remote function module flag is checked.
When adding this new module to the Personas FM Whitelist, it is important to mark the ‘Same session’ checkbox so that our solution works properly. If this were missing, the RFC would open the search help in a separate session, which prevents the data transfer between the new session and the original.
![SH2.jpg]()
When this function module is called, it starts with a selection screen where the filter criteria is entered. This is where we pass on the movement type from the screen and our first script will take care of this.
Let’s call this script “RequestHelp” and attach it to the event OnF4 of the field ‘Movement Reason’:
![SH3.jpg]()
The script looks like the following:
// Perform RFC to call search help
var oRFC = session.createRFC("Z_F4_SHLP_SIMULATION");
oRFC.setParameter("SHLPNAME", "H_T157D");
oRFC.send();
// Add movement type from the screen to search help filter
var mvmt = session.findById("wnd[0]/usr/boxPersonas_146714382058965/ctxtPersonas_146714752027749").text;
session.findById("wnd[1]/usr/sub:SAPLZSDH4:0600/ctxtG_SIMFIELDS-VALUE[0,53]").text = mvmt;
// Continue (press ENTER)
session.findById("wnd[1]/tbar[0]/btn[0]").press();This will call the search help simulation and feed the movement type value into the intermediate screen’s corresponding filter field, then hit ENTER to display the selection list.
![SH4.jpg]()
When the user selects the desired row, another script carries the selected values from the search help’s result screen to the flavor fields. The white popup window behind the value list in the above screen shot is actually the search help’s filter / result screen, except the fields are all hidden because we don’t need them displayed. Right now, it is not possible to hide the entire window or make it invisible, due to how Unified Rendering handles such objects, so the white block is pretty much the best we can have.
After selecting the desired row (let’s pick the third one from top), the result window looks like this:
![SH5.jpg]()
This contains all information we are interested in. Now it’s time to write them into the target fields. We will create a script called “GetValue” and attach it to the popup window’s “onAfterRefresh” screen event.
![SH6.jpg]()
//Get selected movement type
var mvmt=session.findById("wnd[1]/usr/sub:SAPLZSDH4:0600/ctxtG_SIMFIELDS-VALUE[0,53]").text;
//Get selected movement reason and text
var reason=session.findById("wnd[1]/usr/sub:SAPLZSDH4:0600/ctxtG_SIMFIELDS-VALUE[1,53]").text;
var reasonText = session.findById("wnd[1]/usr/sub:SAPLZSDH4:0600/ctxtG_SIMFIELDS-VALUE[2,53]");
//Press CANCEL to leave search help
session.findById("wnd[1]/tbar[0]/btn[12]").press();
//Write retrieved values into the corresponding screen fields
session.findById("wnd[0]/usr/boxPersonas_146714382058965/ctxtPersonas_146714752027749").text=mvmt;
session.findById("wnd[0]/usr/txtPersonas_146714379756427").text=reason;
session.findById("wnd[0]/usr/boxPersonas_146714382058965/lblPersonas_147458701265196").text=reasonText;With this, we are done:
![SH7.jpg]()
Except for one thing… what if the user enters a filter for Movement Type, which results in no value list in the search help? This would create an empty popup window, which we don’t really want to show. Instead, it seems to be a better way to just return to our screen and display a message indicating that no value was found:
![SH8.jpg]()
A possible solution would be to have a script, attached to the “onAfterRefresh” event of the popup window appearing in such a situation. Let's call this "WrongFilter". The script exits the popup and the underlying search help filter / result screen, and then displays the message:
![SH9.jpg]()
//No value, return from search help
// Control (amodal) search help
if (session.idExists("wnd[3]")) { session.findById("wnd[3]").close(); session.findById("wnd[1]").close();
}
else {
// Dialog (modal) search help session.findById("wnd[2]/tbar[0]/btn[12]").press(); session.findById("wnd[1]/tbar[0]/btn[12]").press();
}
//Display alert
session.utils.showOptionDialog("Search result", "No values for this selection", session.utils.MESSAGE_TYPE_INFORMATION, session.utils.MESSAGE_OPTION_OK, onOptionDialogClose, "1");
function onOptionDialogClose(decision, ID){}Note that there is a slightly different handling of the popups, depending on whether the F4 Help uses a control- or modal window-based search help. This is controlled by the user’s F4 Help setting (Help -> Settings -> F4 Help -> Display)
Now, as mentioned, this is only one possible way to provide this functionality. The disadvantage is the white popup window showing behind the result list, which is the result of how the employed search help simulation function module works. To avoid that, there are other standard function modules capable of handling search help requests. One such module would be F4IF_FIELD_VALUE_REQUEST, which doesn’t have the interim popup, however passing filter criteria to it isn’t as good as in case of the function module above, and it doesn’t return the description for the selected movement reason. Depending on the individual scenario, it should be evaluated which function module makes more sense. Or, it is certainly also possible to create your own “ultimate” function module that does it all J
