Enhance mass change process for Sales Orders in Web UI - Enhance Query

Introduction:

I my last blog about MASSEnhance mass change process for Sales Orders in Web UI - Modificable fields I explained how you can enhance the process of modify data adding new or standard fields in Web UI. In this blog I will explain the basics to add standard fields in the query object, to be more specific I will explain how to add the order line description as a searchable field in the sales order item query.

How to enhance the query object?

We are dealing with the search of positions so the dynamic query object is BTQSlsItem, in order to add the new field avaliable you need to enhance the structure CRMST_QUERY_SLSITM_BTIL as you will see and probably wonder, we have a custom include for AET: INCL_EEW_BUS2000131_SEARCH, I guess this custom include only is modified if we add new fields to the BT model via AET, but doesn't apply if we only want to make some standard field avaliable to be used as search criteria, so on our scenario I created a new append structure in the include and I added the field ZZPRODUCT_DESCRIPTION_UC.

How to map input fields to the data dictionary?

The first thing you need to know is MASS uses the customizing table CRMC_REPDY to map the search parameters to the target in the database, the example which I'm explaining is "quite easy" because we are dealing with the standard table CRMD_ORDERADM_I. If you add your field via SM30.

ZZPRODUCT_DESCRIPTION_UC, wait?! I thought you say you will use standard field!! well I will explain that later (aproach2)

As you see the field is repeated I will use this to descrive both approaches.

Approach 1: Using an already delivered standard field.

If you take a look at the table CRMC_REPDY you will see, there are more fields to be used than actually what you can use in the Web Client, so why we can not use an already defined field adding this field in the append structure? That will be the best approach....but there's something which will make you change your mind

The function module CRM_SALESORDER_MASS_SELECT is the one which will do the mapping of your Dynamic query parameters to the internal queryparts (quparts) if you check the FORM BUILD_THE_QUERY (CRM_SALESORDER_MASS_SELECT) you will see a big loop at the internal table LT_RANGE with a case. So if the field is defined in the Dynamic Query structure and in the table CRMC_REPDY, even if is a standard delivered field (CRMC_REPDY), won't work as long is not included in the case. I rasied a message to make one standard field (delivered in table CRMC_REPDY) avaliable in the case and SAP support won't change anything, you can see it as a product error or as custom enhancement, but the resume is if you want to go for that whay you will need to modify the code to add your one case. You can also add a enhancement point at the end of the form, but in this scenario,  I think the best option is do a standard modification.

Approach 2: Using a custom field which points to the standard field.

This aproach is taking advantage on the WHEN OTHERS case, the OTHERS is meant for the AET fields and to take your field in consideration needs the customer name convenion Z* or Y*. Now you are starting to understand why I created the field on the CRMC_REPDY starting with ZZ rignt?

Ok, there's one little step more, this field needs to be populated in the table AXT_RUN_FIELDDEF, this table is meant for the AET extensions so you can't modify it directly, the only way is create a maintenance view and generate a view maitenance program in order to add the new entry via SM30.

So the result will be something like this:

I informed the LOCATION, just to avoid naming confilcts with the fields generated by AET.

Once is everything done, you will be able to search order item description

If for any reason the field is not avaliable in the view configuration (BT115MU_SLSO/SearchItems) that's because you will need to copy/add your new field via desing layer.

Conclusion:

Which approach is better? I prefeir the second one, at least I don't need to modify the standard source and I think informing the location on AXT_RUN_FIELDDEF secures the solution, one think to considere is during upgrades you should check the WHEN OTHERS code doesn't change so this development will stop working, and of course, this is how I filled the GAP between the standard and my customer requeriment, this is not a standard solution and should be perfromed with care

I focused on the saels order item query but the header approach is should be very similar

Cheers!

Luis