High- Level Specification

Functional Overview

Business require ability to change the stock types at handling unit level using Neptune mobility solution. This transaction will allow the stock type change such as e.g unrestricted to blocked stock for all the contents within the handling unit. 

Scope and Objectives

The scope of this document is limited to the development of the Neptune mobility transaction to allow stock type status changes at handling unit level. The Neptune mobile transaction will facilitate to perform stock type change at HU level (applicable to all the contents in the HU) 

Process Flow Diagram

Insert the flowchart and fill in the steps

Assumptions

None

Dependencies

None

Security, Integrity and Controls

None

Configuration Requirements

None

Language Requirements

KDD055 - Multi-Language Support

Special Requirements

None

Design Rationale

Syensqo business will require ability to transfer the stock into different stock type at handling unit level. This is identified as a business requirement within the scope of Neptune mobile transactions. This transaction will be new screen to be developed in Neptune mobile app that will support the user interface to execute the transaction and the background processing of the data to transfer the stocks into required stock type using posting change. 

Functional Requirements

The Neptune mobile transaction will have the user menu option on the screen as a part of the main  or sub menu of the process.  This option will display the stock type change option 

Recommended UI Technology

Consider which technology will be most appropriate – the use of Fiori framework as User Interfaces, other than this, justification is required.

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

How will the user navigate between screens? Are any buttons required that trigger actions?

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 

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