Reports – Functional Specification

Reports is the read-only query layer over everything the other modules produce. The old SM ships 21 operational reports; users routinely export several and merge them in Excel to answer one question. The agreed redesign collapses them into five merged reports + one planning view, each a flexible, filterable query, on one shared viewer platform:

Mental model: every report is a predefined search – a saved configuration of the same flexible query engine. Customers can commission (or, with a technical user, build) additional predefined searches as custom reports (P-002); the flexible-search engine is a licensed Structured Software component, which supports a commercial model of either self-service or paid report additions.

• NEW The Reports landing is a catalogue of report cards grouped by subject: Service delivery (Request, Referral), Agreements & assessments (Service agreements, Assessment next-review), Stock & audit (Stock, Audit), and Custom reports (per-customer predefined searches, P-002). Grouping is a design proposal from the call (“shouldn't the reporting be grouped by…”) – to confirm (OQ-RP1).
• Each card: name, one-line description, the old reports it replaces (small print, the positioning note above), last-run time, and a Run action opening the viewer. Cards with an active schedule show a schedule chip.
• Top-level page – no breadcrumb (standing rule); the module lives in the left menu as Reports with sub-pages per report + Scheduled reports.
• NEW New custom report action – captures a request to SSL (or opens the flexible-search builder for licensed technical users). V1 wireframes demonstrate the request path only (OQ-RP2).

All six reports run on one viewer surface; only filters and columns differ. The platform features are decisions P-001/P-002:

• NEW One row per request: original request (type, raised date/time, requester, service user) → final outcome – the resolution field, from the admin-defined outcomes list (P-005; list managed in Administration).
• Filter by request type (Installation / Change / Decommission / Custom) and priority – incidents are urgent requests, so “how many incidents last month” = filter Urgent (the merge logic agreed with Katrina on the call).
• SLAs shown where set up (P-005 “IMPORTANT”): target vs. actual columns with met/breached RAG pills; targets derive from admin SLA config (Q-006).
• Cancellations: status filter includes Cancelled; the cancellation reason column carries the admin-categorised reason (Q-010), replacing the request half of the old Cancellation Reasons report (P-004).
• REMOVED Task SLA and Termination Reasons as standalone reports – their columns/filters fold in here (P-008).

• NEW Funnel over a date range: referrals received → converted (became service users) → rejected / cancelled, with the reason (admin-defined, categorised: cost / gone into care / no longer required / …). Split out of Cancellation Reasons (P-004).
• Headline tiles (received / converted / rejected + conversion %) above the row grid – mirrors the Referrals console counts (R-007 sources as a filter).
• Business driver from the call: “no responder coverage” rejections are recruitment evidence – the reason filter makes that a one-click query (M5 recruitment signal, referrals spec §Reject).

• NEW One flexible query over agreements + their services + their equipment, replacing eight old reports (P-006). “Anything to do within a service agreement that you're going to find details for” (Robert, naming the report on the call).
• Feature filters: service type (e.g. has responder service), funder (private pay / social services / …), status (active / without active services / active between dates), equipment model – the filter set must cover every option of the merged reports.
• TBD Sub-query design – the notes carry an explicit design TODO (“suggest a design that works – maybe with sub-queries for lower-level queries”). The wireframe proposes a two-level model: base filters on the agreement + an optional sub-query chip row scoped to services or equipment (e.g. agreement rows where any service = Responder and state = Active). Flagged for Tunstall confirmation (OQ-RP3).
• Service-expiry planning (agreements expiring in the next 7 days, noted under Service cancellation in M-notes) is a saved filter preset of this report, not a separate report.

• NEW Merge of all stock reports (P-007): what's in stock, in which store (I-007 store types), expiry dates (battery / warranty – recommended change date; RAG on approaching expiry) and current stock value (the explicit customer ask).
• NEW Generate battery-replacement request from a report row – “what would be nice is if the report has the option to say, do you want to generate a request?” (Andy). Creates a Change request via the standard New-request flow; confirmation modal per the destructive/creative-action rule.
• NEW Recommended re-order level per catalogue line, computed from minimum/recommended stock level, weekly usage and delivery lead time (SaaS4: with manager approval – the approval workflow is Inventory's, the report only surfaces the recommendation).
• Missing stock view – filter preset over stock-take discrepancies (feeds from Inventory stock take, I-005).
• REMOVED Stock Transfer History / Stock Item Transferred History – custody movement questions go to the Audit report (P-008).

• BASE Completed assessments on live agreements with their next review date; columns come from the service agreement (updated via a new assessment when out of date). RAG kept from the old SM: red = overdue, amber = due within a week (Andy/Rob on the call).
• NEW Date-range search around expiry – “have I got a busy March?”; the old report hard-coded next-30-days (P-003).
• NEW Search the auto-generated review tasks (created when the last assessment was saved, P-003; task pipeline per G-002) – shows what is already scheduled vs. unscheduled.
• Click-through to the previous assessment (opens the profile assessment view, file 03).
• Relationship to Scheduling: the planning workload lives in the scheduler (assessments-only filter, C-003); this report remains as the exportable evidence view (“where did my 50 assessments go” – Robert). Link to the scheduler on the report header.

• NEW All tracked/audited activities in one query (P-008) – the old SM had no audit report. Filters: entity type (agreement / request / task / stock item / referral / user admin), action, actor, store (for stock custody), date range.
• Answers the stock-transfer questions that killed the two transfer-history reports (“it's all recorded in the audit” – Andy), plus who-changed-what on any record.
• TBD v1 entity coverage – which audit streams exist at launch depends on the build's audit trail scope (OQ-RP4).

• NEW Schedule any report (or saved configuration) to run at a frequency (e.g. Mondays 09:00 stock levels) or on a specific date, and email recipients a link to the result (P-002).
• Link, not content: the email must contain a link into the system – never the report data – so access control still applies (“my view would be it should be a link, because then we can control who has access” – Andy; the current platform only drops files into a secure org folder, and tenders ask for email distribution). Recipients without report access see a permission error, not data.
• Scheduled reports screen: table of schedules (report, configuration, frequency, next run, recipients, owner, active toggle) + run history with links to past results; New/Edit schedule modal.
• “As of” search (§2) complements scheduling: a past snapshot can be reproduced on demand rather than only captured by a scheduled run.

Reports are read in the system but consumed elsewhere – in board packs, funder updates, contract reviews and emails. Two families of output exist, and both must be one action away.

Defect: popups under in-app zoom CHANGED

The Export menu did not open next to its button – and so appeared not to work at all – whenever the page was zoomed in. The platform's accessibility text-size control applies zoom to the root element; under a root zoom, getBoundingClientRect() and innerWidth/Height report visual pixels (already multiplied by the zoom factor) while an absolutely-positioned popup lays out in unzoomed ones, so the menu was pushed progressively further off-target as the zoom rose.

Fixed centrally rather than locally: shell-a11y.js now exposes uiZoom(), uiRect(), uiVW() and uiVH(), which give measurements back in the element's own coordinate space, and the popup is anchored with position:fixed (so it is also immune to page scroll). The same bug affected the shared Columns popups and the styled tooltips on every page, and all have been migrated. Standing rule: never position a popup from a raw getBoundingClientRect() – always go through the shared helpers. P-010

All 21 old Operational Reports (58 screenshots in Current Service Manager/8 Operational Reports/) accounted for:

Counts: kept/changed 1 · merged into Request 7 (incl. the Cancellation-Reasons request half) · merged into Referral 2 (incl. the referral half) · merged into Agreements 8 · merged into Stock 3 · replaced by Audit 2. (Cancellation Reasons counts once, split across two successors; 1 + 6 + 2 + 8 + 3 + 2 = 21 with the split row counted in both halves' narrative but once in the table.)

• OQ-RP1 – catalogue grouping: the subject groups (Service delivery / Agreements & assessments / Stock & audit) are a design proposal from Dagmara's remark on the call, not an agreed decision. Confirm or re-group.
• OQ-RP2 – custom-report authoring: v1 shows “request a custom report from SSL”. Is the self-service flexible-search builder (licensed component) in scope for any customer at launch, and what is the charging model?
• OQ-RP3 – P-006 sub-query design: the notes leave the design open (“suggest a design that works – maybe with sub-queries”). The proposed base-filters + services/equipment sub-query chips need validation against real queries (e.g. Rob's private-pay lookup).
• OQ-RP4 – audit coverage at v1: which entities' audit trails exist at launch (agreements, requests, tasks, stock, referrals, admin)? The Audit report can only surface what the build tracks.
• OQ-RP5 – scope selector semantics: confirm the within-level narrowing (e.g. one authority inside an ARC) and what PTL's 26-May multi-tenancy delivery actually provides (P-001 note).
• OQ-RP6 – scheduled-run retention: how long are scheduled-run results kept, and are they immutable snapshots or re-runs of the query at open time (interacts with “as of”)?
• OQ-RP7 – battery-request bulk action: single-row request generation is agreed (P-007); is a bulk “generate requests for all expiring” wanted, and does it need manager approval like SaaS4 re-ordering?