Booking — Architecture & data

This page sketches the normal-booking data entities and their relationships. For exact table/field names see docs/DB_SCHEMA_DESIGN/ and the spec.

Relationship diagram (conceptual)

Two record levels: Order → Booking

Confirm copies OrderLine → BookingLine, OrderExtra → BookingExtra, OrderDiscount → BookingDiscount; then creates TermAttendance per session and triggers billing.

Ownership boundary

Block	Who may mutate
Step 1/Step 2 session selection (client-side)	UI (state only, no DB mutation)
TermBookingOrder / TermBooking / Billing / Invoice / CreditNote / TermAttendance (runtime)	Only the existing booking/confirmation services

The UI does not create a TermBookingOrder on Step 1/Step 2 load, and does not call low-level billing/invoice APIs to emulate submit/confirm. All mutations go through backend services.

Key APIs (read/write paths)

Purpose	API
Available sessions	GET /api/ConsumerBooking/GetAvailableSessionsAsync
Capacities	GET /api/ConsumerBooking/GetCapacitiesAsync
Create order (cart)	POST /api/ConsumerBooking/CreateBookingOrder
Submit	POST /api/ConsumerBooking/SubmitBookingOrders
Confirm	POST /api/ConsumerBooking/ConfirmBookingOrders
Quote / Accept	POST .../GenerateQuotesAsync, .../AcceptQuoteAsync
Cancel	POST /api/ConsumerBooking/DeleteBookingOrdersAsync
Discount config	GET/POST /api/discount

Data conventions worth remembering

Field	Convention
TermBookingOrder.TypeId	Booking(0) = normal; Subscription(4)/WaitingList(1) excluded from normal conflict.
Discount slots per line	Up to 3: DiscountId, Discount2Id, Discount3Id.
ProgramCategory.CombinedBookingOptionId	0 = per course; 1 = combine by program category.
ActionLogId	Groups bookings placed in the same action (for combined edit).
Booking number	Shown as BK-xxxx to users.

Next: Codebase flow.