High- Level Specification

Functional Overview

The system enforces a mandatory approval workflow for Bid Waiver forms prior to initiating the Delegation of Authority (DOA) approval process for any Master Agreement, Sub-Agreement, or standalone agreement. This requirement ensures that Contracting Specialists cannot proceed with agreement approvals unless the Bid Waiver has been formally approved. By embedding this control, the process aligns with the Bid Waiver Policy, mitigates operational risk, and upholds audit integrity by preventing unauthorized agreements from advancing in the approval chain.

Scope and Objectives

This custom development focuses on enforcing Bid Waiver compliance within the agreement approval workflow. Specifically, it introduces page-level and logic-based enhancements to ensure that when the Competitive Sourcing metadata is marked as Yes, an approved Bid Waiver form is required before an agreement can be sent for Delegation of Authority (DOA) approval.
The scope includes:

Page-Level Customization:
Implementing an alert on the agreement page when the user clicks “Send for Approval,” guiding them to obtain Bid Waiver approval first.

Enforcement Logic:
Validating the status of the associated Bid Waiver form. The system will block the approval process unless the form is marked as Approved.

Conditional Enforcement:
The Bid Waiver requirement is enforced only when Competitive Sourcing = Yes. If Competitive Sourcing = No, no restrictions or alerts are applied.

Objectives

• Ensure compliance with Bid Waiver policy by preventing agreements from being sent for approval without prior authorization.
• Provide clear and actionable guidance to Contracting Specialists through user-friendly alerts.
• Reduce operational risk and maintain audit integrity by embedding approval checks directly into the workflow.
• Improve user experience by automating enforcement based on metadata conditions, minimizing manual oversight.

Process Flow Diagram

Insert the flowchart and fill in the steps

Assumptions

Describe any assumptions that have been made in the process of completing this design. What functionality is expected of configuration or other developments that pass information to this development and/ or retrieve the information processed by it (performance, triggers, exceptions, etc.)> 

Dependencies

Indicate any dependencies or constraints that may impact development, in terms of requirements from internal or external applications or teams, limited access to legacy system, time constraints or data restrictions. Also, please specify schedule dependencies e.g. interface or batch jobs that must run prior to execution.

Security, Integrity and Controls

To detail the security requirements for processing this object, any data integrity issues associated with the object and the teams that will be responsible for processing the object, i.e. authorization/roles required to who can execute the interface, encryption requirement, etc.

Configuration Requirements

Specify the configuration requirements for this object. Like in case of substitution/ routine specify the configuration needed

Language Requirements

Specify the language requirements for this object. Specify the required language and type of translation, like labels or data. For languages outside the core languages for SyWay, the column Regulatory is mandatory to be filled in, and details need to be provided.

Special Requirements

Specify any special requirements or considerations that may impact the enhancement based on specific locations, regulatory compliance or system limitations. Clearly outline requirements e.g. localization rules for countries like China

If the enhancement interacts with third-party systems such as Icertis, describe any additional integration, security or authentication considerations that must be taken into account.

Design Rationale

This template may be used to specify User Interfaces to SAP applications

Functional Requirements

Detail the functional requirements that are desired to be achieved by the UI 

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.

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