Skip to content
DeviceFlow Validation

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

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

Section titled “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

Section titled “Environment”

Setup

Section titled “Setup”

Status: ✅ PASS

Test Steps

Section titled “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

Section titled “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

Video recording:

2. Step 2: Duplicate warning appears — ✅ PASS

Section titled “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

Video recording:

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

Section titled “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

Video recording:

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

Section titled “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

Video recording:

Database Validations

Section titled “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

Section titled “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).

      SELECT id, order_number, status, procedure_date::text AS procedure_date, sales_account_id
        FROM billing_orders
       WHERE order_number = $1
idorder_numberstatusprocedure_datesales_account_id
ba000002-0000-4000-8000-000000000002ZBO-2025-002submitted2026-04-15fea7b8c9-d0e1-2345-0123-456789012345

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

Section titled “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).

      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

Section titled “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.

      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[])
idorder_numberstatusprocedure_date
ba000002-0000-4000-8000-000000000002ZBO-2025-002submitted2026-04-15

Audit Log Events

Section titled “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

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:

TimeTypeActionUserOrgObject IDPerformedReason
2026-04-23 03:38:14Zuser_loguser:loginbob.kauffman@stellartech.comStellarTech Medical Solutions——
2026-04-23 03:38:22Zuser_loguser:loginbob.kauffman@stellartech.comStellarTech Medical Solutions——
2026-04-23 03:38:35Zuser_loguser:loginbob.kauffman@stellartech.comStellarTech Medical Solutions——
2026-04-23 03:38:49Zuser_loguser:loginbob.kauffman@stellartech.comStellarTech Medical Solutions——

Downloads

Section titled “Downloads”

Feedback

Section titled “Feedback”