# Validation Report: URS-021

**Title:** Warn users before submitting a duplicate Bill-Only order
**Date:** 2026-04-23T03:38:09.990Z
**Duration:** 50.5s
**Overall Status:** ✅ PASS

## User Requirement

> The system shall warn users before submitting a duplicate order.

*Source: `User_Requirement_Specifications_ZuriMED_DeviceFlow.xlsx` — the run below proves the system meets this requirement.*

## Environment

- **Inbox URL:** http://localhost:63274
- **Database:** localhost:63275/cc_repinbox_dev

## Setup

Status: ✅ PASS

## Test Steps

Each step below corresponds to one Playwright test that ran sequentially. Screenshots and video recordings provide visual evidence of the UI behaviour.

### 1. Step 1: Rep logs in and opens /billing/new — ✅ PASS

**What this step proves:**

Logs in as Bob Kauffman (StellarTech rep) and opens /billing/new. Because Bob's organization has exactly one manufacturer partner (ZuriMED), +page.server.ts auto-selects the manufacturer and advances initialFormData.step to 2, so the form lands directly on the "Surgery Details" step. No duplicate warning appears yet because the sales account and procedure date fields are still empty — the duplicate check input builder returns null until both are filled.

**Screenshots:**

![step 01 billing new step2](screenshots/step-01-billing-new-step2.png)

**Video recording:**

[▶ Watch step recording](videos/step-01-login.webm)

---

### 2. Step 2: Duplicate warning appears — ✅ PASS

**What this step proves:**

Selects BOSS Surgical Account Request and enters procedure date 2026-04-09 — the same (sales_account_id, procedure_date) pair used by the existing ZBO-2025-002 (status=submitted). The checkDuplicateBillingOrders remote query returns ZBO-2025-002, DuplicateCheckState.blocked flips to true, and DuplicateOrderWarning.svelte renders the amber "Possible Duplicate Submission" alert listing the existing order with a View affordance, an acknowledge button ("This is not a duplicate — continue"), and an "Exit and review existing submissions" link. The NavigationFooter's Next button is disabled because manager.stepBlocked propagates from DuplicateCheckState.blocked.

**Screenshots:**

![step 02 warning visible](screenshots/step-02-warning-visible.png)

**Video recording:**

[▶ Watch step recording](videos/step-02-warning-appears.webm)

---

### 3. Step 3: Exit returns user to /billing — ✅ PASS

**What this step proves:**

Re-triggers the warning, then clicks the "Exit and review existing submissions" link — an <a href="/billing"> that leaves the wizard without submitting anything. The user lands on /billing. validate-db.ts independently confirms that no new billing_orders row was persisted during the run, proving the cancel path is non-destructive.

**Screenshots:**

![step 03 billing list after exit](screenshots/step-03-billing-list-after-exit.png)

**Video recording:**

[▶ Watch step recording](videos/step-03-exit-and-review.webm)

---

### 4. Step 4: Warning acknowledged, Next enabled — ✅ PASS

**What this step proves:**

Re-triggers the warning, then clicks "This is not a duplicate — continue". The DuplicateCheckState.acknowledge() method sets confirmedNotDuplicate=true, which flips DuplicateCheckState.blocked to false. The alert transitions to its green "Reviewed — Not a Duplicate" state with an Undo button, and the Next button becomes enabled — proving the form is unblocked and the rep can proceed through the remaining wizard steps.

**Screenshots:**

![step 04 acknowledged state](screenshots/step-04-acknowledged-state.png)

**Video recording:**

[▶ Watch step recording](videos/step-04-acknowledge.webm)

---

## Database Validations

The following SQL queries ran against the application database after the Playwright scenarios completed. Each query asserts a specific condition that proves the feature under test persisted its data correctly.

### ZBO-2025-002 still matches the duplicate-check criteria after the run — ✅ PASS

**Assertion:** ZBO-2025-002 must still have status="submitted", procedure_date="2026-04-15", sales_account_id="fea7b8c9-d0e1-2345-0123-456789012345" (BOSS Surgical Account Request).

```sql

      SELECT id, order_number, status, procedure_date::text AS procedure_date, sales_account_id
        FROM billing_orders
       WHERE order_number = $1
```

| id | order_number | status | procedure_date | sales_account_id |
| --- | --- | --- | --- | --- |
| ba000002-0000-4000-8000-000000000002 | ZBO-2025-002 | submitted | 2026-04-15 | fea7b8c9-d0e1-2345-0123-456789012345 |

### Cancel path did not persist a new billing_orders row — ✅ PASS

**Assertion:** Count of billing_orders at (sales_account_id=fea7b8c9-d0e1-2345-0123-456789012345, procedure_date=2026-04-15) must not increase during the run (baseline=1).

```sql

      SELECT COUNT(*)::int AS cnt
        FROM billing_orders
       WHERE sales_account_id = $1
         AND procedure_date = $2
```

| cnt |
| --- |
| 1 |

### A duplicate-check-qualifying row still exists for the test (account, date) — ✅ PASS

**Assertion:** At least one billing_orders row at (sales_account_id=fea7b8c9-d0e1-2345-0123-456789012345, procedure_date=2026-04-15) must have status in BILLING_ORDER_RULES.DUPLICATE_CHECK_STATUSES (submitted, processing, po_missing, billed, completed) — otherwise the duplicate-warning query returns zero rows and the UX silently stops firing. ZBO-2025-002 is expected to satisfy this.

```sql

      SELECT id, order_number, status, procedure_date::text AS procedure_date
        FROM billing_orders
       WHERE sales_account_id = $1
         AND procedure_date = $2
         AND status = ANY($3::text[])
```

| id | order_number | status | procedure_date |
| --- | --- | --- | --- |
| ba000002-0000-4000-8000-000000000002 | ZBO-2025-002 | submitted | 2026-04-15 |

## Audit Log Events

Every row written to `audit_events` while this test was running (scoped to the demo organizations). Provides compliance evidence that user actions are traced end-to-end (URS-003).

**Capture window start:** 2026-04-23T03:38:08.095Z

<details><summary>Query used to capture events</summary>

```sql
SELECT
    ae.created_at,
    ae.event_type,
    ae.action,
    ae.user_id,
    u.email AS user_email,
    ae.organization_id,
    o.name AS organization_name,
    ae.object_id,
    ae.secondary_object_id,
    ae.payload,
    ae.route,
    ae.trace_id
  FROM audit_events ae
  LEFT JOIN users u ON u.id = ae.user_id
  LEFT JOIN organizations o ON o.id = ae.organization_id
  WHERE ae.created_at >= $1
    AND ae.organization_id = ANY($2::uuid[])
  ORDER BY ae.created_at ASC
```
</details>

4 event(s) captured:

| Time | Type | Action | User | Org | Object ID | Performed | Reason |
|------|------|--------|------|-----|-----------|-----------|--------|
| 2026-04-23 03:38:14Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |
| 2026-04-23 03:38:22Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |
| 2026-04-23 03:38:35Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |
| 2026-04-23 03:38:49Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |