DEXPO Exports
ERP System

Dexo Exports Limited is an electronics export company based in Indore, Madhya Pradesh. The company handles the procurement of electronics goods from vendors (Import) and their sale to customers overseas (Export). Currently, these operations are managed through manual processes and disconnected spreadsheets, leading to inventory inaccuracies, delays, and a lack of visibility into order status.

This document specifies the functional requirements for a web-based ERP system to be built on the OutSystems low-code platform. The system will digitalise and centralise all core operations across two delivery phases.

#	Objective	Description
OBJ-01	Centralised Inventory	Maintain a single, accurate record of all stock items, quantities, and valuations. Eliminate the use of offline spreadsheets for stock tracking.
OBJ-02	Digitalised Transactions	Replace manual order creation with a structured digital process for both Import (Purchase Orders) and Export (Sales Orders).
OBJ-03	Role-Based Access Control	Ensure each user sees and can do only what their role permits. No user should be able to access data or functionality outside their assigned scope.
OBJ-04	Management Dashboard	Provide Admin and Manager users with a real-time summary of business performance: order volumes, financials, and inventory health.
OBJ-05	Logistic Integration (Phase 2)	Connect with third-party logistic providers via API to automatically track shipment status, eliminating the need for manual follow-up calls.

The system implements four distinct user roles. Each role is defined by a specific set of permissions. No user can operate outside the scope of their assigned role. Role assignment is done by an Admin during user creation.

Role	Description	Typical User
Admin	Full system access. Manages users, all master data, all transactions, configuration, and sees all reports.	Business owner / IT manager
Manager	Operational access. Can view and manage master data and transactions. Cannot manage users or system configuration.	Operations manager
User	Sales-focused access. Can create and manage Export Orders (SO). Has read-only access to master data.	Sales executive
Logistic User	Restricted to the Logistic Dashboard only. Can update shipment status and fetch live tracking. Cannot access any other screen.	Warehouse / dispatch staff

The system follows the OutSystems three-layer architecture: Foundation at the bottom, Core in the middle, and UI at the top. Dependencies are strictly one-directional — upper layers may reference lower layers, but never the reverse.

Layer	Application / Module	Responsibility
UI Layer	DEXPO	All screens and screen-level logic. No database access. Calls Core server actions only.
Core Layer	DEXPO_CS	Core entities (Customer, Vendor, Item, SO, PO), business rules, and server actions for Phase 1.
Core Layer Phase 2	DEXPO_Logistic_CS	Logistic entities (Provider, Status Mapping, ExportMovement, ExportMovementLog), static entity (DeliveryStatus), wrapper actions to call the Integration Service.
Foundation Layer	DEXO (Theme)	Application theme, UI layouts, login flow, and shared UI templates.
Foundation Layer	Dexpo_Lib	Role definitions, role-based access logic, user management server actions.
Foundation Layer Phase 2	Dexpo_Logistic_IS	Integration Service — sole module responsible for HTTP calls to third-party logistic provider APIs. Contains input/response structures and all error handling.

The Admin manages all user accounts for the DEXPO system. This includes creating new users, assigning roles, editing details, and resetting passwords. The system sends automated email notifications on account creation and password changes.

ID	Requirement	Detail	Priority
UM-01	Navigation entry	A dropdown menu item "Manage Users" is added to the navigation bar, visible only to Admin users. Clicking it opens the Manage Users page.	MUST
UM-02	User list page	The page shows a table of all users with columns: Name (clickable), Email, Roles, Status (Active / Inactive). Default view shows Active users. Filters: Status (All / Active / Inactive), Role (dropdown).	MUST
UM-03	Add new user	Clicking "Add User" opens a popup with fields: Full Name (mandatory), Email (mandatory, used as login), Password (mandatory on create), Retype Password (mandatory on create), Roles (multi-select — at least one required), Is Active (default: checked). On save, user is created and a welcome email is sent.	MUST
UM-04	Edit user	Clicking a user name opens the same popup pre-filled. In edit mode, password fields are optional — leaving them blank retains the existing password. If a new password is provided, it must pass the same validations.	MUST
UM-05	Change password	A "Change Password" link in each user row opens a focused popup. Admin types and confirms a new password. On success, a password reset notification email is sent to the user.	MUST
UM-06	Welcome email	On successful user creation, the system sends an automated email to the user's email address containing their name, login email, and assigned password.	MUST
UM-07	Password reset email	After every successful Admin-initiated password change, the system sends an email to the user with the new password.	MUST

Field	Rule
Full Name	Minimum 2 characters. Cannot be blank.
Email	Must be a valid email format. Must be unique across all users (case-insensitive).
Password (create)	Mandatory. Minimum 6 characters.
Retype Password	Must exactly match the Password field.
Roles	At least one role must be selected. Multi-select is allowed (e.g. Admin + Manager).

Master data refers to the core reference records the system depends on — Categories, Items, Vendors, and Customers. These records are created once and reused across transactions. Incorrect or missing master data will prevent transactions from being created.

Categories group items for reporting and inventory filtering (e.g. "Air Coolers", "Fans", "Water Purifiers").

ID	Requirement	Priority
CAT-01	Admin and Manager can create, edit, and deactivate categories. Category Name is mandatory and must be unique.	MUST
CAT-02	The category list shows Name, Description, and Status (Active / Inactive) with filters for Status.	MUST
CAT-03	A category cannot be deleted if items are associated with it. Deactivation is used instead.	MUST

Items represent the physical products that DEXPO buys (via PO) and sells (via SO). The system automatically adjusts stock quantity when orders are processed.

ID	Requirement	Priority
ITEM-01	Admin and Manager can create, edit, and deactivate items. Each item belongs to a Category.	MUST
ITEM-02	Item fields: Name (mandatory), Category (mandatory), SKU (unique), Unit Rate (decimal), Remaining Quantity (integer, auto-managed), Is Active.	MUST
ITEM-03	When a PO is confirmed, the items in the PO increase the Remaining Quantity for those items. When an SO is confirmed, the items decrease it.	MUST
ITEM-04	The item list supports filtering by Category and Status. The list shows current Remaining Quantity and a stock status badge (Healthy / Low Stock / Critical) based on configurable thresholds.	MUST

Vendors are the suppliers from whom DEXPO purchases goods (Import / Purchase Orders).

ID	Requirement	Priority
VND-01	Admin and Manager can create, edit, and deactivate vendors. Vendor Name is mandatory.	MUST
VND-02	Vendor fields: Name, Contact Person, Email, Phone, Address, Is Active.	MUST

Customers are the buyers to whom DEXPO sells goods (Export / Sales Orders).

ID	Requirement	Priority
CUST-01	Admin, Manager, and User can create, edit, and deactivate customers. Customer Name is mandatory.	MUST
CUST-02	Customer fields: Name, Contact Person, Email, Phone, Billing Address, Is Active.	MUST
CUST-03	A special "Cash Customer" record exists in the system by default for walk-in or one-time buyers where no customer account is needed.	MUST

A Purchase Order (PO) represents a transaction where DEXPO buys goods from a vendor. It is referred to as an "Import Order" in the business context. POs affect the inventory by increasing stock quantities upon confirmation.

ID	Requirement	Priority
PO-01	Admin and Manager can create, view, and manage Purchase Orders. The User role has no access to PO screens.	MUST
PO-02	A PO must have at least one line item to be saved.	MUST
PO-03	Line items can be added, edited, and removed before the PO is confirmed. Once confirmed, no edits are permitted.	MUST
PO-04	The PO Report page displays all POs with filters: Date Range, Vendor, and Status. Each row shows PO ID, Date, Vendor, Item Count, and Total Amount.	MUST
PO-05	An invoice view is available for each PO showing the full breakdown of line items and totals.	SHOULD

A Sales Order (SO) represents a transaction where DEXPO sells goods to a customer. It is referred to as an "Export Order" in the business context. SOs reduce inventory quantities upon confirmation and form the basis of the Logistic tracking workflow in Phase 2.

ID	Requirement	Priority
SO-01	Admin, Manager, and User can create Sales Orders. All three roles can view the SO report.	MUST
SO-02	A Sales Order must have at least one line item to be saved.	MUST
SO-03	The system warns (but does not block by default) if the quantity for a line item exceeds the item's Remaining Quantity.	MUST
SO-04	Once an SO is confirmed, it cannot be edited or deleted. Status changes are managed through the Logistic module in Phase 2.	MUST
SO-05	The SO Report page shows all Sales Orders with filters: Date Range, Customer, and Status. Each row shows SO ID, Date, Customer, Item Count, Total Amount, and current Logistic Status.	MUST
SO-06	An invoice popup is accessible from both the SO Report and the Logistic Dashboard, showing full order breakdown.	MUST

The Admin Dashboard is the home screen for Admin and Manager users after login. It gives a single-screen view of business health across orders, financials, and inventory. All values refresh on every page load.

ID	Component	Description	Priority
DASH-01	Export Order Status Cards	Six KPI cards showing counts of export orders by stage: Total Created, In-Process, Sent to Facility, In-Transit, Delayed (EDD passed but not delivered), Delivered. Status values are derived from the LogisticStatusMaster static entity (Phase 2). In Phase 1, simplified statuses are used.	MUST
DASH-02	Financial KPI Cards	Four cards: Export Revenue Today (SUM of SO totals for today), Export Revenue – 3 Months, Import Spend – 30 Days, Total Discounts Today. Cards show the value only — no percentage delta or comparison lines.	MUST
DASH-03	Export Orders by Status Chart	A doughnut chart showing the distribution of export orders across all current statuses. Segment colours match the LogisticStatusMaster color codes. Statuses with zero orders are still visible in the legend.	MUST
DASH-04	Inventory by Category Chart	A doughnut chart showing stock value (Rate × RemainingQTY) grouped by the top 5 categories. Accompanied by horizontal progress bars showing each category's share of total stock value.	MUST
DASH-05	Inventory Item Summary Table	A table of items sorted by Stock Value (descending). Columns: Item Name, Category, Rate, Remaining Qty, Stock Value, Status badge. Status rules: Critical (Qty < 5), Low Stock (Qty < 15), Healthy. Thresholds are configurable via System Settings — not hardcoded.	MUST

The Logistic Status Master is a Static Entity in OutSystems — meaning it is defined at design time, not managed by users at runtime. It contains the official vocabulary of delivery statuses that DEXPO uses across the system. These statuses represent the states set by the Logistic Provider's API after a shipment is handed over.

#	Identifier	Label	Colour	Meaning
1	ReceivedAtFacility	Received at Facility	Cyan	Provider has received the shipment at their facility
2	Packed	Packed	Violet	Packed and labelled, ready for dispatch
3	Shipped	Shipped	Blue	Dispatched from the facility
4	InTransit	In-Transit	Dark Green	En route to the destination
5	Hold	Hold	Orange	Held — customs, documentation, or provider hold
6	Delivered	Delivered	Green	Successfully delivered to the customer
7	FailedToDeliver	Failed To Deliver	Red	All delivery attempts have failed

DEXPO ships its export orders using third-party logistics companies (e.g. DHL, Blue Dart, FedEx). Each provider communicates shipment status through their own proprietary API and uses their own status code vocabulary. This module lets the Admin register providers in the system and define how each provider's status codes translate to DEXPO's internal DeliveryStatus vocabulary.

• PKIdIntegerAuto-generated primary key
• REQProviderNameTextFull legal name of the logistics company
• REQNickNameText (Unique)Short code used in integrations. Set only on create — cannot be changed after save.
• ContactPersonTextName of the liaison at the provider company
• ContactEmailEmailMust be valid email format if provided
• ContactPhoneText
• AddressTextPhysical address of the provider
• Partner_IDTextObtained from Partner Portal registration
• APIKeyTextObtained from Partner Portal registration
• APISecretTextIn edit mode: shown blank. Leave blank to retain existing secret; enter a new value to replace it.
• IsActiveBooleanDefault: true. Inactive providers cannot be assigned to new shipments.
• CreatedOn / UpdatedOnDateTimeAudit timestamps — system-managed
• FKCreatedBy / UpdatedBy→ UserAudit user references

Each provider uses its own status codes (e.g. "OFD", "DELIVERED_OK"). This table maps each provider code to a DEXPO DeliveryStatus so the system always displays a consistent status.

• PKIdInteger
• FKLogisticProviderId→ Logistic_ProviderWhich provider this mapping row belongs to
• FKDeliveryStatusId→ DeliveryStatusThe DEXPO internal status this code maps to
• ProviderStatusIdTextProvider's raw status code (e.g. "SHIPMENT_OFD")
• ProviderStatusCodeTextProvider's human-readable label
• ProviderStatusDescriptionTextOptional description from the provider
• IsActive / CreatedOn / UpdatedOnBool / DTStandard audit fields

ID	Requirement	Priority
LP-01	Admin can navigate to "Manage Logistic Provider" from the Admin dropdown menu. Other roles cannot see this link.	MUST
LP-02	The Provider List page shows all registered providers in a table: Name, Nick Name, Contact Person, Email, Phone, Status. Clicking a provider name opens the Edit screen.	MUST
LP-03	Clicking "Add Provider" navigates to a dedicated Add/Edit Provider screen (not a popup). On save, the user is redirected back to the Provider List. Cancel also redirects without saving.	MUST
LP-04	The Add/Edit screen has two sections: Provider Details and API Credentials. A third section, Logistic Status Mapping, contains a dynamic table for mapping the provider's status codes to DEXPO's DeliveryStatus. Rows can be added and removed. Saved as part of the same save action as the provider.	MUST
LP-05	NickName is editable only during initial creation. Once saved, it becomes read-only in all future edits.	MUST
LP-06	The entire save (provider + all mapping rows) must execute in a single database transaction. If any part fails, nothing is saved.	MUST

After a Sales Order is confirmed, the physical goods need to be shipped to the customer. The Export Movement module tracks this process from internal preparation through to final delivery. Each SO has exactly one ExportMovement record. Every status change in the lifecycle is logged to ExportMovementLog.

Status	Meaning
New	Order just assigned to a Logistic User. No action taken yet.
In-Process	Logistic User has started packing the order.
Sent to Logistic Facility	Goods handed over to the Logistic Provider. This status triggers the API call to register the shipment. Once set, internal statuses cannot be changed.

After the goods are handed over and the Logistic API is called, all subsequent statuses come from the provider and are mapped to the DeliveryStatus static entity.

Received at Facility → Packed → Shipped → In-Transit → Hold / Delivered / Failed To Deliver

• PKIdInteger
• FKSOID→ SOThe Export Order this movement record belongs to. One-to-one.
• FKAssignedTo→ UserThe Logistic User responsible for this shipment
• FKCurrentDeliveryStatus→ DeliveryStatusThe current status from the static entity
• FKLogisticProviderId→ Logistic_ProviderWhich provider is handling this shipment
• NoteTextInternal note by the Logistic User
• ProviderTrackingNumberTextReturned by the API when Sent to Logistic Facility
• ProviderTrackingNoteTextProvider-supplied tracking note from API response
• ExpectedDeliveryDateDateReturned by the API on registration; updated on subsequent polls
• IsDelayBooleanTrue if EDD has passed and the order is not yet delivered
• DelayReasonTextReason for delay (from API or manual note)
• IsActiveBoolean
• CreatedOn / UpdatedOn / CreatedBy / UpdatedByAuditStandard audit fields

An append-only log. One row is added each time the ExportMovement status changes. This table provides a complete history of the shipment journey.

• PKIdInteger
• FKExportMovementId→ ExportMovementWhich shipment this log entry belongs to
• FKDeliveryStatus→ DeliveryStatusThe status at the time of this log entry
• PartnerStatusCodeTextThe raw status code returned by the provider API
• LastUpdatedDateDateTimeWhen this status was set
• ExpectedDeliveryDateDateEDD at the time of this log entry
• IsDelay / DelayReasonBool / TextDelay flag and reason captured at this point in time
• LastCommentTextAny comment provided at the time of this status update
• UpdatedByTextName of the person or "System" if updated by the auto-poll timer
• CreatedOnDateTimeWhen this log row was inserted. Append-only — rows are never updated.

The Logistic Dashboard is the sole screen visible to users with the Logistic User role. It shows all export orders assigned to that user, allows them to update internal statuses, view invoices, and fetch live tracking from the provider API.

ID	Requirement	Priority
LD-01	On login, a Logistic User is automatically redirected to the Logistic Dashboard. All other screens are hidden from the nav and blocked from direct URL access.	MUST
LD-02	The page shows a welcome banner with the user's name, last auto-poll time, and a live countdown to the next scheduled poll (15 minutes).	MUST
LD-03	Four KPI cards: Total Assigned, In Progress, Sent to Facility, Delivered. Counts update after every status change.	MUST
LD-04	A table shows all assigned orders with columns: Order ID (clickable → Invoice popup), Tracking ID, Date, Status (clickable badge for internal statuses), Logistic Company, Expected Delivery, Last Updated, Fetch button.	MUST
LD-05	New status orders always appear at the top of the table, regardless of date. All other orders are sorted by date descending.	MUST
LD-06	Table filters: Order ID (text, partial match), Tracking ID (text, partial match), Date (exact), Status (dropdown). All four filters apply simultaneously using AND logic.	MUST
LD-07	Clicking an Order ID opens an invoice popup showing full order details (customer, line items, totals) without navigating away from the dashboard.	MUST
LD-08	Clicking a status badge (for internal statuses: New, In-Process, Sent to Logistic Facility) opens a Status Update popup. The popup shows the three manual options plus — under a divider — the current API-set status read-only, if applicable. Once the status reaches "Sent to Logistic Facility" or beyond, the manual options are locked.	MUST
LD-09	The Fetch button is shown only for rows where: a Tracking ID exists AND the current status is not Delivered or Failed To Deliver. Clicking it calls the API for that single order and updates the status in real time.	MUST
LD-10	A "Fetch All Statuses Now" button polls the API for all eligible orders simultaneously. Shows a spinner during processing. On completion, displays a toast with the count of orders polled and updated.	MUST

DEXPO integrates with registered Logistic Providers via a REST API. All API communication is handled exclusively by the Dexpo_Logistic_IS Foundation module. No other module makes direct HTTP calls. API documentation is available at: https://labs.lowcademy.com/logistic/api-docs.php

ID	Requirement	Priority
API-01	When the Logistic User sets a status to "Sent to Logistic Facility", the system immediately calls the selected Provider's API endpoint using the provider's Partner ID, API Key, and API Secret to register the shipment.	MUST
API-02	The API response must return a Tracking Number and Expected Delivery Date. Both are saved to the ExportMovement record and displayed in the Logistic Dashboard table.	MUST
API-03	If the API call fails, the status is rolled back to its previous value. The user sees an inline error: "Failed to register shipment. Please retry." The system retries once automatically before showing the error.	MUST
API-04	While the API call is in progress, the Confirm button is disabled and shows a loading spinner to prevent double-submission.	MUST

ID	Requirement	Priority
API-05	Clicking the Fetch button on a row calls the Provider API with the order's Tracking Number. The returned status is mapped through the provider's Logistic_Status_Mapping records and the matching DeliveryStatus is applied to the ExportMovement record.	MUST
API-06	The updated status, EDD, and LastUpdatedDate are reflected in the Logistic Dashboard table immediately after the API call completes. A log entry is appended to ExportMovementLog.	MUST

ID	Requirement	Priority
API-07	An OutSystems Timer named PollLogisticStatuses is configured to run every 15 minutes. It queries all ExportMovement records where: TrackingID is not null AND CurrentDeliveryStatus is not Delivered or FailedToDeliver.	MUST
API-08	For each eligible record, the timer calls the provider's API, applies the status mapping, and updates the ExportMovement record. A log entry is appended to ExportMovementLog with UpdatedBy = "System".	MUST
API-09	Each timer run logs a record to SO_Logistic_PollLog with: RunAt, OrdersPolled, UpdatedCount, ErrorCount. This allows audit and debugging of polling activity.	MUST
API-10	The timer is exception-safe per record. If one API call fails, the remaining records continue processing. The failure increments ErrorCount in the PollLog but does not abort the timer run.	MUST