High- Level Specification

Functional Overview

The PM Notification application is a custom SAP Fiori application intended to allow end users to create and consult maintenance notifications in a simplified and user-friendly way.

The application will be developed on SAP BTP and integrated with SAP S/4HANA for notification creation and retrieval. The application is expected to be exposed to end users through two portals (one for internal and the other for the external)

The application provides two main capabilities:

• Create Notification
• Notifications List

The user experience is intentionally simplified in order to support non-SAP users (lab researchers), especially laboratory and site users. Technical SAP fields are hidden from the UI and automatically derived in the backend wherever possible.

Notifications are created in SAP S/4HANA through backend integration using a technical user. The actual requester identity is nevertheless captured and transferred as part of the notification data.

Scope and Objectives

• Allowing users to create maintenance notifications through a simplified Fiori UI
• Allowing users to consult existing notifications in a dedicated list screen
• Enabling secure access for internal users through SAP Cloud Identity Services
• Restricting user access based on plant/site authorization
• Integrating the application with SAP S/4HANA for both create and get operations

Process Flow Diagram

Application Screen:

Assumptions

• End users are not SAP experts and require a simplified interface
• The app is developed on SAP BTP
• SAP S/4HANA exposes the required backend services for notification creation and retrieval
• Internal users can be associated with an authorization attribute identifying their plant/site

Dependencies

The application depends on the following components:

• SAP BTP
• SAP S/4HANA PM
• SAP Cloud Identity Services
• Portal / launch mechanism for end users
• Backend integration services or APIs for create and get operations
• Custom configuration tables for approval and email routing, where applicable

Security, Integrity and Controls

Authentication for internal users shall be based on SAP Cloud Identity Services.

Authorization shall be controlled through user attributes, in particular the authorized plant/site. The application shall restrict both data visibility and data creation rights accordingly.

Users shall only be able to:

• create notifications for their authorized plant/site
• view only notifications belonging to their authorized plant/site
• access only the functional locations and equipment belonging to their authorized scope

Although the notification is technically created in S/4HANA by a technical user, the actual requester identity must be captured and transferred in the notification payload.

A backend validation shall ensure that no notification can be created outside the user’s authorized scope, even if UI filtering is bypassed.

The external access model is still under discussion and will be finalized separately by the project technical team.

Configuration Requirements

The following configuration elements are required:

• User authorization attribute identifying the plant/site
• Filtering logic for functional locations and equipment by plant/site
• Email recipient mapping by cost center if approval remains in scope

Language Requirements

The application language shall be English/French

Additional language support may be considered later depending on project needs.

Special Requirements

• Intuitive and simplified UI
• Plant/site-based filtering for both creation and consultation
• Separate list tab for consultation of existing notifications
• Priority field available in the creation form
• A section for HSE evaluation needs to be added at the bottom

Design Rationale

The following design choices have been made:

• technical fields such as planner group, work center, and cost center are exposed to end users.
• a simplified HSE / Safety section may be retained for high-level information only
• a notification list screen is introduced to provide users with visibility on previously created requests
• priority is explicitly captured in the UI to help classify the request from the start

This approach is aligned with SAP best practices, where the notification captures the maintenance need, while technical, planning, and safety assessments are handled later during order preparation and execution.

Functional Requirements

The application shall provide the following functionalities.

1.  Create Notification

The user shall be able to create a maintenance notification through a simplified form.

The form shall allow the user to maintain:

• Functional location
• equipment (optional)
• title (short description)
• description (long text)
• priority
• requested start date
• requested end date
• simplified safety / HSE information if retained

The system shall:

• validate mandatory fields
• restrict selectable technical objects based on plant/site authorization
• create the notification in SAP S/4HANA
• display a confirmation message with the notification number

1.  Notifications List (similar to IW29)

The user shall be able to consult previously created maintenance notifications through a dedicated list tab.

The user shall be able to:

• retrieve a list of notifications
• filter the list by predefined criteria
• view notification details in read-only mode

The system shall ensure that the user only sees notifications related to the authorized plant/site.

1.  Automatic Derivation

The system shall automatically derive from technical object:

• planner group
• work center
• cost center

The user will be able to suggest the cost center with an activity code

Recommended UI Technology

The application shall be developed as a SAP Fiori (SAPUI5) application on SAP BTP.

The final launch mechanism to end users, including the potential use of SAP Build Work Zone, shall be confirmed by the tech team.

Application Screen

The application consists of two main tabs:

• Create Notification
• Notifications List

Wireframe or Mock-Up

Screenshots and mock-ups shall be inserted in this section.

They shall illustrate:

• creation screen
• notification list screen
• priority field
• simplified HSE / Safety section

 Screen Behavior

Create Notification

• requester information shall be prefilled when available from the authentication context
• user scope shall be automatically restricted by plant/site
• functional location value help shall be filtered by the authorized plant/site
• equipment value help shall be filtered by the authorized plant/site
• priority shall be selected from a predefined list
• description shall be guided by a standard text template
• mandatory fields shall be validated before submission
• submit action shall trigger a final confirmation popup
• upon successful creation, the notification number shall be displayed

Notifications List

• the list shall be filtered by authorized scope by default
• the user shall be able to apply additional filters
• the user shall be able to open a notification in read-only mode
• the list shall display key business information in a readable table format

Screen Navigation

Entry

The user accesses the PM Notification application through the target portal / launch mechanism.

Main Navigation

The application provides two main tabs:

Tab 1: Create Notification

• Sections:
• User Information
• Request Details
• Planning Information
• Safety Information
• Submission

Tab 2: Notifications List

Sections:

• Filters
• Results Table
• Notification Detail View

Data Integration

Provide the details about the information will be displayed in the interface and where /how the information will be read/stored from. This must match to the screen mock-up

Custom Tables

If any custom configuration tables are required, which will be read by the enhancement logic, then specify them here. Can be deleted if not needed.

Master data

Table Name (add more sections for different tables) 

Include an overview of the table and what it’s used for 

 Configuration table

Table Name (add more sections for different tables) 

Include an overview of the table and what it’s used for 

Processing Logic

Describe the required logic to be implemented

Tooltips

Tooltips shall be provided where needed to support non-SAP users, especially for:

• Functional Location
• Equipment
• Priority
• Safety Information

Front-End

The application front-end shall be developed as a custom SAP Fiori application using SAPUI5 on SAP BTP.

Mobile Services

The application is primarily intended for browser-based usage.

Authentication & Authorization

Internal Users shall authenticate through SAP Cloud Identity Services.

Each user shall carry an authorization attribute identifying the authorized plant/site.

This attribute shall drive:

• field value filtering
• notification creation scope
• notification consultation scope

External Users: thhe authentication and authorization model for external users is still under discussion by the technical team.

Accessibility

Detail if the Interface will have accessibility features, i.e. Speech Recognition, Photos, Barcode Input

Volumetrics

The application is expected to support:

• regular daily notification creation by site users
• notification consultation across an active but limited user population

Performance Consideration

• notification retrieval in the list screen shall remain performant under standard filtering usage
• backend filtering shall be used to avoid unnecessary data loading
• plant/site restriction shall be applied as early as possible in the request flow

Error Handling

The application shall handle at least the following error cases:

• mandatory field missing
• invalid date range
• backend service unavailable
• notification creation failure
• notification retrieval failure

Error messages shall be clear and business-friendly.

Examples:

• “Please complete all mandatory fields.”
• “The notification could not be created. Please try again later.”
• “The notifications list could not be loaded. Please try again later.”

Testing

How to Test

Please provide some guidance and/or test data to help the developer unit test the user interface. This can be included here or in a separate document. If possible, testing is to be done prior by Functional team, for those transactions or business processes to be automated. Please include both positive and negative testing (to validate error situations handling)

Test Conditions and Expected Results

List all test conditions – this will then be used as a basis to execute both the technical and functional unit tests

Test Considerations/Dependencies

List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.

Other Information

Development Details

Package

UI Implementation

API Implementation

Other Development Objects

Appendix

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log