Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
Showing results for 
Search instead for 
Did you mean: 


BusinessPartner IDs and OrgUnit IDs are most often numeric and instead of memorizing hundreds or thousands of 10-digit customer numbers, end users tend to use the well known F4 value help search popups. When searching for a customer number the end user spends quite some time and mouse clicks: launch the F4 value help popup, enter customer name, country, city, click on search button, check if the customer was found, maybe: correct spelling of the name, click search botton again, locate the right customer number and finally select the right entry to be taken into the input field.

User efficiency is kind of harmed.

What if you could just type all the search criteria into the input field, in which you have to put in the numeric ID and the system auto-proposes the customerIDs, which are relevant?

For TM systems (release 9.0 and higher) there is a solution to improve user efficiency and it does not require a fuzzy search based on a HANA DB.

Solution - Result

Just an example, config and background is explained later.

You work for CustomerService and when creating a new order you need to enter BP IDs and on the e-mailed document there is no customer number - as usual there is only Name and Address: >>Phil & Co, 833 Broadway 3rd Floor, New York 10003<<

Instead of using the F4 value help popup, just start typing: "Phil"

The system auto-proposes relevant customers.

Type a <space> and "US" for the country

The dropdown list reduces to the customers from the US.

Type another <space> and "ne" for the city.

Now, in this example, there is only one left in the list, which is most often not the case in reality, but it demos the effect.

Anytime you use then the arrow down key to select the entry and hit ENTER and that's it. You found the BP number within seconds and no mouse click was required.

This is not a fuzzy search and it is also not hard coded. There is a configuration, which in this example controls the following:

The string "Phil us ne" is split by the separator <space> into 3 individual strings. The first one is the name, the second one is the country and the third one is the city.

Solution - Implementation

There is a customizing, in which you can activate the so called "Combined Search" for input fields for BPs or Org.Units.

Prerequisite: notes 2205284 and 2198536

Use transaction SM34 for the view cluster /SCMB/VC_TYASH in case the following customizing node is not yet available:

It is a 2-level customizing.

In the first view you can declare two different things:

  • Declare for collective search helps the relevant elementary search help (of this collective search help), which shall be used by the system to execute the combined search.
  • Declare the elementary search help, for which the combined search feature shall be activated and declare the separator, which shall be used to split the search string into the individual search input values.

In the second view you declare for the elementary search help the search parameters and its sequence.

BP search config (example/recommendation)

OrgUnit search config (example/recommendation)


The combined search help is only applied for input fields, for which the type ahead search / auto-value-proposal is activated.

The combined search help is not applied to the input field (despite it is activated) if the user enters a pure numeric value. The system assumes here that the user enters the actual ID and applies the regular search help and autocompletion / auto-proposed values come with all IDs, which start with the entered numeric value.

As of today the combined search works for the following search helps:

Collective search helps:

  • Business Partner: /SCMTMS/CSH_BUPA

Elementary search helps:

  • Business Partner:
  • Organizational Unit:


Feature 1: For the activated collective search help in the search help exit a particular elementary search help (to be used for the type ahead search) is set. The standard behaviour (without this feature) would be: the system uses the elementary search help, which was used by you the last time in the F4 value help popup.

Feature 2: For the activated elementary search help in the search help exit the declared standard input parameter is replaced by the declared list of search parameters and the entered string is split at the seperator character into the individual search value. The content of the internal selopt table is modified accordingly. As of today the options 'equal' and 'contains pattern' are supported.

This customizing and the underlying framework (class /SCMB/CL_SH_TYPE_AHEAD_HELPER) can also be used for own custom developed search helps. It only requires to implement the helper method calls into the search help exit. And it certainly requires a SCM system, which has got the SCM Basis layer.

Very special/exceptional case

In the rare case where both kind of IDs - numeric and alphanumeric - exist in the system and some users like to continue searching with the external alphanumeric ID and other users prefer to search for the numeric ID using the combined search parameters, then a compromise is needed: In the search parameters declare the ID to be the first search parameter, followed by the actually intended search parameters. Now the users, who type external alphanumeric IDs and expect the auto-proposed value list to come, can just work as before. All other users, who like to use the new way of search for numeric IDs, need to start typing the separator (here: <space>) in order to suppress the first selection criteria 'ID'.

Runtime performance aspect

This "combined search" feature is expected to be used the same way the end users used the F4 value help popup before in terms of which parameters are selected to enter a search value. Hence it is expected that anyway you already have secondary indexes for the search help parameters.Hence the auto-proposed values come up in the drop down as fast as the user would get the search result in the F4 value help popup. Make sure to execute performance tests for your configuration before deploying this feature to production.

Known weakness

As of today there is no way for a ABAP WebDynpro to declare an input field, which allows a longer input-string for type ahead search purposes than the actual defined length of the field (like possible in SAP GUI).

Hence, the 10-digit BP number field allows a maximum of 10 characters for searching via type-ahead. This is a real weakness, but it is preferred to wait for a central solution from ABAP WD - instead of spending the time to extend the field length of relevant fields in all the UI structures.

For customer implementation projects it is OK and recommended to increase the field length of relevant UI fields in order to use this search feature to a full extent. There is no issue expected as the final value from the UI field is parsed to the corresponding backend field and the backend field still remains with its original length and all further processing and input checks etc. is done as before.