Booking — End-user view

This page describes who clicks what in the booking flow, from the customer and admin/staff side.

Customer (Customer Portal / AimyMe)

Step 1 — Select sessions

• Open Booking Flow → Course List, pick a course → see available sessions.
• Select sessions for an attendee. At this stage the system creates no booking state — it only keeps client-side selection.
• If not signed in: click Next → login popup opens; the selection is preserved after login.

Course List — URL context & site filter

• Customer Portal (/programs): keeps _e and org_id (allowed sites), drops _b; site access is not limited by _b. AimyMe and the Embedded Booking Page also never carry _b.
• Admin Mode (Admin Portal / Onsite App): always has _b; the site list only contains sites per BusinessUnit + user permissions.
• GlobalBookingView = False → SiteId is preselected and the Site Filter is hidden — applies whether coming from the Landing Page, Course Details, make-another-booking, or a direct URL.
• Landing Page Book Now → opens Course List with that site preselected; make another booking → keeps the site preselected if the site is still accessible.
• User clears the filter → sees programs of all accessible sites; _b is not re-added on the customer surface.
• A site param outside the allowed set → ignored, access is not expanded; going back from Course Details → filter state is restored if the site is still in the access set.

Real-world example: A parent opens /programs from a marketing link that carries _b=siteA outside their permissions. → Do not let a client parameter decide the customer's site scope. → Course List drops _b and only shows programs of sites allowed by org_id.

Course List — course cards by category

Category	Tag on card
Class	Has a weekday tag
Subscription	Has a weekday tag
Holiday	No weekday tag shown
Term Care	No weekday tag shown

• A card shows manually overridden Term Planner Requirements / Price values, not regenerated ones, unless the Term Planner actively overrides again.
• Card height follows content; cards in the same row are as tall as the tallest card in that row (per-row, not uniform across the grid).

Real-world example: Admin overrides the price of a Holiday course, then opens Course List for the customer. → The manually edited price is shown, not recomputed. → The Holiday card has no weekday tag and shows the saved manual price.

Step 2 — Review & pay

• The customer's account holder is preloaded and locked (cannot be changed).
• Review sessions, add-ons, and applied discounts.
• Choose a payment method → Submit:
  • Pay Now (full / deposit), Direct Debit, or Pay Later (if eligible).
• After submit, depending on configuration: confirm immediately, or receive a Quote to review then Accept.

My Bookings

• View placed bookings, Edit (if still editable), or cancel per policy.
• When editing a booking related to another attendee/course (same ActionLogId), a combine popup may appear — see Combine booking rule.

Bookings → View Calendar

• Each event's time range uses the shared time display format: the user's saved timeFormat if present, otherwise the business unit's timeDisplayFormat.
• 12-hour format → shows proper AM/PM, no tt token; 24-hour format → noAM/PM/tt.
• Session/calendar popups show times per the enterprise timezone mode (INV-ENTTZMODE-003):
  • Enterprise Local → shows the enterprise's local time (original wall-clock), not shifted by the user/browser timezone.
  • Enterprise MultiZone → converts to the user's saved timezoneIdentifier; none → falls back to the browser timezone (chain: user saved timezone → browser timezone).
  • Mode concept: see Timezone & DateTime.

Real-world example: A user in Vietnam opens the session popup of a Local enterprise based in Sydney. → Avoid showing the wrong time by auto-shifting to the user's timezone. → The popup shows the original Sydney time; with a MultiZone enterprise, it shifts to the user's timezoneIdentifier.

Admin / Staff (Admin Portal / Onsite App)

New booking

• Open Normal Booking Step 2 for a new booking: Account Holder Info starts empty — the system does not preselect from login/route/profile, nor from the account Subscription Booking just selected.
• Staff must select an account (or select an attendee to derive the account) before submit is enabled.
• Changing the account clears attendees and account-scoped selections.

Actions & confirmation

• Admin Mode groups submit into a single Submit control → opens a 3-choice menu: Submit, Submit & Confirm, Submit & Confirm Attendance (no longer separate buttons).
• A selection not eligible to submit → the Submit control is disabled, all 3 choices do not run. Customers outside Admin Mode keep the old buttons and do not see Submit & Confirm / Submit & Confirm Attendance.
• Other actions: Confirm Booking, Cancel Booking.
• Each action shows a confirmation popup listing bookings as BK-xxxx (with attendee names when available).
• For an edited confirmed booking that is eligible, Submit & Confirm runs Submit → Billing Difference preview → final Confirm popup. Submit & Confirm Attendance never needs a preview.
• When Preview is disabled or the booking is ineligible, Submit & Confirm skips preview and keeps Mute Notifications in the direct-confirm popup; for a Created Edit, it may appear after Submit.
• The final Confirm popup has Mute Notifications (off by default); the choice applies to the confirmation notification.
• In Booking Manager, bulk Confirm Booking is only for selections containing new bookings. If a selection contains an edit or mixed new/edit rows, the system does not queue the batch and requires each booking group to be confirmed separately through Preview.
• Bulk Confirm Attendance keeps the existing flow and does not open Billing Difference.

Editing a confirmed booking

• Submit & Confirm in edit mode is split into: submit (silent, muted) → review Billing Difference → notification choice popup → click Confirm to actually confirm.
• When Preview is disabled or unavailable by policy, the first popup collects the mute choice and the booking confirms directly after submit.
• Submit & Confirm Attendance does not open Billing Difference: after submit → confirm attendance immediately (status Attendance_Approved, not yet fully confirmed).
• Staff may Edit again, or View Submitted Booking in Booking Manager without confirming.

Billing Difference preview by attendee

• The top of Preview is a decision summary: it prioritizes Net billing change, then shows the transition from Current net billed to Projected net billed, together with Paid to date and Open invoice balance.
• These values are billing-record totals. Projected net billed = Current net billed + Difference; do not treat Difference as a per-attendee price or compare it directly with the form estimate.
• Paid to date and Open invoice balance come from existing invoices and are not allocated to attendees; if data is missing, show Not available, not $0.00 by default.
• Current net billed is net of existing credit notes; therefore it may differ from Paid to date + Open invoice balance, which reflects invoice balances before credits. The UI shows existing credits to explain this difference.
• If the three values still fail to reconcile after existing credit notes are considered, the UI shows a Billing balance needs review warning; it does not change the authoritative Difference.

Real-world example: A billing record has $125.00 in invoice balance and an existing $1.50 credit note. → Current net billed is $123.50; → the system does not show a false reconciliation warning because the credit is explained.

• Preview separates each attendee belonging to the booking orders just submitted so admin can review the impact of the group being edited.
• If the billing record has another booking group sharing the same BillingId, that group's amounts are grouped under Other booking groups, are not counted in the selected-attendee count, and are available under View reconciliation details.
• Amounts that cannot be reliably attributed are shown under Shared / Unallocated.
• Net billing change in the decision summary is the authoritative impact for the whole billing scope, not the per-attendee estimate on the booking form. Attendee rows are a verification breakdown.
• Transactions and attendee details are hidden by default to reduce noise; click the text-only View billing details control when inspection is needed. Opening details does not change the billing total.
• In the breakdown, each attendee shows only Current billed, After edit, and Change from this edit; invoice and credit-note counts are secondary information.
• A grouped bucket with a non-zero current amount remains available to explain the billing total; a bucket with no billing activity may be collapsed or hidden to reduce clutter. Selected attendees remain visible even when their net impact is $0.00.

Real-world example: Admin edits the second group containing Mike Child 1 and TEST03 in an order with another group. → The confirmation popup and Preview both identify only the 2 submitted attendees; the other group is shown as a grouped row, while the final Preview total still covers the shared billing record.

Booking Rule Options (admin override)

Admins can turn off individual rules in the Booking Rule Options panel, for example:

• Booking Cut-off OFF → past sessions become selectable (all program categories).
• Height / Weight Restriction OFF individually → bypass that one rule; the other still blocks.

Closure Day Booking Adjustment

Admin Portal → the Closure Day Booking Adjustment page: manage bookings affected by a closure day.

• Layout: PageHeader → content card → filter group → programme info → action area → booking table. Narrow viewport → filters wrap, table keeps horizontal scroll.
• Filters: Site, Closure Days, Programmes, Sessions (multi-select); use Programme, not Program.
• States: no Site → prompt; no Closure Days → prompt to pick 1+; no bookings → empty state (not implying a finance/worker error); filters match nothing → prompt to adjust.
• No booking selected → cancel-and-credit disabled; bookings selected → shows selected/total eligible.
• Cancel confirmation: danger, distinguishes singular/plural, states it cancels bookings and generates matching credit notes.
• UI-only: no change to API payload, persistence, finance, or worker processing.

Real-world example: Admin picks a site + one closure day to see who is affected before bulk cancelling. → Avoid blind actions on empty data and make the destructive action clear. → The page lists the affected bookings; admin selects them and clicks cancel-and-credit, a danger dialog confirms and generates a credit note per booking.

Notification template — Checkout Instruction

• Booking templates have a CheckoutInstruction field (plain text) and a placeholder inserting the whole block; no token in the template → no block inserted.
• Renders by the booking's Billing.PaymentOptionId: PayNow/PayNowDeposit → render; PayLater/DirectDebit/null → replaced with an empty string. → checkout URL, keeping line breaks.
• The Booking Confirmation - Parent template adds , , , , , .
• The ConfirmBooking_Account generator replaces every placeholder before sending (no token leaks as-is): → enterprise logo; → attendee/program/price/date range; → TermProgramSet.Instruction; / → rich-text HTML (PDF: view/download link). Not configured → empty.

Real-world example: Admin writes "Booking Confirmation - Parent" with a reminder to pay before class. → PayNow customers receive the checkout instruction at the right time; PayLater customers are not misled. → The template inserts ; a PayNow booking renders CheckoutInstruction with the link, a PayLater booking replaces the block with an empty string.

Next: Core concepts.

Calendar event detail

Clicking an event in Booking Calendar opens a read-only popup in this order: TPS name → session name → session time → each attendee on its own line. Missing fields are omitted and an event without a time does not show a placeholder. The calendar library's quick-info/editor/alert popups are suppressed; clicking +N more does not open a replacement popup.

Real-world example: A month tile shortens an event with four attendees. → Open the event. → The popup shows every attendee and uses the same time zone/format as the tile.