# WP2 — Request payment scenarios (R4/R5/R6)

## Goal
One spec `e2e/specs/lis-request-payment.spec.ts` with 3 scenarios covering payment states, tagged `@lis @request @payment`. Payment is money-sensitive — assert amounts precisely.

## 📖 DOCUMENTATION STANDARD (owner mandate — every test case is a GUIDE)
Each `test(...)` MUST have:
1. A 2nd-arg `{ annotation: { type: "description", description: "..." } }` — a clear one-line Arabic-or-English description of WHAT this scenario proves and WHY.
2. Rich, human-readable `test.step("...")` for EVERY meaningful step — named so a non-dev reads the drill-down and understands the flow (e.g. `test.step("create an insurance request via API (contract + approval no.)")`, `test.step("assert the patient share and insurance share split correctly on the invoice")`). NOT `step 1`, `step 2`.
3. A JSDoc block above the test summarising the scenario in plain words (like the existing lis-result-review-flow.spec.ts header).
These steps + description are what render in the System Tests drill-down, so they ARE the living guide. Reuse helpers from e2e/helpers (auth: loginByApi/authHeaders/API_BASE/APP_BASE; lisSetup; uiSearch: fillSearchUntilVisible for flake). Write-isolated to company 8. Unique ids per run (testData helpers). API-setup + UI-assert where the value is.

## Scenarios (UI cashier where the value is)
- **R4 — full payment** `@payment`: create a request (API), then via the UI cashier pay the FULL amount → assert status becomes `paid` and the outstanding is 0 (UI + API).
- **R5 — partial payment**: pay LESS than the total via the cashier UI → assert status `partially_paid` and the remaining balance = total − paid (exact numbers in the step name + assertion).
- **R6 — deferred / unpaid**: create the request with no payment → assert it is unpaid/deferred and appears in receivables/outstanding.

## Notes
- Reuse `lisSetup` to create the request; drive the cashier screen (find it under /lab — inspect the payments/cashier component for selectors) for R4/R5. Assert money via UI AND API source-of-truth (`GET /lis/requests/{id}` or the invoice).
- Money is decimal(12,3). Compute expected remaining exactly. Name steps with the actual amounts (e.g. "pay 50 of 120 → assert remaining 70, status partially_paid").
- ⛔ Do NOT change any settings/accounts; only create+pay within company 8.

## Ids from WP0
Base investigation (3941) is enough for a priced request; use it. Env fallbacks.

## Acceptance
- [ ] 3 scenarios with description + named steps + JSDoc.
- [ ] R4 paid/outstanding-0, R5 partially_paid + exact remaining, R6 unpaid/deferred — all asserted (UI + API).
- [ ] `npx playwright test --grep "@payment"` green. ng build unaffected.

## Out of scope
Client types (WP1), tests/packages (WP3), lifecycle (WP4). No BE/settings changes.

## Flags
Money-sensitive (assertions on amounts/status) but NO money-logic change — tests only. Native review of the amount math. No migration.