Skip to content

Accounting Period dropdown defaults to the earliest OPEN period

Why (owner, 2026-06-23)

The global Period selector at the top of the Accounting page (T-058's PeriodContext) defaulted to the latest fiscal period (periods[0], newest-first). Owner wants it to land on the earliest OPEN period instead β€” the oldest fiscal period not yet fully closed β€” so a bookkeeper opens the page already positioned on the oldest period still needing work.

What changed

components/accounting/PeriodContext.tsx only (read-side default selection): - PeriodProvider now self-resolves the active subsidiary via useDefaultSubsidiary('erl') (same hook the page uses) and fetches that subsidiary's closed months from GET /api/accounting/periods?subsidiaryId=…. - New default rule: scan basis periods oldest-first and select the first one that is not fully closed (isBasisPeriodFullyClosed β€” every 'YYYY-MM' the period spans has a close record). That period's endingYear becomes the initial selection. - Default resolves once both the period list and the closed-month set are loaded (avoids flashing the wrong period); keyed on subsidiary so it re-resolves if the primary subsidiary loads late / changes, and never overrides a selection the user already made.

Edge cases

  • Nothing closed β†’ earliest open = the oldest period (P1). Correct per the request.
  • Every period fully closed β†’ no open period β†’ falls back to the newest period (prior behaviour).
  • Close-data fetch fails β†’ treated as "nothing closed" so the default still resolves and the page stays usable.

Verification

  • npx tsc --noEmit clean.
  • Manual UI check is owner-side (can't drive the browser from here): open Accounting β†’ the Period dropdown should land on the oldest not-yet-closed fiscal period instead of the current one.

Log

  • 2026-06-23 created + shipped. Read-side only; no data migration. "Open" is defined by the existing period-close records (per-month), rolled up to the basis period. Source: Accounting (Diagnostics) Β· https://claude.ai/code/session_01G58Y71noihrYCDEDMexmea

Commit index (backfilled 2026-07-01, best-effort Β· Coaching (Diagnostic))

Candidate related commits, auto-backfilled from git on main: commits whose message references this task's UID or a PR number it cites. Not verified β€” this squash-merged history can't yield a precise per-task list, so rows tagged (mentions only) name the task in passing (may be tangential) and untagged work commits may be missing. Treat as a starting point: verify, prune tangential rows, and append any real ones per the AGENTS.md "record every related SHA" policy.

  • (no git-discoverable commit references this UID or its PRs β€” append real SHAs here as identified.)