Booking — Core concepts

Domain objects to know before booking

Normal booking does not define courses or schedules from scratch. It reads the product hierarchy, lets the user select sessions, then writes that selection into booking runtime records.

ProgramCategory -> Program -> TermProgramSet -> TermProduct / Session
                                  ^
                                  |
                                Term

Object	What it is	Role in booking
Term	Operating period/term with StartDate, EndDate, status, and usually a site/org scope.	Sets the time boundary for courses and sessions; one Term contains many TermProgramSet records.
ProgramCategory / Category	Program type, such as TermCare, Holiday, or Class.	Holds many base rules for booking, payment, discount, invoice, cut-off, and combine booking.
Program	A concrete program under a category, usually tied to a site/org.	Acts as the course/template source used to create term-specific offerings.
TermProgramSet / TPS	A concrete offering/course within a Term.	Defines schedule, price, capacity, weekdays, discounts, and booking display metadata.
TermProduct / Session	A concrete session/slot generated from a TPS, with date, time, capacity, price, and ProductType.	The smallest selectable unit recorded on booking lines. If someone says "Section" in this booking context, read it as Session/TermProduct, not a separate entity.
Holiday	A special ProgramType/category (Holiday = 12).	Uses booking modes Casual/Standard, FullTime/Full Term, and PartTime/Full Week; also supports day activities.
Activity	ProductType.Activity, used only by Holiday.	A holiday day theme/activity; it has no price and is not the main time slot like a Session.

Runtime objects connect the user to that setup:

Object	What it is	When it appears
Account	Family/payer responsible for finance.	Selected manually in admin booking, or resolved from the authenticated customer flow.
Attendee	Child/participant being booked into sessions.	Each order/booking targets one attendee; validation uses profile fields such as age, school year, height, and weight.
TermBookingOrder	In-flight booking request, like a cart/request.	Created when sessions are selected and submitted before confirmation.
TermBooking	Confirmed booking, the official runtime record.	Created when a TermBookingOrder is confirmed.
TermAttendance	Roll-call/attendance record for each confirmed session.	Created during booking confirmation.
Billing / Invoice	Booking finance ledger and invoice.	Billing is created on submit; invoice generation is triggered on confirm according to payment/finance rules.

Order vs Booking: request vs confirmed

The most important distinction:

	TermBookingOrder	TermBooking
What	An in-flight booking request (cart)	A confirmed booking (actual runtime)
When	From creation until confirmation	After confirmation
Child rows	TermBookingOrderLine/Extra/Discount	TermBookingLine/Extra/Discount
Finance	Submit → creates Billing	Confirm → triggers Invoice + TermAttendance

Spec: the system models the flow using TermBookingOrder for in-flight requests and TermBooking for confirmed enrollments (openspec/specs/booking/spec.md).

Status lifecycle

TermBookingStatus (Tux/src/Tux.Core/Enums/TermBookingStatus.cs):

Status	Code	Meaning
Removed	0	Deleted request / change request.
Draft	100	Draft.
Created	200	Saved to cart (after CreateBookingOrder).
Submitted	300	Submitted new request / saved change request.
Submitted_Change	350	Affected by other submits — not displayed.
Attendance_Approved	450	Attendance-only confirmation.
Quote	475	Quote generated.
Accept	485	Quote accepted.
Approved	500	Confirmed (final).
Archived/Suspended/Closed	600/700/800	Archived/suspended/closed states.
Canceled	900	Cancelled.

Processing (400) is NOT IN USE.

Order type — booking kinds

TermBookingOrderType (Tux/src/Tux.Core/Enums/TermBookingOrderType.cs):

Type	Code	Note
Booking	0	Normal booking (scope of this section).
WaitingList	1	Waiting list.
TrialSession	2	Trial session (shares submit/confirm path with Booking).
Subscription	4	Subscription booking (Enrollment path).
EoI	5	Expression of Interest.

⚠️ In the normal booking double-booking guard, records with TypeId = Subscription or WaitingList are not treated as conflicts. MakeupSession/ClosureDay are used only on Line/Extra, not as TypeId.

Confirmation type — confirm tied to payment

TermBookingConfirmationType (...Enums/TermBookingConfirmationType.cs):

Type	Code	When
Confirm_Without_Payment	101	Confirm with no payment.
Pay_Now_Pay_All	201	Pay in full now.
Pay_Now_Pay_Deposit	202	Pay deposit now.
Direct_Debit	301	Set up recurring debit.
Admin_Confirm	401	Admin confirm (used by subscription direct-confirm).

PayNow / Deposit / Direct Debit may arm an auto-cancel timeout; PayLater has no timeout but must pass eligibility validation.

Account resolution: admin vs customer

Context	Target account
Admin — new booking	Empty, must select account/attendee manually (not from login/profile/subscription).
Admin — edit booking/order	Account of the edited booking/order, locked.
Customer — new/edit	Authenticated account, locked.

Billing Difference review

When editing a confirmed booking (original status Approved/Attendance_Approved/Quote), confirmation is gated by the Billing Difference modal: the financial delta must be reviewed before the real confirm. Edit-mode submit is sent muted; the final mute choice is collected at the confirm popup.

Next: Architecture & data.