Skip to content

PG Accommodation Rent, Deposit & Maintenance Manager for Paying-Guest Owners (Django + MySQL)

  • 13 slides
  • 14 viva questions
  • 7 modules
  • Code included

@pg-accommodation-rent-deposit-managerUpdated Oct 2026

Beds, rent, electricity split, deposit refunds and repair tickets for a PG, without the notebook

BCA, General · Sem 6 · Intermediate · 14 weeks · Solo

More info
Branch
General
Level
Intermediate · 14 weeks · Solo
Relevant for
All India
Common at
IGNOU, Bengaluru City University, GGSIPU
Syllabus
IGNOU BCA (revised) — BCSP-064 guidelines · BCSP-064 Project · Semester 6
Tech stack
  • Python 3.12
  • Django 5
  • MySQL 8
  • mysqlclient
  • Django templates
  • Bootstrap 5 (industry-standard extra)
  • Django test framework
For educational purposes only

Unlock this project

Full PPT + speaker notes, source code and setup steps, READMEFIRST, instructions and all 14 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

    PG Accommodation Rent, Deposit & Maintenance Manager (PGRDM) is a Django and MySQL web application for owners of paying-guest (PG) accommodation of the kind found around IT parks and colleges in Bengaluru and Pune. A typical PG has 20 to 80 beds spread over shared rooms, a caretaker, and an owner who tracks everything in a notebook and a WhatsApp group. Rent is collected over UPI with no link to the tenant, electricity bills are split by guesswork, security deposits are argued over at exit, and repair requests are forgotten.

    PGRDM gives the owner, the caretaker and each tenant one place to work. The owner defines rooms and beds and sets rent and deposit amounts. The caretaker onboards tenants (contact and emergency details only, no government ID numbers stored), records sub-meter readings and logs UPI payments with their reference numbers. The system generates monthly invoices, splits each room's electricity bill among its occupants pro-rata by days stayed, maintains a deposit ledger with deductions and computes the refund when a tenant leaves. Tenants log in to see their dues and passbook and to raise maintenance tickets. Dues reminders go out by email, and reports show occupancy, collections and outstanding amounts.

    The project is designed as an individual IGNOU BCSP-064 project. It includes the level-0, level-1 and level-2 DFDs and ER diagram the guidelines require, a dedicated security design (authentication, role-based access, password hashing, CSRF protection, input validation and an audit log), and a test-case table.

    Syllabus alignment

    IGNOU · BCA (revised) — BCSP-064 guidelines

    BCSP-064 · Project · Semester 6 · 8 credits · 200 = report 150 + viva 50 (≥40% each)

    Subjects this project applies
    • Python (web application with Django)
    • MySQL (relational database design and SQL)
    • Software engineering: SDLC, DFD up to level 2, ER diagram, test cases
    • JavaScript (client-side form checks)
    How it is evaluated

    Team: individual only

    synopsis with DFD (≥ level 2), ER/class diagrams; 50–80-page hardbound report (±10%); test cases; security section. Prohibited: C/C++ for DB projects, VB + MS-Access, dBase/FoxPro. Plagiarism → Exam Discipline Committee

    Also fits: BCU SEP 2024, GGSIPU 4-year BCA 2024, Kerala University FYUGP 2024.

    1 min read · 14 viva questions

  2. 2 min

    Synopsis

    Abstract

    Paying-guest accommodation is a large informal housing sector in Indian cities, but most PGs are run with notebooks, spreadsheets and chat groups. This causes missed rent, disputed electricity charges, deposit refund arguments and ignored repairs. This project develops the PG Accommodation Rent, Deposit & Maintenance Manager, a role-based web application built with Python (Django) and MySQL. It manages rooms and beds, tenant onboarding and exit, monthly invoices with pro-rata electricity split, UPI payment recording, a deposit ledger with refund calculation, maintenance tickets, dues reminders and reports. Security is designed in from the start with hashed passwords, role-based access, CSRF protection, validated input and an audit log.

    Introduction

    I studied two PGs with about 40 beds each near an IT corridor. In both, the owner visited once a week, the caretaker handled daily work, and rent records were a notebook plus bank SMS alerts. Owners said the hardest tasks were matching UPI credits to tenants, dividing the electricity bill fairly when tenants join mid-month, and settling deposits on exit.

    Existing system and its limitations

    • Notebook and spreadsheet records with no single view of who owes what.
    • UPI credits arrive without a clear link to a tenant or month; reconciliation takes hours.
    • Electricity is split equally regardless of days stayed, causing disputes.
    • Deposit deductions are decided at exit from memory; tenants have no record.
    • Repair requests are sent on chat and lost.

    Proposed system

    • Rooms, beds and occupancy with an allocation history.
    • Monthly invoice generation: rent, electricity share, other charges.
    • Payment entry with UPI reference number; duplicate references are rejected.
    • Deposit ledger (collected, deductions with reasons, refund) visible to the tenant.
    • Maintenance tickets with status and closure notes.
    • Dues reminders, reports and an audit trail of every financial change.

    Feasibility

    • Technical: Python and MySQL are permitted by the BCSP-064 guidelines; Django provides authentication, ORM, forms and CSRF protection.
    • Economic: open-source software on an ordinary laptop; a low-cost VPS if deployed.
    • Operational: screens follow the caretaker's current notebook columns.
    • Schedule: fits a 14-week plan including synopsis approval, development, testing and report writing.
  3. 1 min

    Problem statement

    Paying-guest owners manage dozens of tenants who join and leave at different dates, share rooms and a common electricity meter, pay rent through UPI and hand over a security deposit. Because records are kept in notebooks and chat groups, owners cannot quickly see pending dues, UPI payments are hard to match to tenants and months, electricity bills are split unfairly when tenants stay only part of a month, and deposit deductions at exit become disputes because there is no shared ledger. Maintenance complaints such as a broken geyser or a leaking tap are raised informally and forgotten.

    The problem is to build a secure, role-based web application that keeps an accurate record of beds, tenancies, invoices, payments, deposits and maintenance tickets, calculates electricity shares and deposit refunds correctly, reminds tenants of dues, and gives owners reliable reports, without storing sensitive government identity numbers.

  4. 1 min

    Objectives & scope

    1. 01Analyse the current PG workflow and document it with level-0, level-1 and level-2 data flow diagrams.
    2. 02Design a normalised MySQL database (3NF) for properties, rooms, beds, tenants, tenancies, invoices, payments, deposit transactions, meter readings, tickets and audit logs.
    3. 03Implement role-based access for Owner, Caretaker and Tenant using Django authentication, groups and permissions.
    4. 04Generate monthly invoices that combine rent with a pro-rata electricity share based on sub-meter readings and days stayed.
    5. 05Record UPI payments with unique reference numbers and maintain a running balance per tenant.
    6. 06Maintain a deposit ledger with itemised deductions and compute the refund at exit.
    7. 07Provide a maintenance ticket workflow and scheduled dues reminders by email.
    8. 08Apply security controls: hashed passwords, CSRF protection, server-side validation, session timeout and an audit log.
    9. 09Prepare and execute a documented set of test cases covering functional, boundary and security scenarios.

    Scope

    In scope

    • One owner with one or more PG properties, each with rooms and beds of different sharing types (single, double, triple).
    • Three roles: Owner (administrator), Caretaker (daily operations) and Tenant (self-service view).
    • Tenant onboarding and exit, bed allocation and transfer, monthly invoicing, electricity split, payment recording, deposit ledger and refund, maintenance tickets, email reminders and reports (occupancy, collection, dues, deposit liability).
    • Tenant identity verification recorded only as a status (verified or pending), the document type seen and who verified it.

    Out of scope

    • Online payment gateway integration; UPI payments are made outside the system and recorded with their reference number.
    • Storage of Aadhaar, PAN or any government ID number or scan.
    • Food/mess menu planning and attendance.
    • Native mobile app (the web interface is responsive).
  5. 1 min

    Methodology

    The project follows the Waterfall model with a prototyping step in the design phase. Waterfall suits an individual IGNOU project because the synopsis must be approved before development, and a quick screen prototype helps confirm requirements with the PG owner before the database is fixed.

    PhaseWeeksActivitiesDeliverable
    Problem study1–2Visit two PGs, interview owner and caretaker, collect sample notebook pages and billsRequirement notes
    Synopsis3Objectives, DFD level 0–2, ER diagram, tools, proforma; submit for approvalApproved synopsis
    System design4–5Table design in 3NF, screen prototypes, security design, test planDesign document
    Coding6–10Models and migrations, authentication and roles, rooms and tenancy, invoicing and electricity split, payments and deposit ledger, tickets, reminders, reportsWorking application
    Testing11–12Unit tests for calculations, functional test cases per module, security tests (access control, CSRF, validation)Test report
    Documentation13–14Report of 50–80 pages, user manual, screenshots, viva preparationFinal report

    Electricity split rule. For each room and month: units = closing reading − opening reading; room amount = units × tariff per unit set by the owner. Each tenant's share = room amount × (days the tenant occupied a bed in that room ÷ total bed-days occupied in that room). Amounts are rounded to the rupee and the rounding difference is added to the last share so the total matches the bill exactly.

  6. 3 min

    Architecture & tech stack

    • Python 3.12
    • Django 5
    • MySQL 8
    • mysqlclient
    • Django templates
    • Bootstrap 5 (industry-standard extra)
    • Django test framework

    PGRDM follows Django's Model–View–Template (MVT) pattern in a three-tier deployment: browser → Django application (views, forms, business services) → MySQL 8.

    DFD Level 0 (context diagram)

    flowchart TD
      OW["Owner"] -->|"rooms, rent, tariff"| P0(("PG Rent, Deposit and Maintenance Manager"))
      CT["Caretaker"] -->|"tenant details, readings, payments"| P0
      TN["Tenant"] -->|"login, tickets"| P0
      P0 -->|"reports, deposit liability"| OW
      P0 -->|"ticket list, dues list"| CT
      P0 -->|"invoices, passbook, reminders"| TN

    DFD Level 1

    flowchart TD
      OW["Owner"] --> P1(("1.0 Manage rooms and beds"))
      CT["Caretaker"] --> P2(("2.0 Tenant onboarding and exit"))
      CT --> P3(("3.0 Billing and payments"))
      TN["Tenant"] --> P5(("5.0 Maintenance tickets"))
      P1 --> D1[("D1 Rooms and beds")]
      P2 --> D2[("D2 Tenants and tenancies")]
      D1 --> P2
      P2 --> P4(("4.0 Deposit ledger"))
      P4 --> D4[("D4 Deposit transactions")]
      D2 --> P3
      P3 --> D3[("D3 Invoices and payments")]
      P5 --> D5[("D5 Tickets")]
      D3 --> P6(("6.0 Reports and reminders"))
      D4 --> P6
      D5 --> P6
      P6 --> OW
      P6 --> TN

    DFD Level 2 (process 3.0 Billing and payments)

    flowchart TD
      CT["Caretaker"] -->|"meter readings"| P31(("3.1 Record sub-meter readings"))
      P31 --> D6[("D6 Meter readings")]
      D6 --> P32(("3.2 Compute electricity share"))
      D2[("D2 Tenancies")] --> P32
      P32 --> P33(("3.3 Generate monthly invoice"))
      D2 --> P33
      P33 --> D3[("D3 Invoices")]
      CT -->|"amount, UPI reference"| P34(("3.4 Record payment"))
      P34 --> D7[("D7 Payments")]
      D3 --> P35(("3.5 Update balance and dues"))
      D7 --> P35
      P35 --> TN["Tenant"]
      P35 --> D8[("D8 Audit log")]

    ER diagram

    erDiagram
      PROPERTY ||--o{ ROOM : has
      ROOM ||--|{ BED : contains
      BED ||--o{ TENANCY : "occupied by"
      TENANT ||--o{ TENANCY : holds
      TENANCY ||--o{ INVOICE : billed
      INVOICE ||--o{ PAYMENT : "settled by"
      TENANCY ||--o{ DEPOSIT_TXN : records
      ROOM ||--o{ METER_READING : measures
      TENANCY ||--o{ TICKET : raises
      USER ||--o{ AUDIT_LOG : performs
      PROPERTY {
        int id PK
        string name
        string city
      }
      ROOM {
        int id PK
        int property_id FK
        string number
        string sharing_type
      }
      BED {
        int id PK
        int room_id FK
        string label
        decimal monthly_rent
      }
      TENANT {
        int id PK
        int user_id FK
        string full_name
        string phone
        string emergency_contact
        string id_verification_status
      }
      TENANCY {
        int id PK
        int tenant_id FK
        int bed_id FK
        date start_date
        date end_date
        decimal deposit_agreed
      }
      INVOICE {
        int id PK
        int tenancy_id FK
        string period
        decimal rent_amount
        decimal electricity_amount
        decimal total
      }
      PAYMENT {
        int id PK
        int invoice_id FK
        decimal amount
        string upi_reference
        date paid_on
      }
      DEPOSIT_TXN {
        int id PK
        int tenancy_id FK
        string txn_type
        decimal amount
        string reason
      }
      METER_READING {
        int id PK
        int room_id FK
        string period
        int opening_units
        int closing_units
      }
      TICKET {
        int id PK
        int tenancy_id FK
        string category
        string status
      }
      USER {
        int id PK
        string username
        string role
      }
      AUDIT_LOG {
        int id PK
        int user_id FK
        string action
        string entity
        datetime created_at
      }

    Security design

    • Authentication: Django's authentication system with login, logout and password change; sessions expire after 30 minutes of inactivity (SESSION_COOKIE_AGE) and cookies are HttpOnly and Secure in production.
    • Password hashing: Django's default PBKDF2-SHA256 hasher with per-user salt; Django's password validators enforce minimum length and reject common passwords.
    • Role-based access: users belong to the Owner, Caretaker or Tenant group. Views use @login_required and permission checks; tenant querysets are always filtered by the logged-in tenant so one tenant can never open another's invoice by changing the URL.
    • CSRF protection: Django's CSRF middleware and {% csrf_token %} in every form; state-changing actions accept only POST.
    • Input validation: Django forms and model validators check amounts (positive, two decimals), dates (exit after entry), meter readings (closing ≥ opening) and UPI reference format; the ORM uses parameterised queries, which prevents SQL injection, and templates escape output, which prevents cross-site scripting.
    • Audit log: every create, update or delete on invoices, payments, deposit transactions and tenancies writes a row with user, action, entity, old and new values and timestamp. Audit rows cannot be edited from the interface.
    • Data minimisation: no Aadhaar, PAN or ID numbers or scans are stored, in line with the principles of the Digital Personal Data Protection Act, 2023.
    • Backups: a nightly mysqldump script is documented for the owner.
  7. 7 modules

    Modules

    • Authentication, Roles and Audit Log

      Login, logout, password change and session timeout using Django authentication. Owner, Caretaker and Tenant groups control which views and actions are available, and a signal-based audit logger records every financial change with user and timestamp.

    • Property, Room and Bed Management

      The owner defines properties, rooms with sharing type and beds with individual monthly rent. An occupancy board shows each bed as vacant, occupied or reserved, with the tenant's name and stay dates.

    • Tenant Onboarding, Transfer and Exit

      The caretaker registers a tenant with name, phone, emergency contact and occupation, records ID verification as a status only, allocates a vacant bed and records the agreed deposit. Transfers close one tenancy and open another; exit triggers the final invoice and deposit settlement.

    • Billing, Electricity Split and Payments

      Monthly invoice generation combines bed rent (pro-rata for partial months) with each tenant's electricity share calculated from room sub-meter readings and bed-days. Payments are recorded with amount, date and a unique UPI reference, and the tenant balance updates immediately.

    • Deposit Ledger and Refund

      Every deposit receipt and deduction (damage, unpaid dues, key loss) is stored as a ledger transaction with a reason. At exit the system shows deposit collected minus deductions minus outstanding dues, and records the refund with its UPI reference.

    • Maintenance Tickets

      Tenants raise tickets by category (plumbing, electrical, Wi-Fi, housekeeping) with a description. The caretaker updates status from Open to In Progress to Resolved with a closure note, and the owner sees average resolution time by category.

    • Reminders and Reports

      A Django management command, scheduled with cron or Windows Task Scheduler, emails tenants with dues after the fifth of each month. Reports cover occupancy, monthly collection, outstanding dues and total deposit liability, with CSV export.

  8. Locked

    Presentation

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

    1. PG Accommodation Rent, Deposit & Maintenance Manager
    2. Problem
    3. Objectives
    4. Existing vs proposed system
    5. Tools and environment
    6. DFD level 0 and level 1
    7. DFD level 2: Billing and payments
    8. ER diagram and tables
    9. Key modules
    10. Security
    11. Testing
    12. Screenshots
    13. Conclusion and future scope

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

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

  9. 1 min

    Future scope

    • Payment gateway or UPI collect-request integration so payments are matched automatically instead of entered by the caretaker.
    • WhatsApp or SMS reminders through an approved business messaging provider.
    • PDF rent receipts that tenants can submit for house-rent allowance claims.
    • Multi-owner SaaS version with separate data per owner.
    • Analytics on vacancy trends and repair costs to help owners plan pricing and maintenance.
  10. 9 sources

    References

    1. Django Documentation
    2. Django Documentation: Security in Django
    3. MySQL 8.0 Reference Manual
    4. OWASP Top 10 Web Application Security Risks
    5. OWASP Password Storage Cheat Sheet
    6. Indira Gandhi National Open University
    7. Digital Personal Data Protection Act, 2023, Government of India
    8. Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems, 7th ed., Pearson
    9. Roger S. Pressman and Bruce R. Maxim, Software Engineering: A Practitioner's Approach, 9th ed., McGraw-Hill

    Cite this bundle

    OnlyProjects. (2026). PG Accommodation Rent, Deposit & Maintenance Manager for Paying-Guest Owners (Django + MySQL): BCA General project bundle [Educational resource]. https://onlyprojects.online/projects/bca-general-pg-accommodation-rent-deposit-manager

Slides, diagrams & files

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

  1. SLIDE 1

    PG Accommodation Rent, Deposit & Maintenance Manager

  2. SLIDE 2

    Problem

  3. SLIDE 3

    Objectives

  4. SLIDE 4

    Existing vs proposed system

  5. SLIDE 5

    Tools and environment

  6. SLIDE 6

    DFD level 0 and level 1

  7. SLIDE 7

    DFD level 2: Billing and payments

  8. SLIDE 8

    ER diagram and tables

  9. SLIDE 9

    Key modules

  10. SLIDE 10

    Security

  11. SLIDE 11

    Testing

  12. SLIDE 12

    Screenshots

  13. SLIDE 13

    Conclusion and future scope

Architecture diagrams · 4

1
flowchart TD
  OW["Owner"] -->|"rooms, rent, tariff"| P0(("PG Rent, Deposit and Maintenance Manager"))
  CT["Caretaker"] -->|"tenant details, readings, payments"| P0
  TN["Tenant"] -->|"login, tickets"| P0
  P0 -->|"reports, deposit liability"| OW
  P0 -->|"ticket list, dues list"| CT
  P0 -->|"invoices, passbook, reminders"| TN
2
flowchart TD
  OW["Owner"] --> P1(("1.0 Manage rooms and beds"))
  CT["Caretaker"] --> P2(("2.0 Tenant onboarding and exit"))
  CT --> P3(("3.0 Billing and payments"))
  TN["Tenant"] --> P5(("5.0 Maintenance tickets"))
  P1 --> D1[("D1 Rooms and beds")]
  P2 --> D2[("D2 Tenants and tenancies")]
  D1 --> P2
  P2 --> P4(("4.0 Deposit ledger"))
  P4 --> D4[("D4 Deposit transactions")]
  D2 --> P3
  P3 --> D3[("D3 Invoices and payments")]
  P5 --> D5[("D5 Tickets")]
  D3 --> P6(("6.0 Reports and reminders"))
  D4 --> P6
  D5 --> P6
  P6 --> OW
  P6 --> TN
3
flowchart TD
  CT["Caretaker"] -->|"meter readings"| P31(("3.1 Record sub-meter readings"))
  P31 --> D6[("D6 Meter readings")]
  D6 --> P32(("3.2 Compute electricity share"))
  D2[("D2 Tenancies")] --> P32
  P32 --> P33(("3.3 Generate monthly invoice"))
  D2 --> P33
  P33 --> D3[("D3 Invoices")]
  CT -->|"amount, UPI reference"| P34(("3.4 Record payment"))
  P34 --> D7[("D7 Payments")]
  D3 --> P35(("3.5 Update balance and dues"))
  D7 --> P35
  P35 --> TN["Tenant"]
  P35 --> D8[("D8 Audit log")]
4
erDiagram
  PROPERTY ||--o{ ROOM : has
  ROOM ||--|{ BED : contains
  BED ||--o{ TENANCY : "occupied by"
  TENANT ||--o{ TENANCY : holds
  TENANCY ||--o{ INVOICE : billed
  INVOICE ||--o{ PAYMENT : "settled by"
  TENANCY ||--o{ DEPOSIT_TXN : records
  ROOM ||--o{ METER_READING : measures
  TENANCY ||--o{ TICKET : raises
  USER ||--o{ AUDIT_LOG : performs
  PROPERTY {
    int id PK
    string name
    string city
  }
  ROOM {
    int id PK
    int property_id FK
    string number
    string sharing_type
  }
  BED {
    int id PK
    int room_id FK
    string label
    decimal monthly_rent
  }
  TENANT {
    int id PK
    int user_id FK
    string full_name
    string phone
    string emergency_contact
    string id_verification_status
  }
  TENANCY {
    int id PK
    int tenant_id FK
    int bed_id FK
    date start_date
    date end_date
    decimal deposit_agreed
  }
  INVOICE {
    int id PK
    int tenancy_id FK
    string period
    decimal rent_amount
    decimal electricity_amount
    decimal total
  }
  PAYMENT {
    int id PK
    int invoice_id FK
    decimal amount
    string upi_reference
    date paid_on
  }
  DEPOSIT_TXN {
    int id PK
    int tenancy_id FK
    string txn_type
    decimal amount
    string reason
  }
  METER_READING {
    int id PK
    int room_id FK
    string period
    int opening_units
    int closing_units
  }
  TICKET {
    int id PK
    int tenancy_id FK
    string category
    string status
  }
  USER {
    int id PK
    string username
    string role
  }
  AUDIT_LOG {
    int id PK
    int user_id FK
    string action
    string entity
    datetime created_at
  }

Files

Viva questions & answers

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

  1. Design

    Draw your level-2 DFD and explain which process it expands.

    My level-2 DFD expands process 3.0 Billing and payments into five sub-processes: recording sub-meter readings, computing each tenant's electricity share, generating the monthly invoice, recording UPI payments, and updating balance and dues. It uses the tenancy, meter reading, invoice, payment and audit log data stores.

  2. Design

    Why is Tenancy a separate entity from Tenant?

    A tenant can stay, leave and return later, or move from one bed to another. Each stay has its own bed, start and end dates and agreed deposit. Keeping Tenancy separate avoids repeating tenant details and lets invoices and deposit transactions belong to a specific stay.

  3. Design

    Is your database normalised? Give an example.

    Yes, it is in third normal form. For example, bed rent is stored on the Bed table and the room's sharing type on the Room table, not repeated on every invoice row. Invoices store only the amounts calculated for that month, which must stay fixed even if rent changes later.

+11 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.