Booking — Luồng xử lý trong code

Trang này trace từ API → service → validation cho normal booking. File chính:

• Controller: Tux/src/Tux.Api/Controllers/Consumer/ConsumerBookingController.cs
• Service: Tux/src/Services/Tux.Service/BookingService.cs
• Helper: Tux/src/Services/Tux.Service/Helpers/BookingHelper.cs

Tổng thể

Luồng 1 — Create order (giỏ hàng)

• API: CreateBookingOrder.
• Tạo TermBookingOrder + TermBookingOrderLine (status Created).
• Validate: attendee/term product hợp lệ, org setting, measurement (chiều cao/cân nặng) nếu bật, double-booking (trừ khi IgnoreDoubleBooking).
• Chưa tạo Billing.

Luồng 2 — Submit

• API: SubmitBookingOrders → BookingService.SubmitBookingAsync.
• Chỉ chấp nhận order type Booking và TrialSession.
• Tạo Billing (tổng hợp tài chính); validate Pay Later eligibility (qua BookingHelper).
• Có thể arm timeout auto-cancel nếu payment option yêu cầu (PayNow/Deposit/Direct Debit).
• Double-booking check lần cuối. Status → Submitted. Chưa tạo Invoice.
• Trả về đủ TermBookingOrderIds để confirm sau (đầy đủ hoặc attendance) không cần suy đoán ở UI.

Luồng 3 — Billing Difference preview

• Entry chính: PreviewBillingDifference → ConsumerBookingController → BillingService.
• Backend kiểm tra canonical order IDs, permission, scope và billing context; sau đó dùng shared BookingConfirmationPlan và financial rules với Confirm.
• Preview là read-only, trả Difference, projected transaction data, breakdown và PreviewSnapshotToken; không gọi writer hoặc SaveChanges.
• Confirm chuẩn bị lại kết quả, kiểm tra token trong transaction rồi persist; feature tắt hoặc booking không đủ điều kiện thì bỏ qua Preview/token theo policy.

Chi tiết từng file, điều kiện và error code nằm ở Code flow Preview Billing Diff.

Luồng 3b — Bulk Confirm trong Booking Manager

• UI: BatchActionToolbar gom các row được chọn rồi gọi BatchActionInQueue.
• Selection chỉ gồm booking mới → giữ bulk Confirm_Booking và queue như flow hiện có.
• Selection có edit hoặc mixed new/edit → UI dừng trước khi gọi API, yêu cầu confirm từng booking group qua preview-first flow.
• Backend BookingService.BatchActionInQueueAsync kiểm tra lại TermBookingId, editOrderId lineage/action và trả PREVIEW_BILLING_DIFF_BATCH_EDIT_NOT_SUPPORTED trước khi tạo lock hoặc scheduler.
• Confirm_Attendance không đi qua billing guard và vẫn queue bình thường.

Ví dụ thực tế: Admin chọn đồng thời một booking mới và một edit booking trong Booking Manager. → Tránh queue một phần mà bỏ qua billing review. → Toàn bộ selection bị từ chối; booking mới không bị lock, còn edit booking được confirm riêng qua Preview.

Luồng 4 — Confirm / Quote

• API: ConfirmBookingOrders → BookingService.ConfirmBookingAsync (hoặc GenerateQuotesAsync/AcceptQuoteAsync).
• Tạo TermBooking từ TermBookingOrder; copy Line/Extra/Discount.
• Áp discount, tính tổng (xem Discount rule).
• Tạo TermAttendance cho từng session; trigger billing sinh Invoice.
• Status → Approved (hoặc Attendance_Approved, hoặc Quote).
• Action type Confirm_Attendance (1050) → chỉ chốt điểm danh, status Attendance_Approved, không confirm đầy đủ; dùng cho Submit & Confirm Attendance của admin, không mở Billing Difference.
• Edited booking: confirm build một BookingConfirmationPlan chung từ TermBookingOrderIds trước khi áp side-effect thật (invariant INV-BOOK-23).
  • BookingConfirmationPlan là projection source of truth order → booking (header/line/extra/ discount); code preview không nhân bản thuật toán projection này.
  • Edit confirm tạo lại line + thay TermAttendance vì giá/discount đổi → giữ roll call cũ (status, giờ, sign-in/out, RollCallHistory) khi attendance cũ có RollCallStatusId > 0 (invariant INV-BOOK-27); retry không nhân đôi history.

Luồng Subscription Enrichment trong Booking

Đây là đường runtime của Subscription Booking, không phải CreateBookingOrder của normal booking:

1. ConsumerEnrollment nhận selection-only Enrichment và lưu pattern theo ngày.
2. Preview/submit/confirm resolve cùng TermProduct effective, closure-day và occurrence date.
3. EnrollmentService.GenerateBookingFromEnrollment tạo một TermBookingLine có giá/item cho mỗi occurrence và tạo attendance tương ứng.
4. Booking Billing/Reconciliation xử lý các line đó; SubscriptionBillingService chỉ xử lý base schedule/add-on của EnrollmentBillingSchedule.
5. Replay dùng operation/semantic-key guard; không tạo duplicate active line hoặc duplicate charge.

Ví dụ thực tế: Worker confirm chạy lại cùng operation sau timeout. → Resolver thấy key Booking + TermProduct + Date đã tồn tại. → Không thêm line/attendance thứ hai và tổng Booking không tăng.

Luồng 5 — Cancel

• API: DeleteBookingOrdersAsync → BookingService.CancelBookingAsync.
• Status → Canceled; đảo invoice bằng credit note; deactivate TermAttendance (kể cả khi một số line trước đó đã rời Approved).

Validation chính

Loại	Ở đâu
Capacity	TermProduct.Capacity, TermProgramSetCapacity; check ở create/submit/confirm.
Double-booking	So attendee × session trùng ngày/giờ; bypass bằng IgnoreDoubleBooking.
Measurement	Chiều cao/cân nặng vs cấu hình course; admin override từng rule.
Lock & pending	Booking locked / có pending order → chặn edit.
Discount eligibility	DiscountEligibilityService + BookingHelper.ApplyDiscount.

Calendar và special-day flow

• Calendar wrapper map event → click handler; handler mở read-only detail popup và cancel mọi quick-info, editor, alert, +N more popup của Syncfusion. Time formatter dùng lại logic của tile.
• Special-day matching group theo sessionGroupKey, sau đó match product + time slot để tránh gộp sai; Tuke loại session đặc biệt khỏi booking surface theo trạng thái không bookable.

Ví dụ thực tế: Click event khi popup trước đó còn mở. → Nội dung chuyển toàn bộ sang event mới, không giữ attendee/time của event cũ; click empty cell không tạo popup.

Tiếp theo: Discount rule.