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.
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.
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.
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 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’:
The script looks like the following:
//Get movement type from the screen
var mvmt = session.findById("wnd[0]/usr/boxPersonas_146714382058965/ctxtPersonas_146714752027749").text;
//Perform RFC to call search help
var oRFC = session.createRFC("Z_F4_SHLP_SIMULATION");
oRFC.setParameter("SHLPNAME", "H_T157D");
oRFC.send();
//Add movement type to search help filter
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.
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, 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:
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.
//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]").text;
//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_157292370574635").text = reasontext;
With this, we are done:
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:
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:
//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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
35 | |
25 | |
14 | |
7 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |