Booking System
En bref
Booking System handles court reservations end-to-end, from single time slots to recurring weekly, biweekly, and monthly series, with integrated payment, walk-in handling, explicit confirmation, and audited cancellation. It enforces conflict detection against existing bookings, competition allocations, and maintenance windows so every confirmed reservation is guaranteed to be playable when the booker arrives.
Comment ça fonctionne
A reservation is a time slot bound to a specific court within a venue. On creation the booking engine runs a two-pass conflict check: first against other bookings on the same court, then against competition allocations and maintenance windows surfaced by Court Management. Overlap detection uses half-open intervals so back-to-back slots never collide, and any conflict aborts the booking with a structured error indicating which entity blocked it.
The booking calendar exposes a public availability view that includes bookings, allocations, and recurring series so external apps and embedded widgets on club websites can render an accurate occupancy grid without authentication. Recurring bookings are stored as series definitions (weekly, biweekly, or monthly) and expanded into individual instances; the expansion is conflict-aware, skipping or flagging dates that collide with existing reservations or future competition blocks rather than silently failing.
Competition court blocking is enforced at allocation time: when a tournament director allocates courts for a session, the booking layer marks those courts unavailable for the duration and rejects new reservations or recurring instances that would overlap. This guarantees that ranked tournaments never lose courts to ad-hoc club bookings.
Payment is integrated as part of the booking record itself. Each booking carries a fee, currency, payment_status, and invoice_id, and a successful payment automatically transitions the booking to confirmed. For bookings that are taken over the phone or at reception, the explicit /confirm endpoint lets staff move a pending booking to confirmed with a confirmed_at timestamp without payment.
The system distinguishes reservation bookings from walk-ins via booking_type, supporting venues that operate hybrid models — pre-booked competitive players plus drop-in casual play. Cancellations are handled in two flavours: a hard DELETE for staff cleanup and a POST /cancel that records reason, cancelled_at, and cancelled_by for audit and refund processing.
Capacités clés
- Court reservation with overlap detection and allocation cross-check
- Public booking calendar showing bookings and allocations
- Recurring weekly, biweekly, and monthly series with conflict-aware expansion
- Automatic blocking when competition court allocations are confirmed
- Integrated payment with auto-confirm on successful charge
- Walk-in versus reservation booking types
- Cancellation with reason, timestamp, and audit trail
En pratique
A club captain wants to lock in Tuesday evening practice for the entire winter season. From the booking calendar he selects court 2, picks 18:00 to 20:00, and chooses weekly recurrence through March. The expansion runs and flags two Tuesdays that collide with a regional tournament's court allocation; he accepts the system's suggestion to skip those dates.
The series is created with 16 instances, each carrying the per-session fee and a pending payment status. He pays for the whole season with a single invoice; payment integration confirms every instance in one transaction, and the calendar immediately reflects the recurring booking. Members see the slots reserved, and the venue dashboard shows projected revenue for the term.
Fonctionnalités de ce sous-système
8| ID | Status | Fonctionnalités |
|---|---|---|
| F07.03.01 | Livré | Court reservation (time slot per court with overlap detection + allocation cross-check) ✅ PL-F0703a |
| F07.03.02 | Livré | Booking calendar with availability view (public endpoint, includes allocations) ✅ PL-F0703a |
| F07.03.03 | Livré | Recurring bookings (weekly/biweekly/monthly series with conflict-aware expansion) ✅ PL-F0703a |
| F07.03.04 | Livré | Competition court blocking (allocations block regular bookings and recurring series) ✅ PL-F0703a |
| F07.03.05 | Livré | Booking payment integration (fee, currency, payment_status, invoice_id; auto-confirm on payment) ✅ PL-F0703b |
| F07.03.06 | Livré | Booking confirmation (confirmed_at timestamp, explicit /confirm endpoint for pending bookings) ✅ PL-F0703b |
| F07.03.07 | Livré | Walk-in vs. reservation management (booking_type: reservation\ walk_in, /walk-in endpoint, filter by type) | ✅ PL-F0703b |
| F07.03.08 | Livré | Cancellation (DELETE + POST /cancel with reason, cancelled_at, cancelled_by, cancellation_reason) ✅ PL-F0703b |
Parties prenantes qui ont besoin de ce sous-système
Apparaît dans 3 analyses de parties prenantes