Chapter 13.2 — Booking Lifecycle Workflow
Context
The booking lifecycle is the central operational workflow of the platform. This chapter visualises it end-to-end from offer search through travel completion, with the financial side-effects called out at each step. The full text definition is in Chapter 4.1.
Roles
| Role | Involvement |
|---|---|
| Customer | Travels; pays |
| Agent | Selects offer, creates booking, services bookings |
| Approver | Approves above-threshold bookings |
| Cashier | Receives cash payments |
| Accountant | Reconciles payments, processes refunds |
| System | Holds, recognises, sweeps timelimits |
Pre-conditions
- Customer record exists and is active.
- Supplier active for the chosen product.
- Partner has open accounting period.
Sequence — Standard credit booking (corporate)
sequenceDiagram
autonumber
actor Cust as Customer
actor Ag as Agent
participant UI as travoBooks UI
participant API as travoBooks API
participant DB as MySQL
participant Q as Queue
participant GDS as GDS / NDC Supplier
participant SES as Email (SES)
participant WH as Webhooks
Cust->>Ag: Request flight DAC-DXB May 28
Ag->>UI: Search offer
UI->>API: GET /offers?...
API->>GDS: Air_MasterPricerTravelBoardSearch
GDS-->>API: Offers
API-->>UI: Offers list
Ag->>UI: Select offer; assign Customer Beta
UI->>API: POST /bookings (offer_id, customer_id, pax)
API->>GDS: Air_SellFromRecommendation
GDS-->>API: PNR ABC123 + timelimit
API->>DB: INSERT booking (state=HELD)
API-->>UI: 201 booking_id, ref TVB-2026-000123
Ag->>UI: Add traveller details, confirm price
Ag->>UI: Issue ticket
UI->>API: POST /bookings/{id}/issue
API->>API: Credit-check Beta Corp
API->>GDS: Fare_PricePNRWithBookingClass (re-price)
GDS-->>API: TST priced 65,400 BDT
API->>DB: BEGIN TX
API->>GDS: DocIssuance_IssueTicket
GDS-->>API: Ticket 176-2400000123
API->>DB: INSERT booking_tickets
API->>DB: INSERT journal_entries + lines
API->>DB: UPDATE booking state=ISSUED, issued_at
API->>DB: UPDATE customer_balances + commission_accruals
API->>DB: COMMIT
API->>Q: Enqueue: pdf_generate, email_send, webhook_dispatch
Q->>SES: Send e-ticket
Q->>WH: POST booking.issued to partner endpoints
SES-->>Cust: E-ticket email
Note over DB: Service date May 28 → recognition run will flip deferred → earned
Sequence — Cash retail booking
sequenceDiagram
autonumber
actor Cust as Walk-in Customer
actor Ag as Agent
actor Cs as Cashier
participant UI as travoBooks UI
participant API as travoBooks API
participant DB as MySQL
participant GDS as GDS Supplier
Cust->>Ag: Walk-in; selects DAC-CGP one-way
Ag->>UI: Create booking with walk-in customer or quick-create
UI->>API: POST /bookings
API->>GDS: Air_SellFromRecommendation
GDS-->>API: PNR + price
API->>DB: state=HELD; state=PENDING_PAYMENT (cash flow)
UI-->>Ag: Show price to collect: BDT 8,500
Ag->>Cs: Collect cash 8,500
Cs->>UI: Capture cash receipt (cash_drawer DHK-01)
UI->>API: POST /payments
API->>DB: INSERT payments + apply not yet
API->>API: Mark booking ready-to-issue
UI->>API: POST /bookings/{id}/issue
API->>GDS: Issue
GDS-->>API: Ticket
API->>DB: BEGIN; INSERT tickets, JE, state=ISSUED; payment-apply against future invoice or directly to AR-cash flow; COMMIT
UI-->>Ag: Receipt + e-ticket
Ag->>Cust: Hand over receipt and e-ticket
State machine
stateDiagram-v2
[*] --> DRAFT
DRAFT --> HELD: Supplier hold
DRAFT --> EXPIRED: Auto 30m
DRAFT --> CANCELLED_BEFORE_ISSUE: Abandon
HELD --> PENDING_PAYMENT: Cash flow
HELD --> PENDING_APPROVAL: Over threshold
HELD --> ISSUED: Credit auto-approved
PENDING_PAYMENT --> ISSUED: Payment OK
PENDING_PAYMENT --> CANCELLED_BEFORE_ISSUE: Payment failed
PENDING_APPROVAL --> ISSUED: Approved
PENDING_APPROVAL --> DRAFT: Rejected
HELD --> EXPIRED: Timelimit
ISSUED --> PARTIALLY_USED: First segment flown
PARTIALLY_USED --> COMPLETED: All used
ISSUED --> COMPLETED: All used (single seg)
ISSUED --> CANCELLED_AFTER_ISSUE: Void / full refund
ISSUED --> PARTIALLY_REFUNDED: Partial refund
PARTIALLY_REFUNDED --> CANCELLED_AFTER_ISSUE
COMPLETED --> ARCHIVED: Retention
CANCELLED_AFTER_ISSUE --> ARCHIVED
Decision points
flowchart TD
A[Booking selected] --> B{Customer type}
B -->|Walk-in| C[Cash flow: PENDING_PAYMENT]
B -->|Corporate w/ credit| D{Above threshold?}
D -->|Yes| E[PENDING_APPROVAL]
D -->|No| F{Credit OK?}
F -->|Yes| G[ISSUE]
F -->|No| H[Override path or reject]
E -->|Approved| G
E -->|Rejected| I[Back to DRAFT or cancel]
C --> J{Payment received?}
J -->|Yes| G
J -->|No / failed| I
G --> K[Generate ticket, JE posted same TX]
K --> L[Async: PDF, email, webhook]
Financial side-effects per state transition
| From → To | Financial impact |
|---|---|
| DRAFT → HELD | None (supplier hold only) |
| HELD → ISSUED | Full issuance JE (gross AR/cash, BSP/AP payable, commission accrual, taxes, service fee) |
| HELD → EXPIRED | None |
| ISSUED → CANCELLED_AFTER_ISSUE (void same day) | Full reversing JE |
| ISSUED → PARTIALLY_REFUNDED | Partial reversing JE per refund quote; commission recall |
| Service-date reached | Recognition JE: deferred → earned |
Outcomes
| Terminal | Meaning |
|---|---|
| COMPLETED | Customer travelled; revenue fully recognised |
| CANCELLED_AFTER_ISSUE | Reversed; potentially with retained service fee |
| CANCELLED_BEFORE_ISSUE | No financial impact |
| EXPIRED | Hold lapsed; no impact |
| ARCHIVED | Post-retention state |
Cross-references
- Chapter 4.1 — Booking Lifecycle (text definition)
- Chapter 4.2 — Ticketing & PNR
- Chapter 4.3 — Refunds & Cancellations
- Chapter 5.1 — Chart of Accounts
- Chapter 5.2 — Journals & Ledger
- Chapter 5.7 — Deferred Revenue