[Issue]: Need separate button for Payment #91

New issue

Open

opened 2026-06-23 01:18:31 +00:00 by shad0w · 1 comment

shad0w commented

2026-06-23 01:18:31 +00:00

Owner

Raised by

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

Description

Need separate button to initiate Payment Request.
It should be done together with submission.
Separate approval for payment is required by the Manager.
Payment can be: PART or FULL / ADVANCE / UPON RECEIVING INVOICE / AFTER DELIVERY / 30 DAYS AFTER INVOICE. ALSO PROVISION TO MENTION EXACT SUM DUE FOR PAYMENT TO BE GIVEN

Priority

P1 — High

Context

Page: /dashboard
Reported at: 2026-06-23T01:18:31.572Z

### Raised by Kaushal Pal Singh (kps@pelagiamarine.com, MANAGER) — via portal Report Issue button ### Description Need separate button to initiate Payment Request. It should be done together with submission. Separate approval for payment is required by the Manager. Payment can be: PART or FULL / ADVANCE / UPON RECEIVING INVOICE / AFTER DELIVERY / 30 DAYS AFTER INVOICE. ALSO PROVISION TO MENTION EXACT SUM DUE FOR PAYMENT TO BE GIVEN ### Priority P1 — High ### Context - Page: `/dashboard` - Reported at: 2026-06-23T01:18:31.572Z

shad0w added the

portal

label 2026-06-23 01:18:31 +00:00

shad0w added the

feature

interactive

triaged

labels 2026-06-23 01:22:45 +00:00

shad0w commented

2026-06-23 01:22:45 +00:00

Author

Owner

Claude triage

Triage — Issue #91: Need separate button for Payment

Raised by: Kaushal Pal Singh (MANAGER) · Priority: P1 — High · Page: /dashboard

Interpretation

The reporter (a Manager) wants the payment side of a PO to become its own
explicitly-initiated, separately-approved workflow, distinct from the existing PO
approval. Reading the request literally:

A separate "Payment Request" button to initiate a payment request.
The payment request is raised together with PO submission (i.e. at submit time the
submitter also lodges the payment ask).
The payment request needs a separate Manager approval — distinct from the existing
PO/approve_po step.
The request must carry a payment type/term, one of:
PART or FULL / ADVANCE / UPON RECEIVING INVOICE / AFTER DELIVERY /
30 DAYS AFTER INVOICE.
A field to state the exact sum due for payment (which may differ from the PO total —
e.g. a part/advance amount).

This is effectively a new approval lane parallel to the PO lifecycle, not a cosmetic
button. Several requirements conflict / are underspecified (see Open Questions).

Current state (what exists today)

Submission: app/(portal)/po/new/new-po-form.tsx (Save as Draft / Submit for
Approval buttons) → app/(portal)/po/new/actions.ts createPo. Submit creates the PO
then moves it SUBMITTED → MGR_REVIEW. No payment concept at submit time.
State machine: lib/po-state-machine.ts. Payment-relevant transitions:
MGR_APPROVED → SENT_FOR_PAYMENT (process_payment, ACCOUNTS/SUPERUSER) and
SENT_FOR_PAYMENT → PAID_DELIVERED | PARTIALLY_PAID (mark_paid/mark_partial_payment).
There is no separate Manager approval of the payment — Accounts initiates payment
directly after PO approval.
Payment recording: app/(portal)/payments/payment-actions.tsx +
app/(portal)/payments/actions.ts (processPayment, markPaid). Fields on
PurchaseOrder (prisma/schema.prisma): paymentRef, paymentDate, paidAmount.
paidAmount already supports partial settlement.
Payment terms: only free-text tcPaymentTerms (T&C), default "Within 30 days from
delivery." No structured enum for ADVANCE / UPON INVOICE / AFTER DELIVERY / etc.
Permissions: lib/permissions.ts — approve_po (MANAGER/SUPERUSER),
process_payment (ACCOUNTS/SUPERUSER/MANAGER). No request_payment /
approve_payment_request.
Dashboard: app/(portal)/dashboard/page.tsx — role-specific stat cards/links only;
no payment-request button.

Action items (developer breakdown)

Schema migration (prisma/schema.prisma + new migration):
- New enum for payment term/type (PART/FULL, ADVANCE, UPON_INVOICE, AFTER_DELIVERY,
  NET_30_AFTER_INVOICE).
- New fields on PurchaseOrder: payment term type, requested/exact sum due, payment
  request status + requested/approved timestamps + approver.
- (Possibly a dedicated PaymentRequest model if multiple requests per PO are intended.)
State machine (lib/po-state-machine.ts): add a payment-request-approval state /
transitions (e.g. PAYMENT_REQUESTED → PAYMENT_APPROVED) plus required roles, and wire
into the existing flow without breaking current transitions + POAction audit trail.
Permissions (lib/permissions.ts): add request_payment /
approve_payment_request and assign to roles.
Submit flow (new-po-form.tsx, actions.ts, lib/validations/po.ts): add the
"Payment Request" button + payment type select + exact-sum input, with Zod validation.
Manager approval UI: payment-request approval surface (likely /approvals and/or
PO detail components/po/po-detail.tsx), plus server actions.
Dashboard (dashboard/page.tsx): Manager payment-request queue / button.
Notifications (lib/notifier.ts) and audit trail updates for the new steps.
Tests: unit + integration for the new validation, transitions, and permissions.

Open questions (need human/business decision)

"Done together with submission" vs "separate approval by Manager" — is the payment
request raised at submit by the submitter, then approved by the Manager? Or is it a
fully separate button raised later? The two sentences pull in different directions.
Is the separate payment approval in addition to today's PO approval, or does it
replace the Accounts-initiated process_payment step?
"PART or FULL" — is this a recurring/looping part-payment workflow (multiple requests per
PO, like the existing PARTIALLY_PAID loop) or a single choice at request time?
Exact data model for payment terms (single enum field vs structured schedule, e.g.
"30 days after invoice" implying a computed due date).
Which roles may raise vs approve the payment request, and where the button lives
(dashboard, PO detail, submit form, or a new Payments screen).

Routing rationale

Routing rationale: interactive — this is a large, multi-file P1 feature that is
underspecified/ambiguous and squarely touches the excluded areas (a DB migration, the PO
state machine, role permissions, and payments/money), so it needs human steering and
business/design decisions rather than an unattended run.

Routing: interactive | Type: feature

## Claude triage # Triage — Issue #91: Need separate button for Payment **Raised by:** Kaushal Pal Singh (MANAGER) · **Priority:** P1 — High · **Page:** `/dashboard` ## Interpretation The reporter (a Manager) wants the **payment side of a PO to become its own explicitly-initiated, separately-approved workflow**, distinct from the existing PO approval. Reading the request literally: 1. A **separate "Payment Request" button** to initiate a payment request. 2. The payment request **is raised together with PO submission** (i.e. at submit time the submitter also lodges the payment ask). 3. The payment request needs a **separate Manager approval** — distinct from the existing PO/`approve_po` step. 4. The request must carry a **payment type/term**, one of: `PART` or `FULL` / `ADVANCE` / `UPON RECEIVING INVOICE` / `AFTER DELIVERY` / `30 DAYS AFTER INVOICE`. 5. A field to **state the exact sum due for payment** (which may differ from the PO total — e.g. a part/advance amount). This is effectively a **new approval lane parallel to the PO lifecycle**, not a cosmetic button. Several requirements conflict / are underspecified (see Open Questions). ## Current state (what exists today) - **Submission:** `app/(portal)/po/new/new-po-form.tsx` (Save as Draft / Submit for Approval buttons) → `app/(portal)/po/new/actions.ts` `createPo`. Submit creates the PO then moves it `SUBMITTED → MGR_REVIEW`. No payment concept at submit time. - **State machine:** `lib/po-state-machine.ts`. Payment-relevant transitions: `MGR_APPROVED → SENT_FOR_PAYMENT` (`process_payment`, ACCOUNTS/SUPERUSER) and `SENT_FOR_PAYMENT → PAID_DELIVERED | PARTIALLY_PAID` (`mark_paid`/`mark_partial_payment`). There is **no separate Manager approval of the payment** — Accounts initiates payment directly after PO approval. - **Payment recording:** `app/(portal)/payments/payment-actions.tsx` + `app/(portal)/payments/actions.ts` (`processPayment`, `markPaid`). Fields on `PurchaseOrder` (`prisma/schema.prisma`): `paymentRef`, `paymentDate`, `paidAmount`. `paidAmount` already supports partial settlement. - **Payment terms:** only free-text `tcPaymentTerms` (T&C), default "Within 30 days from delivery." No structured enum for ADVANCE / UPON INVOICE / AFTER DELIVERY / etc. - **Permissions:** `lib/permissions.ts` — `approve_po` (MANAGER/SUPERUSER), `process_payment` (ACCOUNTS/SUPERUSER/MANAGER). No `request_payment` / `approve_payment_request`. - **Dashboard:** `app/(portal)/dashboard/page.tsx` — role-specific stat cards/links only; no payment-request button. ## Action items (developer breakdown) 1. **Schema migration** (`prisma/schema.prisma` + new migration): - New enum for payment term/type (PART/FULL, ADVANCE, UPON_INVOICE, AFTER_DELIVERY, NET_30_AFTER_INVOICE). - New fields on `PurchaseOrder`: payment term type, requested/exact sum due, payment request status + requested/approved timestamps + approver. - (Possibly a dedicated `PaymentRequest` model if multiple requests per PO are intended.) 2. **State machine** (`lib/po-state-machine.ts`): add a payment-request-approval state / transitions (e.g. `PAYMENT_REQUESTED → PAYMENT_APPROVED`) plus required roles, and wire into the existing flow without breaking current transitions + `POAction` audit trail. 3. **Permissions** (`lib/permissions.ts`): add `request_payment` / `approve_payment_request` and assign to roles. 4. **Submit flow** (`new-po-form.tsx`, `actions.ts`, `lib/validations/po.ts`): add the "Payment Request" button + payment type select + exact-sum input, with Zod validation. 5. **Manager approval UI**: payment-request approval surface (likely `/approvals` and/or PO detail `components/po/po-detail.tsx`), plus server actions. 6. **Dashboard** (`dashboard/page.tsx`): Manager payment-request queue / button. 7. **Notifications** (`lib/notifier.ts`) and **audit trail** updates for the new steps. 8. **Tests:** unit + integration for the new validation, transitions, and permissions. ## Open questions (need human/business decision) - "Done together with submission" vs "separate approval by Manager" — is the payment request raised at submit by the submitter, then approved by the Manager? Or is it a fully separate button raised later? The two sentences pull in different directions. - Is the separate payment approval **in addition to** today's PO approval, or does it replace the Accounts-initiated `process_payment` step? - "PART or FULL" — is this a recurring/looping part-payment workflow (multiple requests per PO, like the existing `PARTIALLY_PAID` loop) or a single choice at request time? - Exact data model for payment terms (single enum field vs structured schedule, e.g. "30 days after invoice" implying a computed due date). - Which roles may **raise** vs **approve** the payment request, and where the button lives (dashboard, PO detail, submit form, or a new Payments screen). ## Routing rationale Routing rationale: **interactive** — this is a large, multi-file P1 feature that is underspecified/ambiguous and squarely touches the excluded areas (a DB migration, the PO state machine, role permissions, and payments/money), so it needs human steering and business/design decisions rather than an unattended run. **Routing:** `interactive` | **Type:** `feature`

shad0w referenced this issue from a commit

2026-06-23 20:15:59 +00:00

docs(schema): note suggestedAdvancePayment is the reuse point for issue #91