shad0w/pelagia-portal

Fork 0

[Issue]: Not able to see submitters PO #133

New issue

Closed

opened 2026-06-25 10:06:13 +00:00 by shad0w · 1 comment

shad0w commented

2026-06-25 10:06:13 +00:00

Owner

Raised by

Supriya Sutar (Pelagia) (supriya.s@pelagiamarine.com, TECHNICAL) — via portal Report Issue button

Description

Pls add PO summary in dashboard so we can track who issued the PO.
2.Add TCS & Discount below GST.

Priority

P2 — Medium

Context

Page: /po/cmqtb4z8m00mouxaw96r0z0nx
Reported at: 2026-06-25T10:06:13.804Z

### Raised by Supriya Sutar (Pelagia) (supriya.s@pelagiamarine.com, TECHNICAL) — via portal Report Issue button ### Description 1. Pls add PO summary in dashboard so we can track who issued the PO. 2.Add TCS & Discount below GST. ### Priority P2 — Medium ### Context - Page: `/po/cmqtb4z8m00mouxaw96r0z0nx` - Reported at: 2026-06-25T10:06:13.804Z

shad0w added the

portal

label 2026-06-25 10:06:13 +00:00

shad0w added the

feature

interactive

triaged

labels 2026-06-25 10:11:36 +00:00

shad0w commented

2026-06-25 10:11:36 +00:00

Author

Owner

Claude triage

Triage — Issue #133: "Not able to see submitters PO"

Type: Feature (two bundled enhancements) · Priority: P2 · Reporter: Supriya Sutar (TECHNICAL)

The title and body don't describe anything broken. The reporter asks for two new capabilities, so this is a feature request, not a bug. It actually bundles two unrelated asks, both touching sensitive areas.

Request 1 — "Add PO summary in dashboard so we can track who issued the PO"

Wants a dashboard view that surfaces who submitted/issued each PO (the submitter).

What exists today

app/(portal)/dashboard/page.tsx renders role-specific dashboards:
- SubmitterDashboard (TECHNICAL/MANNING/SUPERUSER) — only shows the current user's own POs (where: { submitterId: userId }). For these users "who issued" is always themselves, so a submitter column here is meaningless — the request only makes sense as a cross-submitter view.
- ManagerDashboard — "Recent Approved Orders" table (PO / Title / Cost Centre / Status / Amount / Approved). No submitter column.
- AccountsDashboard / GenericDashboard — stat cards only.
PurchaseOrder.submitter relation (submitterId → User, named relation "Submitter") already exists (prisma/schema.prisma:601), so the data is available without a migration.

Likely action items

Add a "Submitted by" / "Issued by" column (join submitter: { select: { name: true } }) to the relevant dashboard table(s), and/or a small "PO summary" grouping of recent POs by submitter.

Open questions (block an unattended run)

Which dashboard / which role should gain this? The reporter is TECHNICAL — whose own dashboard is self-scoped, so satisfying her implies showing other people's POs. That is a scope/permissions decision (cf. the NEXT_PUBLIC_SUBMITTER_VIEW_ALL_ENABLED flag that gates submitters reading all POs). Showing all submitters' POs to a TECHNICAL user by default could leak data and likely needs gating.
What does "PO summary" mean concretely — a new column on the existing recent-orders table, a per-submitter count/spend roll-up, or a new table/section? Underspecified; needs a design decision.

Request 2 — "Add TCS & Discount below GST"

Add TCS (Tax Collected at Source) and a Discount line to the PO totals breakdown, positioned below the GST line.

What exists today

Totals are computed in components/po/po-line-items-editor.tsx calcTotals() → { taxable, gst, grand }, rendered as Taxable subtotal → GST → Grand Total (both the read-only and editable variants; the "below GST" slot is here).
totalAmount = sum(qty × unitPrice × (1 + gstRate)) is recomputed server-side in the PO server actions (po/new/actions.ts, po/[id]/edit/actions.ts, po/import/actions.ts) and stored on PurchaseOrder.totalAmount (Decimal(12,2)).
No tcs/discount fields exist anywhere (schema, lib, components, validations all confirmed clean). GST lives only as a per-line POLineItem.gstRate.

Likely action items (wide blast radius)

Schema migration: add PO-level (and/or line-level) discount and tcs fields — rate and/or amount — to PurchaseOrder / POLineItem. db:migrate against pelagia_test.
Money recompute: change the totalAmount formula in every server action (new / edit / import) to apply discount and add TCS — a payments/money calculation change.
Validation: extend the Zod schemas in lib/validations/po.ts.
UI: new inputs + new total rows below GST in po-line-items-editor.tsx; display in po-detail.tsx.
Export: update the PDF/XLSX export (app/api/po/[id]/export/) invoice/totals block.

Open questions

Is TCS a percentage or a fixed amount, and on what base (taxable, or taxable+GST)? Is Discount a % or absolute, pre- or post-GST? These change the money formula materially and aren't specified.
PO-level vs per-line-item? Effect on historical/imported POs (nullable, default 0).

Files / areas involved

app/(portal)/dashboard/page.tsx, components/dashboard/* (Request 1)
prisma/schema.prisma + a new migration (Request 2)
components/po/po-line-items-editor.tsx, components/po/po-detail.tsx (Request 2 UI)
app/(portal)/po/new/actions.ts, po/[id]/edit/actions.ts, po/import/actions.ts (totalAmount recompute)
lib/validations/po.ts (Zod), app/api/po/[id]/export/ (PDF/XLSX)

Why not claude-queue

Request 2 requires a DB migration and changes the money/total calculation across multiple server actions and the export — explicitly out of bounds for an unattended run — and the tax/discount semantics are undefined. Request 1 needs a scope/permissions + design decision about which roles see whose POs. Both legs need human steering.

Routing rationale: Two-part feature request whose totals leg needs a schema migration plus a money-calculation change with undefined tax semantics, and whose dashboard leg needs a permissions/scope design decision — route to interactive.

Routing: interactive | Type: feature

## Claude triage # Triage — Issue #133: "Not able to see submitters PO" **Type:** Feature (two bundled enhancements) · **Priority:** P2 · **Reporter:** Supriya Sutar (TECHNICAL) The title and body don't describe anything broken. The reporter asks for two *new* capabilities, so this is a feature request, not a bug. It actually bundles **two unrelated asks**, both touching sensitive areas. --- ## Request 1 — "Add PO summary in dashboard so we can track who issued the PO" Wants a dashboard view that surfaces **who submitted/issued each PO** (the submitter). ### What exists today - `app/(portal)/dashboard/page.tsx` renders **role-specific** dashboards: - `SubmitterDashboard` (TECHNICAL/MANNING/SUPERUSER) — only shows the **current user's own** POs (`where: { submitterId: userId }`). For these users "who issued" is always themselves, so a submitter column here is meaningless — the request only makes sense as a **cross-submitter view**. - `ManagerDashboard` — "Recent Approved Orders" table (PO / Title / Cost Centre / Status / Amount / Approved). No submitter column. - `AccountsDashboard` / `GenericDashboard` — stat cards only. - `PurchaseOrder.submitter` relation (`submitterId` → `User`, named relation `"Submitter"`) already exists (`prisma/schema.prisma:601`), so the data is available without a migration. ### Likely action items - Add a **"Submitted by" / "Issued by"** column (join `submitter: { select: { name: true } }`) to the relevant dashboard table(s), and/or a small "PO summary" grouping of recent POs by submitter. ### Open questions (block an unattended run) - **Which dashboard / which role** should gain this? The reporter is TECHNICAL — whose own dashboard is self-scoped, so satisfying her implies showing **other people's** POs. That is a **scope/permissions decision** (cf. the `NEXT_PUBLIC_SUBMITTER_VIEW_ALL_ENABLED` flag that gates submitters reading all POs). Showing all submitters' POs to a TECHNICAL user by default could leak data and likely needs gating. - What does "PO summary" mean concretely — a new column on the existing recent-orders table, a per-submitter count/spend roll-up, or a new table/section? Underspecified; needs a design decision. --- ## Request 2 — "Add TCS & Discount below GST" Add **TCS** (Tax Collected at Source) and a **Discount** line to the PO totals breakdown, positioned **below the GST** line. ### What exists today - Totals are computed in `components/po/po-line-items-editor.tsx` `calcTotals()` → `{ taxable, gst, grand }`, rendered as **Taxable subtotal → GST → Grand Total** (both the read-only and editable variants; the "below GST" slot is here). - `totalAmount = sum(qty × unitPrice × (1 + gstRate))` is recomputed server-side in the PO server actions (`po/new/actions.ts`, `po/[id]/edit/actions.ts`, `po/import/actions.ts`) and stored on `PurchaseOrder.totalAmount` (`Decimal(12,2)`). - **No `tcs`/`discount` fields exist anywhere** (schema, lib, components, validations all confirmed clean). GST lives only as a per-line `POLineItem.gstRate`. ### Likely action items (wide blast radius) - **Schema migration**: add PO-level (and/or line-level) `discount` and `tcs` fields — rate and/or amount — to `PurchaseOrder` / `POLineItem`. `db:migrate` against `pelagia_test`. - **Money recompute**: change the `totalAmount` formula in **every** server action (new / edit / import) to apply discount and add TCS — a payments/money calculation change. - **Validation**: extend the Zod schemas in `lib/validations/po.ts`. - **UI**: new inputs + new total rows below GST in `po-line-items-editor.tsx`; display in `po-detail.tsx`. - **Export**: update the PDF/XLSX export (`app/api/po/[id]/export/`) invoice/totals block. ### Open questions - Is **TCS a percentage or a fixed amount**, and on what base (taxable, or taxable+GST)? Is **Discount** a % or absolute, pre- or post-GST? These change the money formula materially and aren't specified. - PO-level vs per-line-item? Effect on historical/imported POs (nullable, default 0). --- ## Files / areas involved - `app/(portal)/dashboard/page.tsx`, `components/dashboard/*` (Request 1) - `prisma/schema.prisma` + a **new migration** (Request 2) - `components/po/po-line-items-editor.tsx`, `components/po/po-detail.tsx` (Request 2 UI) - `app/(portal)/po/new/actions.ts`, `po/[id]/edit/actions.ts`, `po/import/actions.ts` (totalAmount recompute) - `lib/validations/po.ts` (Zod), `app/api/po/[id]/export/` (PDF/XLSX) ## Why not claude-queue Request 2 requires a **DB migration** and changes the **money/total calculation** across multiple server actions and the export — explicitly out of bounds for an unattended run — and the tax/discount semantics are undefined. Request 1 needs a **scope/permissions + design decision** about which roles see whose POs. Both legs need human steering. **Routing rationale:** Two-part feature request whose totals leg needs a schema migration plus a money-calculation change with undefined tax semantics, and whose dashboard leg needs a permissions/scope design decision — route to interactive. **Routing:** `interactive` | **Type:** `feature`

shad0w referenced this issue from a commit

2026-06-29 09:20:37 +00:00

feat(po): TCS & Discount below GST (#133)

shad0w referenced this issue

2026-06-29 09:20:52 +00:00

feat(po): TCS & Discount below GST (#133) #149

shad0w referenced this issue from a commit

2026-06-29 09:30:47 +00:00

Merge pull request 'feat(po): TCS & Discount below GST (#133)' (#149) from claude/issue-133-tcs-discount into master

shad0w closed this issue

2026-06-29 19:40:46 +00:00