Skip to content

Configuration Interaction Map

This page documents how HellaBooking configuration entities depend on and interact with each other. Understanding these chains is essential for correct system setup -- a missing link in any chain will break downstream functionality.

1. Reservation to Pricing Chain

The full configuration chain required for a bookable, priced time slot:

flowchart TD
    Season["Season\n(date range, active flag)"]
    BH["BusinessHours\n(open/close per day)"]
    SFA["SportsFieldAvailability\n(field + season + hours)"]
    SFR["SportsFieldRent\n(base pricing rules)"]
    RPP["RentPricingPeriod\n(time bands within a day)"]
    RPPI["RentPricingPeriodInterval\n(price per interval slot)"]
    Reservation["Reservation\n(customer booking)"]

    Season --> BH
    BH --> SFA
    SFA --> SFR
    SFR --> RPP
    RPP --> RPPI
    RPPI --> Reservation

    style Season fill:#4a90d9,color:#fff
    style Reservation fill:#50c878,color:#fff

All six entities must be configured for a sports field to appear as bookable with correct pricing. If any entity in the chain is missing, the field will either not appear in the calendar or show zero pricing.

2. User Type to Payment Behavior

The CustomerBookAndPayLater system parameter interacts with UserType_Enum to determine payment flow:

flowchart TD
    UT["User.UserType_ID"]
    CBPL["SystemParameter:\nCustomerBookAndPayLater"]

    UT --> Decision{Value?}
    CBPL --> Decision

    Decision -->|OFF| PayNow["All users must\npay immediately"]
    Decision -->|CLUBMEMBER| Split{UserType?}
    Decision -->|ALL| PayLater["All users can\ndefer payment"]

    Split -->|ClubMember, Trainer,\nReception, Admin| PayLater2["Can book and\npay later"]
    Split -->|CasualVisitor| PayNow2["Must pay\nimmediately"]

    style PayNow fill:#e74c3c,color:#fff
    style PayNow2 fill:#e74c3c,color:#fff
    style PayLater fill:#50c878,color:#fff
    style PayLater2 fill:#50c878,color:#fff

When CustomerBookAndPayLaterInActiveStatus=ON, only users with Active status (Status_ID=2) can defer payment regardless of the main setting.

3. Credit System Flow

flowchart TD
    CE["SystemParameter:\nCreditEnabled=YES"]
    CD["CreditDefinition\n(packages: amount, price, expiry)"]
    CT["CreditTransaction\n(purchase, payment, refund...)"]
    UB["User.CreditBalance"]
    Pay["Payment\n(PaidByCredit field)"]

    CE -->|activates| CD
    CD -->|customer purchases| CT
    CT -->|updates| UB
    UB -->|sufficient balance| Pay
    Pay -->|deducts via| CT

    style CE fill:#4a90d9,color:#fff
    style UB fill:#f39c12,color:#fff

When a customer pays with credit, Payment.PaidByCredit records the credit amount applied, reducing the PayableAmount. A CreditTransaction of type Payment (ID=2) is created to track the deduction.

4. Training Credit Chain

flowchart TD
    TCE["SystemParameter:\nTrainingCreditEnabled=ALL"]
    TCD["SystemParameter:\nTrainingCreditDefinitionSetup=PACKAGE"]
    CP["CoursePackage /\nTrainingGroupPackage"]
    TCC["TrainingCredit\n(customer's credit balance)"]
    ATT["Attendance\n(session participation)"]
    TPT["TrainingPackageTransaction\n(debit on attendance)"]

    TCE -->|activates| TCD
    TCD -->|PACKAGE mode| CP
    CP -->|customer purchases| TCC
    TCC -->|consumed by| ATT
    ATT -->|creates| TPT

    style TCE fill:#4a90d9,color:#fff
    style TPT fill:#50c878,color:#fff
  • TrainingCreditMatch=ANY allows credits from any package to be used for any training type.
  • TrainingCreditMatch=EXACT requires credits to match the specific course/training group.
  • TrainingCreditHourBased=YES calculates consumption by hours instead of sessions.

5. Discount Stacking

Multiple discount sources can apply to a single reservation. The system evaluates them in priority order:

flowchart TD
    GD["Group.Discount\n(percentage)"]
    GSD["Group.SeasonDiscount\n(season-specific %)"]
    SDOO["SystemParameter:\nSeasonDiscountForOneOffReservations"]
    USDE["User.SeasonDiscountEnabled"]
    UDD["User.DiscountsDisabled"]

    GD --> Eval["Discount Evaluation"]
    GSD --> Eval
    SDOO --> Eval
    USDE --> Eval
    UDD --> Override{"DiscountsDisabled?"}

    Override -->|YES| Zero["No discount applied"]
    Override -->|NO| Eval
    Eval --> Final["Final discount %"]

    style Zero fill:#e74c3c,color:#fff
    style Final fill:#50c878,color:#fff

Priority rules:

  1. User.DiscountsDisabled = true overrides everything -- no discounts apply.
  2. User.SeasonDiscountEnabled must be true for season discounts to apply to that user.
  3. Group.SeasonDiscount takes precedence over Group.Discount during the applicable season.
  4. SeasonDiscountForOneOffReservations must be YES for season discounts on non-recurring bookings.
  5. SeasonDiscountForShortRecurringReservations controls eligibility for short recurring series.
  6. When a user belongs to multiple groups, the group with the highest priority applies.

6. Cancellation Timing Logic

The cancellation deadline determines which status a cancelled reservation receives:

flowchart LR
    Cancel["Customer requests\ncancellation"]
    Check{"Hours until\nstart >= deadline?"}
    Cancel --> Check

    Check -->|YES| Status2["Status = Cancelled\n(ID=2)\nFull refund eligible"]
    Check -->|NO| Status3["Status = LastMinuteCancelled\n(ID=3)\nNo refund"]

    style Status2 fill:#50c878,color:#fff
    style Status3 fill:#e74c3c,color:#fff

The deadline varies by user type:

User Type Parameter Default
Casual Visitor MinReservationCancellationCasualVisitor_Hours 24 hours
Club Member MinReservationCancellationClubMember_Hours 24 hours

7. Field Type to Pricing Model

The sports field type determines the reservation type, which in turn determines the pricing model:

flowchart TD
    SFT["SportsFieldType\n(e.g., Tennis Court, Squash)"]
    RT["SportsFieldType.ReservationType_ID"]
    SFT --> RT

    RT -->|1 = Hourly| HP["Hourly Pricing\nRentPricingPeriodInterval\nper time slot"]
    RT -->|2 = Daily| DP["Daily Pricing\nSingle price per day\nfrom SportsFieldRent"]

    HP --> Cal["Calendar shows\ntime slot grid"]
    DP --> Cal2["Calendar shows\nfull-day slots"]

    style HP fill:#4a90d9,color:#fff
    style DP fill:#f39c12,color:#fff
  • Hourly fields use ReservationIntervalIncrement_Mins (default: 30) to define the slot grid and Min_ReservationInterval_Mins (default: 60) for minimum booking length.
  • Daily fields ignore time-slot parameters and book the entire day.

Cross-Reference Summary

Interaction Key Parameters/Tables Effect
Pricing chain Season -> BusinessHours -> SportsFieldAvailability -> SportsFieldRent -> RentPricingPeriod -> RentPricingPeriodInterval All required for bookable slots
Pay later CustomerBookAndPayLater + UserType Controls who pays immediately vs deferred
Credit payment CreditEnabled + CreditDefinition + Payment.PaidByCredit Enables wallet-based payments
Training credits TrainingCreditEnabled + TrainingCreditDefinitionSetup + packages Controls training credit consumption
Discount stacking Group.Discount + SeasonDiscount + User flags Priority-based discount resolution
Cancellation status MinReservationCancellation*_Hours Determines Cancelled vs LastMinuteCancelled
Pricing model SportsFieldType.ReservationType_ID Hourly vs Daily pricing and calendar