High- Level Specification

Functional Overview

For requesting maintenance on regular activities, the app “Create Maintenance Request”  (App ID : F1511A) will be used. However, when requesting Project Work, we will need to use a different WDA application called “Create Maintenance Notification” (App ID : W0006). In this application, the targeted users will add WBS Element to the notification when they are requesting a Project Work from Maintenance. Once the WBS Element is entered, we will need to validate if this WBSE is a valid one. (e.g. Accounting Indicator must be set etc.)

Scope and Objectives

This development has 3 main objectives as follows;

1. Launchpad Design & App Tile Configuration: In A2D, the app “Create Maintenance Request”  (App ID : F1511A) will be used for raising maintenance requests on regular activities. However, we will need a separate Fiori application to raise "Project Work". For this purpose, the WDA application called “Create Maintenance Notification” (App ID : W0006) will be used with certain launchpad configuration which is mentioned in detail at the Configuration Details section. This app will be targeted only for certain user groups (e.g. Project Managers), which is also explained in the Security, Integrity and Controls section.
2. Performing checks and validations: In standard app “Create Maintenance Request”  (App ID : F1511A), WBS Element field (which is also a standard field) is not present. It is also not supplied with OData Services/CDS Views the app is using as well. On the other hand, the field is already available in the app “Create Maintenance Notification” (App ID : W0006) which is intended to be used here. So, once this WBS element field is entered, a validation has to be done to check if the WBS Element is a valid one. A valid WBS Element has Accounting indicator as true ("X"). Also, when the maintenance event is created and assigned, there should be another validation to see, there is no other open notification exists with Notification Type: 'Y3' and same maintenance event assigned.
3. Updating the notification: Once the WBS Element field is entered, Project Number should also be updated in the notification during save.

Assumptions

The “Create Maintenance Notification” (App ID : W0006) will only be used for creating Y3 Notifications via a targeted group of users. For regular maintenance activities, “Create Maintenance Request”  (App ID : F1511A) app will be used instead.

Dependencies

WBS Element needs to be created prior to create a Y3 Notification as a prerequisite.

Security, Integrity and Controls

Since the app intended to be used, “Create Maintenance Notification” (App ID : W0006), is a standard one. The authorization checks it has is sufficient. Nevertheless, this app is intended for a targeted user group, therefore, following Launchpad design changes needs to be applied from Security, Integrity and Controls perspective;

• The app can be copied from Technical Catalog: SAP_TC_EAM_BE_APPS or from the business catalog: SAP_EAM_BC_NTF_MW to a new Business Catalog: ZSAP_EAM_BC_NTF_MW_PS, Description: EAM - Notification for Projects. The new business catalog and fiori app tile than can be added to the dedicated role created for this process.

The details of Fiori Tile configuration will be mentioned in the Configuration Requirements section below.

Configuration Requirements

Below you can find the details for the App Tile Configuration;

Language Requirements

Since this is a standard Fiori app, there is no language requirement for the UI. However, the error messages that will be used, needs to be translated accordingly.

Special Requirements

Design Rationale

Functional Requirements

During notification creation, a valid WBS Element needs to be entered. For this process, a valid WBS Element requires Accounting Element field (PRPS-BELKZ) to be set as true ('X'). This is because only than the maintenance costs later in the maintenance order can be settled to this WBS Element.

When the notification is created using this WDA app, the WBS Element in Organization Tab will be entered. Once saved, this entry only populates VIQMEL-PROID field with corresponding data. However, it's also required by I2M to fill the following field: VIQMEL-PSP_NR with same value. This is not possible in the standard behavior. For that, Save BADI mentioned below can be used.

Proposed Technology to Use

1. Check if the WBS Element field is valid & validate if the notification does not have duplicates: For that purpose, SAP BADI: EAM_NOTIFICATION_FIELD_CONTROL can be used.
   1. Once the field "WBS Element" is populated with a value, it needs to go to PRPS table and see if Accounting Indicator (BELKZ) is set. If not, it needs to throw an error with following message; "This WBS Element is not set as Accounting Element, please use a valid WBS Element".
   2. When both "WBS Element" and "Maintenance Event" field is populated, this enhancement needs to check if there is any other open maintenance notification exists with following criteria;
      1. Maintenance Notification is not closed: VIQMEL-PHASE < 4
      2. Maintenance Notification Type is "Y3": VIQMEL-QMART = "Y3"
      3. Maintenance Notification has the same "WBS Element" (VIQMEL-POSID) & "Maintenance Event/Revision" (VIQMEL-REVNR) with the current one 
      4. In this case, it should throw following error: "There is already a maintenance notification with &1 and &2 is assigned. Please check notification &3" (&1=Maintenance Event/Revision, &2=WBS Element, &3=Maintenance Notification) 
2. Pass WBS Element from PROID to PSP_NR field in VIQMEL: For this purpose, SAP BADI: NOTIF_EVENT_SAVE can be used to pass WBS Element data accordingly. In this BADI, filter type: QMART is used. Here the filter value will be "Y3". In the CHANGE_DATA_AT_SAVE method, if the PROID field is not empty, it needs to be also copied to PSP_NR field in the structure; CS_VIQMEL.

Here is an example code;

  METHOD if_ex_notif_event_save~change_data_at_save.
    IF cs_viqmel-proid IS NOT INITIAL AND cs_viqmel-psp_nr IS INITIAL.
      cs_viqmel-psp_nr = cs_viqmel-proid.
    ENDIF.
  ENDMETHOD.

Data Source Considerations

Data Validation Considerations

Custom Tables

N/A

Master Data

N/A

Configuration Table

N/A

Selection Screen Enhancement

N/A

Processing Logic

Volumetrics

Performance Considerations

Error Handling

Testing

How to Test

Test Conditions and Expected Results

Test Considerations/Dependencies

Other Information

Development Details

Package

Enhancement Implementation

Other Development Objects

Appendix

Custom Authorization Group Naming Convention

This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.

See also

Change log