URS-021 · Warn users before submitting a duplicate Bill-Only order

Title: Warn users before submitting a duplicate Bill-Only order Date: 2026-09-29T02:31:02.740Z Duration: 55.5s Overall Status: ✅ PASS

User Requirement

The system shall warn users before submitting a duplicate order.

Source: User_Requirement_Specifications_Vantis_DeviceFlow.xlsx — the run below proves the system meets this requirement.

Environment

• Inbox URL: http://localhost:43383
• Database: localhost:42299/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 Blair Bennett (Corveta rep) and opens /billing/new. Because Blair’s organization has exactly one manufacturer partner (Vantis), +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:

Video recording:

---

2. Step 2a: No warning without an identity match — ✅ PASS

What this step proves:

Selects ROSS Surgical Account Request and enters procedure date 2026-04-09 — the same (sales_account_id, procedure_date) pair used by the existing VBO-2025-002 (status=submitted). Since DF-2947 that alone is NOT enough: at least one identity signal (patient MRN, patient last name, or surgeon name) must also match, and blank-on-either-side never matches. The spec asserts no warning renders with the identity fields blank, and again after entering a non-matching patient MRN — proving the duplicate check is no longer over-eager.

Screenshots:

Video recording:

---

3. Step 2b: Duplicate warning appears — ✅ PASS

What this step proves:

With the same account + date filled, entering VBO-2025-002’s patient MRN (PT-76534, typed as a lowercase variant — MRN matching is trim + lowercase) supplies the required identity signal. The checkDuplicateBillingOrders remote query returns VBO-2025-002 flagged with patientIdComparison=‘match’, DuplicateCheckState.blocked flips to true, and DuplicateOrderWarning.svelte renders the amber “Possible Duplicate Submission” alert listing the existing order with a View affordance and a “(Same patient ID)” badge, an acknowledge button (“This is not a duplicate”), and an “Exit” link. The NavigationFooter’s Next button is blocked because manager.stepBlocked propagates from DuplicateCheckState.blocked.

Screenshots:

---

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

What this step proves:

Re-triggers the warning (matching account, date, and patient MRN), then clicks the “Exit” 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:

Video recording:

---

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

What this step proves:

Re-triggers the warning (matching account, date, and patient MRN), then clicks “This is not a duplicate”. 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:

Video recording:

---

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.

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

Assertion: VBO-2025-002 must still have status=“submitted”, procedure_date=“2026-09-21”, sales_account_id=“fea7b8c9-d0e1-2345-0123-456789012345” (ROSS Surgical Account Request), patient_id=“PT-76534” (the DF-2947 identity signal the spec matches on).

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

id	order_number	status	procedure_date	sales_account_id	patient_id
ba000002-0000-4000-8000-000000000002	VBO-2025-002	submitted	2026-09-21	fea7b8c9-d0e1-2345-0123-456789012345	PT-76534

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-09-21) must not increase during the run (baseline=1).

      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-09-21) 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. VBO-2025-002 is expected to satisfy this.

      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	VBO-2025-002	submitted	2026-09-21

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-09-29T02:31:01.158Z

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

4 event(s) captured:

Time	Type	Action	User	Org	Object ID	Performed	Reason
2026-09-29 02:31:09Z	user_log	user:login	blair.bennett@corvetasurgical.com	Corveta Surgical Group	—	—
2026-09-29 02:31:20Z	user_log	user:login	blair.bennett@corvetasurgical.com	Corveta Surgical Group	—	—
2026-09-29 02:31:34Z	user_log	user:login	blair.bennett@corvetasurgical.com	Corveta Surgical Group	—	—
2026-09-29 02:31:48Z	user_log	user:login	blair.bennett@corvetasurgical.com	Corveta Surgical Group	—	—

Downloads

• audit-events.json
• report.md
• result.json
• screenshots-index.json
• step-timings.json

Feedback