From 0e178b670ef34979f05e4c10e4a18732f8a53c50 Mon Sep 17 00:00:00 2001 From: shad0w Date: Fri, 26 Jun 2026 02:49:06 +0530 Subject: [PATCH] =?UTF-8?q?docs:=20report=E2=86=92PO=20drill-down,=20PO=20?= =?UTF-8?q?History=20accounting-code=20filter,=20PR-review=20watcher?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Covers changes merged after the last wiki update (2026-06-24): - #126/#123 report detail "View POs" drill-down + PO History accounting-code filter and approved-date window (Reports, Purchase-Orders, Pages-and-Navigation) - #129/#131/#134 PR review-comment watcher (Issue-to-Deploy-Pipeline) - Changelog mirror entries --- Changelog.md | 2 ++ Issue-to-Deploy-Pipeline.md | 24 ++++++++++++++++++++++++ Pages-and-Navigation.md | 2 +- Purchase-Orders.md | 23 +++++++++++++++++++++++ Reports.md | 27 +++++++++++++++++++++++++++ 5 files changed, 77 insertions(+), 1 deletion(-) diff --git a/Changelog.md b/Changelog.md index bd7249c..412ccfa 100644 --- a/Changelog.md +++ b/Changelog.md @@ -9,6 +9,8 @@ checked out in `~/pms`. See [Deployment and Operations](Deployment-and-Operation ### Added - **Reports — Purchasing spend analytics** (`view_analytics`) — `/reports/cost-centres` and `/reports/accounting-codes`, each index → drill-down → detail; KPI tiles, comparison/trend charts (one colour per item), Top-N tables, sparklines, CSV export; URL-driven filters (Weekly/Monthly/Yearly, FY, Top/Bottom-N, "Add to graph"). Spend = post-approval POs by `approvedAt`/`totalAmount`, allocated per line-item account. See [Reports](Reports). +- **Report → PO drill-down** (#126) — the Cost Centre and Accounting Code report detail pages gain a **"View POs"** link that opens **PO History** pre-filtered to that cost centre / accounting code and the period currently in view (mapped to the approved-date window via `periodRange`, since spend is dated by `approvedAt`). PO History gains an **Accounting Code** filter that accepts any tree node and matches a PO whose PO-level account **or** any line-item account falls under that node's leaves. The History page and its CSV/PDF export share one `buildPoHistoryWhere` builder so they never diverge. See [Reports](Reports#drill-down-to-pos) and [Purchase Orders](Purchase-Orders#po-history--export). +- **PR review-comment watcher** (#129/#131/#134) — a second pms1 cron watcher (`automation/claude-pr-review-watcher.sh`) closes the loop on the review side: leave a comment starting with **`claude-review:`** on any Claude-raised PR and the watcher checks out the PR branch, runs headless Claude to address every collaborator `claude-review:` comment, pushes the fix, and acknowledges. Own clone (`~/pelagia-pr-review`), config, and lock; a one-command updater redeploys it. See [Issue to Deploy Pipeline](Issue-to-Deploy-Pipeline#pr-review-comment-watcher). - **Email PO to vendor** (issue #14) — Outlook draft with a 7-day PO-PDF link, rendered by the **PdfService** microservice and cached per PO. See [Deployment and Operations](Deployment-and-Operations#microservices). - **Microservices** — `EpfoService` (UAN/EPFO lookup) and `PdfService` (PO→PDF) join `GstService`; all auto-deployed on each release tag via `ecosystem.config.js`. - **Unsaved-changes prompt** (issue #18) — leaving the PO create/edit screen with unsaved edits offers Save as draft / Discard / Stay. diff --git a/Issue-to-Deploy-Pipeline.md b/Issue-to-Deploy-Pipeline.md index 791c056..90febd2 100644 --- a/Issue-to-Deploy-Pipeline.md +++ b/Issue-to-Deploy-Pipeline.md @@ -91,5 +91,29 @@ So the fix stage verifies against realistic data without touching production: - Schema-migration issues are routed to `interactive`, so the unattended fixer should not be altering the schema. +## PR review-comment watcher + +Where the issue watcher turns *issues* into PRs, a second watcher +(`automation/claude-pr-review-watcher.sh`) closes the loop on the **review** side — +it addresses review comments left on the PRs Claude already raised, so a reviewer +can request changes in plain English instead of editing code by hand. + +- **How to drive it (as a reviewer):** on any open Claude-raised PR, leave a comment + (inline, a review summary, or a general comment) that **starts with the marker + `claude-review:`**. The text after the marker is the instruction, e.g. + `claude-review: null-check order.vendor before dereferencing it, and add a test`. +- **Each run (every 10 min via its own cron entry):** it scans **all** open + Claude-raised PRs, collects every `claude-review:` comment **from repo + collaborators only**, skips ones it has already handled (it stamps an + `` acknowledgement), checks out the **PR's own + branch** in its dedicated clone, runs headless Claude to implement the changes, and + pushes the result back onto the PR branch. +- **Isolation:** own clone (`~/pelagia-pr-review`), own config + lock, separate from + both the deployed `~/pms` and the issue watcher's `~/pelagia-autofix`, so the two + watchers can't race. Sensitive changes (migrations, payments, permissions) are left + uncommitted for a human; the bot posts back why and waits for a follow-up + `claude-review:` instruction. A one-command updater redeploys the script + config + from the repo onto pms1. + See [Deployment and Operations](Deployment-and-Operations) for the deploy workflow and staging, and `automation/README.md` for the authoritative runbook. diff --git a/Pages-and-Navigation.md b/Pages-and-Navigation.md index 843848a..e71a824 100644 --- a/Pages-and-Navigation.md +++ b/Pages-and-Navigation.md @@ -48,7 +48,7 @@ SuperUser Requests /admin/superuser-requests ← ADMIN | `/approvals/[id]` | Approval Detail | Approve / Approve+Note / Reject / Request Edits / Request Vendor ID; inline line-item edit | | `/payments` | Payment Queue | MGR_APPROVED & SENT_FOR_PAYMENT cards; send/mark paid; partial | | `/payments/history` | Payment History | Completed payments (ACCOUNTS, MANAGER) | -| `/history` | History & Export | All POs; filter by date/cost centre/multiple statuses; CSV/PDF. `export_reports` holders, plus submitters when the `SUBMITTER_VIEW_ALL` flag is on | +| `/history` | History & Export | All POs; filter by created-date / **approved-date** / cost centre / **accounting code** / multiple statuses; CSV/PDF. `export_reports` holders, plus submitters when the `SUBMITTER_VIEW_ALL` flag is on. The accounting-code filter and approved-date window back the report → PO drill-down (see [Reports](Reports#drill-down-to-pos)) | | `/reports/cost-centres` | Reports → Cost Centres | Approved spend compared across cost centres (vessels); drill to a cost-centre report. `view_analytics` | | `/reports/accounting-codes` | Reports → Accounting Codes | Approved spend by the accounting-code tree (drill headings → sub → leaf); leaf opens its report. `view_analytics` | | `/inventory/items` | Items (read-only) | Catalogue; expand for per-vendor prices; Cheapest/★Closest tags | diff --git a/Purchase-Orders.md b/Purchase-Orders.md index 23eb388..a87dc03 100644 --- a/Purchase-Orders.md +++ b/Purchase-Orders.md @@ -117,6 +117,29 @@ brand-colour bar (`#92D050`) runs full-width along the bottom. Each piece is optional except the bar, which is always drawn. See [File Storage](File-Storage#where-files-attach). +## PO History & Export + +`/history` (**History & Export**, gated by `export_reports` — see +[Roles and Permissions](Roles-and-Permissions)) lists **every** PO with a filter +panel and a CSV / PDF export of the filtered set. Filters: + +- **Created-date** range (`dateFrom` / `dateTo`, on `createdAt`). +- **Approved-date** range (`approvedFrom` / `approvedTo`, on `approvedAt`) — the + window the [Reports](Reports#drill-down-to-pos) drill-down uses, since spend is + dated by approval. +- **Cost Centre** (`vesselId`). +- **Accounting Code** (`accountId`) — accepts **any** node of the 3-level account + tree (Heading / Sub-heading / Leaf), not just leaves. It expands to the leaf codes + beneath (`accountLeafIds`) and matches a PO whose **PO-level `accountId` _or_ any + line-item `accountId`** is in that set — the same allocation basis as the spend + reports, so a report figure and its “View POs” list reconcile. +- **Status** (multi-select). + +The page list **and** the CSV/PDF export route share a single +**`buildPoHistoryWhere()`** builder (`lib/history-filter.ts`), so the on-screen +results and the exported file can never diverge. All filters are URL query params, +so a filtered view (including a report drill-down link) is bookmarkable. + ## Import PO → CLOSED `/po/import` parses a Pelagia-format Excel PO (`lib/po-import-parser.ts`, diff --git a/Reports.md b/Reports.md index 94ebcd3..8d543e8 100644 --- a/Reports.md +++ b/Reports.md @@ -55,6 +55,33 @@ Charts use **recharts**; the comparison chart draws **one colour per item** (cos centre / accounting code) in every granularity, including the yearly grouped-bars view. KPI tiles, tables and breadcrumbs are server-rendered. +## Drill-down to POs + +Every **detail** page (cost-centre and accounting-code) carries a **“View POs · _period_”** +link that opens **PO History** (`/history`) pre-filtered to that dimension and the +period currently in view — closing the loop from an aggregate number back to the +underlying purchase orders. + +- **Cost-centre detail** links to `/history?vesselId=&approvedFrom=…&approvedTo=…`. +- **Accounting-code detail** links to `/history?accountId=&approvedFrom=…&approvedTo=…`. + +Because spend is dated by **`approvedAt`** (not `createdAt`), the link filters PO +History by its **approved-date** window, not the created-date one. +**`periodRange(gran, fy, month, fys)`** (`lib/reports.ts`) maps the on-screen period +onto that window so the two always agree: + +| Granularity | Approved-date window | +|---|---| +| Weekly | the focused FY **month** (calendar `from`/`to` for that month) | +| Monthly | the selected **financial year** (Apr 1 → Mar 31) | +| Yearly | the full span of FYs in view (first FY's Apr 1 → last FY's Mar 31) | + +On the History side, the **accounting-code filter** expands any account-tree node to +its leaf codes (`accountLeafIds`) and matches a PO whose **PO-level account _or_ any +line-item account** falls under it — the same attribution basis the reports use, so +the PO list reconciles with the report total. See +[Purchase Orders → PO History & Export](Purchase-Orders#po-history--export). + ## Export The toolbar **Export** links to `/api/reports/spend?dim=…` — a CSV mirroring the