Search Help Exit to Filter Blocked Vendors

[Former Member]

I have been asked to modify the standard vendor search helps to filter out blocked vendors using a search help exit. This sounds pretty simple at first glance (and maybe it is), but I haven't been able to figure it out how to do it.

I have made a copy of F4IF_SHLP_EXIT_EXAMPLE and assigned it to elementary search help KREDA.

The selection method is M_KREDA; however this view and the others for vendors do not include the u2018blocked vendoru2019 indicator (SPERR). So I am not sure how to use the SHLP-SELOPT internal table.

It actually seems a lot simpler simply to go to the individual views and add the condition to the selection conditions.

Does anyone have any thoughts on this?

Thanks

Rob

[kesavadas_thekkillath]

Hi Rob,

It actually seems a lot simpler simply to go to the individual views and 
add the condition to the selection conditions. 

Even i got a similar requirement long back. But that was for transaction migo, input field vendor .

What i did id appended a search help to KRED, included a new selection method from a view which had a selection condition.

You can also try it this way,

You can create one search help exit. in that when the field step in call control structure = presel, add your required values to SELOPT based on your filter condition.

I am leaving office now. May be tomorrow if this thread is unanswered i can give you the steps.

[Former Member]

Thanks Keshav - the users want blocked vendors not to display for all search helps, so simply creating a new search help won't work. I'm going to have to change the existing ones.

I want to add my values to SELOPT, but the filed I want to use (SPERR) is not in the view (M_KREDA).

Rob

[brad_bohn]

You are right - it's not easily done. However, it CAN be done via exits, both a collective search help exit and an elementary search help exit. As you pointed-out, you can't use a select-option in this case. In most, if not all, cases you should be calling the collective help KRED first, right?

Add an exit function to that collective help. What you need to do at the collective level is to redefine the interface of the selected elementary search helps at step 'SELONE' - this is where you can filter non-desired search helps dynamically before the user can pick one, but you can also redefine the interface of each search help listed in SHLP_TAB, i.e., change SHLP_TAB-INTDESCR-SELMEXIT to add your new elementary search help exit helper function. In this function, you are going to use step 'DISP' which is called after the view selection has been made. RECORD_TAB is going to have your selected records. You need to use the F4 helper funtion to map RECORD_TAB to an internal table to get the vendor numbers, then check for the SPERR value, then filter/delete the RECORD_TAB records out that are blocked according to your check. See F4UT_POST_SELECTION_EXAMPLE as a filtering example.

Fun stuff - next your users will be asking why your vendor search helps are so sloooowwww...

[Former Member]

Thanks Brad - yes, KRED will be used in most, if not all cases. In the cases where it is not used, another collective search help will be used.

I never even thought about doing this at the collective search help level, but it makes sense and should actually simplify the process. I'll have to look into your suggestion for a bit and get back to you.

Thanks again.

Rob

[Former Member]

OK Brad, this is where I'm at:

I have copied FMs F4IF_SHLP_EXIT_EXAMPLE and F4UT_POST_SELECTION_EXAMPLE to a Z function group. I have assigned FM F4IF_SHLP_EXIT_EXAMPLE as the search help exit for KREDA and F4UT_POST_SELECTION_EXAMPLE as the search help exit for KRED.

I put a break-pint in the copy of F4UT_POST_SELECTION_EXAMPLE and indeed it stops when the collective search help is called and the value of callcontrol-step is 'SELONE'. So far, so good.

However, the value of SHLP_TAB-INTDESCR-SELMEXIT is ZZ_F4IF_SHLP_EXIT_EXAMPLE (for KREDA). Do I change it to ZZ_F4UT_POST_SELECTION_EXAMPLE now? It is a structure, not an internal table, so I cannot append it.

Rob

[brad_bohn]

You only need to assign the collective exit at design time (DDIC - KRED). The elementary SH exit is a runtime assignment at the collective 'SELONE' step based on the entries that show up in the SHLP_TAB table (KREDA, KREDK, etc.) You certainly could go through all of the elementary helps and directly assign the new elementary exit to every one, but in my mind, that's no different than just going through and modifying every view/selection method in those elementary helps. This gives you a more dynamic way of filtering out the non-desired recs after view selection.

[Former Member]

Hi Rob

You don't need F4UT_POST_SELECTION_EXAMPLE: it's just an example.

You need your Z-function based on F4IF_SHLP_EXIT_EXAMPLE

You can delete the data in step DISP ( the code starting at IF CALLCONTROL-STEP = 'DISP'.)

Here you can delete the data before displaying it are in RECORD_TAB, if you use that fm as exit for KREDA, the data to be displayed are arranged in according to view M_KREDA.

So you can move the record to workarea like M_KREDA and then delete the records not to be shown, but probably you can find out the name of the view in the interface parameters of your fm, so u can manage then dymanically by field-symbols

Max

[brad_bohn]

Yeah, but F4UT_POST_SELECTION_EXAMPLE is a very good example of what needs to happen at the elementary SH level in order to make the whole process dynamic for all SH's in the collective. That's the root of the issue, not handling a single elementary help. You are certainly right about being able to map the value based on the view definition for that single help but to cover all of the elementary helps (including future adds), whether they use a view or an exit for data selection, I think the code in the function is better (parameter retrieval via function and deletion by index), though it should be done at 'DISP' and not 'POSTSEL'.

[Former Member]

@MAX - I understand this is just an example, but I had to use something and this was convenient. I am just working in a sandbox environment now. When I get more comfortable with this I will create my on FM and use that.

@Brad - I'm still looking at what you have provided.

Rob

[Former Member]

Ok Rob

I'm sorry

Max

[Former Member]

Not to apologize - was taking a quick shortcut.

Rob

[brad_bohn]

This might help - for the collective one you just need:

* Collective Mod
  IF callcontrol-step EQ 'SELONE'.
    LOOP AT shlp_tab.
      shlp_tab-intdescr-selmexit = 'Z_F4IF_SHLP_EXIT_MY_FUNC'.
      MODIFY shlp_tab.
    ENDLOOP.
    EXIT.
  ENDIF.

In the elementary one, use that sample code to pull out the vendor parameter, select the SPERR value, then delete the non-desired ones (as shown in that example as well).

[Former Member]

I wasn't able to get the exit for the collective help to work. It kept dumping at a FM saying that not all of the import parameters were specified. But I could see that they were there. After spending most of the afternoon trying to figure that out, I gave up and tried to get it working for the individual search helps.

Rather than going back to the database, it turns out that when vendors are blocked around here, they change the search term1 to 'BLOCKED'. So I filtered on that instead. It woks.

An imperfect solution, but one that I can use for now. If we decide to go ahead with this I will revisit the collective help option and we will decide if the search term is satisfactory or if we will have to go back to the database again.

Thanks to all who helped.

Rob

[Former Member]

An update - I was able to spend a bit more time on the collective help exit and got it working.

I'm not sure what the original problem was. I had created a new function group and copied all if the FMs from group SDHI to it plus F4UT_POST_SELECTION_EXAMPLE from another group. When I tried the search helps using exits in this group it dumped and I was not able to determine the cause.

So I started over, creating a new function group with only two FMs in it. Bother were a copy of F4IF_SHLP_EXIT_EXAMPLE. From then on, it was simple to create the exit for the collective help and then the exit that was used when the individual search helps were called.

Potential issues:

The field that I am checking is not in any of the views that are used in the individual search helps, so the exit had to go back to the table (LFA1) to get the blocked indicator. This will take more time, but it seemed pretty quick nonetheless.

The exit reduces removes unwanted entries after the selection has been made, so if the user restricts the number of entries to say 500, fewer rows may be returned even though more than 500 rows may satisfy the selection conditions.

Both of these issues would probably be resolved by simply adding a condition to the selection conditions of the selection method of the individual search helps. But that would be a mod.

Thanks again for the help.

Rob

[alejandro_bindi]

The exit reduces removes unwanted entries after the selection has been made, so if the user restricts the number of entries to say 500, fewer rows may be returned even though more than 500 rows may satisfy the selection conditions.

I know this thread is closed, but since I've been looking for the way to do this and this seems to be a documentation issue from SAP, I thought it would be nice to clarify it so it helps upcoming people:

The way to avoid this exact problem you mention is to call the function F4UT_POST_SELECTION_PROCESSING and use the event POSTSEL instead of DISP to delete entries you don't want to show.

The only point I found where this is clearly documented, is in the commentaries of function module SAPBC_GLOBAL_F4_SFLIGHT_MIN_FR. The example F4UT_POST_SELECTION_EXAMPLE does it in the same way, but explains nothing about it. And the most commonly used example, F4IF_SHLP_EXIT_EXAMPLE, is misleading, because it mentions the event DISP should be used for this.

Regards

[Former Member]

Thanks for the additional information.

One question though - how does this affect the number of entries selected? If the user requests 500 entries, will it now return 500 entries?

Rob

[alejandro_bindi]

As long as there are 500 entries existing fullfilling the conditions you apply in your exit, yes.

Your function may be called more than one time with this event, until the limit is reached, or there are no more entries.

If you take a quick look at F4UT_POST_SELECTION_PROCESSING, it does basically this:

- Only gets executed for event 'SELECT'.

- Does selections in blocks inside a WHERE loop and calling back your exit (so the callstack shows Z_EXIT > F4UT_POST_SELECTION_PROCESSING > Z_EXIT).

- Always return 'DISP' as the current step (so you must be careful to process DISP below the call, if you must).

I coudn't debug in detail though, since aparently it uses a selection cursor inside the WHERE loop, and a dump occurs.

I was reluctant to use this function since it seems to be scarcely used, it's also not released. But I compared the results using both DISP and the f.m + POSTSEL, and the latter alternative doesn't have the problem you describe.

Regards

[Former Member]

Thanks for the update.

Rob