Booking — Góc nhìn end-user

Trang này mô tả ai bấm gì trong luồng booking, từ phía khách và phía admin/staff.

Khách hàng (Customer Portal / AimyMe)

Step 1 — Chọn suất học

• Mở Booking Flow → Course List, chọn course → xem session khả dụng.
• Chọn các session cho attendee. Ở bước này hệ thống chưa tạo state booking nào — chỉ giữ lựa chọn phía client.
• Nếu chưa đăng nhập: bấm Next → mở popup login; lựa chọn được giữ lại sau khi đăng nhập.

Course List — URL context & bộ lọc site

• Customer Portal (/programs): giữ _e và org_id (các site được phép), bỏ _b; site access không bị giới hạn theo _b. AimyMe và Embedded Booking Page cũng không bao giờ mang _b.
• Admin Mode (Admin Portal / Onsite App): luôn có _b; danh sách site chỉ gồm site theo BusinessUnit + quyền user.
• GlobalBookingView = False → SiteId được preselect, ẩn Site Filter — áp dụng dù tới từ Landing Page, Course Details, make-another-booking hay URL trực tiếp.
• Landing Page Book Now → mở Course List với site đó preselected; make another booking → giữ nguyên site preselected nếu site vẫn accessible.
• User clear bộ lọc → xem program của toàn bộ site accessible, không thêm lại _b cho customer surface.
• Site param ngoài tập cho phép → bỏ qua, không mở rộng access; back từ Course Details → khôi phục trạng thái filter nếu site còn trong access set.

Ví dụ thực tế: Phụ huynh mở /programs từ link marketing có kèm _b=siteA không thuộc quyền. → Không để tham số client quyết định phạm vi site của khách. → Course List bỏ _b, chỉ hiện program thuộc site được phép từ org_id.

Course List — thẻ course theo category

Category	Tag trên card
Class	Có tag ngày trong tuần (weekday)
Subscription	Có tag ngày trong tuần
Holiday	Không hiện tag weekday
Term Care	Không hiện tag weekday

• Card hiện giá trị Term Planner Requirements / Price đã bị ghi đè tay (manual), không thay bằng giá trị tự sinh lại trừ khi Term Planner chủ động ghi đè.
• Chiều cao card theo nội dung; các card cùng hàng cao bằng card cao nhất trong hàng đó (per-row, không đồng nhất toàn grid).

Ví dụ thực tế: Admin ghi đè price cho course Holiday rồi mở Course List cho khách xem. → Hiển thị đúng giá đã chỉnh tay, không tự tính lại. → Card Holiday không có tag weekday và hiện price manual đã lưu.

Step 2 — Xác nhận & thanh toán

• Account holder của khách được preload và khóa (không đổi được).
• Xem lại session, add-on, discount đã áp.
• Chọn cách thanh toán → Submit:
  • Pay Now (trả hết / đặt cọc), Direct Debit, hoặc Pay Later (nếu đủ điều kiện).
• Sau submit, tùy cấu hình: confirm ngay, hoặc nhận Quote để xem rồi Accept.

My Bookings

• Xem các booking đã đặt, Edit (nếu còn editable), hoặc hủy theo chính sách.
• Khi edit một booking có liên quan attendee/course khác (cùng ActionLogId), hệ thống có thể hiện popup gộp — xem Combine booking rule.

Bookings → View Calendar

• Time range của mỗi event dùng time display format chung: timeFormat đã lưu của user nếu có, ngược lại timeDisplayFormat của business unit.
• Format 12 giờ → hiện AM/PM chuẩn, không hiện token tt; format 24 giờ → không kèm AM/PM/tt.
• Popup session/calendar hiện giờ theo enterprise timezone mode (INV-ENTTZMODE-003):
  • Enterprise Local → hiện giờ local của enterprise (wall-clock gốc), không shift theo timezone user/browser.
  • Enterprise MultiZone → convert sang timezoneIdentifier đã lưu của user; không có → fallback browser timezone (chuỗi: user saved timezone → browser timezone).
  • Khái niệm mode: xem Timezone & DateTime.

Ví dụ thực tế: User ở Việt Nam mở popup session của enterprise Local đặt ở Sydney. → Tránh hiện sai giờ do tự đổi sang múi giờ user. → Popup hiện đúng giờ Sydney gốc; với enterprise MultiZone, popup đổi sang timezoneIdentifier của user.

Calendar event detail

Click một event trong Booking Calendar mở popup read-only theo thứ tự: TPS name → session name → session time → từng attendee trên một dòng. Field thiếu được bỏ qua; event không có thời gian không hiện placeholder. Các quick-info/editor/alert của calendar library bị suppress; click +N more không mở popup thay thế.

Ví dụ thực tế: Một event có 4 attendee bị rút gọn trên tile tháng. → Vẫn xem đủ danh sách. → Click event mở popup, mỗi attendee một dòng và giờ dùng cùng timezone/format với tile.

Admin / Staff (Admin Portal / Onsite App)

Tạo booking mới

• Mở Normal Booking Step 2 cho booking mới: Account Holder Info bắt đầu rỗng — hệ thống không tự lấy account từ login/route/profile, cũng không lấy account mà Subscription Booking vừa chọn.
• Phải chọn account (hoặc chọn attendee để suy ra account) thì nút submit mới bật.
• Đổi account → xóa attendee & các lựa chọn gắn account cũ.

Hành động & xác nhận

• Admin Mode gom submit thành một control Submit → mở menu 3 lựa chọn: Submit, Submit & Confirm, Submit & Confirm Attendance (không còn là các nút tách rời).
• Selection chưa đủ điều kiện submit → control Submit bị disable, cả 3 lựa chọn không chạy. Khách ngoài Admin Mode giữ nút cũ và không thấy Submit & Confirm/Submit & Confirm Attendance.
• Các hành động khác: Confirm Booking, Cancel Booking.
• Mỗi hành động hiện popup xác nhận liệt kê booking dạng BK-xxxx (kèm tên attendee nếu có).
• Với booking đã confirm bị edit lại và đủ điều kiện, Submit & Confirm chạy theo thứ tự Submit → Billing Difference preview → popup Confirm cuối. Submit & Confirm Attendance không bao giờ cần preview.
• Nếu Preview bị tắt hoặc booking không đủ điều kiện, Submit & Confirm bỏ qua preview và vẫn giữ Mute Notifications trong direct-confirm popup; với Created Edit, popup này có thể xuất hiện sau Submit.
• Popup Confirm cuối có Mute Notifications (mặc định off); lựa chọn này áp dụng cho notification của bước confirm.
• Trong Booking Manager, bulk Confirm Booking chỉ dành cho selection toàn booking mới. Nếu selection có edit hoặc mixed new/edit, hệ thống không queue batch và yêu cầu confirm riêng từng booking group qua Preview.
• Bulk Confirm Attendance vẫn dùng flow hiện có và không mở Billing Difference.

Edit booking đã confirm

• Submit & Confirm ở edit mode tách thành: submit (im lặng, mute) → xem Billing Difference → popup chọn notification → bấm Confirm mới thực sự confirm.
• Khi Preview bị tắt hoặc không khả dụng theo policy, popup đầu tiên lấy lựa chọn mute và booking được confirm trực tiếp sau submit.
• Submit & Confirm Attendance thì không mở Billing Difference: submit xong → confirm attendance ngay (status Attendance_Approved, chưa phải confirmed đầy đủ).
• Có thể chọn Edit lại, hoặc View Submitted Booking in Booking Manager mà không confirm.

Billing Difference preview theo attendee

• Phần đầu Preview là decision summary: ưu tiên Net billing change, rồi cho thấy luồng Current net billed → Projected net billed, kèm Paid to date và Open invoice balance.
• Các số này là tổng của billing record. Projected net billed = Current net billed + Difference; không dùng Difference như giá per-attendee và không đối chiếu trực tiếp với estimate trên form.
• Paid to date và Open invoice balance lấy từ invoice hiện hữu, không phân bổ cho attendee; thiếu dữ liệu thì hiển thị Not available, không mặc định $0.00.
• Current net billed là số net sau các credit note hiện hữu; vì vậy có thể khác Paid to date + Open invoice balance, vốn phản ánh số dư của invoice trước credits. UI hiển thị khoản credit note hiện hữu để giải thích chênh lệch này.
• Nếu sau khi tính credit note hiện hữu mà ba số vẫn không reconcile, UI cảnh báo Billing balance needs review; cảnh báo không tự thay đổi Difference authoritative.

Ví dụ thực tế: Billing có invoice balance $125.00 và credit note hiện hữu $1.50. → Current billing total hiển thị $123.50; → hệ thống không cảnh báo sai vì đã giải thích khoản credit note.

• Preview tách riêng từng attendee thuộc các booking order vừa submit để admin kiểm tra tác động của nhóm đang edit.
• Nếu billing record có booking group khác cùng BillingId, các khoản của nhóm đó được gom dưới Other booking groups, không được tính vào số attendee đã chọn.
• Khoản không thể gán attribution chắc chắn hiển thị dưới Shared / Unallocated.
• Net billing change ở phần decision summary là tác động authoritative của toàn bộ billing scope, không phải estimate per attendee trên booking form. Các row attendee chỉ là breakdown để kiểm tra.
• Transaction và attendee details được ẩn mặc định để tránh nhiễu; bấm View billing details dạng text để expand khi cần kiểm tra. Việc mở detail không thay đổi tổng billing.
• Trong breakdown, mỗi attendee chỉ hiển thị Current billed, After edit và Change from this edit; số lượng invoice/credit note là thông tin phụ.
• Bucket grouped có current amount khác $0.00 vẫn hiển thị để giải thích tổng billing; khi đã có attendee xác định, chúng nằm sau View reconciliation details và không chiếm luồng quét chính. Bucket không có hoạt động billing mới có thể ẩn. Attendee đã chọn vẫn được hiển thị kể cả khi net impact bằng $0.00.

Ví dụ thực tế: Admin edit nhóm thứ hai gồm Mike Child 1 và TEST03 trong order có thêm một nhóm khác. → Popup xác nhận và Preview đều chỉ nhận diện 2 attendee được submit; nhóm còn lại hiển thị gộp, còn tổng cuối Preview vẫn bao quát billing record dùng chung.

Booking Rule Options (admin override)

Admin có thể tắt từng rule trong panel Booking Rule Options, ví dụ:

• Booking Cut-off OFF → chọn được session quá khứ (mọi program category).
• Height / Weight Restriction OFF từng cái → bỏ qua đúng rule đó, rule còn lại vẫn chặn.

Closure Day Booking Adjustment

Admin Portal → trang Closure Day Booking Adjustment: quản lý các booking bị ảnh hưởng bởi closure day.

• Layout: PageHeader → card nội dung → bộ filter → thông tin programme → action → bảng booking. Viewport hẹp → filter wrap, bảng giữ scroll ngang.
• Filter: Site, Closure Days, Programmes, Sessions (multi-select); dùng từ Programme, không dùng Program.
• Trạng thái: chưa chọn Site → nhắc; chưa chọn Closure Days → nhắc chọn 1+; không có booking → empty state (không hàm ý lỗi finance/worker); filter không khớp → nhắc điều chỉnh.
• Chưa chọn booking → cancel-and-credit disabled; đã chọn → hiện số chọn / tổng eligible.
• Xác nhận cancel: danger, phân biệt số ít/nhiều, nêu rõ hủy booking + sinh credit note tương ứng.
• UI-only: không đổi API payload, persistence, finance hay worker.

Ví dụ thực tế: Admin chọn site + 1 closure day để xem ai bị ảnh hưởng trước khi hủy đồng loạt. → Tránh thao tác mù trên dữ liệu trống và hiểu rõ hành động destructive. → Trang liệt kê booking bị ảnh hưởng; admin chọn rồi bấm cancel-and-credit, dialog danger xác nhận và sinh credit note theo từng booking.

Notification template — Checkout Instruction

• Template booking có field CheckoutInstruction (plain text) và placeholder chèn cả block; template không chứa token → không chèn.
• Render theo Billing.PaymentOptionId của booking: PayNow/PayNowDeposit → render; PayLater/DirectDebit/null → thay bằng chuỗi rỗng. → URL checkout, giữ xuống dòng.
• Template Booking Confirmation - Parent thêm biến , , , , , .
• Generator ConfirmBooking_Account thay mọi placeholder trước khi gửi (không token nào lọt nguyên dạng): → logo enterprise; → attendee/program/price/khoảng ngày; → TermProgramSet.Instruction; / → rich-text HTML (PDF: link xem/tải). Chưa cấu hình → rỗng.

Ví dụ thực tế: Admin soạn "Booking Confirmation - Parent" kèm lời dặn thanh toán trước khi vào lớp. → Khách PayNow nhận hướng dẫn checkout đúng lúc, khách PayLater không bị nhầm. → Template chèn ; booking PayNow render CheckoutInstruction kèm link, booking PayLater thay block bằng chuỗi rỗng.

Tiếp theo: Khái niệm cốt lõi.