Skip to content

OJT Report and Job-Card Tracker for a Two-Wheeler Service Centre (Flask + SQLite)

  • 12 slides
  • 15 viva questions
  • 5 modules
  • Code included

@two-wheeler-service-job-card-trackerUpdated Oct 2026

An OJT report on a paper job-card workflow, plus a small Flask app for check-in, estimates, parts, mechanics and delivery

B.Voc, Software Development · Sem 2 / 4 / 6 · Beginner · 5 weeks · Team of 2

More info
Level
Beginner · 5 weeks · Team of 2
Relevant for
All India
Common at
UGC
Syllabus
UGC UGC B.Voc (NSQF) · On-the-job training / industry project (each year; skill component ≈ 60 % of credits) · Semester 2 / 4 / 6
Tech stack
  • Python 3
  • Flask
  • SQLite
  • Jinja2 templates
  • HTML/CSS
  • Bootstrap 5
  • JavaScript
  • pytest
For educational purposes only

Unlock this project

Full PPT + speaker notes, source code and setup steps, READMEFIRST, instructions and all 15 viva answers.

One-time. No subscription, no auto-renew, no drama.

Project packs

Credits never expire and work on any project. Use one here, save the rest for your friend who “will pay you back”.

  1. Pinned

    1 min

    Overview

    This bundle is an on-the-job training (OJT) report plus a working software deliverable, written for the skill component of a UGC B.Voc in Software Development.

    Our two-member team spent the OJT period at SpeedLine Two-Wheeler Care (a fictional name), a small service centre with one service advisor, five mechanics and about 25–40 motorcycles and scooters a day. During the first half of the training we observed and documented how the centre actually works: a customer arrives, the advisor writes a paper job card with the registration number, odometer reading, complaints and a rough estimate, the card travels with the vehicle to a mechanic, spare parts are noted in the margin, and at delivery the bill is calculated by hand. We recorded where cards got lost, where estimates changed without the customer being informed and how long customers waited for status updates on the phone.

    In the second half we built a small Job-Card Tracker web app with Python Flask, SQLite and Bootstrap. It handles vehicle check-in, digital job cards with complaint lines and estimates, parts used, mechanic assignment, a colour-coded status board, a ready-to-send delivery message that the advisor can copy into SMS or WhatsApp, and an end-of-day summary.

    The report covers the organisation profile, our daily tasks, process observations, the app, testing with the advisor and our learning outcomes.

    Syllabus alignment

    UGC · UGC B.Voc (NSQF)

    On-the-job training / industry project (each year; skill component ≈ 60 % of credits) · Semester 2 / 4 / 6

    Subjects this project applies
    • Programming in Python (Software Development trade)
    • Web design with HTML, CSS, Bootstrap and JavaScript
    • Database fundamentals with SQL (SQLite)
    • Software testing basics (pytest)
    • Workplace communication and OJT documentation
    How it is evaluated

    See your department's project guidelines.

    1 min read · 15 viva questions

  2. 2 min

    Synopsis

    Abstract

    Small two-wheeler service centres run on paper job cards. This OJT project documents the existing job-card process at a neighbourhood service centre and delivers a lightweight web application that digitises it. The app, built with Flask and SQLite, supports check-in, job cards, parts, mechanic assignment, a status board, delivery message text and a daily summary. It runs on a single shop computer with no internet dependency.

    Introduction

    Two-wheelers are the most common personal vehicles in India, and most periodic servicing happens in small independent workshops. These workshops rarely use software beyond a billing tool, because commercial dealer-management systems are expensive and complex. Yet their daily problems — which bike is where, what was promised to the customer, which parts were used — are exactly the problems a simple database solves.

    Existing system (observed during OJT)

    • The advisor fills a carbon-copy job card; the original goes with the vehicle, the copy stays at the desk.
    • Complaints are written in shorthand that other mechanics sometimes misread.
    • Parts used are scribbled on the card and later typed into the billing tool; items are occasionally missed.
    • Customers call repeatedly to ask whether the vehicle is ready; the advisor has to walk to the bay to check.
    • At closing time nobody knows exactly how many jobs were completed, pending or waiting for parts.

    Proposed system

    • One screen to check in a vehicle and create a numbered job card with complaint lines and an estimate.
    • Mechanic assignment and a status board (Waiting → In Service → Waiting for Parts → Ready → Delivered).
    • A parts-used list with quantities and rates, feeding the final amount.
    • An auto-generated, editable delivery message for SMS/WhatsApp.
    • A daily summary of jobs, revenue estimate and pending vehicles.

    Feasibility

    • Technical: Python, Flask and SQLite are free and run on the shop's existing Windows desktop.
    • Economic: no licence or hosting cost; the app works offline on the local network.
    • Operational: the advisor tried the prototype for three days of the OJT and needed about 20 minutes of guidance.
  3. 1 min

    Problem statement

    At SpeedLine Two-Wheeler Care, every service job depends on a single paper job card. When a card is misplaced or becomes unreadable with grease, the advisor cannot tell the customer what was promised, which mechanic is working on the vehicle or which parts have been fitted. Estimates are revised verbally in the bay and the customer learns the new amount only at delivery, which leads to arguments at the counter. Customers phone several times a day for status updates, interrupting the advisor, and at closing time there is no reliable count of completed, pending and parts-awaited jobs.

    The centre does not need a large dealer-management system. It needs a simple, offline, low-cost tool that records each job card digitally, shows the live status of every vehicle, keeps the parts list and estimate together, prepares a clear delivery message and produces a daily summary — and that a service advisor with basic computer skills can learn in minutes. This OJT project documents the current process and delivers such a tool.

  4. 1 min

    Objectives & scope

    1. 01Study and document the existing paper job-card process at the service centre during OJT, including observed delays and errors.
    2. 02Design a simple relational database for customers, vehicles, job cards, complaint lines, parts, mechanics and users.
    3. 03Build a Flask web app for vehicle check-in, job-card creation with estimates and mechanic assignment.
    4. 04Provide a colour-coded status board showing every vehicle's current stage.
    5. 05Record parts used against each job card and compute the final amount.
    6. 06Generate ready-to-copy delivery message text and an end-of-day summary.
    7. 07Test the app with the service advisor and record feedback and learning outcomes in the OJT report.

    Scope

    In scope

    • One service centre, one advisor login and one manager login, used on a shop desktop or on phones over the shop Wi-Fi.
    • Customer name and mobile number, vehicle registration number, make/model and odometer reading.
    • Job cards with multiple complaint lines, an estimate, a promised delivery time and status history.
    • Parts-used entries (from a small parts master) and labour charge; final amount calculation.
    • Delivery message text that the advisor copies into SMS or WhatsApp manually.
    • Daily summary page and CSV export.

    Out of scope

    • Automatic SMS/WhatsApp sending through a paid gateway.
    • GST invoicing and accounting (the centre continues with its billing tool).
    • Full inventory management and supplier purchase orders.
    • Storing any government ID (Aadhaar, driving licence number) — the app deliberately never asks for these.
  5. 1 min

    Methodology

    The OJT followed an observe → document → build → trial approach, and the software part used a small iterative (prototype) model because the advisor's feedback changed several screens.

    WeekOJT activitySoftware activityOwner
    1Orientation, safety briefing, shadowing the advisor, collecting blank job-card samples—both
    2Process mapping, timing check-in and delivery, interviews with advisor and two mechanicsRequirements list, ER diagram, screen sketchesboth
    3Continued shadowing at peak hoursCheck-in, job card, parts (Member A); login, status board (Member B)split
    4Trial of prototype at the desk for three days alongside paper cardsDelivery message, daily summary, fixes from feedbacksplit
    5Feedback collection, final observationsTesting, CSV export, user guide, report and presentationboth

    Data collected during OJT: a daily log of tasks, 20 sample job cards (with customer details masked), time taken for check-in and delivery for a sample of vehicles, and the list of problems reported by the advisor. Customer names and numbers were never copied into our notebook or the report.

    Testing approach: pytest unit tests for amount calculation and status transitions, manual test cases for every screen and a three-day parallel run where the advisor used both paper and the app.

  6. 2 min

    Architecture & tech stack

    • Python 3
    • Flask
    • SQLite
    • Jinja2 templates
    • HTML/CSS
    • Bootstrap 5
    • JavaScript
    • pytest

    The Job-Card Tracker is a classic three-layer Flask application running on one computer at the service desk. Phones on the shop Wi-Fi can open the status board through the desktop's local IP address.

    flowchart TD
      A["Service advisor browser (desktop or phone)"] --> B["Flask routes (Python)"]
      B --> C["Jinja2 templates with Bootstrap 5"]
      B --> D["Business logic: estimate, amount, status rules"]
      D --> E["sqlite3 data-access helpers"]
      E --> F[("SQLite file: instance/jobcards.sqlite")]
      B --> G["Delivery message text builder"]
      B --> H["Daily summary and CSV export"]

    Observed paper process vs new flow

    flowchart TD
      P1["Customer arrives"] --> P2["Advisor checks in vehicle"]
      P2 --> P3["Job card with complaints and estimate"]
      P3 --> P4["Mechanic assigned"]
      P4 --> P5["Parts fitted and recorded"]
      P5 --> P6{"Estimate exceeded?"}
      P6 -->|yes| P7["Advisor calls customer for approval"]
      P6 -->|no| P8["Marked Ready"]
      P7 --> P8
      P8 --> P9["Delivery message copied to SMS or WhatsApp"]
      P9 --> P10["Delivered and included in daily summary"]

    ER diagram

    erDiagram
      CUSTOMER ||--o{ VEHICLE : owns
      VEHICLE ||--o{ JOB_CARD : "is serviced in"
      MECHANIC ||--o{ JOB_CARD : "works on"
      JOB_CARD ||--|{ COMPLAINT_LINE : lists
      JOB_CARD ||--o{ JOB_PART : uses
      PART ||--o{ JOB_PART : "appears in"
      JOB_CARD ||--o{ STATUS_LOG : records
    
      CUSTOMER {
        int id PK
        string name
        string mobile
      }
      VEHICLE {
        int id PK
        int customer_id FK
        string reg_no
        string make_model
      }
      MECHANIC {
        int id PK
        string name
        int active
      }
      JOB_CARD {
        int id PK
        int vehicle_id FK
        int mechanic_id FK
        int odometer_km
        decimal estimate
        decimal labour
        string status
        datetime promised_at
        datetime created_at
      }
      COMPLAINT_LINE {
        int id PK
        int job_card_id FK
        string description
      }
      PART {
        int id PK
        string name
        decimal rate
      }
      JOB_PART {
        int id PK
        int job_card_id FK
        int part_id FK
        int qty
        decimal rate
      }
      STATUS_LOG {
        int id PK
        int job_card_id FK
        string status
        datetime changed_at
      }

    The rate is copied into JOB_PART at the time of use so that later price changes in the parts master do not alter old job cards. Status changes are appended to STATUS_LOG, which lets the daily summary compute how long vehicles waited at each stage.

  7. 5 modules

    Modules

    • Vehicle Check-in and Job Card (Member A)

      Member A built the check-in form that finds or creates the customer and vehicle by registration number, then opens a numbered job card with odometer reading, multiple complaint lines, estimate and promised delivery time, and a printable job-card view for the bay.

    • Parts Used and Amount Calculation (Member A)

      Member A implemented the parts master and the parts-used screen, where the advisor adds parts with quantity; the app copies the current rate, adds labour and shows the running total against the estimate, highlighting when the estimate is exceeded.

    • Login, Mechanics and Status Board (Member B)

      Member B implemented advisor and manager logins with hashed passwords, the mechanic list and assignment, and the colour-coded status board that groups vehicles into Waiting, In Service, Waiting for Parts, Ready and Delivered with allowed transitions only.

    • Delivery Message and Daily Summary (Member B)

      Member B built the delivery message generator, which fills a template with customer name, registration number and final amount for the advisor to copy, and the daily summary page with counts by status, estimated revenue, pending vehicles and CSV export.

    • OJT Documentation (both members)

      Both members maintained the daily OJT log, drew the as-is process map from observations, conducted the three-day parallel trial with the advisor, and wrote the organisation profile, observations and learning-outcome chapters of the report.

  8. Locked

    Presentation

    12 slides with speaker notes. The outline below is free; the bullets, notes and the generated .pptx unlock with the project.

    1. OJT Report and Job-Card Tracker
    2. Organisation profile
    3. Our OJT tasks
    4. Existing paper process
    5. Problem statement and objectives
    6. Technology used
    7. Design
    8. Modules
    9. Demo
    10. Testing and trial
    11. Learning outcomes
    12. Conclusion and future scope

    Bullets, speaker notes and the .pptx download unlock with the project.

    Presentation is locked: 12 slides, Speaker notes, .pptx download.

  9. 1 min

    Future scope

    • Automatic SMS or WhatsApp notifications through a business messaging provider when a vehicle becomes Ready.
    • Service reminders based on date and odometer reading of the last service.
    • Parts stock tracking with minimum-level alerts and supplier orders.
    • GST-compliant invoice generation and UPI QR on the bill.
    • Mechanic productivity report (jobs and hours per mechanic) from the status log.
    • A simple Progressive Web App so mechanics can update status from their phones in the bay.
  10. 7 sources

    References

    1. Flask Documentation
    2. Python sqlite3 module documentation
    3. SQLite Documentation
    4. Bootstrap 5 Documentation
    5. pytest Documentation
    6. University Grants Commission — official website (B.Voc guidelines)
    7. Miguel Grinberg, Flask Web Development, 2nd ed., O'Reilly

    Cite this bundle

    OnlyProjects. (2026). OJT Report and Job-Card Tracker for a Two-Wheeler Service Centre (Flask + SQLite): B.Voc Software Development project bundle [Educational resource]. https://onlyprojects.online/projects/bvoc-software-two-wheeler-service-job-card-tracker

Slides, diagrams & files

12 slides. Titles are free; bullets, speaker notes and the .pptx unlock with the project.

  1. SLIDE 1

    OJT Report and Job-Card Tracker

  2. SLIDE 2

    Organisation profile

  3. SLIDE 3

    Our OJT tasks

  4. SLIDE 4

    Existing paper process

  5. SLIDE 5

    Problem statement and objectives

  6. SLIDE 6

    Technology used

  7. SLIDE 7

    Design

  8. SLIDE 8

    Modules

  9. SLIDE 9

    Demo

  10. SLIDE 10

    Testing and trial

  11. SLIDE 11

    Learning outcomes

  12. SLIDE 12

    Conclusion and future scope

Architecture diagrams · 3

1
flowchart TD
  A["Service advisor browser (desktop or phone)"] --> B["Flask routes (Python)"]
  B --> C["Jinja2 templates with Bootstrap 5"]
  B --> D["Business logic: estimate, amount, status rules"]
  D --> E["sqlite3 data-access helpers"]
  E --> F[("SQLite file: instance/jobcards.sqlite")]
  B --> G["Delivery message text builder"]
  B --> H["Daily summary and CSV export"]
2
flowchart TD
  P1["Customer arrives"] --> P2["Advisor checks in vehicle"]
  P2 --> P3["Job card with complaints and estimate"]
  P3 --> P4["Mechanic assigned"]
  P4 --> P5["Parts fitted and recorded"]
  P5 --> P6{"Estimate exceeded?"}
  P6 -->|yes| P7["Advisor calls customer for approval"]
  P6 -->|no| P8["Marked Ready"]
  P7 --> P8
  P8 --> P9["Delivery message copied to SMS or WhatsApp"]
  P9 --> P10["Delivered and included in daily summary"]
3
erDiagram
  CUSTOMER ||--o{ VEHICLE : owns
  VEHICLE ||--o{ JOB_CARD : "is serviced in"
  MECHANIC ||--o{ JOB_CARD : "works on"
  JOB_CARD ||--|{ COMPLAINT_LINE : lists
  JOB_CARD ||--o{ JOB_PART : uses
  PART ||--o{ JOB_PART : "appears in"
  JOB_CARD ||--o{ STATUS_LOG : records

  CUSTOMER {
    int id PK
    string name
    string mobile
  }
  VEHICLE {
    int id PK
    int customer_id FK
    string reg_no
    string make_model
  }
  MECHANIC {
    int id PK
    string name
    int active
  }
  JOB_CARD {
    int id PK
    int vehicle_id FK
    int mechanic_id FK
    int odometer_km
    decimal estimate
    decimal labour
    string status
    datetime promised_at
    datetime created_at
  }
  COMPLAINT_LINE {
    int id PK
    int job_card_id FK
    string description
  }
  PART {
    int id PK
    string name
    decimal rate
  }
  JOB_PART {
    int id PK
    int job_card_id FK
    int part_id FK
    int qty
    decimal rate
  }
  STATUS_LOG {
    int id PK
    int job_card_id FK
    string status
    datetime changed_at
  }

Files

Viva questions & answers

3 of 15 questions free. Explain each answer in your own words before you move on.

  1. Concept

    What is a job card in a service centre and why is it important?

    A job card is the record opened when a vehicle is checked in: it lists the vehicle, odometer reading, customer complaints, estimate and later the parts and labour. At SpeedLine it was the only link between the advisor, the mechanic and the bill, so losing it meant losing the whole history of that job.

  2. Concept

    Why did you choose SQLite instead of MySQL?

    The centre has one desktop, a handful of users and no IT staff. SQLite stores the whole database in a single file, needs no server installation or password management, and is included with Python, so backup is simply copying one file. MySQL would add setup effort without any benefit at this scale.

  3. Concept

    What is Flask and what is a route?

    Flask is a lightweight Python web framework. A route maps a URL and HTTP method to a Python function; for example, the route for /jobcards/new shows the form on GET and saves the new job card on POST, then redirects to the job card's detail page.

+12 more questions

They and the answers unlock with the project. Try answering the ones above yourself first. Your examiner will.

For educational purposes only. Use this bundle to understand how the project works, then build and write your own. Submitting it verbatim is between you, your conscience and your external examiner.