shad0w/pelagia-portal

Fork 0

[Issue]: Allow manager to decide payment type for PO #92

New issue

Closed

opened 2026-06-23 06:26:21 +00:00 by shad0w · 1 comment

shad0w commented

2026-06-23 06:26:21 +00:00

Owner

Raised by

Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button

Description

The payment type - complete or partial should be decided upon by the manager approving the PO. There should be below slider when you click approve -

Slider for advance payment - 0 to 100% (Full PO value). By default at 100%.

This data must get added to PO and be visible to accounts once PO is sent for payment

Priority

P2 — Medium

Context

Page: /dashboard
Reported at: 2026-06-23T06:26:21.417Z

### Raised by Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button ### Description The payment type - complete or partial should be decided upon by the manager approving the PO. There should be below slider when you click approve - Slider for advance payment - 0 to 100% (Full PO value). By default at 100%. This data must get added to PO and be visible to accounts once PO is sent for payment ### Priority P2 — Medium ### Context - Page: `/dashboard` - Reported at: 2026-06-23T06:26:21.417Z

shad0w added the

portal

label 2026-06-23 06:26:21 +00:00

shad0w added the

feature

interactive

triaged

labels 2026-06-23 06:31:32 +00:00

shad0w commented

2026-06-23 06:31:32 +00:00

Author

Owner

Claude triage

Triage — Issue #92: Allow manager to decide payment type (advance %) for PO

Type: Feature (new capability layered onto the existing manager-approval flow)
Routing: interactive
Priority: P2

What's being asked

When a Manager approves a PO, they should be able to set how much of the PO value is to
be paid as an advance — a slider from 0% to 100% of the full PO value, defaulting
to 100% ("complete" vs "partial" payment). This decision must be:

Captured at approval time (a slider that appears when the manager clicks Approve).
Stored on the PO.
Surfaced to Accounts once the PO is sent for payment.

Action items

Data model (DB migration) — add a field to PurchaseOrder to hold the manager's
advance decision, e.g. advancePaymentPercent Decimal @db.Decimal(5,2) @default(100)
(or an absolute advanceAmount). New column ⇒ Prisma schema change + migration +
prisma generate. Touches prisma/schema.prisma, prisma/migrations/.
Approval UI — add the 0–100% slider (default 100) to the approve flow in
app/(portal)/approvals/[id]/approval-actions.tsx. Currently dispatch("approve")
fires immediately with no intermediate panel, so the "show slider on Approve click"
interaction needs a two-step confirm (like the existing reject / request-edits pattern)
or an always-visible slider above the Approve button.
Approve server action — approvePo() in app/(portal)/approvals/[id]/actions.ts
must accept and persist the advance value, ideally validated via a new/extended Zod
schema in lib/validations/po.ts. Record it on the POAction audit row (APPROVED).
Accounts visibility — show the advance %/amount in the payment queue
(app/(portal)/payments/page.tsx) and PO detail (components/po/po-detail.tsx), so
Accounts sees the intended advance when the PO reaches SENT_FOR_PAYMENT. Decide
whether the exported PO/invoice (lib/po-export-layout.ts) should also reflect it.
Decimal→Client boundary — per CLAUDE.md, convert the Decimal with Number() in the
Server Component before passing into any Client Component (slider / display).

Files / areas involved

prisma/schema.prisma + new migration (prisma/migrations/) — schema change
app/(portal)/approvals/[id]/approval-actions.tsx — slider UI (client)
app/(portal)/approvals/[id]/actions.ts — approvePo() persist + audit
lib/validations/po.ts — validate 0–100 range
app/(portal)/payments/page.tsx, app/(portal)/payments/actions.ts — Accounts surface
components/po/po-detail.tsx, possibly lib/po-export-layout.ts — display
Tests: tests/integration/ (approve flow), tests/unit/ (slider component)

Open questions (need human / business steering)

Relationship to the existing partial-payment flow. Accounts already drives partial
payments today: markPaid() accepts a paymentAmount, and the state machine has
PARTIALLY_PAID / mark_partial_payment. Is the manager's advance % meant to cap /
pre-fill the first Accounts payment, just be advisory, or drive an automatic split?
This determines whether markPaid / payment-actions.tsx logic must change too.
Percent vs absolute amount, and rounding rules against totalAmount (Decimal(12,2)).
Where does the remaining balance go? If advance < 100%, what status/flow handles the
balance — does it still funnel through the normal PARTIALLY_PAID loop?
Should the advance be editable after approval, or locked once set?
Should it appear on the exported PO / invoice document?
Backfill / default for the prod-mirror's existing POs (default 100% seems safe).

Why interactive (not claude-queue)

This is explicitly disqualified on multiple counts: it requires a DB schema migration,
it is a payments/money change, and it carries genuine business-logic ambiguity
(how the manager's advance interacts with the existing Accounts-driven partial-payment
state machine) plus a UI interaction design decision (how/when the slider appears) that
needs visual verification. An unattended run could not safely resolve these without human
steering.

Routing rationale: New payments-related capability requiring a DB migration, money logic, and unresolved business/UX decisions about how the advance interacts with the existing partial-payment flow — needs human steering, so interactive.

Routing: interactive | Type: feature

## Claude triage # Triage — Issue #92: Allow manager to decide payment type (advance %) for PO **Type:** Feature (new capability layered onto the existing manager-approval flow) **Routing:** interactive **Priority:** P2 ## What's being asked When a Manager approves a PO, they should be able to set how much of the PO value is to be paid as an **advance** — a slider from **0% to 100%** of the full PO value, defaulting to **100%** ("complete" vs "partial" payment). This decision must be: 1. Captured at approval time (a slider that appears when the manager clicks **Approve**). 2. Stored on the PO. 3. Surfaced to **Accounts** once the PO is sent for payment. ## Action items 1. **Data model (DB migration)** — add a field to `PurchaseOrder` to hold the manager's advance decision, e.g. `advancePaymentPercent Decimal @db.Decimal(5,2) @default(100)` (or an absolute `advanceAmount`). New column ⇒ Prisma schema change + migration + `prisma generate`. Touches `prisma/schema.prisma`, `prisma/migrations/`. 2. **Approval UI** — add the 0–100% slider (default 100) to the approve flow in `app/(portal)/approvals/[id]/approval-actions.tsx`. Currently `dispatch("approve")` fires immediately with no intermediate panel, so the "show slider on Approve click" interaction needs a two-step confirm (like the existing reject / request-edits pattern) or an always-visible slider above the Approve button. 3. **Approve server action** — `approvePo()` in `app/(portal)/approvals/[id]/actions.ts` must accept and persist the advance value, ideally validated via a new/extended Zod schema in `lib/validations/po.ts`. Record it on the `POAction` audit row (`APPROVED`). 4. **Accounts visibility** — show the advance %/amount in the payment queue (`app/(portal)/payments/page.tsx`) and PO detail (`components/po/po-detail.tsx`), so Accounts sees the intended advance when the PO reaches `SENT_FOR_PAYMENT`. Decide whether the exported PO/invoice (`lib/po-export-layout.ts`) should also reflect it. 5. **Decimal→Client boundary** — per CLAUDE.md, convert the Decimal with `Number()` in the Server Component before passing into any Client Component (slider / display). ## Files / areas involved - `prisma/schema.prisma` + new migration (`prisma/migrations/`) — **schema change** - `app/(portal)/approvals/[id]/approval-actions.tsx` — slider UI (client) - `app/(portal)/approvals/[id]/actions.ts` — `approvePo()` persist + audit - `lib/validations/po.ts` — validate 0–100 range - `app/(portal)/payments/page.tsx`, `app/(portal)/payments/actions.ts` — Accounts surface - `components/po/po-detail.tsx`, possibly `lib/po-export-layout.ts` — display - Tests: `tests/integration/` (approve flow), `tests/unit/` (slider component) ## Open questions (need human / business steering) - **Relationship to the existing partial-payment flow.** Accounts already drives partial payments today: `markPaid()` accepts a `paymentAmount`, and the state machine has `PARTIALLY_PAID` / `mark_partial_payment`. Is the manager's advance % meant to *cap* / *pre-fill* the first Accounts payment, just be advisory, or drive an automatic split? This determines whether `markPaid` / `payment-actions.tsx` logic must change too. - **Percent vs absolute amount**, and rounding rules against `totalAmount` (Decimal(12,2)). - **Where does the remaining balance go?** If advance < 100%, what status/flow handles the balance — does it still funnel through the normal `PARTIALLY_PAID` loop? - Should the advance be **editable** after approval, or locked once set? - Should it appear on the **exported PO / invoice** document? - Backfill / default for the prod-mirror's existing POs (default 100% seems safe). ## Why interactive (not claude-queue) This is explicitly disqualified on multiple counts: it **requires a DB schema migration**, it is a **payments/money** change, and it carries genuine **business-logic ambiguity** (how the manager's advance interacts with the existing Accounts-driven partial-payment state machine) plus a **UI interaction design decision** (how/when the slider appears) that needs visual verification. An unattended run could not safely resolve these without human steering. Routing rationale: New payments-related capability requiring a DB migration, money logic, and unresolved business/UX decisions about how the advance interacts with the existing partial-payment flow — needs human steering, so interactive. **Routing:** `interactive` | **Type:** `feature`

shad0w referenced this issue from a commit

2026-06-23 20:10:27 +00:00

feat(po): manager sets advance payment on approval (issue #92)

shad0w referenced this issue from a pull request that will close it,

2026-06-23 20:10:43 +00:00

feat(po): manager sets advance payment on approval (#92) #99

shad0w closed this issue

2026-06-23 20:26:28 +00:00

shad0w referenced this issue from a commit

2026-06-23 20:26:29 +00:00

Merge pull request 'feat(po): manager sets advance payment on approval (#92)' (#99) from feat/manager-advance-payment into master

shad0w referenced this issue from a commit