Skip to main content

06 — Account Groups & Ledgers

What it is: how account groups and ledgers are represented — neither is a standalone tbl_* lookup table. Account-group data is read from the vendor; a program's ledger is a config key, not a table.

Account groups (no lookup table)​

Account groups are a vendor concept. Attend reads them via the vendor API and uses them for gating and (eventually) per-group pricing. There is no tbl_account_groups table — the only related table is the junction tbl_user_account_groups (which user belongs to which group), in the user module.

tbl_user_account_groups.accountGroupId intentionally has no FK — group data comes from the vendor, and we don't want FK violations if a group changes vendor-side.

Ledgers (a config key, not a table)​

A ledger is a per-season record-keeping scope in the vendor (e.g. '2025-26'). In Attend it's a ledger config key inside tbl_flex_program_configs (JSONB), validated by LedgerConfigDto — there is no tbl_ledgers table, and tbl_user_account_credit.ledgerCode is a plain varchar code, not a foreign key. Credit in one ledger can't cross into another.

Where these live in code​

The auth module's entities are User, UserSession, UserAccountGroup (junction), and UserAccountCredit — there are no AccountGroup or Ledger entities.

Key rules​

  • Account-group data is read from the vendor; reading an account-credit balance is live, but spending credit at checkout isn't wired into V3 yet (upcoming "bank of credit" work).
  • Real-world example: Knicks/Rangers fans buy $2.5k/$5k/$10k credit → land in matching account groups → same ticket priced differently per group (via ticket type codes).