Kalyana Mantapa (Marriage Hall) Booking and Advance Tracking App (Android/Java)

MantapaBook is an Android app that replaces the fat date register, diary of phone enquiries and bundle of handwritten advance receipts kept at the front desk of a typical Chennai kalyana mantapa (marriage hall). Marriage-hall bookings in Tamil Nadu cluster violently around auspicious muhurtham dates: on such days a popular hall may receive thirty calls for one slot, and the paper register is where double-booking disputes, lost advance receipts and forgotten refunds are born.

The app gives the hall's owner and manager a live calendar of every hall — main mantapa, mini hall and dining block — colour-coded as Booked, On Hold, Free or Maintenance, with full-day and split-day slots (morning and evening can go to different parties only where the hall permits). Each booking walks a tracked lifecycle — Enquiry → Date Hold → Advance Paid → Confirmed → Completed, with holds that expire automatically if the advance does not arrive and cancellations that follow a configurable refund-slab table by days remaining. Every payment is a ledger entry; every receipt a numbered PDF. Bookings are written inside a Room transaction guarded by a unique index, so two managers booking the same muhurtham slot at the same moment cannot both succeed.

Built with Java on Android using Room, MVVM and WorkManager — the mobile-application course (MC4204) applied with the transaction and schema discipline of Advanced Database Technology (MC4202) — it runs fully offline, needs no server or subscription, and is a practical, viva-defensible Anna University MCA R2021 Semester-4 project.

A marriage hall's front office sells the same handful of muhurtham dates many times over — as enquiries, holds and confirmed bookings — but tracks them in a wall calendar and a diary. Holds are promises kept in someone's memory, advances are recorded in handwritten receipt books, and refund amounts depend on who is arguing. The result is double-booking disputes on exactly the dates that matter most, receipts that cannot be produced at settlement time, refunds applied inconsistently, and no answer to basic questions such as what the hall earned last month or how many enquiries became bookings. There is a need for an offline-first Android application that shows live slot availability, enforces the booking lifecycle with automatically expiring holds, records every advance, balance and refund in an auditable ledger, generates numbered PDF receipts, applies a written refund-slab policy, and reports revenue and occupancy — while storing only the customer's name, mobile number and event details, never Aadhaar or other identity documents.

Abstract

This project delivers an offline-first Android application for a marriage hall's front office: an availability calendar with full-day and split-day slots, a lifecycle with expiring holds and refund slabs, an advance-and-payment ledger with numbered PDF receipts, and dashboards for dues and monthly revenue. It is implemented in Java with Room on SQLite following MVVM, and the design centres on one guarantee — no date is ever sold twice.

Introduction

Chennai's kalyana mantapas run on thin margins and phone calls. A mid-size hall hosts 120–180 weddings a year, with demand concentrated on a handful of muhurtham dates that families fix months ahead. The desk tracks availability on a paper calendar, quotes rates by memory, takes advances against handwritten receipts and settles refunds by negotiation. Disputes cost the hall its reputation, and with one desk, two staff and unreliable broadband, the answer must be a single-device offline app, not a cloud portal.

Existing System and Its Limitations

• Availability lives on a wall calendar; enquiries sit in a diary against a name and a promise.
• Holds are enforced by memory — a family that delayed its advance finds the date gone.
• Advance receipts are handwritten carbon books; refund amounts are settled by argument, not by a written policy.
• Owners learn monthly revenue by totalling the diary; enquiry-to-booking conversion is unknown.
• Gap: event-venue software for banquet chains is subscription-priced and cloud-first; nothing simple, free and offline serves a single hall's front desk.

Proposed System

• A per-hall month calendar with dates marked Free, Hold, Booked or Maintenance and slots of Full Day / Morning / Evening; split-day use is per-hall configuration.
• A booking lifecycle Enquiry → Date Hold → Advance Paid → Confirmed → Completed, plus Cancelled and Expired; holds expire by default after 7 days, enforced by a WorkManager sweep and an on-launch check.
• Every confirmed-advance write happens in a Room transaction guarded by a unique index on hall, date and slot, so double-selling is impossible even with two rapid taps.
• A payment ledger with part payments (cash/UPI reference) and a configurable refund-slab table (for example 80% above 60 days, 50% between 30 and 60, none below 30) applied automatically on cancellation.
• Numbered PDF receipts from a per-financial-year counter, rendered with Android's PdfDocument.
• A dashboard of expiring holds, pending balances and the next 30 days of events, plus monthly revenue, occupancy and enquiry-conversion reports with CSV export.

Feasibility Study

• Technical: Room provides compile-time-checked queries and transactional writes; WorkManager runs expiry sweeps reliably even after reboots; PdfDocument needs no licence. The app runs on any Android 8+ tablet or phone.
• Economic: Zero recurring cost — no server, no subscription — against a cloud venue tool's ₹200–500 monthly fee, and it survives the hall's patchy broadband.
• Operational: The app mirrors the desk's paper flow screen by screen; training takes under an hour, and the register can run in parallel for one cycle as a safety net.

In scope

• One mantapa property with multiple halls (main, mini, dining) and per-hall slot configuration; single shared device.
• Two roles: owner (rates, refund policy, users, reports) and manager (calendar, bookings, payments, receipts).
• Booking lifecycle with holds, expiry sweeps, cancellation and slab-based refunds; numbered PDF receipts.
• Payment ledger with cash/UPI-reference entries; dashboards, reminders and CSV exports; seeded demo season of 24 months.

Out of scope (v1)

• A customer-facing app or website (enquiries are recorded by the desk from phone calls and walk-ins).
• Online payment collection (UPI is recorded as a reference, not processed in-app).
• Caterer/decorator vendor management beyond free-text vendor notes per booking.
• SMS/WhatsApp confirmations and multi-branch (group-of-halls) support.

The project follows an incremental SDLC with a fixed design front-end: the slot model and lifecycle are settled in design (weeks 3–4) because retrofitting a double-booking guarantee later is painful, while features ship in four fortnightly increments, each demoed to the guide.

Testing approach: JUnit tests for the refund calculator, slot-overlap logic and receipt numbering; AndroidX instrumented tests for Room DAOs including the unique-index rejection; Espresso flows for the booking path; and a concurrency trial that fires two rapid bookings for the same muhurtham slot and asserts exactly one succeeds.

The app is a single-device, offline-first Android application in strict MVVM, with the business rules living below the UI where they can be tested.

1. UI layer: activities and fragments with XML layouts and ViewBinding; Material 3 components; Jetpack Navigation between calendar, booking, ledger and reports. Fragments observe LiveData and never touch the database.
2. ViewModel layer: one ViewModel per screen holding UI state and invoking repository methods; survives rotation during a booking entry.
3. Data layer: repositories wrap Room DAOs. The booking write runs inTransaction, re-checking slot availability and relying on the unique index on (hallId, eventDate, slot) as the final guarantee. A WorkManager periodic worker expires stale holds; an identical on-launch sweep makes expiry correct even if the worker was killed. Receipts render through PdfDocument from a per-financial-year counter table incremented inside the same transaction as the payment.

flowchart TD
  U["Owner / Manager"] --> F["Fragments: calendar, booking, ledger"]
  F -->|"actions"| VM["ViewModels (LiveData state)"]
  VM --> RP["Repositories + business rules"]
  RP --> TX["Booking transaction: availability check + unique index"]
  TX --> DB[("Room / SQLite")]
  RP --> WM["WorkManager: hold-expiry sweep"]
  RP --> PDF["PdfDocument receipt generator"]
  RP --> CSV["CSV report exporter"]

ER diagram

erDiagram
  USER ||--o{ BOOKING : manages
  CUSTOMER ||--o{ BOOKING : places
  HALL ||--o{ BOOKING : "is booked as"
  BOOKING ||--o{ PAYMENT : "is settled by"
  BOOKING ||--o{ CHECKLIST_ITEM : "tracks"
  USER ||--o{ PAYMENT : records

  USER {
    string id PK
    string name
    string role
    string passwordHash
  }
  HALL {
    string id PK
    string name
    int capacity
    boolean splitDayAllowed
    string status
  }
  CUSTOMER {
    string id PK
    string name
    string mobile
    string address
  }
  BOOKING {
    string id PK
    string hallId FK
    string customerId FK
    string eventDate
    string slot
    string status
    datetime holdExpiresAt
    decimal agreedAmount
  }
  PAYMENT {
    string id PK
    string bookingId FK
    string kind
    decimal amount
    string mode
    string receiptNo UK
    datetime paidAt
  }
  CHECKLIST_ITEM {
    string id PK
    string bookingId FK
    string label
    boolean done
  }

Booking state machine

flowchart LR
  E["Enquiry"] --> H["Date Hold"]
  H -->|"advance received"| A["Advance Paid"]
  H -->|"hold expiry"| X["Expired"]
  A --> C["Confirmed"]
  C --> D["Completed"]
  A -->|"cancelled"| K["Cancelled"]
  C -->|"cancelled"| K
  K --> RF["Refund per slab"]

The customer table deliberately holds only name, mobile and event details — no Aadhaar, PAN or identity uploads — so a lost backup exposes nothing.

• A customer-facing enquiry portal (Firebase Auth + Firestore) so families request dates and the desk converts them into holds.
• Online advance payments via UPI intent links with automatic ledger reconciliation.
• SMS/WhatsApp confirmations for holds, receipts and event-day reminders.
• Multi-hall groups with an owner console across branches and a shared enquiry pool.
• Seasonal pricing and demand analytics — suggesting fair rates for high-demand muhurtham dates from enquiry history.