Enhance mass change process for Sales Orders in Web UI – Enhance Item 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 item 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.

Approach 3: Using a custom field created via AET(CUSTOMER_H or CUSTOMER_I)

In this scenario I will cover the case of using fields enhanced via AET at CRMD_CUSTOMER_H or CRMD_CUSTOMER_I level (for AET fields which points directly at CRMD_ORDERADM_H or CRMD_ORDERADM_I, you can follow the Approach 1.

Ok! Let’s say I created a new feld on the table CRMD_CUSTOMER_H via AET, the field name generated isZZAFLD00001W. The first thing I need to do is add this field at the table CRMC_REPDY.

Let’s pay attention on the Dynamic Access Name field, as you observe informed ZZDYN_CUSTOMER_H this should be a existing method of the standard class CL_CRM_REPORT_ACC_DYNAMIC which is called dynamically at the method BUILD_DYN_SQL (for example), at my current version I don’t have a DYN_CUSTOMER_H so I created one myself enhancing the standard class CL_CRM_REPORT_ACC_DYNAMIC adding the new method (ZZDYN_CUSTOMER_H) the interface of the new method should be the same a other DYN* methods:

This scenario es simple, so the code is not a big deal, other DYN* methods are more complicated, for example, in order to influence the join.

METHOD ZZDYN_CUSTOMER_H .
  IF i_add_sql_part NE ‘X’ AND it_add_where_for IS NOT INITIAL.
    CALL FUNCTION ‘CRM_REPORT_DYN_ITAB_BREAK_DOWN’
      EXPORTING
        i_name_on_db = ‘CRMD_CUSTOMER_H~ZZAFLD00001W’
        it_quparts   = it_add_where_for
      CHANGING
        ct_where     = gt_where.
  ENDIF.
ENDMETHOD.

The only thing missign now is enhance the mass query object, structures CRMST_QUERY_SLSORD_BTIL (for header search) and CRMST_QUERY_SLSITM_BTIL (for item search) I put here both, despite this blog is focused on the mass item query, because in this approach both header and Item works equaly.

Conclusion:

Between Approach 1 and Approach 2, Which 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 thing 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 😉 and of course this also applies for Approach 3.

This blog is specific for the Item query, the header query works different for approach 1 and 2!

Cheers!

Luis