Enhancing the Account Search

Let’s keep this a possible solution. As to many challenges you face when implementing systems, there are usually more than one solution. I have noticed this is an easy to implement, transparent and user-friendly option.

What we start with is create a new ID Type, for instance ‘ZALIAS’. ‘ZALIAS’ should not be unique and should allow multiple values per partner.

“Why ID Numbers?” you might think. ID numbers are standard indexed well, and should act well on search performance. Furthermore, they are easily maintainable in standard SAP, and offer an 1:N Relationship (one partner can have multiple aliases). Also, they replicate to ECC out of the box, and are thus maintainable and available there as well.

This blog focusses on enhancing the SAP CRM account search in the webclient, and does not include enhancing the BP value help to do the same.

Just adding an ID Type is unfortunately not enough in our case. Of course it can be, if you want to instruct the end user to also search on the ID-number field if the account looking for was not found in the system. More user friendly would be to enhance the search query to also include a search on the ID-numbers automatically using the value from the name field in the search.

Adding the additional query

So, plan is to after having performed the standard search, to grab the value from the name field in the query and repeat the query, but now with the criterion ID_NUMBER <entered operator> <entered_value>.

So, we start with identifying the component and view we would like to enhance. In our case, this is the BP_HEAD_SEARCH/MainSearch. As the search is triggered by the event ‘Search’, we want to enhance the event handler EH_ONSEARCH.

In the EH_ONSEARCH, we first call the standard (super->eh_onsearch), followed by the coding where we loop over the search criteria (in the searchcriteria collection in the typed context, me->typed_context->search->collection_wrapper), and if we find the mc_name1 with a value, we replace the attr_name to id_number and add the original searchvalue and operator to the ID number, fire the new query and add the results to the results collection. If the MC_NAME1 is not among the search criteria, or the value is initial, the second query should not be fired.

Make sure…

• You don’t change the actual search criteria, because this might show up in the search screen
• You don’t try to add the id number as an additional criterion to the original search criteria, because this will only narrow down the search instead of retrieving extra search hits.
• You insert the value again after changing the ATTR_NAME, as the BOL will automatically initialise the value and operator when changing to another search option.

If the user uses the BP_HEAD_SEARCH with mc_name as a search criterion, the system will not only search for accounts where mc_name1 fits the description, but will automatically look a little bit further, possible finding the right customer.

While implementing, you can also check if maybe adding the search option ID_TYPE (eq ‘ZALIAS’) can improve the performance of the second search. Ideally it would, as this further narrows down on the id number search.