# Business Rules

## Bookings

1. A booking is the authoritative operational record for an event.
2. One booking may reserve multiple spaces via `booking_spaces`.
3. Booking statuses: enquiry, provisional, awaiting_approval, awaiting_deposit, confirmed, in_progress, completed, postponed, cancelled, no_show.
4. Confirmation rules are configurable and may require accepted quotation, issued invoice, deposit, full payment, and/or manual approval.
5. Before confirmation, availability is re-checked inside a database transaction.
6. Rescheduling confirmed bookings re-runs availability checks under lock.
7. Overrides of billable days/hours require permission and a recorded reason (audited).

## Availability & Holds

1. Conflict includes setup start through breakdown end.
2. Adjacent periods (exact touch) are allowed.
3. Provisional holds block availability until expiry or release.
4. Expired holds do not block; lazy expiry runs before availability/calendar/view/confirm.
5. Maintenance and internal blocks always conflict with new reservations.
6. Space opening/closing hours constrain setup/event windows.
7. A quotation never reserves a space unless a hold or confirmed reservation exists.
8. Occupancy is computed from active reservations — never a permanent space status.

## Pricing

1. All calculations use PricingService with two-decimal rounding.
2. Billable days default to distinct local calendar dates spanned by the event (minimum 1).
3. Line amounts derive from charge basis × quantity × applicable guests/days/hours.
4. Document totals: subtotal − discount + service charge + tax = grand total (order defined by PricingService).
5. Deposit requirement is calculated; balance is never manually editable — it is derived from payments.

## Documents

1. Issued quotations and invoices retain immutable snapshots.
2. Master data changes (products, packages, customers) do not alter issued documents.
3. Quote conversion: lock quote → ensure not converted → create one invoice with snapshots → link booking unchanged → mark quote converted → audit.
4. Draft invoices may be edited/deleted by authorized users.
5. Issued invoices are voided (with reason), never permanently deleted.
6. Invoices with payments cannot be permanently deleted.
7. Overdue status is computed from due date + outstanding balance on read/update.

## Payments

1. Methods: cash, bank transfer, mobile money, credit/debit card, cheque, credit account, other.
2. Statuses: posted, reversed, refunded.
3. Invoice payment status: unpaid, partially_paid, paid, overpaid, refunded — derived from transactions.
4. Record / reverse / refund run in transactions and produce audit entries.

## Master Data

1. Referenced customers, products, packages, and spaces are archived, not hard-deleted.
2. Archived records remain visible on historical documents.
3. Space operational status (active, inactive, under_maintenance, temporarily_closed, archived) is independent of booking occupancy.

## Security & Audit

1. State-changing actions use POST/PUT/PATCH/DELETE only.
2. Permission checks are server-side on every protected route/action.
3. Audit logs never store passwords, session IDs, or secrets.
4. Mandatory reasons for voids, reversals, refunds, and significant overrides.
