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, we will need to make WBS Element field mandatory. Also after 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. Enabling certain standard fields and making them mandatory: 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 available in the “Create Maintenance Notification” (App ID : W0006) which is intended to be used for this process but hidden. Therefore, this field needs to be configured to become visible and also have to be a mandatory field via configuration that is explained in the Configuration Details section. 
3. Performing checks and validations during saving the notification: Once the 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.

In A2D, 

Assumptions

Dependencies

Security, Integrity and Controls

Configuration Requirements

Language Requirements

Special Requirements

Design Rationale

Functional Requirements

Proposed Technology to Use

Data Source Considerations

Data Validation Considerations

Custom Tables

Master Data

Configuration Table

Selection Screen Enhancement

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