High- Level Specification
| Parameter | Value |
|---|---|
| Application System | Icertis |
| Business Process Reference | 03.03.04.01. Create Agreement/Amendment |
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
Step | Description | Comment |
|---|---|---|
Assumptions
Dependencies
Security, Integrity and Controls
Configuration Requirements
Language Requirements
Special Requirements
Design Rationale
Functional Requirements
Recommended UI Technology
Application Screen
Wireframe or Mock-Up
Screen Behavior
Screen Navigation
Data Integration
| Field | Table-Field Name | Comments / Calculation / Field Manipulation / Input / Output / Validation rule / Value help |
|---|---|---|
Custom Tables
Master data
| Field | Description | Data Type/Length | Validation rule / Value help |
|---|---|---|---|
Configuration table
| Field | Description | Data Type/Length | Validation rule / Value help |
|---|---|---|---|
Tooltips
Front-End
Mobile Services
Authentication & Authorization
Accessibility
Volumetrics
Performance Consideration
Error Handling
Testing
How to Test
Test Conditions and Expected Results
| ID | Condition | Expected Result |
|---|---|---|
Test Considerations/Dependencies
Other Information
Development Details
Package
| Package Name | Parent Package |
|---|---|
UI Implementation
UI Type | UI Name | Fiori Catalogue | Design Rationale Reference |
|---|---|---|---|
API Implementation
| API Type | API Name | Purpose / High Level Logic | API Product | Design Rationale Reference |
|---|---|---|---|---|
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|