Hall (Event) Module Documentation

Overview

The Hall Module manages the reservation of conference rooms, banquet halls, and meeting spaces. It handles complex billing scenarios including hourly/daily rates, catering packages, and equipment rentals. It features a robust Conflict Detection engine to prevent double bookings.

Architecture

Domain Layer (app/Domain/Hall)

Models (5 Models)

Hall (Hall.php)

• Table: halls
• Key Fields:
  • capacity: Max pax.
  • rate_type: HOURLY | HALF_DAY | DAILY.
  • base_rate: Price per unit.

HallBooking (HallBooking.php)

• Table: hall_bookings
• Status Enum: DRAFT | CONFIRMED | CANCELLED | COMPLETED.
• Key Fields:
  • event_name: Title.
  • hall_charge: Rental cost.
  • catering_charge: Food cost (sum of lines).
  • services_charge: Equipment cost.

Services

HallBookingService (HallBookingService.php)

Purpose: Lifecycle management of events.

Key Methods:

createBooking(customer, hall, data)

Initializes the request.

• Validation: Checks hall->isAvailable(start, end). Throws exception on overlap.
• Calculation: Determines Hall Charge using rate_type logic (e.g. 4 Hours = 1 Half Day block).
• SMS: Sends 'hall_reservation' notification.

addAttendees(booking, count)

Updates headcount.

• Reactivity: Automatically iterates through all linked Catering packages and updates their total_charge (rate_per_person * new_count).
• Recalculation: Triggers calculateTotal() to update Tax and Grand Total.

confirmBooking(booking)

Locks the event.

• Accounting:
  • Dr AR (103).
  • Cr Hall Revenue (412).
  • Cr Catering Revenue (415).
  • Cr Services Revenue (416).
  • Cr Tax (204).

cancelBooking(booking)

Reverses the flow.

• Logic: If previously CONFIRMED, creates a Reversal Journal Entry (dr Revenue, cr AR) to zero out the GL.

---

Audit Findings & Improvements

Strengths

• Granular Revenue Recognition: Unlike basic systems that lump everything as "Event Income", this module splits Revenue into Rental, Food, and Services. This allows the F&B Director to see their contribution separate from the Facilities Manager.
• Dynamic Catering: The auto-update of catering costs when attendee count changes prevents billing errors ("We added 50 chairs but forgot to charge for 50 more lunches").

Issues Identified

Major

• Hardcoded Account Codes: The service explicitly looks for '103', '412', '415', '416', '417', '204'. A change in the COA (e.g. using '4120' instead of '412') will silently fail or default to Account ID 1.
  • Fix: Use AccountSettings::get('hall_revenue') or similar abstraction.

Minor

• Cancellation Reason: The cancelBooking method requires a reason string, but the UI often sends null.
• SMS Catch: The service catches SMS exceptions Log::warning(). While safe, it means staff might not know if the customer failed to receive the text.

---

Module Version

Version: 1.0 Status: Production Ready