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

SAP Fiori (SAPUI5) on SAP build work zone

Application Screen

Wireframe or Mock-Up

Please provide a Hi fidelity mock-up of the new application’s screens. Ensure Syensqo's Brand standards are adhered to. (i.e. logo, font, colors, etc.) 

The developers should follow UI best practice to keep the screens user-friendly and consistent

 Screen Behavior

Is any dynamic screen behaviour required? This typically sets the visibility, read-only or mandatory properties of the UI elements. E.g. if field ‘a’ has a value ‘x’, then make fields ‘b’, ‘c’ and ‘d’ read-only, and make field ‘e’ mandatory. For simple input fields, does the value need to be validated? Can a value-help be assigned?

Screen Navigation

First Screen - Authentication screen

fields required: First name / Last name / E-mail address / Plant (dropdown value list)

> Next Screen  - Create Maintenance request

First section > User information

Second section > Standard fields required in order to create the notification 

Third section: Risk Evaluation + Medical risk + HSE Checklist 

button to submit the notification, with final confirmation required

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

Can tooltips or input prompts be used to help and guide the user?

Front-End

Mention the environment (desktop, mobile phone, tablet) in which this User Interface will be running. This will drive the screen estate/size of the screen.

Mobile Services

Explain mobility services will be integrated in the Interface, i.e. Intune, MS Company Portal,

Authentication & Authorization

Detail authentication and authorization mechanisms, i.e. SSO/SAML, SSO/SNC.

Accessibility

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

Volumetrics

Provide volumetrics details: Initial load volumes, Number of Records, Expected Frequency, Expected Long term Growth)

Performance Consideration

Specify if there are any specific performance factors that need to be taken into consideration during development i.e. interface must be able to handle 100 posting per-hour, etc.

Error Handling

Detail how errors will be handled: Notification, Restart/ Recovery and Re-Processing Procedures

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