# AccountReports Documentation Set

This folder documents the GB4.7 → GB5 AccountReports migration wave: the reports built so far,
how they're configured per client, and the process for migrating the reports still to come (plus
building genuinely new report services that don't exist in legacy).

**Status as of 2026-08-01**: 7 report endpoints across 6 report families are code-complete,
live-verified on GB5DEMO, and committed to `dev` — see [AccountReports_Catalog.md](AccountReports_Catalog.md)
for exactly what "live-verified" means for each one, and what is *not yet* verified (notably:
none of these have had a browser click-through against the actual FE ReportViewer yet — only
direct backend HTTP calls).

## Who should read what

| You are... | Start here |
|---|---|
| **End user** (someone who runs these reports day to day) | [AccountReports_Overview.md](AccountReports_Overview.md), then the "For End Users" section of each report in [AccountReports_Catalog.md](AccountReports_Catalog.md) |
| **Client Admin** (configures menus/permissions/report views for a client) | [AccountReports_Overview.md](AccountReports_Overview.md), then [AccountReports_AdminConfigGuide.md](AccountReports_AdminConfigGuide.md) |
| **Implementation Team** (rolls a client onto GB5, decides which reports to enable) | [AccountReports_AdminConfigGuide.md](AccountReports_AdminConfigGuide.md), then the "For ImpTeam" section per report in the Catalog |
| **BE/FE developer** (builds the next report, or extends one of these) | [AccountReports_DeveloperPlaybook.md](AccountReports_DeveloperPlaybook.md) is the main one; use [AccountReports_Reference.md](AccountReports_Reference.md) as your lookup table while coding |

## Files in this set

1. **[AccountReports_Overview.md](AccountReports_Overview.md)** — what this migration wave is, why it's happening, plain-language framing for non-technical readers.
2. **[AccountReports_Catalog.md](AccountReports_Catalog.md)** — one entry per report family: what it does, who uses it, what's configurable, how it's wired, technical notes, verification status. This is the "explainer" half of the ask.
3. **[AccountReports_AdminConfigGuide.md](AccountReports_AdminConfigGuide.md)** — how the MetaReport/ReportView framework works in practice: menu linking, access-rights limits, currency/criteria defaults, what a Client Admin actually clicks.
4. **[AccountReports_DeveloperPlaybook.md](AccountReports_DeveloperPlaybook.md)** — the "guide" half of the ask: the step-by-step process used to migrate each report so far, decision points, what's automatable vs. what needs a developer's judgment, and how the process changes for genuinely new (non-legacy) report services.
5. **[AccountReports_Reference.md](AccountReports_Reference.md)** — glossary, the full shared criteria-field table, REPORTID/BizTransactionClassId reference tables, and the shared C# builder methods every report reuses.

## Keeping this up to date

This is a living document set — every future report migration should:
- Add its entry to [AccountReports_Catalog.md](AccountReports_Catalog.md) (copy an existing entry's structure).
- Add any new shared criteria field to the table in [AccountReports_Reference.md](AccountReports_Reference.md).
- Note any new pattern or gotcha in [AccountReports_DeveloperPlaybook.md](AccountReports_DeveloperPlaybook.md)'s "Lessons learned" section.

Don't get ahead of reality here. If a report is "code complete but not live-verified," say exactly
that; don't round it up to "done."