CashLine ERP Business Team Handover
Professionally branded BRD + FRD + PRD package for incoming business owners, product teams, operations, finance, compliance, QA, and go-live governance.
CashLine ERP Business Team Detailed BRD
Business Intent, Operating Model, User Journeys, And Functional Detail
Version: 1.0
Date: 2026-04-20
Prepared for: Incoming Business Team, Product Owners, Operations, Finance, Compliance, QA, Implementation Leads, and Go-Live Governance
1. Why This Document Exists
This document is written for the new business team that will manage CashLine ERP going forward.
The purpose is to explain the business intent behind the system, what each business area is meant to achieve, who uses it, what actions they perform, what controls apply, and how each part connects to the wider operating model.
This BRD is intentionally more explanatory than the technical BRD. It should help a new team understand the platform as a business operation, not only as a software application.
2. Executive Business Intent
CashLine ERP is intended to become the controlled operating backbone for institutional supply, procurement, onboarding, inventory, delivery, finance, supplier interaction, customer interaction, reporting, and governance.
The business problem it solves is the fragmentation of supplier data, customer requests, procurement actions, delivery evidence, invoices, payments, approvals, and audit records across manual tools, email, spreadsheets, and disconnected teams.
The intended business outcome is one governed platform where:
- suppliers and customers can interact through controlled self-service portals
- internal users can process onboarding, procurement, sales, inventory, delivery, and finance work through role-based workflows
- management can see reliable operational, financial, and control information
- administrators can control user access and function visibility
- all important actions are traceable, auditable, and reportable
3. Product Positioning
CashLine ERP should be positioned as a production-MVP enterprise operating platform.
It should not be presented as a full final enterprise-suite launch yet. The first production release is a controlled MVP focused on stable, auditable, role-controlled business operations.
The platform is designed to grow through future releases, including deeper Islamic Finance, Murabaha operations, live external integrations, and regulated fintech controls.
4. Current Production MVP Position
The current go-live strategy is a controlled named-user production MVP.
Included in the MVP:
- public landing and login
- supplier and customer onboarding
- internal onboarding review and case management
- supplier and customer activation
- administrator user and function governance
- system-owner administrator governance
- role-based side navigation and access enforcement
- core supplier/customer read models
- core procurement, sales, AP, AR, and finance visibility where evidenced
- workflow status, audit, notifications, reporting snapshots
- web portal and desktop app consistency
- SQL Server production path and rollback procedure
Held or deferred outside MVP:
- full Islamic Finance production launch
- Murabaha operations launch
- Oracle production parity
- broad open-user rollout
- live ETA qualification until target credentials and authority evidence are signed off
- live Paymob/Fawry qualification until target merchant evidence is signed off
- formal FRA fintech compliance certification claims
5. Business Operating Principles
The business team should manage the platform according to the following principles:
- Every visible function must serve a real business operation.
- Every user should see only the functions required for their role.
- Every critical action must be auditable.
- Maker/checker control must apply to sensitive actions.
- Demo-only, training-only, or placeholder guidance must not appear to end users in production.
- Arabic/RTL experiences must be production-ready where Arabic is used.
- Reports must reflect real operational status, not static demo cards.
- Non-MVP functions should be hidden or restricted until signed off.
6. Business Capabilities Overview
| Capability | Business Purpose | Primary Users | MVP Treatment |
|---|---|---|---|
| Public access and login | Allow users to enter the correct portal securely | All users | Included |
| Supplier onboarding | Create and review supplier records before activation | Suppliers, Operations | Included |
| Customer onboarding | Create and review customer records before activation | Customers, Operations | Included |
| User administration | Create and govern users and functions | System Owner, Administrator | Included |
| Function governance | Control side menus and feature access | Administrator | Included |
| Supplier portal | Supplier self-service for profile, documents, orders, invoices, status | Suppliers | Included as MVP read/action scope |
| Customer portal | Customer self-service for requests, orders, invoices, statements, status | Customers | Included as MVP read/action scope |
| Procurement | Manage purchase flow from request to PO and supplier interaction | Procurement, Operations, Finance | Included where evidenced |
| Sales and fulfillment | Manage customer order flow and downstream delivery/finance visibility | Sales/Operations, Finance | Included where evidenced |
| Inventory | Track stock, movements, counts, transfers, and exceptions | Inventory, Operations, Finance | Included where evidenced |
| Delivery | Capture dispatch, POD, failed delivery, and returns | Delivery, Operations | Included where evidenced |
| Finance | AP, AR, statements, payments visibility, close, reports | Finance | Included where evidenced |
| Notifications | Surface actions, updates, failures, and recovery events | All roles by permission | Included as foundation |
| Reporting | Provide operational, finance, user-admin, and audit visibility | Management, Finance, Admin | Included as foundation |
| Payments/gateways | Track payment execution and settlement flows | Finance, Operations | Conditional/held for live gateways |
| FX/multi-currency | Support USD/EGP and currency impacts | Finance | Included as evidenced lane |
| Islamic Finance | Manage Shariah/Murabaha/receivables finance flows | Islamic Finance team | Deferred from production MVP |
| Regulatory fintech layer | Digital identity, e-contract, e-record, outsourcing, sandbox | Compliance/Product | Future controlled enhancement |
7. User And Role Operating Model
7.1 System Owner
Business intent:
The System Owner is a tightly restricted governance role used to bootstrap and govern Administrator users. This role protects the system from uncontrolled creation of Administrator accounts.
Allowed business actions:
- create the first Administrator user
- create additional Administrator users
- govern Administrator status
- view Administrator activity reports
Not allowed:
- supplier workflows
- customer workflows
- procurement
- finance
- inventory
- operational dashboards
- non-Administrator user reports
Control rule:
Only System_Owner can create Administrator users.
7.2 Administrator
Business intent:
The Administrator manages users and function access. This role is not a business operations role; it is a platform governance role.
Allowed business actions:
- create users
- assign user type and role
- assign/remove functions
- manage role/function sets
- configure portal menu visibility
- suspend, hold, revoke, or delete users with mandatory reason
- export/print user administration reports
Control rule:
Administrator must not see or operate unrelated business modules.
7.3 Operations User
Business intent:
Operations users manage business workflow execution, especially onboarding review, case handling, exceptions, and coordination across procurement, customer, supplier, and delivery operations.
Typical actions:
- review onboarding cases
- return case for rework
- reject case
- hold case
- reopen case
- approve case for activation
- monitor work queues
- review operational exceptions
7.4 Finance User
Business intent:
Finance users manage AP, AR, payments visibility, statements, close, reconciliation, tax, and financial reporting.
Typical actions:
- review supplier invoices
- view AP settlement status
- review customer invoices and receipts
- monitor AR aging and collections
- produce customer and supplier statements
- review finance reports
- execute or review close controls
- monitor tax/ETA/gateway exceptions where enabled
7.5 Supplier User
Business intent:
Supplier users should have a secure self-service experience to manage their relationship with CashLine.
Typical actions:
- complete onboarding
- maintain company profile
- upload compliance documents
- view orders or requests
- submit or track invoices where enabled
- view statement/status information
- receive notifications
Data rule:
Supplier users can only see their own organization data.
7.6 Customer User
Business intent:
Customer users should have a controlled self-service experience to track requests, orders, invoices, statements, payments, and status updates.
Typical actions:
- complete onboarding
- view customer profile
- submit or track requests where enabled
- view orders and invoices
- view statements/payment status
- receive notifications
Data rule:
Customer users can only see their own organization data.
8. End-To-End Business Journeys
8.1 Supplier Onboarding Journey
Business intent:
Convert a supplier from a public prospect into an approved and controlled supplier profile with documents, review evidence, status, and access rights.
Trigger:
A supplier starts self-onboarding from the public/login page.
Happy path:
1. Supplier opens supplier landing page. 2. Supplier reads the supplier portal description. 3. Supplier enters company/contact data. 4. Supplier uploads compliance/KYC documents. 5. System creates supplier lead/profile/case. 6. Operations sees the case in onboarding queue. 7. Reviewer checks documents and checklist items. 8. Reviewer records findings if needed. 9. Case moves to approval. 10. Supplier is approved and activated. 11. Supplier access is provisioned. 12. Notification/credential flow is triggered. 13. Supplier can login and view supplier dashboard.
Exception paths:
- missing documents: case cannot be approved
- open findings: case remains blocked
- incorrect data: case returned for rework
- risk/compliance concern: case placed on hold
- unacceptable profile: case rejected
Business outputs:
- supplier profile
- onboarding case
- KYC/document record
- review checklist
- approval/audit trail
- supplier portal account
- notification event
- onboarding report visibility
8.2 Customer Onboarding Journey
Business intent:
Convert a customer/entity from a public prospect into an approved customer profile with controlled access and operational visibility.
Trigger:
A customer starts onboarding from the public/login page.
Happy path:
1. Customer enters organization/contact information. 2. Customer uploads required evidence. 3. System creates customer profile and onboarding case. 4. Operations reviews completeness and documents. 5. Reviewer approves or routes for decision. 6. Customer profile becomes active. 7. Customer access is provisioned. 8. Customer can login and view dashboard/status.
Exception paths:
- missing tax/compliance data
- duplicate profile suspected
- invalid documents
- open reviewer findings
- rejected or held customer case
Business outputs:
- customer profile
- onboarding case
- compliance document record
- review decision
- portal access
- customer reporting visibility
8.3 Supplier To Procurement To AP Settlement Journey
Business intent:
Connect supplier onboarding, procurement, goods/service receipt, supplier invoicing, AP settlement, and supplier visibility.
Expected flow:
1. Supplier is active. 2. Procurement/Operations creates or manages purchase need. 3. Supplier receives PO/request visibility where enabled. 4. Supplier acknowledges or responds. 5. Goods/service receipt is recorded. 6. Supplier invoice is submitted or captured. 7. Finance reviews AP impact. 8. Settlement/payment status is tracked. 9. Supplier statement reflects relevant activity. 10. Reports and audit trail show downstream state.
Control points:
- supplier must be active
- procurement approval may be required
- invoice/payment actions require finance authority
- settlement exceptions must be traceable
8.4 Customer To Sales To AR Receipt Journey
Business intent:
Connect customer profile, order/request, fulfillment, invoice, AR receipt, statement, and customer visibility.
Expected flow:
1. Customer is active. 2. Customer request/order is created or visible. 3. Operations/sales processes order. 4. Inventory/fulfillment releases where applicable. 5. Delivery/POD is captured. 6. Customer invoice is generated. 7. Customer payment/receipt is recorded or tracked. 8. Customer statement updates. 9. Finance and management reports reflect the lifecycle.
Control points:
- credit control may block release
- discounts require approval
- returns/credit notes require controlled processing
- receipt reversal/reallocation must be audited
8.5 Administrator User Provisioning Journey
Business intent:
Create users with correct role, user type, and function access without exposing unrelated business capabilities.
Expected flow:
1. Administrator opens Create New User. 2. Administrator selects user type. 3. System shows only valid roles for that user type. 4. Administrator selects role. 5. System shows applicable function sets/menu sections. 6. Administrator assigns functions. 7. User is created with correct status. 8. Audit trail captures who created the user and what access was assigned.
Control points:
- dependent dropdowns must prevent invalid role combinations
- function assignment must be persisted
- frontend and backend must enforce the same access
- suspend/hold/delete require reason
8.6 Notification Failure And Recovery Journey
Business intent:
Ensure business updates and actions are not silently lost.
Expected flow:
1. Business event occurs. 2. Notification is queued. 3. Worker attempts delivery. 4. Success is recorded, or failure is retained. 5. Retry or replay is available. 6. Final status appears in monitoring/reporting.
Control points:
- failed notifications must remain traceable
- recovery must not duplicate business transactions
- notifications should support audit and operational follow-up
9. Detailed Business Domain Requirements
9.1 Public Landing And Login
Business intent:
Provide a production-ready entry point for supplier, customer, internal, Administrator, and System Owner users.
Requirements:
- login must be clear and compact
- supplier landing description must explain self-service purpose
- public pages must not show demo/UAT/prototype wording
- Arabic version must avoid English leftovers unless intentionally bilingual
- buttons must be visually consistent and production-grade
- users must route to the correct workspace after login
9.2 Supplier Portal
Business intent:
Give suppliers controlled visibility and self-service capability without exposing internal operations.
Requirements:
- supplier profile view
- document/compliance section
- onboarding status
- request/order visibility
- invoice/status visibility where enabled
- statement/payment status where enabled
- notifications
- role-based menu sections such as Access & Identity, Onboarding & KYC, Payments & Settlement, Islamic Finance, Offers, and other supplier functions where configured
MVP note:
Only MVP-approved supplier functions should be visible in production.
9.3 Customer Portal
Business intent:
Give customers a secure channel to track business interaction with CashLine.
Requirements:
- customer profile view
- request/order visibility
- invoice and payment status
- statement view
- documents
- notifications
- role-based visibility only
9.4 Internal Operations
Business intent:
Provide internal teams with queues and screens to process business work efficiently.
Requirements:
- onboarding queue
- approval queue
- exception queue
- workflow monitoring
- operational dashboard
- case detail views
- return/reject/hold/reopen/approve actions
- audit and status history
9.5 Procurement
Business intent:
Support controlled supplier sourcing and purchasing.
Requirements:
- purchase request/RFQ/PO visibility
- supplier linkage
- goods receipt linkage
- invoice matching support
- procurement reporting
- maker/checker on sensitive actions
9.6 Sales And Fulfillment
Business intent:
Support customer-facing transaction lifecycle from order/request through delivery and finance.
Requirements:
- customer order/request visibility
- pricing and discount controls
- credit control
- dispatch/fulfillment linkage
- invoicing and AR linkage
- returns and credit-note handling
9.7 Inventory
Business intent:
Maintain operational confidence in stock availability, movement, and valuation impact.
Requirements:
- item master
- warehouse/location visibility
- stock movement
- stock transfer
- stock count and variance
- inventory adjustment
- replenishment and safety stock
- damaged/quarantine/expired stock handling
- lot/serial traceability where applicable
- finance traceability
9.8 Delivery
Business intent:
Capture the evidence that goods or services reached the customer, and manage delivery exceptions.
Requirements:
- dispatch planning
- proof of delivery
- failed delivery reason
- delivery recovery
- returns
- attachment/evidence linkage
- impact on invoice/customer status
9.9 Finance
Business intent:
Provide financial control and visibility over AP, AR, statements, payments, close, tax, and reporting.
Requirements:
- supplier invoice visibility
- AP settlement status
- customer invoice visibility
- AR receipt status
- customer and supplier statements
- aging reports
- collections workbench
- payment reversal/repost controls
- cash/treasury transfer
- month-end close
- period lock
- finance statements and reports
9.10 Payments And Gateways
Business intent:
Track payment execution, provider callbacks, settlement, and exceptions in a controlled way.
Requirements:
- payment channel configuration
- provider execution tracking
- callback settlement
- replay protection
- settlement batches
- exception handling
- wallet/card token reference handling where required
MVP note:
Live Paymob/Fawry qualification remains held until target credentials and owner evidence are complete.
9.11 FX And Multi-Currency
Business intent:
Allow finance and operations to handle currency differences, especially USD/EGP.
Requirements:
- FX quote history
- manual FX override with maker/checker
- multi-currency transaction visibility
- revaluation impact
- finance reporting impact
9.12 Islamic Finance And Murabaha
Business intent:
Provide an extensible business domain for Shariah-compliant finance, partner lending, Murabaha cases, contract templates, disbursement, settlement, and reporting.
Requirements:
- partner lender profiles
- Islamic product profiles
- facilities
- finance requests
- Shariah reviews
- Murabaha cases
- contract templates
- contract generation
- disbursements
- settlements
- receivables finance
- accounting hooks
- Islamic Finance reporting
MVP note:
This is not production MVP scope unless separately remediated and signed off.
9.13 Reporting
Business intent:
Give management, operations, finance, and administrators reliable visibility into business status.
Requirements:
- user administration reports
- onboarding reports
- supplier/customer reports
- procurement reports
- sales/order reports
- inventory reports
- delivery/POD reports
- AP/AR reports
- statements
- tax/ETA reports
- workflow/exception reports
- notification reports
- export/print in PDF and Excel/CSV where applicable
9.14 Notifications Center
Business intent:
Use notifications as the proper place for updates and actions, replacing activity-card style demo content.
Requirements:
- notify users about assigned actions
- show status updates
- show failure/retry/recovery events
- retain traceability
- support role-based notification visibility
9.15 UI/UX And Arabic
Business intent:
The platform must feel live, operational, and commercially deployable.
Requirements:
- remove guideline/demo/helper cards from production UI
- remove UAT/prototype labels from user-facing pages
- remove unnecessary activity cards
- use production-ready cards and compact buttons
- frame cards/icons visibly where required
- align dropdowns and forms consistently
- support Arabic labels and RTL layouts
- avoid English leftovers in Arabic version
- keep sidebar as the main navigation method
10. Business Rules
10.1 Access Rules
- users see only assigned menu sections and functions
- backend must block access to unassigned functions
- supplier/customer users see only their organization data
- Administrator sees only user/function administration
- System Owner sees only Administrator governance
10.2 Approval Rules
- critical actions require maker/checker
- self-approval is not allowed
- rejection and return must preserve history
- hold/reopen must preserve reason and user
- finance-sensitive actions require finance authority
10.3 User Status Rules
- suspend, hold, revoke, and delete require mandatory reason
- reason must appear in audit/reporting
- deleted/revoked users must not retain active access
10.4 Onboarding Rules
- required KYC checklist items must be resolved before approval
- open findings block approval
- returned cases must be corrected before resubmission
- rejected cases must remain traceable
- activated parties can receive portal access
10.5 Reporting Rules
- reports must show operational data, not demo guidance
- exports must respect role permissions
- administrator reports must include user status/action reason fields
- drilldown should be available where the business process requires traceability
11. Data Ownership
| Data Area | Business Owner | Notes |
|---|---|---|
| Users and functions | Administrator / System Owner | System Owner governs Administrators only |
| Supplier profile | Operations / Supplier Management | Supplier can maintain allowed self-service data |
| Customer profile | Operations / Customer Management | Customer can view/maintain allowed data |
| KYC documents | Operations / Compliance | Approval gated by checklist and findings |
| Procurement | Procurement / Operations | Linked to supplier and finance |
| Sales/orders | Operations / Sales | Linked to customer, delivery, and AR |
| Inventory | Inventory / Operations | Linked to procurement, delivery, and finance |
| Finance | Finance | Owns AP, AR, statements, tax, close |
| Notifications | Platform / Operations | Reflect events and actions |
| Reports | Respective business owner | Access controlled by role/function |
12. Production MVP Acceptance Criteria
The business team should consider the MVP acceptable only when:
- supplier onboarding journey works end to end
- customer onboarding journey works end to end
- Administrator can create users and assign functions
- System Owner can govern Administrators only
- role/function visibility matches business rules
- non-MVP modules are hidden/restricted
- web and desktop behave consistently
- reports expose only relevant business information
- no demo/UAT/guideline content is visible to production users
- Arabic version is clean for production use
- rollback and support procedures exist
13. Open Decisions For The New Business Team
The new business team should decide:
- which named users are included in the first MVP rollout
- which supplier functions are visible at production launch
- which customer functions are visible at production launch
- whether payments are simulation-only or live-target qualified
- whether ETA is held or live-qualified
- when Islamic Finance moves from deferred to active production scope
- who owns KYC/compliance checklist policy
- who approves user suspension/hold/delete reason taxonomy
- what reports are mandatory for day-one production
- what Arabic legal/disclosure wording must be controlled
14. Post-MVP Roadmap Themes
Recommended post-MVP business roadmap:
- complete FRA fintech compliance layer
- harden Islamic Finance and Murabaha
- qualify live ETA target environment
- qualify Paymob/Fawry live environments
- expand customer/supplier self-service actions
- deepen reports and dashboards
- mature notification center
- add controlled outsourcing register
- add digital identity/e-contract/e-record evidence layers
- expand mobile/handheld inventory support if needed
15. Final Business Summary
CashLine ERP has moved beyond the original dual-portal ERP concept into a controlled business operating platform.
The most important business shift is that the system is no longer only about modules. It is about governed operations: who can do what, under which workflow, with which evidence, and with what downstream impact.
The new business team should manage the platform as a production MVP first, keep the launch scope disciplined, and treat all advanced or regulated capabilities as controlled post-MVP expansions unless separately signed off.
16. Functional Requirements Document
This section converts the business intent above into functional requirements that can be used by product, QA, business owners, and engineering teams.
Requirement priorities:
Must: required for Production MVP or core control integrityShould: required for near-term operational maturityCould: desirable enhancement or post-MVP optimizationDeferred: explicitly outside Production MVP unless separately approved
Requirement status:
MVP: included in current Production MVP boundaryConditional: available only if target environment, owner signoff, or module hardening is completedPost-MVP: future controlled enhancementDeferred: not included in production launch scope
16.1 Platform Access And Authentication Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-ACC-001 | The system shall provide a public entry point for supplier, customer, internal, Administrator, and System Owner users. | Must | MVP |
| FRD-ACC-002 | The system shall authenticate users before protected pages, APIs, reports, or role workspaces are accessible. | Must | MVP |
| FRD-ACC-003 | The system shall route each authenticated user to the correct role workspace after login. | Must | MVP |
| FRD-ACC-004 | The system shall clear or block incompatible cached sessions when a user attempts to open a portal outside their authorized role. | Must | MVP |
| FRD-ACC-005 | The system shall keep browser and desktop authentication behavior consistent. | Must | MVP |
| FRD-ACC-006 | The system shall prevent direct URL access to unassigned functions even if the page route is known. | Must | MVP |
| FRD-ACC-007 | The system shall support session logout and prevent unauthorized reuse after logout. | Must | MVP |
16.2 Role And Access Governance Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-RBAC-001 | The system shall define a dedicated System_Owner role. | Must | MVP |
| FRD-RBAC-002 | The System_Owner role shall be the only role authorized to create the first Administrator account. | Must | MVP |
| FRD-RBAC-003 | The System_Owner role shall be the only role authorized to create additional Administrator users. | Must | MVP |
| FRD-RBAC-004 | The System_Owner role shall not access supplier, customer, finance, procurement, inventory, reporting, or operational functions. | Must | MVP |
| FRD-RBAC-005 | The System_Owner role shall access only Administrator-related reporting and audit views. | Must | MVP |
| FRD-RBAC-006 | The system shall define an Administrator role limited to user creation, user lifecycle, and user-function administration. | Must | MVP |
| FRD-RBAC-007 | The Administrator shall not access unrelated operational business modules. | Must | MVP |
| FRD-RBAC-008 | The system shall enforce user type, role, function, and menu visibility consistently in frontend and backend layers. | Must | MVP |
| FRD-RBAC-009 | The system shall maintain audit records for role and function assignment changes. | Must | MVP |
16.3 User Administration Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-ADM-001 | Administrator shall be able to create new users. | Must | MVP |
| FRD-ADM-002 | Administrator shall select user type before role selection. | Must | MVP |
| FRD-ADM-003 | The role dropdown shall show only roles valid for the selected user type. | Must | MVP |
| FRD-ADM-004 | External user type shall expose supplier and customer role paths where configured. | Must | MVP |
| FRD-ADM-005 | The selected role shall drive available function sets and menu sections. | Must | MVP |
| FRD-ADM-006 | Administrator shall be able to assign and remove functions for users. | Must | MVP |
| FRD-ADM-007 | Administrator shall be able to suspend, hold, revoke, and delete users according to authority. | Must | MVP |
| FRD-ADM-008 | Suspend, hold, revoke, and delete actions shall require a mandatory reason before acceptance. | Must | MVP |
| FRD-ADM-009 | The mandatory reason shall be persisted and visible in audit and user administration reports. | Must | MVP |
| FRD-ADM-010 | Administrator shall be able to export user administration reports in PDF and Excel-compatible format. | Must | MVP |
| FRD-ADM-011 | User administration reports shall include user name, user type, role, joining date, suspension date, status, reason, action user, and timestamp. | Must | MVP |
| FRD-ADM-012 | Future reason capture shall support migration from free text to controlled reason list without redesigning the process. | Should | Post-MVP |
16.4 Function And Portal Menu Governance Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-FNC-001 | Administrator shall be able to manage menu sections by user type and role. | Must | MVP |
| FRD-FNC-002 | Administrator shall be able to manage child functions under each menu section. | Must | MVP |
| FRD-FNC-003 | Administrator shall be able to enable or disable functional areas for supplier, customer, internal, and admin roles. | Must | MVP |
| FRD-FNC-004 | Supplier portal function groups shall support areas such as Access & Identity, New Onboarding & KYC, Payments & Settlement, Islamic Finance, Offers, and other configured sections. | Should | Conditional |
| FRD-FNC-005 | Function visibility shall be reflected in the side navigation. | Must | MVP |
| FRD-FNC-006 | Function access shall be enforced by backend authorization, not only hidden in UI. | Must | MVP |
| FRD-FNC-007 | Disabled or deferred modules shall not be visible to production MVP users unless explicitly assigned and signed off. | Must | MVP |
| FRD-FNC-008 | Active child menu items shall be visually highlighted. | Must | MVP |
| FRD-FNC-009 | Parent menu sections shall support expand/collapse behavior. | Must | MVP |
| FRD-FNC-010 | Arabic/RTL menu behavior shall align with English/LTR behavior. | Must | MVP |
16.5 Public Landing And Login Page Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-PUB-001 | Public landing pages shall not show UAT, demo, placeholder, or prototype language. | Must | MVP |
| FRD-PUB-002 | Supplier landing page shall include production business description of the Supplier Portal. | Must | MVP |
| FRD-PUB-003 | Login buttons shall be compact, visible, aligned, and consistent across languages. | Must | MVP |
| FRD-PUB-004 | Arabic public pages shall not show untranslated English labels unless intentionally approved. | Must | MVP |
| FRD-PUB-005 | Public onboarding actions shall route users into the correct supplier or customer path. | Must | MVP |
| FRD-PUB-006 | Public pages shall use subtle company logo watermark/background without impacting readability. | Should | MVP |
16.6 Supplier Onboarding Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-SUPONB-001 | Supplier shall be able to start onboarding from public access. | Must | MVP |
| FRD-SUPONB-002 | Supplier shall be able to enter company, contact, tax, and compliance-related profile data. | Must | MVP |
| FRD-SUPONB-003 | Supplier shall be able to upload compliance/KYC documents. | Must | MVP |
| FRD-SUPONB-004 | System shall create supplier onboarding case from public intake. | Must | MVP |
| FRD-SUPONB-005 | Supplier case shall appear in internal onboarding queue. | Must | MVP |
| FRD-SUPONB-006 | Reviewer shall be able to save checklist outcomes. | Must | MVP |
| FRD-SUPONB-007 | Reviewer shall be able to record findings. | Must | MVP |
| FRD-SUPONB-008 | Approval shall be blocked if required checklist items are unresolved. | Must | MVP |
| FRD-SUPONB-009 | Approval shall be blocked if open findings remain. | Must | MVP |
| FRD-SUPONB-010 | Reviewer shall be able to return supplier case for rework. | Must | MVP |
| FRD-SUPONB-011 | Reviewer shall be able to hold supplier case with reason. | Must | MVP |
| FRD-SUPONB-012 | Reviewer shall be able to reject supplier case with reason. | Must | MVP |
| FRD-SUPONB-013 | Reviewer shall be able to reopen held or returned supplier case. | Must | MVP |
| FRD-SUPONB-014 | Approved supplier shall be activated and become eligible for supplier portal access. | Must | MVP |
| FRD-SUPONB-015 | Supplier activation shall trigger credential or notification workflow where configured. | Must | MVP |
16.7 Customer Onboarding Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-CUSONB-001 | Customer shall be able to start onboarding from public access. | Must | MVP |
| FRD-CUSONB-002 | Customer shall be able to enter company/entity, contact, tax, and compliance profile data. | Must | MVP |
| FRD-CUSONB-003 | Customer shall be able to upload required documents. | Must | MVP |
| FRD-CUSONB-004 | System shall create customer onboarding case from public intake. | Must | MVP |
| FRD-CUSONB-005 | Customer case shall appear in internal onboarding queue. | Must | MVP |
| FRD-CUSONB-006 | Reviewer shall be able to review checklist outcomes and findings. | Must | MVP |
| FRD-CUSONB-007 | Customer approval shall be blocked by unresolved required checklist items or open findings. | Must | MVP |
| FRD-CUSONB-008 | Reviewer shall be able to return, hold, reject, reopen, approve, and activate customer onboarding case. | Must | MVP |
| FRD-CUSONB-009 | Activated customer shall become eligible for customer portal access. | Must | MVP |
| FRD-CUSONB-010 | Customer activation shall trigger credential or notification workflow where configured. | Must | MVP |
16.8 Supplier Portal Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-SUP-001 | Supplier shall see only its own organization data. | Must | MVP |
| FRD-SUP-002 | Supplier shall view profile and onboarding status. | Must | MVP |
| FRD-SUP-003 | Supplier shall view and manage allowed compliance documents. | Must | MVP |
| FRD-SUP-004 | Supplier shall view relevant orders or requests where enabled. | Should | MVP |
| FRD-SUP-005 | Supplier shall view invoice and payment/status information where enabled. | Should | MVP |
| FRD-SUP-006 | Supplier shall view supplier statement or account status where enabled. | Should | MVP |
| FRD-SUP-007 | Supplier shall receive role-relevant notifications. | Must | MVP |
| FRD-SUP-008 | Supplier shall not see internal, customer-only, administrator, or system-owner functions. | Must | MVP |
16.9 Customer Portal Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-CUS-001 | Customer shall see only its own organization data. | Must | MVP |
| FRD-CUS-002 | Customer shall view profile and onboarding status. | Must | MVP |
| FRD-CUS-003 | Customer shall view requests/orders where enabled. | Should | MVP |
| FRD-CUS-004 | Customer shall view invoices and payment/receipt status where enabled. | Should | MVP |
| FRD-CUS-005 | Customer shall view customer statements where enabled. | Should | MVP |
| FRD-CUS-006 | Customer shall view relevant documents. | Should | MVP |
| FRD-CUS-007 | Customer shall receive role-relevant notifications. | Must | MVP |
| FRD-CUS-008 | Customer shall not see supplier-only, internal, administrator, or system-owner functions. | Must | MVP |
16.10 Internal Operations Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-OPS-001 | Operations users shall access onboarding queues based on assigned functions. | Must | MVP |
| FRD-OPS-002 | Operations users shall view onboarding case details. | Must | MVP |
| FRD-OPS-003 | Operations users shall perform return, reject, hold, reopen, approve, and activation actions where authorized. | Must | MVP |
| FRD-OPS-004 | Operations users shall view workflow status and queue posture. | Must | MVP |
| FRD-OPS-005 | Operations users shall access operational exception queues where assigned. | Should | MVP |
| FRD-OPS-006 | Operations users shall not access finance-only or admin-only actions unless separately assigned. | Must | MVP |
16.11 Procurement Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-PRO-001 | System shall support supplier-linked procurement workflow visibility. | Must | MVP |
| FRD-PRO-002 | System shall support purchase request/RFQ/PO lifecycle where enabled. | Should | MVP |
| FRD-PRO-003 | System shall link procurement actions to supplier records. | Must | MVP |
| FRD-PRO-004 | System shall link goods receipt and supplier invoice matching where enabled. | Should | MVP |
| FRD-PRO-005 | Sensitive procurement actions shall be maker/checker controlled. | Must | MVP |
| FRD-PRO-006 | Procurement status shall be reflected in reporting and downstream finance where applicable. | Should | MVP |
16.12 Sales And Fulfillment Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-SAL-001 | System shall support customer-linked sales/order visibility. | Must | MVP |
| FRD-SAL-002 | System shall support pricing rule application where enabled. | Should | MVP |
| FRD-SAL-003 | Discount overrides shall require approval where configured. | Must | MVP |
| FRD-SAL-004 | Customer credit control shall be enforced where configured. | Must | MVP |
| FRD-SAL-005 | Sales orders shall link to fulfillment, delivery, invoice, and AR visibility where available. | Should | MVP |
| FRD-SAL-006 | Sales returns and credit notes shall be controlled and auditable. | Should | MVP |
16.13 Inventory Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-INV-001 | System shall maintain item and warehouse/location visibility. | Must | MVP |
| FRD-INV-002 | System shall support stock movement visibility. | Must | MVP |
| FRD-INV-003 | System shall support warehouse transfer workflow where enabled. | Should | MVP |
| FRD-INV-004 | System shall support stock count and variance handling. | Should | MVP |
| FRD-INV-005 | Manual stock adjustments shall be auditable and approval-controlled where sensitive. | Must | MVP |
| FRD-INV-006 | System shall support replenishment, safety stock, and reorder controls. | Should | Post-MVP |
| FRD-INV-007 | System shall support quarantine, damaged, expired, and near-expiry stock statuses where configured. | Should | Post-MVP |
| FRD-INV-008 | System shall support lot and serial traceability where item policy requires it. | Should | Post-MVP |
| FRD-INV-009 | Inventory movements with finance impact shall be traceable to accounting records where implemented. | Must | MVP |
16.14 Delivery Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-DEL-001 | System shall support dispatch and delivery status visibility. | Must | MVP |
| FRD-DEL-002 | System shall support proof of delivery capture. | Must | MVP |
| FRD-DEL-003 | Proof of delivery shall link to relevant customer order/invoice context where available. | Should | MVP |
| FRD-DEL-004 | System shall support failed delivery reason and recovery workflow where enabled. | Should | MVP |
| FRD-DEL-005 | Delivery exception closure shall be auditable. | Must | MVP |
16.15 Finance, AP, AR, Statements, And Close Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-FIN-001 | Finance users shall view AP and supplier settlement status where enabled. | Must | MVP |
| FRD-FIN-002 | Finance users shall view AR and customer receipt status where enabled. | Must | MVP |
| FRD-FIN-003 | System shall support supplier statement visibility. | Should | MVP |
| FRD-FIN-004 | System shall support customer statement visibility. | Should | MVP |
| FRD-FIN-005 | System shall support AP/AR aging reports. | Should | MVP |
| FRD-FIN-006 | System shall support collections workbench visibility. | Should | MVP |
| FRD-FIN-007 | Payment reversal and controlled repost shall be auditable. | Should | MVP |
| FRD-FIN-008 | Cash account and treasury transfer shall be controlled where enabled. | Should | MVP |
| FRD-FIN-009 | Period close and period lock rules shall prevent unauthorized post-close changes. | Must | MVP |
| FRD-FIN-010 | Finance statements and GL drilldown shall be available where configured. | Should | MVP |
| FRD-FIN-011 | Withholding tax review/reporting shall be supported where configured. | Should | MVP |
16.16 Tax And ETA Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-TAX-001 | System shall preserve Egypt tax and ETA readiness design from the original BRD. | Must | MVP foundation |
| FRD-TAX-002 | System shall maintain tax-relevant supplier/customer profile data. | Must | MVP |
| FRD-TAX-003 | System shall support tax/ETA status visibility where implemented. | Should | Conditional |
| FRD-TAX-004 | ETA live submission shall not be represented as production-qualified until target environment credentials and authority evidence are signed off. | Must | Conditional |
| FRD-TAX-005 | ETA exception/status reporting shall be available to authorized finance/support users where enabled. | Should | Conditional |
16.17 Payments And Gateway Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-PAY-001 | System shall support payment channel setup and provider configuration. | Should | Conditional |
| FRD-PAY-002 | System shall support payment execution tracking. | Should | Conditional |
| FRD-PAY-003 | System shall process gateway callbacks through controlled callback handling. | Should | Conditional |
| FRD-PAY-004 | Gateway callbacks shall include replay-protection and auditability where enabled. | Must | Conditional |
| FRD-PAY-005 | System shall support settlement batch and settlement exception operations. | Should | Conditional |
| FRD-PAY-006 | Paymob/Fawry live production use shall remain held until target merchant evidence and owner signoff are completed. | Must | Conditional |
16.18 FX And Multi-Currency Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-FX-001 | System shall support USD/EGP priority currency handling where configured. | Must | MVP |
| FRD-FX-002 | System shall maintain FX source and quote history. | Should | MVP |
| FRD-FX-003 | Manual FX override shall require maker/checker control. | Must | MVP |
| FRD-FX-004 | FX revaluation and accounting impacts shall be traceable where implemented. | Should | MVP |
| FRD-FX-005 | FX reports shall support finance review and acceptance evidence. | Should | MVP |
16.19 Islamic Finance Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-IF-001 | System shall support Islamic Finance partner lender records. | Should | Deferred |
| FRD-IF-002 | System shall support Islamic Finance product profiles and facilities. | Should | Deferred |
| FRD-IF-003 | System shall support Islamic Finance requests and assignment/decision workflow. | Should | Deferred |
| FRD-IF-004 | System shall support Shariah review workflow. | Should | Deferred |
| FRD-IF-005 | System shall support Murabaha case lifecycle. | Should | Deferred |
| FRD-IF-006 | System shall support Islamic contract templates and contract generation. | Should | Deferred |
| FRD-IF-007 | System shall support disbursement and settlement workflows. | Should | Deferred |
| FRD-IF-008 | System shall support receivables finance and Islamic Finance reporting. | Should | Deferred |
| FRD-IF-009 | Islamic Finance functions shall remain hidden or restricted in production MVP unless separately hardened and signed off. | Must | MVP |
16.20 Murabaha Operations Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-MUR-001 | System shall preserve Murabaha operations design for future production expansion. | Should | Deferred |
| FRD-MUR-002 | Murabaha operations shall support state model, integration contracts, PO/GR, earnest margin, servicing, installments, delinquency, restructure, notices, and settlement linkage. | Should | Deferred |
| FRD-MUR-003 | Murabaha operations shall not be production MVP scope unless separately signed off. | Must | MVP |
16.21 Notifications And Async Processing Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-NOT-001 | System shall create notification events for relevant user actions and status updates. | Must | MVP |
| FRD-NOT-002 | Notifications shall be role-relevant and permission-aware. | Must | MVP |
| FRD-NOT-003 | Notification templates shall be centrally managed where implemented. | Should | MVP |
| FRD-NOT-004 | Failed notifications shall be traceable. | Must | MVP |
| FRD-NOT-005 | Notification retry/recovery shall avoid duplicate business transactions. | Must | MVP |
| FRD-ASY-001 | System shall support outbox event creation for selected business events. | Must | MVP |
| FRD-ASY-002 | System shall support inbox processing where integration events are consumed. | Should | MVP |
| FRD-ASY-003 | System shall support dead-letter handling and replay tooling. | Should | MVP |
| FRD-ASY-004 | Workers shall process asynchronous queues without bypassing audit or authorization rules. | Must | MVP |
16.22 Reporting Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-REP-001 | System shall provide role-based operational dashboards. | Must | MVP |
| FRD-REP-002 | System shall provide onboarding reports. | Must | MVP |
| FRD-REP-003 | System shall provide user administration reports. | Must | MVP |
| FRD-REP-004 | System shall provide finance reports and statement views where configured. | Should | MVP |
| FRD-REP-005 | System shall provide procurement, sales, inventory, and delivery reports where configured. | Should | MVP |
| FRD-REP-006 | System shall provide notification and workflow exception reporting where configured. | Should | MVP |
| FRD-REP-007 | Reports shall support PDF and Excel/CSV export where applicable. | Must | MVP |
| FRD-REP-008 | Reports shall not contain demo-only guidance, placeholder text, or non-operational cards. | Must | MVP |
| FRD-REP-009 | Arabic reports/screens shall not show English leftovers unless approved. | Must | MVP |
16.23 UI/UX Functional Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-UI-001 | The application shall use a production-ready shell with side navigation, top bar, breadcrumbs, and content header. | Must | MVP |
| FRD-UI-002 | Side navigation shall use expandable parent nodes and child items. | Must | MVP |
| FRD-UI-003 | Active child navigation items shall be highlighted. | Must | MVP |
| FRD-UI-004 | Side navigation shall respect role/function visibility. | Must | MVP |
| FRD-UI-005 | Buttons shall be compact and not stretch end-to-end unless the layout intentionally requires it. | Must | MVP |
| FRD-UI-006 | Action buttons shall use production visual treatment and avoid excessive heavy styling. | Must | MVP |
| FRD-UI-007 | Refresh buttons shall be visually lighter than primary action buttons where grouped with actions. | Should | MVP |
| FRD-UI-008 | Dropdown labels, selected values, and arrows shall be aligned consistently in web and desktop. | Must | MVP |
| FRD-UI-009 | All cards and key sidebar icons shall use approved visible framing where required by current UI direction. | Should | MVP |
| FRD-UI-010 | The company logo watermark shall be subtle, consistent, and non-intrusive. | Should | MVP |
| FRD-UI-011 | Arabic/RTL layouts shall align fields, dropdowns, buttons, and menu behavior correctly. | Must | MVP |
| FRD-UI-012 | UAT, demo, instructional, guideline, and placeholder content shall be removed from production user-facing screens. | Must | MVP |
16.24 Desktop Application Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-DESK-001 | Desktop app shall point to the same production backend endpoint as the web portal. | Must | MVP |
| FRD-DESK-002 | Desktop app shall inherit the same role/function access rules as web. | Must | MVP |
| FRD-DESK-003 | Desktop app shall inherit the same UI shell, watermark, and production visual cleanup as web. | Must | MVP |
| FRD-DESK-004 | Desktop logout/session behavior shall be consistent with web. | Must | MVP |
| FRD-DESK-005 | Desktop app shall not contain independent business logic that bypasses backend authorization. | Must | MVP |
16.25 Integration And API Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-INT-001 | System shall maintain integration endpoint registry where integrations are configured. | Should | MVP |
| FRD-INT-002 | System shall provide API documentation and OpenAPI artifacts for supported APIs. | Should | MVP |
| FRD-INT-003 | System shall preserve developer portal publication artifacts for partner/API onboarding. | Should | MVP |
| FRD-INT-004 | API publication shall include versioning, changelog, support model, and deprecation policy. | Should | MVP |
| FRD-INT-005 | External integrations shall not be marked production-ready until target environment evidence is signed off. | Must | MVP |
16.26 Regulatory And Compliance Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-COMP-001 | The MVP shall support role clarity, governed access, auditability, workflow traceability, and document capture. | Must | MVP |
| FRD-COMP-002 | The system shall not claim full FRA fintech compliance until dedicated compliance layers are implemented and signed off. | Must | MVP |
| FRD-COMP-003 | Future compliance layer shall support digital identity evidence. | Should | Post-MVP |
| FRD-COMP-004 | Future compliance layer shall support e-KYC verification evidence. | Should | Post-MVP |
| FRD-COMP-005 | Future compliance layer shall support digital contracts and e-signature evidence. | Should | Post-MVP |
| FRD-COMP-006 | Future compliance layer shall support digital records/evidence ledger. | Should | Post-MVP |
| FRD-COMP-007 | Future compliance layer shall support outsourcing provider register. | Should | Post-MVP |
| FRD-COMP-008 | Future compliance layer shall support sandbox governance. | Should | Post-MVP |
| FRD-COMP-009 | Future compliance layer shall support Arabic legal disclosure and consent registry. | Should | Post-MVP |
16.27 Data And Audit Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-DATA-001 | System shall segregate data by role, function, user type, and organization. | Must | MVP |
| FRD-DATA-002 | Supplier users shall access only supplier-owned data. | Must | MVP |
| FRD-DATA-003 | Customer users shall access only customer-owned data. | Must | MVP |
| FRD-DATA-004 | Administrative actions shall be auditable with user, timestamp, action, status, reason, and affected record. | Must | MVP |
| FRD-DATA-005 | Workflow status changes shall be auditable. | Must | MVP |
| FRD-DATA-006 | Document uploads, lifecycle changes, and review decisions shall be traceable. | Must | MVP |
| FRD-DATA-007 | Reports and exports shall respect access control. | Must | MVP |
16.28 Non-Functional Requirements
| ID | Requirement | Priority | Release Treatment |
|---|---|---|---|
| FRD-NFR-001 | The system shall be secure by default and enforce least privilege. | Must | MVP |
| FRD-NFR-002 | The system shall be responsive for common role dashboards and transaction screens. | Must | MVP |
| FRD-NFR-003 | The system shall support controlled production rollout and rollback. | Must | MVP |
| FRD-NFR-004 | The system shall provide health/readiness evidence for cutover governance. | Must | MVP |
| FRD-NFR-005 | The system shall support Arabic/English localization and RTL behavior. | Must | MVP |
| FRD-NFR-006 | The system shall be maintainable through documented modules, APIs, and release governance. | Must | MVP |
| FRD-NFR-007 | The system shall preserve production-ready visual consistency across web and desktop. | Must | MVP |
16.29 FRD Traceability Matrix
| Business Area | Key FRD Groups |
|---|---|
| Access and identity | FRD-ACC, FRD-RBAC, FRD-ADM, FRD-FNC |
| Supplier journey | FRD-SUPONB, FRD-SUP, FRD-PRO, FRD-FIN, FRD-NOT, FRD-REP |
| Customer journey | FRD-CUSONB, FRD-CUS, FRD-SAL, FRD-DEL, FRD-FIN, FRD-NOT, FRD-REP |
| Internal operations | FRD-OPS, FRD-PRO, FRD-SAL, FRD-INV, FRD-DEL |
| Finance and controls | FRD-FIN, FRD-TAX, FRD-PAY, FRD-FX, FRD-DATA |
| UI and channels | FRD-PUB, FRD-UI, FRD-DESK |
| Integrations and async | FRD-INT, FRD-NOT, FRD-ASY, FRD-PAY, FRD-TAX |
| Deferred regulated/advanced scope | FRD-IF, FRD-MUR, FRD-COMP |
16.30 FRD Signoff Criteria
The business team can sign off the FRD for Production MVP when:
- all
Mustrequirements markedMVPare either implemented, tested, or explicitly waived by accountable owner - all
Conditionalitems have owner decision and target-environment status recorded - all
Deferreditems are hidden or restricted from production users - all role-specific journeys have assigned business owners
- all production-visible reports remove demo/guideline content
- Arabic/RTL screens used in production are reviewed by the business owner
- Administrator and System Owner restrictions are verified
- web and desktop behavior are validated against the same access model
17. Product Requirements Document
This section defines the product view of CashLine ERP: the product problem, target users, value proposition, MVP definition, feature priorities, user experience expectations, metrics, roadmap, and release decision rules.
The BRD explains the business need. The FRD explains what functions are required. The PRD explains what product experience should be delivered and how product success will be judged.
17.1 Product Name
Product name:
CashLine ERP
Product type:
Enterprise operating platform with supplier portal, customer portal, internal operations portal, administrator governance, and desktop/web delivery.
Current product stage:
Production MVP Preparation
Recommended product status:
Ready for controlled production MVP preparation with disciplined scope
Not recommended product status:
Full enterprise-suite go-live
17.2 Product Problem Statement
The organization needs a single controlled platform to manage supplier and customer onboarding, procurement, inventory, delivery, finance, user governance, workflow visibility, notifications, and reporting.
Without CashLine ERP, business operations are exposed to:
- fragmented supplier/customer records
- manual onboarding and document tracking
- unclear role ownership
- weak auditability
- disconnected procurement, delivery, and finance status
- delayed exception visibility
- inconsistent external-party communication
- manual reporting and spreadsheet dependency
- unclear production readiness evidence
CashLine ERP is intended to reduce those risks by creating one governed business operating environment.
17.3 Product Vision
CashLine ERP should become the operating cockpit for CashLine's supplier, customer, operations, finance, and governance workflows.
The product vision is:
Create a production-grade, role-clear, auditable business platform where every user sees the right functions, every action updates the right downstream records, and every important business state can be reviewed, reported, and governed.
17.4 Product Value Proposition
For executive management:
CashLine ERP provides controlled visibility into onboarding, workflow status, operations, finance, and production readiness.
For operations:
CashLine ERP provides queues, case handling, status control, and exception visibility.
For finance:
CashLine ERP provides AP/AR visibility, statements, payments status, reports, close controls, FX visibility, and audit support.
For suppliers:
CashLine ERP provides a secure self-service portal for onboarding, documents, orders, invoices, and status updates.
For customers:
CashLine ERP provides a secure self-service portal for requests, orders, invoices, statements, and status updates.
For administrators:
CashLine ERP provides controlled user provisioning and function governance.
For compliance and governance:
CashLine ERP provides role clarity, audit trail, document evidence, and a foundation for regulated fintech controls.
17.5 Target Users And Personas
| Persona | Primary Need | Product Promise |
|---|---|---|
| Executive Sponsor | Know whether the platform is operationally credible and ready | Clear status, controlled scope, evidence-based readiness |
| Business Owner | Manage business process execution | Role-specific workflow, reports, and exception visibility |
| System Owner | Control Administrator creation | Restricted bootstrap/governance workspace |
| Administrator | Create users and assign functions | Safe user lifecycle and function governance |
| Operations Reviewer | Process supplier/customer cases | Queue-based onboarding review and lifecycle actions |
| Finance User | Control AP, AR, payments, statements, tax, close | Traceable finance visibility and reports |
| Supplier User | Manage supplier relationship with CashLine | Self-service onboarding, documents, orders, invoices, status |
| Customer User | Track customer interaction with CashLine | Self-service profile, orders, invoices, statements, status |
| Support/Hypercare User | Resolve early production issues | Monitoring, runbooks, status and notification visibility |
| QA/UAT Lead | Validate workflows and regression | Testable flows, acceptance criteria, and release evidence |
17.6 Product Goals
| Goal ID | Product Goal | Success Definition |
|---|---|---|
| PRD-GOAL-001 | Enable controlled production MVP launch | MVP scope is clear, non-MVP features are hidden/restricted, readiness evidence is available |
| PRD-GOAL-002 | Reduce onboarding friction | Supplier/customer onboarding can be initiated, reviewed, decided, and activated |
| PRD-GOAL-003 | Improve role clarity | Users only see authorized functions and backend access matches UI visibility |
| PRD-GOAL-004 | Strengthen governance | System Owner and Administrator restrictions are enforced |
| PRD-GOAL-005 | Improve operational visibility | Operations and finance can see relevant cases, statuses, reports, and exceptions |
| PRD-GOAL-006 | Improve production perception | No demo/UAT/guideline content appears to end users |
| PRD-GOAL-007 | Support bilingual production use | Arabic/RTL pages are clean, aligned, and usable |
| PRD-GOAL-008 | Preserve future growth | Islamic Finance, Murabaha, ETA, gateways, and FRA controls remain structured for post-MVP expansion |
17.7 MVP Product Definition
The MVP is not a small demo. It is the smallest production-acceptable operating product.
The MVP must include:
- secure login and role routing
- supplier onboarding and supplier portal foundation
- customer onboarding and customer portal foundation
- internal onboarding review and operations workbench
- Administrator user creation and function governance
- System Owner administrator governance
- role-based navigation and backend access enforcement
- core finance/procurement/sales/inventory visibility where evidenced
- workflow, audit, notifications, and reporting foundation
- web and desktop consistency
- production-ready UI cleanup and Arabic/RTL polish
- cutover, rollback, and support evidence
The MVP must exclude or restrict:
- full Islamic Finance production launch
- Murabaha operations production launch
- live Paymob/Fawry use without target signoff
- live ETA use without target signoff
- Oracle parity as a blocker
- unrestricted broad rollout
- claims of full FRA fintech compliance
17.8 Product Scope By Release
| Release | Product Scope | Product Intent |
|---|---|---|
| V1 Production MVP | Controlled named-user launch with onboarding, access governance, core portal visibility, audit/reporting, web/desktop shell | Safe production entry |
| V1.1 Stabilization | Fix MVP findings, refine reports, strengthen role/function smoke tests, improve notifications | Stabilize adoption |
| V1.2 Operational Expansion | Expand supplier/customer actions, deeper finance reports, workflow drilldowns, notification center maturity | Increase day-to-day usage |
| V2 Islamic Finance | Harden Islamic Finance and Murabaha for production launch | Product expansion |
| V2 External Integrations | Live ETA, Paymob/Fawry, and other target integrations after qualification | External ecosystem readiness |
| V2 Compliance Layer | Digital identity, e-contract, digital records, outsourcing, sandbox, Arabic disclosures | Regulated fintech maturity |
17.9 Product Features And Priority
| Feature | Priority | MVP Status | Notes |
|---|---|---|---|
| Login and role routing | P0 | Required | Core entry point |
| System Owner governance | P0 | Required | Administrator bootstrap control |
| Administrator user provisioning | P0 | Required | User and function lifecycle |
| Function/menu governance | P0 | Required | Controls visibility and access |
| Supplier onboarding | P0 | Required | Main supplier acquisition path |
| Customer onboarding | P0 | Required | Main customer acquisition path |
| Operations onboarding workbench | P0 | Required | Internal review and decisioning |
| Supplier portal foundation | P0 | Required | External supplier visibility |
| Customer portal foundation | P0 | Required | External customer visibility |
| Reports and exports foundation | P0 | Required | Business visibility |
| Notifications foundation | P0 | Required | Updates and actions |
| Web/desktop shell consistency | P0 | Required | Channel parity |
| Arabic/RTL cleanup | P0 | Required where Arabic used | Production acceptance |
| Finance visibility | P1 | Included where evidenced | AP/AR/statements/reports |
| Procurement visibility | P1 | Included where evidenced | Supplier-to-procurement path |
| Sales/order visibility | P1 | Included where evidenced | Customer-to-sales path |
| Inventory visibility | P1 | Included where evidenced | Stock and movement traceability |
| Payments/gateways | P1 | Conditional | Held for live gateway signoff |
| FX/multi-currency | P1 | Included where evidenced | USD/EGP priority |
| Islamic Finance | P2 | Deferred | Requires hardening/signoff |
| Murabaha operations | P2 | Deferred | Requires dedicated release |
| FRA fintech layer | P2 | Post-MVP | Compliance expansion |
17.10 User Experience Principles
The product experience must feel operational, not instructional.
UX principles:
- show business actions, not demo guidance
- keep navigation role-specific
- keep buttons compact and readable
- make primary actions visible but not visually aggressive
- keep refresh/secondary actions lighter than primary actions
- align forms, dropdowns, and buttons consistently
- support Arabic/RTL cleanly
- use clear active navigation state
- avoid exposing empty shells or placeholder cards
- keep the desktop app visually consistent with web
- use company branding subtly through watermark/background
17.11 Key Product Journeys
| Journey | Product Outcome |
|---|---|
| Supplier onboarding to activation | Supplier can become an approved portal user through controlled review |
| Customer onboarding to activation | Customer can become an approved portal user through controlled review |
| Administrator creates user | New user receives correct role/function access |
| System Owner creates Administrator | Administrator governance remains controlled |
| Supplier views orders/invoices/status | Supplier can self-serve core business visibility |
| Customer views orders/invoices/statements | Customer can self-serve core business visibility |
| Operations reviews onboarding case | Internal team can decide, hold, return, reject, or approve |
| Finance reviews AP/AR/status | Finance can monitor business-finance state |
| Notification failure/retry | Updates are not silently lost |
| Report export | Authorized users can produce business evidence |
17.12 Product Metrics
MVP success should be measured using business, product, and operational metrics.
Business metrics:
- number of suppliers onboarded
- number of customers onboarded
- average onboarding review time
- percentage of onboarding cases returned for rework
- percentage of cases blocked by missing KYC
- number of active supplier/customer users
Operational metrics:
- open onboarding queue count
- overdue case count
- notification failures and retries
- workflow exceptions
- payment/gateway exceptions where enabled
- ETA exceptions where enabled
Governance metrics:
- user creation count
- user suspension/hold/delete count
- missing mandatory reason count
- unauthorized access attempt count
- function assignment changes
- role/function mismatch defects
Product adoption metrics:
- login frequency by role
- active users by portal
- report exports by role
- supplier/customer portal page usage
- desktop app usage versus web usage
Quality metrics:
- MVP smoke pass rate
- regression pass rate for MVP functions
- UI/Arabic defect count
- post-go-live incident count
- time to resolve hypercare issues
17.13 Product Analytics And Reporting Needs
The product should provide management with:
- user adoption dashboard
- supplier onboarding funnel
- customer onboarding funnel
- open cases by status
- case aging and SLA posture
- user administration action report
- function assignment report
- notification health report
- finance visibility dashboard
- supplier/customer statement export usage
- MVP release health view
17.14 Product Dependencies
| Dependency | Why It Matters | Treatment |
|---|---|---|
| Target production endpoint | Required for web/desktop production use | Must be configured before launch |
| Named-user rollout list | Defines production MVP users | Required before go-live |
| Role/function matrix | Controls user visibility | Required before go-live |
| Arabic wording review | Required for Arabic production quality | Required where Arabic is used |
| ETA credentials and authority access | Needed for live ETA | Held unless signed off |
| Paymob/Fawry credentials | Needed for live gateways | Held unless signed off |
| Business owner signoff | Needed for launch accountability | Required |
| Hypercare owner | Needed for early support | Required |
17.15 Product Assumptions
- MVP launch will be controlled and named-user based.
- Non-MVP functions can be hidden or restricted without blocking MVP.
- Web is the canonical channel and desktop inherits the same backend.
- Administrator and System Owner functions are governance-only.
- Arabic/RTL quality is required where Arabic screens are production-visible.
- Live ETA and Paymob/Fawry are not assumed ready unless target evidence is available.
- Islamic Finance is valuable but deferred from MVP production unless separately signed off.
17.16 Product Constraints
- The MVP must not overpromise full enterprise-suite completion.
- The product must not expose demo/UAT support content to production users.
- Non-MVP modules must not create user confusion.
- Backend authorization must match UI visibility.
- Desktop must not diverge from web.
- Production reporting must show real operational value.
- Compliance claims must match implemented controls.
17.17 Product Risks
| Risk | Impact | Mitigation |
|---|---|---|
| Too much scope exposed at MVP | User confusion and failed go-live perception | Hide/restrict non-MVP functions |
| Function governance mismatch | Users see blocked pages or unauthorized functions | Run role/function smoke tests |
| Arabic UI gaps | Poor production credibility | Business owner Arabic review |
| Live gateway not qualified | Payment failures | Keep simulation/held condition until signed off |
| ETA not qualified | Statutory integration risk | Keep held condition until target evidence |
| Islamic Finance exposed too early | Regression risk | Keep deferred/restricted |
| Admin role overexposed | Governance risk | Enforce admin-only module boundary |
| System Owner overexposed | Critical control failure | Enforce Administrator-only governance |
17.18 Product Launch Criteria
The product can proceed to controlled production MVP only when:
- MVP scope is frozen
- MVP user list is approved
- role/function matrix is approved
- System Owner and Administrator restrictions pass validation
- supplier onboarding path passes
- customer onboarding path passes
- internal operations review path passes
- supplier/customer portal visibility passes
- web and desktop parity passes
- production UI cleanup passes
- Arabic/RTL production screens pass review
- non-MVP functions are hidden/restricted
- readiness/cutover report is green
- rollback and hypercare plan are available
17.19 Product Backlog Themes
P0 backlog:
- close MVP role/function smoke testing
- lock named-user production access
- confirm production endpoint for web and desktop
- verify onboarding and administrator journeys
- remove any remaining demo/UAT content
P1 backlog:
- deepen notification center
- refine reports and exports
- improve supplier/customer self-service
- expand finance/procurement/sales/inventory drilldowns
- strengthen role-based product analytics
P2 backlog:
- Islamic Finance production hardening
- Murabaha operations production release
- live ETA target qualification
- live Paymob/Fawry target qualification
- FRA fintech compliance layer
- mobile/handheld inventory expansion
17.20 Product Roadmap
| Phase | Timeframe | Product Focus | Exit Outcome |
|---|---|---|---|
| MVP Readiness | Immediate | Scope freeze, role/function validation, UI cleanup, launch users | Launch decision pack |
| MVP Launch | First controlled production wave | Named-user operations and hypercare | Controlled live usage |
| Stabilization | Early post-launch | Defects, reports, usability, performance, support | Stable operating baseline |
| Expansion 1 | Post-stabilization | Deeper supplier/customer actions and reports | Higher adoption |
| Expansion 2 | Post-MVP | Payments/ETA live qualification and Islamic Finance hardening | Broader business capability |
| Compliance Maturity | Future | FRA fintech layer, digital identity, e-contracts, records, outsourcing, sandbox | Regulated operating maturity |
17.21 Product Acceptance Criteria
The product is acceptable for business handover when:
- business intent is understood by the incoming team
- personas and role boundaries are documented
- MVP and deferred scope are clearly separated
- key journeys are documented and testable
- FRD requirements are traceable to business capabilities
- launch criteria and success metrics are defined
- open decisions are listed for business ownership
- risks and mitigations are documented
- product roadmap is clear
17.22 PRD Signoff Checklist
| Area | Signoff Question | Owner |
|---|---|---|
| Product scope | Is MVP scope clear and acceptable? | Executive Sponsor / Product Owner |
| User roles | Are all role boundaries understood? | Product Owner / Administrator Owner |
| Supplier journey | Is supplier onboarding acceptable for MVP? | Supplier Business Owner |
| Customer journey | Is customer onboarding acceptable for MVP? | Customer Business Owner |
| Finance scope | Are finance views and held items clear? | Finance Owner |
| UI/Arabic | Are production screens acceptable? | Business Owner / Arabic Reviewer |
| Integrations | Are held external conditions documented? | Integration Owner |
| Compliance | Are compliance claims appropriately limited? | Compliance Owner |
| Launch | Is the controlled production MVP launch approved? | Go-Live Owner |
17.23 Final PRD Summary
CashLine ERP should be managed as a focused production MVP first, not as an unlimited enterprise launch.
The strongest product value is controlled business operation: role clarity, supplier/customer onboarding, workflow visibility, auditability, reporting, and governed access.
The product should expand only after the MVP proves stable in real controlled usage.