Integrate SAP Quality Issue Resolution Custom Methodologies in S/4HANA Private Cloud or On-premise

[Maximilian_Kasselmann]

Introduction

If you integrate SAP Quality Issues Resolution (QIR) in your SAP S/4HANA Cloud Private Editionor On-premise system (in the following only referred as S/4HANA) using the SAP-provided integration then all problem-solving processes that you create in QIR from quality notifications in S/4HANA will use methodology 8D. This methodology is the default one and provided as part of QIR out-of-the-box. Currently there is no “configuration-only”-way to use your own defined custom methodologies from QIR in the S/4HANA integration, i.e., from quality notifications you cannot create problem-solving processes that use any of your custom methodologies

In this blog I demonstrate how you can implement a custom function module for the quality notification action box that provides support for your QIR custom problem-solving methodologies.

Hint for S/4HANA Cloud Public Edition users: The approach demonstrated here cannot be applied in S/4HANA Cloud Public Edition.

The function module will be implemented in such a way that the parts critical for the system-to-system integration will be reused.

The following business requirements are realized in the example:

1. For problem-solving processes created for items of quality notifications of origin “Customer Complaint” (Q1) the user shall select the problem-solving methodology from a list.
2. For problem-solving processes created for items of quality notifications of origin “Complaint against Supplier” (Q2) the system shall automatically select the methodology from a decision table based on the notification data.
3. For problem-solving processes created for items of quality notifications of origin “Internal problem notification” (Q3) the system shall automatically set the methodology Z_INT_8D (i.e., any internal complaint is processed via the same methodology).

The assumptions behind the requirements are:

1. If we work on a customer complaint the customer will tell us what methodology, we shall adhere to. The default might be 8D, but we might have special agreements with some customers for which we only must provide a shortened version of 8D: an 4D. The user must make the decision based on the communication from the customer.
2. Similarly, if we raise a complaint against a supplier, we request them to solve the problem according to a given methodology. However, this time we want to preconfigure the decision in a decision table and let the system pick the methodology automatically.
3. For internal problem-solving anybody must stick to our company-wide used version of 8D which we call Z_INT_8D.

As assumption for the sake of this example let’s assume that you have created the following problem-solving methodologies in QIR:

Methodology ID	Methodology	Problem-Solving Scenario
010	Z_INT_8D	Internal Problem-solving
011	Z_7D	Customer Problem-Solving Supplier Problem-Solving
012	Z_4D	Customer Problem-Solving Supplier Problem-Solving

You can see the Methodology ID of each custom methodology in QIR in the app Define Problem-Solving Methodologies.

Prerequisites

To make use of the system-to-system integration reuse features from the SAP-standard your system must contain the following SAP Notes or must be equal to or higher than OP2022 SP03: https://me.sap.com/notes/3347088, https://me.sap.com/notes/3265674

Preparation

Extend Structure for API Data

To create problem-solving processes for custom methodologies in QIR additional data needs to be provided to the OData API that creates the problem-solving process. This data needs to be provided in a variable of a structure type which therefore needs to be extended by one additional field: Create an append structure for the structure QMS_QIR_INTG_STEP_API_DATA. The append structure must contain the component SOURCE_STEP_TYPE_ID with data type CHAR of length 2 (you can make use of a component type here).

Figure 1: Append Structure

Figure 2: The extended QMS_QIR_INTG_STEP_API_DATA

The purpose of this new additional field is not to transfer the methodology ID. A field already exists for this. The new field is required to transport information for the (always mandatory) D1-step. It will be used in chapter "Implementation to Adapt the Step Data".

Extend API Name Mapping

The OData API that is called to create a problem-solving process accepts a JSON payload. The previously introduced field SOURCE_STEP_TYPE_ID in ABAP has a different name in the OData API. We provide a mapping between the names by specializing class CL_QICR_PSP_ACCESS:

Create a new class and enter CL_QICR_PSP_ACCESS as superclass. Name it e.g., ZEXT_CL_QICR_PSP_ACCESS.

Redefine method GET_PSP_CRT_JSON_NAME_MAPPINGS and implement it as follows:

rv_name_mappings = super->get_psp_crt_json_name_mappings( ).

INSERT VALUE #(
    abap = 'SOURCE_STEP_TYPE_ID' json = 'sourceStepTypeId'
) INTO TABLE rv_name_mappings.

The actual usage of the new class will be introduced in the next step.

Create New Function Module

Before we implement the logic to fulfill the business requirements, we prepare the new function module as a starting point.

1. Create a new function group in any package of your choice.
2. Open function module QICR_REQUEST_PSP_FOR_ITEM from package QICR_INTEGRATION and create a copy of it. Assign the copy to your new function group.

After that step the new function module will show a syntax error because it references the class LCL_PSP_FOR_ITEM which is a local class of function group QICR_QN_INTEGRATION.

SAP Note https://me.sap.com/notes/3265674 provides a solution for that by using function module QICR_ACCESS_PSP_FOR_ITEM. In your new function module simply replace the line:

DATA(lo_psp_for_item) = lcl_psp_for_item=>get_instance( ).

By this:

DATA lo_psp_for_item TYPE REF TO if_qicr_psp_for_item.

CALL FUNCTION 'QICR_ACCESS_PSP_FOR_ITEM'
  IMPORTING
    eo_instance = lo_psp_for_item.

Now the function module does work exactly like the SAP-standard function module for the QIR integration QICR_REQUEST_PSP_FOR_ITEM.

To use your new class from the previous step, replace this line:

DATA(lo_qicr_psp_access)  = cl_qicr_psp_access=>get_instance( ).

By this:

DATA lo_qicr_psp_access TYPE REF TO if_qicr_psp_access.
lo_qicr_psp_access = NEW zext_cl_qicr_psp_access( ).

For some early testing you can already create a new action box activity for the quality notification and assign the new function module. Use the same function module for the notifications origins Q1, Q2 and Q3. For productive usage replace the function module in the existing action box activities that are used for the QIR integration.

Implementing the New Logic

In this step we will implement the logic to set the QIR custom problem-solving methodology for the problem-solving process that is to be created. Basically, we add some logic after the SAP-standard logic has determined all values for the new problem-solving process but before the request to create it is sent to QIR via the OData API.

In your new function module find the line with the following call:

DATA(ls_psp_data) = lo_psp_for_item->map_data_to_api_data(...).

After the call of this method all data for the new problem-solving process is known – including the default methodology 8D – and we can manipulate it.

As a starting point we add an if-else that differentiates by the quality notification origin because our requirements demand different logic based in this. After the call of lo_psp_for_item->map_data_to_api_data add:

IF i_viqmel-herkz EQ 'Q1'.
  " customer complaint -> user selection from dialog
ELSEIF i_viqmel-herkz EQ 'Q2'.
  " complaint against supplier -> pick from decision table
ELSEIF i_viqmel-herkz EQ 'Q3'.
  " internal complaint -> pick statically (hard coded)
ENDIF.

Implementation for Internal Complaints

Let’s start with the easiest one: For internal complaints always methodology Z_INT_8D shall be used. After the condition for Q3 add:

ls_psp_data-methodology_id = 'Z_INT_8D'.

As result, every time a new problem-solving process is triggered from an internal quality notification it will get methodology Z_INT_8D assigned.

Implementation for Supplier Complaints

For complaints against suppliers the system shall select the methodology automatically based on rules. In this blog I will not show how to setup such a rule engine in detail, because there are endless ways to do this. As food for thought here are just some ideas what could be used:

• Decision table via BRF+ (Business Rule Framework)
• A “lightweight” self-designed decision table as a new DB table incl. a maintenance view to maintain the values.
• A coded algorithm that determines the methodology based in the criteria that you need.

For this demo I assume that the logic to determine the QIR problem-solving methodology is encapsulated in a method DET_METHOD_FOR_SUPPLIER of a class ZCL_QIR_INTEG_EXT. Therefore, the implementation in the new function module would simply be calling this API:

ls_psp_data-methodology_id =
zcl_qir_integ_ext=>get_instance( )->det_method_for_supplier(
    is_notification = i_viqmel
    is_item         = ls_selected_item
).

Implementation for Customer Complaints

In case a problem-solving process is started for a customer complaint the user shall select the methodology from a dialog. There are several ways how a dialog could be realized. Since we are in the context of the quality notification in an SAP GUI application we make use of function module RS_VALUES_BOX. For the system to know the available methodologies we assume that an application data DB table has been created to (manually) replicate the available methodologies from QIR to S/4HANA. Considering the costs to implement an automatic replication and the low frequency in which new methodologies are created or removed a manually replication is a reasonable trade-off.

In the example the available methodologies are hard-coded in a variable. In a productive implementation you would select the available methodologies from the database table where they would be replicated to.

And here is the full implementation for Q1:

DATA(lv_selection_idx) = 0.
TYPES ty_it_rsvbfidesc TYPE STANDARD TABLE OF rsvbfidesc WITH DEFAULT KEY.
DATA(it_rsvbfidesc) = VALUE ty_it_rsvbfidesc(
  ( fieldnum = 1 display = abap_false )
  ( fieldnum = 2 display = abap_true )
  ( fieldnum = 3 display = abap_false )
  ( fieldnum = 4 display = abap_false )
  ( fieldnum = 5 display = abap_false )
  ( fieldnum = 6 display = abap_false )
  ( fieldnum = 7 display = abap_false )
).

TYPES: BEGIN OF ty_qir_sup_methodologies,
         qir_methodology      TYPE char80,
         qir_methodology_desc TYPE char200,
       END OF ty_qir_sup_methodologies.

TYPES tt_qir_sup_methodologies TYPE STANDARD TABLE OF ty_qir_sup_methodologies.
DATA lt_qir_cust_methodologies TYPE tt_qir_sup_methodologies.

lt_qir_cust_methodologies = VALUE #(
 ( qir_methodology = '01' qir_methodology_desc = '8D' )
 ( qir_methodology = '011' qir_methodology_desc = '7D' )
 ( qir_methodology = '012' qir_methodology_desc = '4D' )
).

CALL FUNCTION 'RS_VALUES_BOX'
  EXPORTING
    cursor_field         = 1
    cursor_line          = 1
    left_upper_col       = 10
    left_upper_row       = 5
    title                = 'Select Problem-Solving Methodology'
  IMPORTING
    linenumber           = lv_selection_idx
  TABLES
    field_desc           = it_rsvbfidesc
    value_tab            = lt_qir_cust_methodologies
  EXCEPTIONS
    clear_contents       = 1
    invalid_coordinates  = 2
    invalid_field_number = 3
    no_action            = 4
    no_fields            = 5
    no_markfield         = 6
    process_user_action  = 7
    value_tab_empty      = 8
    value_tab_too_long   = 9
    OTHERS               = 10.

IF sy-subrc <> 0.
  MESSAGE 'Function was stopped' TYPE 'I'.
  RAISE action_stopped.
ENDIF.

IF lv_selection_idx > 0 AND lt_qir_cust_methodologies[ lv_selection_idx ] NE '01'.
  ls_psp_data-methodology_id = lt_qir_cust_methodologies[ lv_selection_idx ]-qir_methodology.
ENDIF.

Implementation to Adapt the Step Data

Independent of the notification origin and independent of the methodology the data regarding the problem-solving steps that is sent to QIR must be adapted. Add the following line after the new if-else:

IF ls_psp_data-methodology_id NE '01'.
  ls_psp_data-psp_step = VALUE #(
    ( source_step_type_id = 'D1'
      team_members = VALUE #(
        ( team_member_email = lv_coordinator_email )
      )
    )
  ).
ENDIF.

Note that we pass the value ‘D1’  hard-coded for one step as source_step_type_id which also contains the e-mail address of the notifications coordinator. This person will become the first team member of the new problem-solving process.

Also note that we only manipulate the steps if another methodology than the default 8D (with ID 01) was selected.

Use in Production

To use the new function module instead of the one delivered by SAP you now only need to adapt the existing action box activities in the customizing or create new action box activities and deactivated the ones that are no longer required.

Conclusion and Further Thoughts

The action box concept coupled with the function module QICR_ACCESS_PSP_FOR_ITEM provides high potential to implement the QIR integration specifically according to your needs. At the same time, you can reuse the core elements of the SAP-provided implemented and can focus on adapting the data. This is a fair trade-off to the increased TCO that comes with having customer specific implementations in general.

I hope this blog helps you to make your QIR integration even better and more useful for your processes!