Indian Transport Management System (ITMS)

The system shall provide functionality to create, manage, and track trips from planning to payment. The system shall allow a Dispatch Manager to create a new trip. A new trip shall include details for Source, Destination, Customer, Material, Weight, Rate (per km/ton/fixed), and Expected Delivery Date. The system shall allow the assignment of an available vehicle to a trip. The system shall allow the assignment of an available driver to a trip. A trip shall progress through a defined set of statuses. The system shall provide a 'Canceled' status that can be set at any stage before 'Delivered'. [ENHANCEMENT - CHANGE] The trip status lifecycle shall be: `Planned` -> `Assigned` -> `In-Transit` <-> `On Hold` -> `Delivered` -> `Completed` (POD received) -> `Invoiced` -> `Paid` (BR-004). The 'On Hold' status can be entered from 'In-Transit' when a critical event is logged and can return to 'In-Transit' once resolved. **Enhancement Justification**: This requirement was enhanced as a ripple effect of adding trip event logging (REQ-FNC-008). The addition of an 'On Hold' status to the trip lifecycle is critical to accurately reflect the state of a trip when an interruption (e.g., Accident, Repair) occurs, providing better operational visibility than simply leaving it as 'In-Transit' or 'Canceled'.

[ENHANCEMENT - CHANGE] The system shall provide a mobile-friendly web interface specifically designed for drivers. [ENHANCEMENT - CHANGE] A logged-in driver shall be able to view a list of their currently assigned and past trips. [ENHANCEMENT - CHANGE] A driver shall be able to change the status of a trip. [ENHANCEMENT - CHANGE] A driver shall be able to upload a Proof of Delivery (POD) to mark a trip as 'Delivered'. [ENHANCEMENT - CHANGE] The POD upload shall support photo or e-signature formats. [ENHANCEMENT - CHANGE] A driver shall be able to access the 'Expense Submission' feature. [ENHANCEMENT - CHANGE] A driver shall be able to view and download the documents for their currently assigned vehicle. [ENHANCEMENT - CHANGE] A driver shall be able to submit advance requests through the portal. [ENHANCEMENT - CHANGE] A driver shall be able to submit leave applications through the portal. [ENHANCEMENT - ADDITION] A driver shall be able to report a trip halt by providing a mandatory text-based reason. [ENHANCEMENT - ADDITION] A driver shall be able to log specific events associated with a trip. [ENHANCEMENT - ADDITION] Trip events shall include a predefined list of types such as 'Accident', 'Repair', 'Government Stoppage', 'Natural Cause', 'Fueling', 'Trip Start', and 'Other'. [ENHANCEMENT - ADDITION] A driver shall be able to attach a photo to a logged event. [ENHANCEMENT - ADDITION] The system shall be configured so that specific events (e.g., 'Accident', 'Repair') can automatically trigger a change in the trip's status to 'On Hold' (BR-005). [ENHANCEMENT - ADDITION] The system shall generate a high-priority alert on the Admin/Manager dashboard when a critical event (e.g., 'Accident', 'Repair', 'Government Stoppage') is logged. **Enhancement Justification**: This requirement was enhanced based on a user request to add trip halt and event logging capabilities for drivers. The additions provide greater real-time visibility into on-ground operations. The requirement was also enhanced to fill an identified workflow gap by specifying that logging a critical event must trigger a dashboard alert for management, ensuring timely response to potential disruptions.

[ENHANCEMENT - ADDITION] The system shall provide standard reports exportable to Excel and PDF. [ENHANCEMENT - ADDITION] The system shall provide a Trip Report, filterable by date range, customer, vehicle, and driver. [ENHANCEMENT - ADDITION] The system shall provide a Vehicle Utilization Report showing on-trip vs. idle time. [ENHANCEMENT - ADDITION] The system shall provide a Driver Performance Report with metrics like on-time delivery percentage and total incentives. [ENHANCEMENT - ADDITION] The system shall provide a Fuel Efficiency Report calculating km per liter for each vehicle. [ENHANCEMENT - ADDITION] The system shall provide a Trip Profitability Report listing revenue, expenses, and net profit per trip. [ENHANCEMENT - ADDITION] The system shall provide a Vehicle Profitability Report aggregating revenue and expenses per vehicle. [ENHANCEMENT - ADDITION] The system shall provide a Customer Revenue Report showing total revenue per customer. [ENHANCEMENT - ADDITION] The system shall provide an Outstanding Invoices Report (Aging Report) categorized by overdue duration. [ENHANCEMENT - ADDITION] The system shall provide a detailed Expense Report, filterable by type, vehicle, and driver. [ENHANCEMENT - ADDITION] The system shall provide a Trip Interruption Report, filterable by date range, driver, vehicle, and event/halt type, to analyze operational disruptions. **Enhancement Justification**: This requirement was enhanced as a ripple effect of adding trip event logging (REQ-FNC-008). The new 'Trip Interruption Report' is essential to leverage the newly captured data on trip halts and events, allowing management to analyze operational disruptions, identify patterns, and improve efficiency.

The system shall provide a real-time, filterable dashboard for Admin/Manager roles. The dashboard shall include a 'Vehicle Status' widget as a pie chart (Available vs. On-Trip vs. In-Maintenance). The dashboard shall include KPIs for 'Pending Deliveries' and 'Delayed Trips'. The dashboard shall include financial summary KPIs for 'Pending Payment Collections', 'Total Revenue (MTD/YTD)', and 'Total Expenses (MTD/YTD)'. [ENHANCEMENT - CHANGE] The dashboard shall include an 'Alerts Panel' for upcoming document expiries, critical trip events logged by drivers (e.g., Accident, Repair), and other critical system alerts. **Enhancement Justification**: This requirement was enhanced as a ripple effect of adding trip event logging (REQ-FNC-008). The 'Alerts Panel' must display notifications for critical events logged by drivers to ensure that management has immediate visibility and can take prompt action, directly addressing a key operational need.

[ENHANCEMENT - CHANGE] The system shall use a Hybrid architectural pattern: Modular Monolith with Decoupled Microservice. [ENHANCEMENT - CHANGE] The core TMS application shall be a modular monolith built as an Odoo 18 addon. [ENHANCEMENT - CHANGE] A separate, lightweight microservice shall be used for GPS data ingestion. [ENHANCEMENT - CHANGE] The GPS ingestion microservice shall communicate with the Odoo monolith asynchronously via a message queue. Justification: This hybrid approach provides the development speed and framework consistency of a monolith with the scalability and resilience of microservices for the most demanding component (GPS tracking).

The system must be developed as an Odoo 18 addon. The frontend must use the Odoo Web Library (OWL). The frontend must be mobile-responsive. A separate native mobile app shall not be developed. The database must be PostgreSQL. Development shall reuse pre-existing Odoo components and conventions where possible. The system must comply with Indian GST regulations for e-invoicing.

The system shall provide a centralized repository to manage all company-owned and outsourced vehicles. The system shall allow a user to create a new vehicle record. A vehicle record shall include fields for Truck Number, Model, Capacity (in Tons), and Owner Details. The system shall allow a user to attach multiple documents to a vehicle record. Each attached document shall have a 'Document Type' and an 'Expiry Date'. The system shall automatically generate an alert 30, 15, and 7 days before a document's expiry date. The system shall allow a user to log service history entries for a vehicle. The system shall enforce that the 'Truck Number' is unique across all vehicle records (BR-002).

The system shall provide a module to manage all driver information. The system shall allow a user to create a new driver record by extending the standard Odoo `hr.employee` model. A driver record shall include fields for License Number and License Expiry Date. The system shall generate an alert 30, 15, and 7 days before a driver's license expiry date. The system shall display a log of all trips and incentives earned by the driver. The system shall prevent a driver from being assigned to a trip if their license has expired (BR-003).

[ENHANCEMENT - ADDITION] The system shall provide a centralized database of all clients by extending Odoo's `res.partner` model. [ENHANCEMENT - ADDITION] The system shall allow a user to create a new customer with fields for Customer Name, Billing Address, GSTIN, and Contact Person. [ENHANCEMENT - ADDITION] The system shall allow a customer to have multiple shipping locations associated with their record. [ENHANCEMENT - ADDITION] The system shall allow storing customer-specific rate agreements. Justification: This addition is crucial for data consistency. It prevents errors in invoicing, allows for customer-specific pricing, and enables powerful reporting on customer-wise revenue and profitability.

[ENHANCEMENT - ADDITION] The system shall provide a module to pre-define standard transportation routes. [ENHANCEMENT - ADDITION] The system shall allow a user to create a new route with fields for Route Name, Source, Destination, Standard Distance (km), and Estimated Transit Time. [ENHANCEMENT - ADDITION] The system shall auto-populate the source, destination, and distance fields when a pre-defined route is selected during trip creation. Justification: This module will speed up trip creation, ensure consistent distance calculations for billing, and help in analyzing the profitability of specific transport lanes.

[ENHANCEMENT - ADDITION] The system shall provide a repository for the types of materials transported. [ENHANCEMENT - ADDITION] The system shall allow an Admin to create and manage a list of material types. [ENHANCEMENT - ADDITION] The system shall allow associating special handling instructions with each material type. Justification: Standardizing material types prevents data entry errors and allows for analysis based on the type of goods being moved, which can influence pricing and vehicle selection.

The application shall be containerized using Docker. The application shall be deployed on a cloud provider. The production environment shall be a high-availability Kubernetes cluster. The production environment shall use a managed PostgreSQL database. The production environment shall use object storage for file attachments. The system shall use Odoo 18. The system shall use Python 3.10 or newer. The system shall use PostgreSQL 15 or newer.

The system shall depend on a procured and maintained subscription with a third-party GPS provider that offers an accessible API. The system shall depend on a procured and maintained subscription with a GST Suvidha Provider (GSP) for e-invoicing integration. The system shall assume users have access to a modern web browser and a stable internet connection.

[ENHANCEMENT - ADDITION] The system shall implement distinct user roles with pre-defined permissions. [ENHANCEMENT - ADDITION] A user assigned the 'Driver' role shall only be able to view trips assigned to them. [ENHANCEMENT - ADDITION] A user assigned the 'Driver' role shall not be able to view any financial data, including trip revenue or profitability. [ENHANCEMENT - ADDITION] A user assigned the 'Finance Officer' role shall be able to generate invoices but not create or assign new trips. [ENHANCEMENT - ADDITION] A user assigned the 'Dispatch Manager' role shall be able to create trips and approve expenses but not manage user accounts. [ENHANCEMENT - ADDITION] A user assigned the 'Admin' role shall have unrestricted access to all system features. [ENHANCEMENT - ADDITION] The system shall enforce that a user can only have one primary role (BR-001). Justification: This addition addresses a critical gap by defining the user hierarchy and segregation of duties. It ensures data security and aligns user capabilities with their operational roles, preventing unauthorized actions and data access.

The system shall provide real-time tracking of vehicles on a map. The system shall display the current location of vehicles associated with 'In-Transit' trips on an integrated map view. The system shall allow a user to define geofences for key locations. The system shall generate an alert when a vehicle enters or exits a defined geofence.

The system shall provide a module for recording and approving all trip-related and vehicle-related expenses. The system shall allow a Driver, via the web interface, to submit an expense for an assigned trip. A submitted expense shall specify the type (Diesel, Toll, Food) and amount. A submitted expense shall require an uploaded photo of the receipt. [ENHANCEMENT - ADDITION] Submitted expenses shall enter an approval queue for a Dispatch Manager or Finance Officer. [ENHANCEMENT - ADDITION] The system shall allow an approver to 'Approve' or 'Reject' a submitted expense. Only 'Approved' expenses shall be included in the trip's profitability calculation. The system shall allow a Finance Officer to add non-trip-related expenses directly to a vehicle's record. Non-trip-related expenses shall include types such as Maintenance, Insurance, and document renewal. Justification: This workflow introduces a necessary financial control, preventing unverified or fraudulent expenses from impacting profitability calculations and ensuring accountability.

[ENHANCEMENT - CHANGE] The system shall provide a feature to manually track and receive alerts for low balances on FASTag and diesel cards. [ENHANCEMENT - CHANGE] The system shall allow a user to create records for FASTag and diesel cards. [ENHANCEMENT - CHANGE] The system shall allow a user to manually update the current balance for each card. [ENHANCEMENT - CHANGE] The system shall allow a user to set a low-balance threshold for each card. [ENHANCEMENT - CHANGE] The system shall generate an alert when the manually updated balance falls below the set threshold. Justification: The original requirement for automated notification is technically infeasible due to the lack of universal APIs. This change modifies the mechanism to a manual input process, which is practical and still meets the core business need for alerts.

The system shall provide functionality for the generation of GST-compliant invoices and tracking of payments. The system shall allow generating a GST-compliant invoice for any trip in the 'Completed' state. Invoice details shall be auto-populated from the corresponding trip record. The system shall integrate with a GSP to generate a valid IRN for e-invoicing. The system shall allow a user to record partial or full payments against an invoice. The system shall maintain a customer ledger showing all invoices, payments, and the outstanding balance for each customer.

The system shall automatically calculate the profitability for each trip. For each trip, the system shall display the total revenue. For each trip, the system shall display the sum of all 'Approved' trip-related expenses. The system shall calculate and display the profitability, defined as (Revenue - Approved Expenses).

The system design shall consider future implementation of live load tracking for customers via a public link or a dedicated customer login portal. The system design shall consider future integration with logistics marketplaces. The system design shall consider future implementation of predictive maintenance alerts using AI. The system design shall consider future implementation of a multilingual UI.

The user interface shall follow Odoo's standard design language for consistency. The driver-facing interface shall be simplified with large buttons and a clear layout for ease of use on mobile devices. All screens shall be fully responsive and functional on screen sizes from 360px width upwards. The system shall strive to meet WCAG 2.1 Level AA accessibility standards. The system shall provide key screens including: Admin/Manager Dashboard, Trip List View, Trip Form View, and Driver Portal View.

The system shall require access to the device's camera via the web browser for uploading photos for POD and expense receipts.

The system shall integrate with a third-party GPS provider's API to fetch real-time location data. The integration pattern for the GPS API shall be asynchronous via a Message Queue. A dedicated microservice shall poll the GPS API, validate the data, and push it to a message queue. An Odoo scheduled job shall consume data from the message queue to update vehicle locations. The microservice shall expect location data in JSON format. The location data JSON shall contain at a minimum: `vehicle_identifier`, `latitude`, `longitude`, and `timestamp`. The system shall integrate with a GSP's API to generate compliant e-invoices. The integration pattern for the GSP API shall be a synchronous API call with an asynchronous fallback. If a synchronous GSP API call fails or times out, the task shall be added to a queue for automatic retries with exponential backoff. The system shall use secure API keys for authentication with the GSP. API keys shall be stored securely.

All communication between the client browser and the server shall be over HTTPS. HTTPS communication shall be enforced with TLS 1.2 or newer.

95% of all standard GET requests shall be completed in under 200ms. Key pages (Dashboard, Trip List) shall achieve a Largest Contentful Paint (LCP) of under 3 seconds on a standard broadband connection. The generation of a single e-invoice shall complete within 5 seconds.

The PostgreSQL database shall be configured for Point-In-Time-Recovery (PITR). Daily database snapshots shall be taken. Daily database snapshots shall be retained for at least 30 days. The entire infrastructure shall be defined using Infrastructure as Code (Terraform). A read replica of the PostgreSQL database shall be maintained for failover. The application shall be deployed with multiple replicas in Kubernetes for high availability.

User authentication shall be handled by Odoo's built-in user management system (`res.users`). Authorization shall be strictly enforced using Odoo's Role-Based Access Control (RBAC). RBAC shall include model-level permissions (`ir.model.access.csv`). RBAC shall include row-level security (`ir.rule`). All web traffic shall be encrypted in transit using TLS 1.2 or newer. Data at rest in the managed PostgreSQL database shall be encrypted. Data at rest in the S3 bucket used for document storage shall be encrypted. [ENHANCEMENT - ADDITION] All sensitive credentials (API keys, database passwords) shall be managed using a dedicated secrets manager. [ENHANCEMENT - ADDITION] Sensitive credentials shall not be stored in the codebase.

The system shall maintain an uptime of 99.9% during business hours. Planned maintenance windows shall be scheduled during off-peak hours. Users shall be notified prior to planned maintenance. The Odoo application and the GPS ingestion service shall be designed to scale horizontally by adding more container instances. The database shall be able to be scaled vertically by increasing CPU/RAM. The system architecture shall support data growth of at least 100GB per year. The TMS shall be developed as a self-contained Odoo addon with clear dependencies. The code shall adhere to PEP 8 and Flake8 standards. A minimum of 80% unit test coverage shall be required for all new business logic. All custom models and complex methods shall be documented with docstrings.

The TMS shall be developed as a custom module (addon) for the Odoo 18 platform. The TMS shall function as a core component within the Odoo ecosystem. The TMS shall leverage Odoo's existing models, including `res.partner` for customers and `hr.employee` for drivers. The TMS shall leverage Odoo's security framework. The system shall be designed as a modular monolith. The system shall include a decoupled microservice for high-volume GPS data ingestion. The system shall interface with a GPS Provider API for receiving real-time vehicle location data. The system shall interface with a GST Suvidha Provider (GSP) API for generating e-invoices.

The system shall use Prometheus for scraping key application and infrastructure metrics. The system shall use Fluentd to collect logs from all application containers. Logs shall be forwarded to a centralized platform like Elasticsearch. The system shall use Grafana for creating monitoring dashboards. The system shall use Alertmanager to send notifications for critical events. Critical events for alerting shall include high API latency, high error rates, and a full message queue.

The system shall be a web-based, mobile-friendly Transport Management System. The system shall be built as an Odoo 18 addon. The system shall manage core master data for Vehicles, Drivers, Customers, Routes, and Materials. The system shall manage the end-to-end trip lifecycle, including planning, assignment, tracking, delivery, and financial settlement. The system shall include financial modules for expense tracking, invoicing, customer ledgers, and profitability analysis. The invoicing module shall support GST e-invoicing. The system shall provide real-time vehicle tracking via third-party GPS integration. The system shall implement role-based access control for Admin, Dispatch, Finance, and Driver user types. The system shall provide a comprehensive dashboard and reporting module for operational and financial insights. The system shall provide system alerts and notifications for critical events. The system shall not include the development of a native mobile application for iOS or Android. The system shall not include direct integration with FASTag or diesel card providers for automated balance checking. Balances for FASTag and diesel cards shall be managed manually within the system. The initial release shall not include future-ready features listed in section 8.

The system shall use Odoo 18 as the platform. The backend language shall be Python 3.10+. The database shall be PostgreSQL 15+. The frontend framework shall be Odoo Web Library (OWL) 2.0. The system shall use Redis for caching. [ENHANCEMENT - ADDITION] The system shall use RabbitMQ or Redis Pub/Sub for the message queue. [ENHANCEMENT - CHANGE] The system shall use AWS S3 or equivalent cloud object storage for file storage. The system shall use Docker for containerization. The system shall use Kubernetes for container orchestration. The system shall use Terraform for Infrastructure as Code. The system shall use GitHub Actions or Jenkins for CI/CD.

[ENHANCEMENT - ADDITION] The system shall provide an 'Admin' user role with full system access. [ENHANCEMENT - ADDITION] The 'Admin' role shall have permissions to manage users, system settings, and all master data. [ENHANCEMENT - ADDITION] The 'Admin' role shall have access to all reports and dashboards. [ENHANCEMENT - ADDITION] The system shall provide a 'Dispatch Manager' user role to manage core logistics operations. [ENHANCEMENT - ADDITION] The 'Dispatch Manager' role shall have permissions to create and manage trips, assign drivers and vehicles, approve expenses, and view operational reports. [ENHANCEMENT - ADDITION] The system shall provide a 'Finance Officer' user role to manage financial aspects. [ENHANCEMENT - ADDITION] The 'Finance Officer' role shall have permissions to handle invoicing, payments, customer ledgers, and financial reporting. [ENHANCEMENT - ADDITION] The system shall provide a 'Driver' user role for on-field users. [ENHANCEMENT - ADDITION] The 'Driver' role shall access the system via a mobile-friendly web interface to view trips, update status, and submit expenses. [ENHANCEMENT - ADDITION] The interface for the 'Driver' role shall be simple and intuitive. Justification: This addition addresses a critical gap by defining the user hierarchy and segregation of duties. It ensures data security and aligns user capabilities with their operational roles, preventing unauthorized actions and data access.

As the owner of a growing Indian transport company, I require a robust, scalable, and user-friendly Transport Management System (TMS) to digitize and manage all aspects of logistics operations, including trip planning, vehicle tracking, freight management, invoicing, driver coordination, and customer service. This system will serve as the digital backbone of the business, helping us optimize vehicle utilization, reduce manual paperwork, and gain real-time visibility into our fleet and deliveries. It should be developed as a web-based application with a mobile-friendly interface for both internal staff and on-the-road drivers. The platform must allow our dispatch team to create and manage trips by assigning vehicles, routes, and drivers. For each trip, we should be able to record the source, destination, material details (e.g., paper rolls, steel, cement), weight, customer details, rate per km or ton, expected delivery date, and payment status. The system should maintain a vehicle master with information such as truck number, model, capacity, owner details (if outsourced), service history, and document expiry reminders (e.g., PUC, insurance, fitness). Similarly, a driver master should track license details, performance, assigned vehicles, salary, and trip-wise incentives. Alerts for expiring documents. All documents have expiry. Documents can be attached to a vehicle. A type of document can be identifiable. The backend must include trip status updates (assigned, in-transit, delivered, canceled), GPS integration for live tracking (via third-party API or GPS device sync), and geofencing options. The system should also maintain diesel and toll expense records, calculate trip profitability, and <<$Change>> allow for manual entry of FASTag and diesel card balances, and notify the team when the manually updated balance falls below a configurable threshold. <<$Change>> Enhancement Justification: The original requirement for automated notification of low FASTag or diesel card balances is technically infeasible due to the lack of universal, real-time API access from various card issuers. This change modifies the mechanism to a manual input process for balances, which is then used by the system to trigger notifications based on configurable thresholds. This preserves the core business need for alerting about low balances while addressing the technical limitations. A financial module should allow for invoice generation, trip-wise expense vs. revenue tracking, and customer ledger maintenance. Integration with GST-compliant e-invoicing and the ability to export reports in Excel/PDF is essential. The driver can easily add a runtime expense from mobile mobile-friendly web interface for a trip. The backend office can add expenses like document renewal, maintenance, insurance, repair etc, these are not related to trip but only related to the vehicle. <<$Change>> The mobile-friendly web interface for drivers must allow them to receive trip assignments, update delivery status with proof of delivery (photo or e-signature), view past trips, and request advances or leave. <<$Change>> Admins should have a powerful dashboard with filters to view pending deliveries, payment collection status, vehicle availability, and fuel efficiency reports. Enhancement Justification: The original requirements contained a contradiction regarding the driver interface, initially stating "mobile-friendly interface" and later "No mobile app required," while also referring to a "mobile app (for drivers)." This change clarifies that the driver interface will be a mobile-friendly web interface, consistent with the explicit statement "No mobile app required," ensuring a unified and unambiguous platform strategy without altering the intended driver functionalities. Optional but future-ready features include: live load tracking for customers via link or login, integration with logistics marketplaces (e.g., BlackBuck, Rivigo), predictive maintenance alerts using AI, and a multilingual UI (Hindi, Marathi, etc.) for driver accessibility. The system must be developed as an Odoo 18 addon. The frontend was also developed in Odoo18 addon, Front end app to be mobile-friendly. Drivers can access the assigned vehicle document from the web UI that is mobile-friendly. No mobile app required. Try to reuse pre-existing components. The system must have all detail required reports. Dashboards Alerts This TMS will not only reduce paperwork and manual errors but also bring professional control and transparency to our transport operations — ultimately helping us scale the business, improve customer trust, and stay competitive in the Indian logistics market.

The client, an Indian transport company owner, requires a robust, scalable, and user-friendly Transport Management System (TMS) developed as an Odoo 18 addon. The system will digitize and manage all logistics operations, aiming to optimize vehicle utilization, reduce paperwork, and provide real-time visibility. It will be a web-based application with a mobile-friendly interface for both internal staff and drivers. Key functionalities include: * **Trip Management:** Creation and management of trips, assigning vehicles, routes, and drivers. Detailed recording of trip information (source, destination, material, weight, customer, rates, delivery dates, payment status). * **Master Data Management:** * **Vehicle Master:** Stores vehicle details (number, model, capacity, owner, service history) and manages document expiry reminders (PUC, insurance, fitness) with document attachment capabilities. * **Driver Master:** Tracks driver license details, performance, assigned vehicles, salary, and trip-wise incentives, along with document expiry alerts. * **Operational Control:** Trip status updates (assigned, in-transit, delivered, canceled), GPS integration for live tracking, and geofencing. * **Financial Management:** Records diesel and toll expenses, calculates trip profitability, generates invoices, tracks trip-wise expense vs. revenue, and maintains customer ledgers. It will support GST-compliant e-invoicing and export reports (Excel/PDF). * **Expense Management:** Drivers can add runtime expenses via the mobile-friendly web interface. Backend staff can add non-trip-related vehicle expenses (maintenance, document renewals). * **Alerts:** Document expiry reminders for vehicles and drivers. <<$Change>> Alerts for low balances in FASTag and diesel cards based on manually entered balances and configurable thresholds. <<$Change>> * **Driver Interface (Mobile-friendly web UI):** <<$Change>> The mobile-friendly web interface for drivers <<$Change>> enables them to receive trip assignments, update delivery status with proof of delivery (photo/e-signature), view past trips, and request advances or leave. Drivers can also access assigned vehicle documents. * **Admin Dashboard:** Provides a powerful overview with filters for pending deliveries, payment collection status, vehicle availability, and fuel efficiency reports. * **Future-Ready Features (Optional):** Live load tracking for customers, integration with logistics marketplaces, AI-driven predictive maintenance alerts, and multilingual UI (Hindi, Marathi). The system emphasizes professional control, transparency, and scalability to enhance customer trust and competitiveness in the Indian logistics market. All required reports, dashboards, and alerts will be integrated.