Job Card and GST Billing System for a Two-Wheeler Service Centre (MERN)

JobCard-GST is a web application that replaces the paper job cards, carbon-copy estimates and hand-written tax invoices used by the thousands of small two-wheeler service centres and independent garages across India. A typical garage juggles walk-ins and phone bookings, tracks each bike's repair on a register, pulls spares from a shelf without recording it, and writes invoices by hand — which makes GST billing slow, stock invisible and service follow-up impossible.

The system gives a garage four internal roles — owner, service advisor and mechanic — plus a public appointment form. Every repair flows through a strict job-card lifecycle: Booked → Vehicle In → Estimate → Approval → In Service → Quality Check → Ready → Delivered, with a rework loop from quality check back to service. Mechanics record the work done and the spares consumed, and each issue decrements the parts stock atomically with a low-stock alert. On delivery the system generates a GST-compliant tax invoice as a PDF — separate line items for parts (HSN 8714) and labour (SAC 9987), CGST/SGST split for intra-state Tamil Nadu sales, and rates held in a configurable table because notifications change. Customer and vehicle history, odometer readings and a configurable interval drive next-service reminders.

Built with React, Node.js/Express and MongoDB — exactly the full-stack taught in MC4201, with the document model from Advanced Database Technology (MC4202) and Git/Docker practice from DevOps (MC4009) — it is a viva-defensible Anna University MCA Regulation 2021 Semester-4 project.

Small two-wheeler service centres in India handle appointments, estimates, repairs, spares and billing on paper and spreadsheets. The same job details are copied three or four times, estimates are given verbally and disputed, parts leave the shelf without being recorded so stock counts and reorder decisions are guesswork, and hand-written GST invoices routinely get the parts-versus-labour tax split wrong. Owners cannot answer basic questions — which bikes are pending, what was billed last month, when a customer's next service is due — because the history is scattered across filled registers. There is a need for a secure, role-based web application that enforces the garage's real workflow as a job-card state machine, keeps an auditable parts ledger with atomic stock updates, generates correct GST invoices from a configurable rate table, and maintains per-vehicle service history with automatic reminders — without storing any government identity numbers.

Abstract

This project delivers a workflow-driven web application for small two-wheeler service centres: appointments, a state-machine job card per bike, parts inventory with atomic stock updates, GST-compliant invoicing and service reminders. The stack is React, Node.js/Express REST APIs and MongoDB behind Mongoose, with JWT-based role-based access control. The design mirrors an Indian garage's daily routine: phone bookings, walk-ins, odometer readings, shelf-picked parts and cash or UPI settlements.

Introduction

Two-wheelers form India's largest vehicle class, serviced by authorised centres and neighbourhood garages alike. Small ones run almost entirely on paper: the job sheet is rewritten three times (estimate, work log, bill), spares leave the shelf unrecorded, and a shortage surfaces only when a part goes missing. GST makes billing errors costly: parts and labour are taxed under different codes and the invoice must show the correct split. The domain workflow — estimate first, approval before work, quality check before delivery — is genuinely procedural, making it an excellent vehicle for demonstrating state machines, transactions and role-based design.

Existing System and Gap

• Existing: paper job cards rewritten for estimate, labour and bill; stock in the owner's memory; hand-totalled invoices; phone-call reminders; history lost when a register fills.
• Limitations: no single source of truth, slow GST invoicing, stock leakage, no audit trail, no measurable turnaround time.
• Gap: affordable workshop software targets car dealerships and large chains; nothing lightweight models the small Indian two-wheeler garage's exact workflow — estimate-before-work, parts-vs-labour GST split, per-bike history.

Proposed System

• A public appointment form creates bookings; the service advisor converts them into job cards when the vehicle arrives.
• A strict job-card state machine (Booked → Vehicle In → Estimate → Approved → In Service → Quality Check → Ready → Delivered, with Cancelled and a Rework loop) enforced on the server, not in the UI.
• Estimates list labour and parts with prices; work starts only after approval, and every deviation becomes a new estimate revision.
• Parts issued to a job card are decremented atomically with a transaction, keeping a stock-movement ledger and triggering low-stock alerts at the reorder level.
• The invoice is generated as a numbered PDF with parts (HSN 8714) and labour (SAC 9987) lines, CGST/SGST computed from a rate table; payments record cash, card or UPI reference.
• Per-vehicle service history plus a configurable day/km interval feeds the owner's reminder list.

Feasibility Study

• Technical: The MERN stack is free and well documented; MongoDB fits the nested line-item structure of job cards and invoices, and multi-document transactions cover stock-sensitive operations. The app runs on any machine with Node.js 20 and MongoDB 7 and deploys via Docker.
• Economic: No licence cost; a low-tier server or the garage's existing PC suffices — far cheaper than the registers and billing errors it replaces.
• Operational: Screens mirror the paper flow: the service advisor trains in under an hour, the mechanic gets a large-button job board, and the owner gets dashboards.

In scope

• One service centre, three internal roles (owner, service advisor, mechanic) and a public appointment request form.
• Two-wheeler vehicles of any make; job cards with labour lines, parts lines, estimate revisions and quality check.
• Parts catalogue with HSN codes, purchase entries, atomic issue/return of stock, low-stock alerts.
• GST tax invoicing with CGST/SGST split, invoice PDF, payment recording and a monthly billing summary.
• Service history, odometer log and reminders; CSV export of bills and stock.

Out of scope (v1)

• Payment-gateway integration (payments are recorded with mode and reference, not processed online).
• Insurance-claim and warranty-claim workflows, multi-branch or franchise support.
• Customer login portal and push/SMS sending (the reminder list is displayed and exportable).
• Bar-code hardware integration; spare-part scanning is manual entry in v1.

The project follows an iterative and incremental (Agile-flavoured) SDLC with one-week iterations and a demo to the guide every fortnight — appropriate because the workflow rules (state machine, approval, stock) are refined by feedback after each working increment.

Testing approach: Jest unit tests for validators and the GST calculator; Supertest integration tests for the API including illegal state transitions and concurrent stock issues; manual black-box test-case tables per screen; UAT with a seeded demo day simulating a garage's morning rush.

The system is a classic three-tier MERN application with a stateless REST API.

1. Presentation tier — a React SPA (Vite build, Tailwind CSS) with role-aware routing; mechanics use a simplified job board, the owner gets dashboards.
2. Application tier — Node.js/Express REST API organised as routes → auth middleware (JWT verification and role checks) → controllers → services holding business rules (state transitions, GST computation, stock transactions).
3. Data tier — MongoDB via Mongoose with validated schemas; multi-document transactions protect stock decrements and invoice creation; PDFKit renders invoices.

flowchart LR
  B["React SPA (advisor / owner / mechanic)"] -->|HTTPS + JWT| API["Express REST API"]
  P["Public appointment form"] --> API
  API --> MW["JWT verify + role middleware"]
  MW --> C["Controllers: job cards, inventory, invoices"]
  C --> S["Services: state machine, GST calc, stock tx"]
  S --> DB[("MongoDB via Mongoose")]
  S --> PDF["PDFKit invoice renderer"]
  S --> F["Stock ledger + low-stock alerts"]

Data model (ER)

erDiagram
  USER ||--o{ JOB_CARD : "works on"
  CUSTOMER ||--o{ VEHICLE : owns
  APPOINTMENT ||--o| JOB_CARD : "becomes"
  VEHICLE ||--o{ JOB_CARD : "has history"
  JOB_CARD ||--o{ JOB_LINE : contains
  PART ||--o{ JOB_LINE : "issued as"
  PART ||--o{ STOCK_MOVE : "moved by"
  JOB_CARD ||--o| INVOICE : "billed by"
  INVOICE ||--o{ PAYMENT : "settled by"
  VEHICLE ||--o{ SERVICE_DUE : "triggers"

  USER {
    string id PK
    string name
    string email UK
    string passwordHash
    string role
  }
  CUSTOMER {
    string id PK
    string name
    string mobile UK
  }
  VEHICLE {
    string id PK
    string customerId FK
    string regNumber
    string makeModel
    int odometerKm
  }
  JOB_CARD {
    string id PK
    string vehicleId FK
    string status
    string assignedMechanicId FK
    date openedAt
  }
  JOB_LINE {
    string id PK
    string jobCardId FK
    string kind
    string hsnSac
    decimal rate
    decimal qty
  }
  PART {
    string id PK
    string name
    string hsn
    int stockQty
    int reorderLevel
  }
  INVOICE {
    string id PK
    string jobCardId FK
    string number UK
    decimal cgst
    decimal sgst
    decimal total
  }

Job-card state machine

flowchart LR
  BK["Booked"] --> VI["Vehicle In"]
  VI --> ES["Estimate Prepared"]
  ES -->|approved| AP["Approved"]
  ES -->|rejected| CX["Cancelled"]
  AP --> IS["In Service"]
  IS --> QC["Quality Check"]
  QC -->|rework needed| IS
  QC --> RD["Ready for Delivery"]
  RD --> DL["Delivered"]

• Online payment capture (UPI/Razorpay) with automatic invoice reconciliation and WhatsApp invoice delivery.
• Insurance-renewal tracking and PUC expiry reminders per vehicle.
• Bar-code/QR scanning for parts issue and a supplier purchase-order module.
• Slow-moving-parts demand analysis to optimise reorder levels.
• Multi-branch support with a central owner console, and a customer portal with live job status and digital job-card acceptance.