Booking — Common cases

Real-world situations and how the system responds.

Double-booking

• The same attendee cannot book the same TermProduct on overlapping date/time.
• Checked at create, submit, and confirm.
• Admin can bypass with IgnoreDoubleBooking = true.
• Records of type Subscription/WaitingList are not counted as a normal booking conflict.

Real-world example: A parent books two children into the same Monday morning session. → Avoid accidentally recording the same child twice. → The system blocks the second child at submit unless admin enables IgnoreDoubleBooking.

Height / weight (measurement)

• A course may configure height/weight bounds. An attendee out of bounds → invalid selection, blocks submit.
• A missing required value (e.g. weight) → submit fails for that selection.
• Admin overrides each rule: turning off Height still lets Weight block, and vice versa.

Real-world example: A swimming class sets a minimum weight threshold; the child has no weight recorded. → Ensure the child meets safety conditions before joining the class. → Submit fails for that selection until weight is entered, or admin turns off the Weight rule only.

Booking Cut-off (selecting past sessions)

• By default sessions past the cut-off cannot be selected.
• Admin turns off Booking Cut-off in Booking Rule Options → past sessions become selectable (all categories: Term Care, Holiday, Class).

Real-world example: A child attended Tuesday but registration was forgotten and needs to be back-booked. → Let ops record a session that already happened for billing/attendance. → Admin turns off Booking Cut-off, selects that past session again, then confirms.

Pay Later & auto-cancel timeout

• PayNow / Deposit / Direct Debit may arm a timeout: if unpaid past the deadline, auto-cancel.
• PayLater has no timeout but must pass eligibility validation at submit.

Real-world example: A parent chooses Deposit, then leaves without paying. → Avoid holding a slot indefinitely and blocking capacity. → When the timeout expires, the booking auto-cancels and the slot opens for someone else.

Capacity

• Limited by TermProduct.Capacity and TermProgramSetCapacity (limited weeks).
• ValidateCapacityForConfirmBooking runs before confirm.

Real-world example: One place remains, and two parents click confirm almost at the same time. → Do not exceed class capacity. → ValidateCapacityForConfirmBooking blocks the later confirm and reports no availability.

Quote → Accept

• Instead of confirming immediately, you can GenerateQuotes (status Quote) → customer AcceptQuote (Accept) → confirm (Approved).

Real-world example: Admin finalizes a holiday program for a family but lets them approve the price themselves. → Let the customer review and accept the quote before committing to payment. → GenerateQuotes sends the quote, the customer runs AcceptQuote, then the booking is confirmed.

Cancel → credit note

• Cancelling a confirmed booking: status → Canceled, reverses invoices via credit note, deactivates TermAttendance — even if some lines previously left Approved.

Real-world example: A family cancels a course that was already paid and attended. → Keep the ledger correct and remove sessions that are no longer valid. → Booking becomes Canceled, the system issues a credit note to reverse the invoice, and TermAttendance is deactivated.

Stale attendance

• A dry-run process detects TermAttendance still active while its parent TermBooking is Canceled (returns a count + sample, without modifying data) so ops can repair safely.

Real-world example: An old issue left attendance behind for a canceled booking, making the attendance report wrong. → Detect bad data before deleting anything automatically. → Dry-run lists the count + sample records so ops can inspect and handle them manually.

Combined edit

• A category with CombinedBookingOptionId = 1: editing one booking loads same-ActionLogId bookings across courses in the category. Removing one from the group on reconfirm → cancel + deactivate its attendance. Details: Combine booking rule.

Real-world example: A parent changes one child's schedule that was booked as part of a combined multi-course group. → Keep the whole group in sync instead of drifting booking by booking. → Editing one booking loads bookings with the same ActionLogId; removing one from the group cancels it and deactivates its attendance.

Editing a confirmed booking (Billing Difference)

• Submit & Confirm is split into two steps: submit (muted) → review Billing Difference → click Confirm.
• Submit returns the complete set of TermBookingOrderIds to preview & confirm together (invariant INV-BOOK-21).

Real-world example: Admin adds one session to an already confirmed booking, and the customer needs to know the extra amount. → Show the billing difference before committing. → Submit (muted) shows Billing Difference; admin reviews it, then clicks Confirm to finalize.

Next: References.