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 (similar to IW29)

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.

For this application we have around 80 external users (this number will increase in the coming months/years) with same role

Scope and Objectives

• Allowing users to create maintenance notifications through a simplified Fiori UI (external users)
• Allowing users to consult existing notifications in a dedicated list screen
• Restricting user access based on plant/site authorization (attributes)
• Integrating the application with SAP S/4HANA for both create and get notifications

Process Flow Diagram

Application Screen:

• First tab: Notification creation

Current Screen of the app: the red areas are no longer needed

• Second tab: Notification List 

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/externals 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
• SailPoint for external access
• Internal Portal / External portal
• Backend integration services or APIs for create and get operations
• Custom configuration tables for approval and email routing, where applicable

Security, Integrity and Controls

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

• Display only notifications created by the user or by users from the same company (user group)

• 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.

Authentication for 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
• Dates 
• HSE Information
• Submission

Tab 2: Notifications List

Sections:

• Filters
• Results Table
• Notification Detail View

Data Integration

Custom Tables

Master data

The application relies primarily on SAP standard master data, including:

• Functional Locations
• Equipment
• Planner Groups
• Work Centers
• Cost Centers
• WBS
• Set of priority

 Configuration table

Configuration tables may be used for:

• approval recipient mapping by cost center
• email routing
• derivation rules where standard logic requires supplement
• potentially priority mapping if needed

The current solution has a pgm that triggers emails to inform different stakeholders of site once a notification is created or closed, this needs to be evaluated if we can replace it by a workflow (the usage of workflows is part of our S4 design)

Processing Logic

Create Notification:

•  User opens the Create Notification tab.
•  User information and plant/site authorization are determined from the authentication context.
•  Functional location and equipment value helps are filtered by authorized scope.
•  User enters the required notification data.
•  If necessary user can select a WBS element from dropdown list, that WBS will be posted as an activity in the notification
•  System validates mandatory fields and data consistency.
•  Backend derives planner group, work center, and cost center.
•  Notification is created in SAP S/4HANA through the backend integration service using the technical user.
•  The actual requester identity is passed into the notification as Reported By.
•  Confirmation is returned to the user.
•  If applicable, an email notification is triggered based on configured approval logic.

Notifications List:

•  User opens the Notifications List / My Requests tab.
•  System retrieves notifications limited to the user’s authorized scope.
•  User applies filters as needed.
•  System refreshes the result list.
•  User opens a notification in read-only mode if needed.

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: the authentication and authorization model for external users is still under discussion by the technical team.

Accessibility

The application shall follow standard SAP Fiori accessibility principles as far as possible

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

The following test categories shall be executed:

• authentication and authorization tests
• notification creation tests
• notification consultation tests
• filter behavior tests
• error handling tests
• integration tests with SAP S/4HANA

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

Testing depends on:

• SAP BTP test environment
• SAP Cloud Identity Services setup
• SAP S/4HANA test APIs / services
• test users with correct plant/site authorization attributes

Other Information

NA

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