# AccountReports: Client Admin / Implementation Team Configuration Guide

This is the practical "what do I actually configure" guide for rolling these reports out to a
client. It assumes you already know GB5's general menu/role/permission model; it only covers what's
specific to the MetaReport/ReportView framework these reports are built on.

## The framework these reports live in

Every report in this catalog is wired into the same four-table chain GB5 already uses for other
reports:

```
MREPORT              — one row per "report" (e.g. "Outstanding Detail"). Legacy-inherited; identified by REPORTID.
  └─ MREPORTVIEW      — one or more named "views" of that report (e.g. "Outstanding Detail" vs. a
                         GroupType=AccountGroup variant). Controls page format/orientation, which
                         menu(s) it's reachable from (APPLICABLEMENUIDS), and default sort.
      └─ MREPORTVIEWFIELDS — the column layout for one view: which fields show, in what order,
                              width, alignment, subtotal/grand-total flags, number format.
          └─ MREPORTVSFIELDS — the catalog of fields a REPORTID *could* show (field name/title).
                                A view's MREPORTVIEWFIELDS rows each point at one of these.
```

**Important**: `MREPORTVIEW` is presentation-only. It does not select which query runs — the
endpoint route (e.g. `/AccountReports/AccountOutstandingDetailReport`) is what actually runs the
query; the `ReportViewId` passed alongside it only controls which columns are displayed and in what
layout. Don't assume creating a new `MREPORTVIEW` row changes report behavior — it changes how the
result is *displayed*.

## What's already done vs. what a client rollout still needs

For every report in this catalog, the migration work already:
- Added the necessary `MREPORTVIEW` row(s) under the report's existing legacy `REPORTID` (see
  [AccountReports_Reference.md](AccountReports_Reference.md) for the exact IDs).
- Reused the existing `MREPORTVSFIELDS` field catalog wherever a matching field already existed —
  only Collection/Payment Projection needed genuinely new field-catalog rows (6 of them, for the
  new payable-side/cash-discount columns).
- Set `APPLICABLEMENUIDS` on each new view to the same real menu ID(s) the report's existing legacy
  sibling views already use — **confirmed live**, not a placeholder, for every report except
  Account Register/Summary (see that report's entry in the Catalog for the open item there).

What a client rollout still needs to check/decide, per client:
1. **Role/menu permissions** — does the relevant role actually have access to the menu(s) these
   views are attached to? This is standard GB5 role-vs-menu configuration, nothing report-specific.
2. **`MROLEVSMENU` day/record limits** — if a role's menu entry has a `DaysLimit` or `RecordsLimit`
   configured, `EnforceAsync`/`EnforceForAsOnDateAsync` (see the Developer Playbook) will reject
   requests that exceed them. If no such row exists for a role/menu pair, these checks currently
   **fail open** (no limit enforced) rather than blocking the report — this was a deliberate choice
   to close a real gap (previously these limits were UI-only and a direct API caller could bypass
   them entirely) without breaking existing configurations that never set a limit. If a client
   needs day/record limits enforced on a specific report, that `MROLEVSMENU` row needs to exist.
3. **`MUSERACCESSRIGHTS.NOOFREADPERIOD`** — if this is set to `1` for a user, period-range reports
   (Register, Ledger, Settlement) reject any `PeriodFromDate` earlier than the user's current work
   period, and as-of-date reports (Outstanding, Ageing, Collection Projection) reject any `AsOnDate`
   earlier than the work period start. This is existing GB5 behavior, not new to these reports —
   just be aware it now applies here too.
4. **Whether the client needs a currency conversion default** — Account Ledger's `CurrencyBasis`/
   `ReportCurrencyId` options need a decision per client (base currency vs. transaction vs. customer
   vs. group currency as the default view) if the client operates in multiple currencies.

## Open item — column customization without a code migration

Today, adding a brand-new `MREPORTVIEW`/`MREPORTVIEWFIELDS` row (a new *view* of an existing report,
or new field-catalog entries) is done via a one-off SQL migration written by a developer — there is
no CRUD screen in this repo for creating `MREPORT`/`MREPORTVSFIELDS` rows from scratch. If GB5 has
(or plans) an admin screen that lets a Client Admin customize an *existing* view's column
selection/order without a migration, confirm that with the FE/framework team — it wasn't in scope
for this migration wave and isn't covered by this document.

## Practical checklist for onboarding a client onto one of these reports

- [ ] Confirm the relevant menu(s) (see [AccountReports_Reference.md](AccountReports_Reference.md)
      for each report's `APPLICABLEMENUIDS`) are assigned to the roles that should see this report.
- [ ] Decide whether day/record limits should apply for this client's roles; add `MROLEVSMENU` rows
      if so.
- [ ] For Ledger: decide the default currency basis for this client.
- [ ] For Outstanding/Ageing/Collection Projection: confirm the client's OU-access-rights setup
      (`MUSERACCESSRIGHTS`) is correct — every one of these reports enforces an OU ceiling based on
      it, on top of any explicit OU filter the user picks.
- [ ] Click through the report in a real browser session before calling the client rollout done —
      see the "FE click-through: Not done" note in the Catalog. This step hasn't been performed for
      any report in this set yet as of this writing.