Case study · Logistics ERP

NPR Logistics

An ERP that turns a loose network of transporters, vehicle owners and drivers into one dispatchable system, from order creation through to the delivery challan.

Production system

Engagement
Full product engineering
Platforms
Web ERP
Role
Product engineering and delivery
Market
India Verify before publishing
NPR Logistics operations console: the order list with pickup and drop legs, the transporter, vehicle-owner and driver network, and a generated delivery challan.
Industry
Logistics
Users
Transporters, vehicle owners, drivers
Platforms
Web
Role
Full product engineering
Capabilities
Orders, network, documents
Status
Production

01The business situation

A logistics network is only as good as its paperwork.

NPR moves freight across the country not with its own fleet but through a network: transporters who hold the client relationship, vehicle owners who supply the trucks, and drivers who run the legs. Coordinating that network is one problem. Proving what happened, in documents that satisfy a client and a tax authority, is another. The system had to do both from the same record.

Core challenge

Turn a three-sided network into one dispatchable order, and make the paperwork fall out of the operation rather than be assembled after it.

Before

Network coordination and documentation handled separately

  • Phone Dispatch
  • Separate Registers
  • Manual Invoicing
  • Paper Challans

After

One order record, from dispatch through to documents

  • Transporter
  • Vehicle Owner
  • Driver
  • Documents

NPR Logistics ERP

02The system at a glance

One ERP. Four connected roles.

  • Admin Dashboard Network, orders and oversight
  • Sub-admin Console Scoped day-to-day operations
  • Order & Document View Challans, proformas, invoices
  • Network Onboarding Transporters, owners and drivers
Core PlatformRole-based, server-rendered and auditable
  • Order Creation
  • Network Onboarding
  • Roles & Permissions
  • Proforma & Invoice
  • Delivery Challan
  • Dashboards & Reports

03Workflow 01

Onboard the network before you dispatch against it.

Transporters, vehicle owners and drivers each enter the system as first-class records with their own roles and permissions. Nothing can be dispatched against a party the system does not already know.

The network onboarding screens: transporter, vehicle-owner and driver records side by side, each with its assigned role, permissions and linked vehicles.
  • Three party types, one registerTransporters, vehicle owners and drivers are modelled distinctly rather than flattened into one contact list.
  • Roles and permissions per userAccess is granted by role, so a sub-admin sees only the slice of operations their work requires.
  • Vehicles linked to ownersA truck belongs to an owner, which is what lets an order be assigned down the chain.

04Workflow 02

One order, assigned down the chain.

An order is raised for a transporter and then fulfilled through the network: a vehicle owner supplies the truck, a driver runs the leg. Each hand-off is recorded against the same order rather than restarting it.

  1. 1Order raised

    Order creation form: client, pickup and drop locations, freight details and the assigned transporter.

  2. 2Vehicle assigned

    Assignment screen showing available vehicle owners and their trucks, with the selected vehicle and driver attached to the order.

  3. 3Leg in progress

    Order status view: the pickup and drop legs with their current state and the responsible party for each.

05Workflow 03

The documents are the output, not an afterthought.

A proforma, an invoice and a delivery challan are generated from the order itself. Because they read the same record the operation ran on, they cannot drift from what actually moved.

  • Generated, not retypedEvery document is produced from the order record, so party details and freight figures agree by construction.
  • Three document typesProforma, invoice and delivery challan each serve a different point in the commercial cycle.
  • Bulk work moved off the requestHeavy generation and reporting run through a queue rather than blocking the person who asked for them.
Document generation view: a proforma, tax invoice and delivery challan produced from one order, with the order summary and party details alongside.
Compact order overview: counts by state, the recent order list and quick access to each order’s documents.

06Engineering behind the product

The system behind a dispatchable network.

A server-rendered ERP with selective interactivity, built so the people running it can move quickly through dense screens without waiting on the browser.

  • Role-based access control

    Users, roles and permissions are first-class, so administrators can add a user and grant exactly the access their work requires.

  • Three-party network model

    Transporters, vehicle owners and drivers are separate entities with their own relationships, which is what makes an order assignable down the chain.

  • Order lifecycle

    Pickup and drop are modelled as legs of one order rather than as separate jobs, so the order stays whole from creation to completion.

  • Document generation

    Proformas, invoices and delivery challans are rendered from order data, keeping the commercial record consistent with the operational one.

  • Server-rendered ERP

    Built on Laravel with server-rendered pages, which keeps dense operational screens fast and simple to reason about.

  • Selective interactivity

    VueJS is used only where it earns its place (interactive graphs and large tables) rather than across the whole application.

  • Cache and queue

    Redis backs both caching and the queue, so bulk operations run in the background instead of holding up a request.

07Technical architecture

Under the hood

The ERP is server-rendered, with client-side interactivity used only where dense data demanded it.

Backend

  • Laravel
  • PHP

Frontend

  • Server-rendered Blade
  • VueJS

Data & cache

  • Redis (cache)
  • Redis (queue)

08Delivery journey

How the ERP was delivered.

  1. Discovery

    Map the network and its commercial cycle

  2. Data modelling

    Model parties, vehicles and orders

  3. Access design

    Define roles and permission boundaries

  4. Engineering

    Build the ERP and document pipeline

  5. UAT

    Validate against real dispatch operations

  6. Production

    Go live with the operating team

  7. Continued support

    Operate and extend alongside the business

The system has been in continuous operation since release. Exact dates, durations and volumes are withheld until confirmed. Verify before publishing

09What the system enabled

What the delivered ERP enabled

  • One order record shared across the whole network
  • Transporters, vehicle owners and drivers onboarded as managed parties
  • Role-based access for admins and sub-admins
  • Proformas, invoices and challans generated from order data
  • Operational dashboards built on live records
  • Continuous operation as a production system

Related systems

Clunker Busters

Vehicle Inspection · Marketplace · Web + Mobile

A connected platform for customers, inspectors, operations, reporting and payments.

Ridebase

Rental Operations · Marketplace · Web + Mobile

A rental operations platform connecting customers, partners and runners: bookings, fleet, handovers, returns and payments in one system.

Your network is probably shaped differently. That is exactly the point.

We model the parties, hand-offs and paperwork your operation actually runs on, then build around them.

Discuss your system