URS-020 · Duplicate Delivered Order Form (DOF / Bill-Only) Detection
Title: Duplicate Delivered Order Form (DOF / Bill-Only) Detection Date: 2026-04-23T03:37:55.647Z Duration: 129.1s Overall Status: ✅ PASS
User Requirement
Section titled “User Requirement”The system shall detect potential duplicate DOFs using account, PO, patient ID, and procedure date.
Source: User_Requirement_Specifications_ZuriMED_DeviceFlow.xlsx — the run below proves the system meets this requirement.
Known Deviations
Section titled “Known Deviations”The run below validates what the merged implementation actually does. The following bullets call out every place where the implementation differs from the URS wording so a reviewer reading them side-by-side does not mistake the spec text for the system behaviour.
- PO number is not a duplicate-detection input. (see DF-2598) URS-020 lists PO number as a detection signal, but
checkDuplicateBillingOrders(inmodules/bill_only/src/services/billing-order-queries.ts) detects duplicates onsales_account_id+procedure_dateonly, scoped to the user’s organization. Patient ID and patient last name are used solely to annotate matched rows with the “(Same patient ID)” / “(Same last name)” badges — not as part of the primary match key. This is intentional: sales reps typically submit bill-onlies before the PO has arrived, so requiring PO in the match would silently disable detection for the common case. The test below exercises the merged behaviour (positive match on account+date, negative match when either differs) rather than the URS wording.
Environment
Section titled “Environment”- Inbox URL: http://localhost:63168
- Database: localhost:63169/cc_repinbox_dev
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: Login and open bill-only form — ✅ PASS
Section titled “1. Step 1: Login and open bill-only form — ✅ PASS”What this step proves:
Bob Kauffman (StellarTech admin, has billing:create) signs in and opens the bill-only creation wizard. Establishes the user + permission context for every subsequent step.
Screenshots:
Video recording:
2. Step 2: Submit reference order — ✅ PASS
Section titled “2. Step 2: Submit reference order — ✅ PASS”What this step proves:
Submits a bill-only order with the canonical reference values — BOSS Surgical account, procedure date 2026-04-15, patient PAT-URS020-001 / URS020TestLastName. No warning appears because no prior duplicate exists. This order becomes the match target for Step 3–5 and is persisted with the “URS-020 validation test” notes marker.
Audit events generated by this step:
(Evidence scoped to step execution window: 2026-04-23T03:38:15.134Z → 2026-04-23T03:38:25.699Z)
| Time | Type | Action | User | Org | Performed |
|---|---|---|---|---|---|
| 2026-04-23 03:38:22Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | no |
| 2026-04-23 03:38:24Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | — |
Emails triggered by this step:
(Evidence matched by declared name — step timing not available or no events fell in window)
Email 1: New Bill-Only Order - 2/22/2026 - ZuriMED BO-1
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1
Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2
Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3
Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4
Template: New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4
Screenshots:
Video recording:
3. Step 3: Duplicate warning with both badges — ✅ PASS
Section titled “3. Step 3: Duplicate warning with both badges — ✅ PASS”What this step proves:
Re-entering the reference account + procedure date + patient ID + last name triggers “Possible Duplicate Submission”. Both “(Same patient ID)” and “(Same last name)” badges render because the match row shares those annotation fields. Clicking “This is not a duplicate — continue” unlocks step advancement and the submission then completes end-to-end — proving duplicate detection is a soft block the user can acknowledge and override, and giving the DB a second row that shares the full (account, date, patient ID, last name) key with the reference order.
Audit events generated by this step:
(Evidence scoped to step execution window: 2026-04-23T03:38:37.192Z → 2026-04-23T03:38:49.206Z)
| Time | Type | Action | User | Org | Performed |
|---|---|---|---|---|---|
| 2026-04-23 03:38:48Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | no |
| 2026-04-23 03:38:49Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | — |
Emails triggered by this step:
(Evidence matched by declared name — step timing not available or no events fell in window)
Email 1: New Bill-Only Order - 2/22/2026 - ZuriMED BO-1
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1
Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2
Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3
Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4
Template: New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4
Screenshots:
Video recording:
4. Step 4: Change date — warning hides — ✅ PASS
Section titled “4. Step 4: Change date — warning hides — ✅ PASS”What this step proves:
Switching procedure date from 2026-04-15 to 2026-04-10 dismisses the warning because the primary match key (sales_account_id, procedure_date) no longer matches. Reverting the date brings the warning back — confirms the check is live-driven by form state, not cached server-side.
Screenshots:
Video recording:
5. Step 5: Clear patient ID — badge hides, warning remains — ✅ PASS
Section titled “5. Step 5: Clear patient ID — badge hides, warning remains — ✅ PASS”What this step proves:
Clearing the patient ID field while leaving account + procedure date intact keeps the “Possible Duplicate Submission” warning (primary key still hits) but drops the “(Same patient ID)” badge — proving patient_id is only an annotation, not part of the primary match, while last-name match still annotates.
Screenshots:
Video recording:
6. Step 6: Different account, same date — no warning — ✅ PASS
Section titled “6. Step 6: Different account, same date — no warning — ✅ PASS”What this step proves:
Submits a bill-only for a DIFFERENT sales account (“Copley Hospital Account Request”) on the reference procedure date (2026-04-15) with the same patient ID + last name as the reference. No warning appears and the order submits cleanly — proving that changing sales_account_id alone is sufficient to escape detection, even when every other field matches the reference row. This is the symmetric negative counterpart to Step 4: Step 4 proves date-variation escapes detection; Step 6 proves account-variation does too.
Audit events generated by this step:
(Evidence scoped to step execution window: 2026-04-23T03:39:30.501Z → 2026-04-23T03:39:38.614Z)
| Time | Type | Action | User | Org | Performed |
|---|---|---|---|---|---|
| 2026-04-23 03:39:36Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | no |
| 2026-04-23 03:39:37Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | — |
Emails triggered by this step:
(Evidence matched by declared name — step timing not available or no events fell in window)
Email 1: New Bill-Only Order - 2/22/2026 - ZuriMED BO-1
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1
Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2
Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3
Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4
Template: New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4
Screenshots:
Video recording:
7. Step 7: Non-duplicate and verify billing list — ✅ PASS
Section titled “7. Step 7: Non-duplicate and verify billing list — ✅ PASS”What this step proves:
Creates a fourth order with the SAME account + patient but the alternate procedure date (2026-04-10). No warning appears and the order submits without any acknowledgement. The billing list is then asserted to display every URS-020 PO number (reference, acknowledged duplicate, different-account negative, alternate-date non-duplicate) — proving every submission from this run landed in the shared view the next operator would see. (The list itself does not render a row-level duplicate indicator — the warning is a creation-time UX only; see README “Known Deviations”.)
Audit events generated by this step:
(Evidence scoped to step execution window: 2026-04-23T03:39:49.371Z → 2026-04-23T03:39:58.458Z)
| Time | Type | Action | User | Org | Performed |
|---|---|---|---|---|---|
| 2026-04-23 03:39:54Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | no |
| 2026-04-23 03:39:56Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | — |
Emails triggered by this step:
(Evidence matched by declared name — step timing not available or no events fell in window)
Email 1: New Bill-Only Order - 2/22/2026 - ZuriMED BO-1
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1
Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2
Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3
Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3
Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4
Template: New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4
Screenshots:
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.
Four URS-020 billing orders created — ✅ PASS
Section titled “Four URS-020 billing orders created — ✅ PASS”Assertion: Playwright submitted four bill-only orders — reference, acknowledged duplicate, different-account negative case, and alternate-date non-duplicate — all tagged with the URS-020 marker.
SELECT id, order_number, sales_account_id, procedure_date, patient_id, patient_last_name, po_number, status, notes, created_at FROM billing_orders WHERE created_by_user_id = $1 AND notes LIKE $2 ORDER BY created_at ASC| id | order_number | sales_account_id | procedure_date | patient_id | patient_last_name | po_number | status | notes | created_at |
|---|---|---|---|---|---|---|---|---|---|
| 019db86a-d7fe-753d-8926-cd3ea0283a46 | BO-1 | fea7b8c9-d0e1-2345-0123-456789012345 | 2026-02-22T06:00:00.000Z | PAT-URS020-001 | URS020TestLastName | PO-URS020-REF | submitted | URS-020 validation test — reference order | 2026-04-23T03:38:22.955Z |
| 019db86b-3d3a-710f-a9a6-6b7d12e367bc | BO-2 | fea7b8c9-d0e1-2345-0123-456789012345 | 2026-02-22T06:00:00.000Z | PAT-URS020-001 | URS020TestLastName | PO-URS020-DUP | submitted | URS-020 validation test — acknowledged duplicate | 2026-04-23T03:38:48.971Z |
| 019db86b-f54a-78cc-a3a6-1de605efb9d9 | BO-3 | 1fb8c9d0-e1f2-3456-1234-567890123456 | 2026-02-22T06:00:00.000Z | PAT-URS020-001 | URS020TestLastName | PO-URS020-ALTACCT | submitted | URS-020 validation test — different account negative case | 2026-04-23T03:39:36.118Z |
| 019db86c-3ed2-76c3-a0ef-7d693cc2e8ca | BO-4 | fea7b8c9-d0e1-2345-0123-456789012345 | 2026-02-17T06:00:00.000Z | PAT-URS020-001 | URS020TestLastName | PO-URS020-NONE | submitted | URS-020 validation test — non-duplicate (alternate procedure date) | 2026-04-23T03:39:54.931Z |
Duplicate pair shares account + procedure date — ✅ PASS
Section titled “Duplicate pair shares account + procedure date — ✅ PASS”Assertion: Two URS-020 orders must share the reference sales account and procedure date; that is exactly what checkDuplicateBillingOrders uses as its primary key.
SELECT id, order_number, po_number, patient_id, patient_last_name, created_at FROM billing_orders WHERE created_by_user_id = $1 AND notes LIKE $2 AND sales_account_id = $3 AND procedure_date = $4 ORDER BY created_at ASC| id | order_number | po_number | patient_id | patient_last_name | created_at |
|---|---|---|---|---|---|
| 019db86a-d7fe-753d-8926-cd3ea0283a46 | BO-1 | PO-URS020-REF | PAT-URS020-001 | URS020TestLastName | 2026-04-23T03:38:22.955Z |
| 019db86b-3d3a-710f-a9a6-6b7d12e367bc | BO-2 | PO-URS020-DUP | PAT-URS020-001 | URS020TestLastName | 2026-04-23T03:38:48.971Z |
Alternate-date order: same account, different date (no warning) — ✅ PASS
Section titled “Alternate-date order: same account, different date (no warning) — ✅ PASS”Assertion: A URS-020 order must exist with the reference sales account but the alternate procedure date. The UI rendered no warning at submission time — evidence that changing procedure_date alone is sufficient to escape duplicate detection.
SELECT id, order_number, po_number, sales_account_id, procedure_date FROM billing_orders WHERE created_by_user_id = $1 AND notes LIKE $2 AND sales_account_id = $3 AND procedure_date = $4| id | order_number | po_number | sales_account_id | procedure_date |
|---|---|---|---|---|
| 019db86c-3ed2-76c3-a0ef-7d693cc2e8ca | BO-4 | PO-URS020-NONE | fea7b8c9-d0e1-2345-0123-456789012345 | 2026-02-17T06:00:00.000Z |
Different-account order: other account, same date (no warning) — ✅ PASS
Section titled “Different-account order: other account, same date (no warning) — ✅ PASS”Assertion: A URS-020 order must exist with the alternate sales account (Copley) on the reference procedure date. The UI rendered no warning at submission time — evidence that changing sales_account_id alone is sufficient to escape duplicate detection, proving account is a primary-key element and the detection key is symmetric in account and date.
SELECT id, order_number, po_number, sales_account_id, procedure_date FROM billing_orders WHERE created_by_user_id = $1 AND notes LIKE $2 AND sales_account_id = $3 AND procedure_date = $4| id | order_number | po_number | sales_account_id | procedure_date |
|---|---|---|---|---|
| 019db86b-f54a-78cc-a3a6-1de605efb9d9 | BO-3 | PO-URS020-ALTACCT | 1fb8c9d0-e1f2-3456-1234-567890123456 | 2026-02-22T06:00:00.000Z |
Duplicate pair also matches patient ID and last name — ✅ PASS
Section titled “Duplicate pair also matches patient ID and last name — ✅ PASS”Assertion: Both duplicate-pair orders carry the reference patient ID and patient last name so the warning surfaced both “(Same patient ID)” and “(Same last name)” badges.
SELECT COUNT(*) AS n FROM billing_orders WHERE created_by_user_id = $1 AND notes LIKE $2 AND sales_account_id = $3 AND procedure_date = $4 AND patient_id = $5 AND patient_last_name = $6| n |
|---|
| 2 |
Audit & Email Assertion Ledger
Section titled “Audit & Email Assertion Ledger”Per-declaration outcome of every expectedAuditActions and expectedEmailTemplates entry written into the orchestrator. Missing evidence here is a real test failure, not a soft warning.
Audit Action Assertions
Section titled “Audit Action Assertions”Each row asserts that a declared expectedAuditActions entry produced a matching row in audit_events. A ❌ flips overall status to FAIL — the declaration is real proof, not just an annotation.
| Step | Expected Audit Action | Found |
|---|---|---|
| Step 2: Submit reference order | decision:bill_only_order.enqueue_upload_classification | ✅ |
| Step 3: Duplicate warning with both badges | decision:bill_only_order.enqueue_upload_classification | ✅ |
| Step 6: Different account, same date — no warning | decision:bill_only_order.enqueue_upload_classification | ✅ |
| Step 7: Non-duplicate and verify billing list | decision:bill_only_order.enqueue_upload_classification | ✅ |
Email Template Assertions
Section titled “Email Template Assertions”Each row asserts that a declared expectedEmailTemplates entry was matched (case-insensitive substring) by a captured email subject or template. A ❌ flips overall status to FAIL.
| Step | Expected Template | Found |
|---|---|---|
| Step 2: Submit reference order | bill-only | ✅ |
| Step 3: Duplicate warning with both badges | bill-only | ✅ |
| Step 6: Different account, same date — no warning | bill-only | ✅ |
| Step 7: Non-duplicate and verify billing list | bill-only | ✅ |
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:37:53.715Z
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 ASC15 event(s) captured:
| Time | Type | Action | User | Org | Object ID | Performed | Reason |
|---|---|---|---|---|---|---|---|
| 2026-04-23 03:37:58Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:38:05Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:38:22Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | 019db86a-d7fe-753d-8926-cd3ea0283a46 | no | No uploaded PO documents |
| 2026-04-23 03:38:24Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | 019db86a-d7fe-753d-8926-cd3ea0283a46 | — | |
| 2026-04-23 03:38:27Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:38:48Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | 019db86b-3d3a-710f-a9a6-6b7d12e367bc | no | No uploaded PO documents |
| 2026-04-23 03:38:49Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | 019db86b-3d3a-710f-a9a6-6b7d12e367bc | — | |
| 2026-04-23 03:38:50Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:39:05Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:39:22Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:39:36Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | 019db86b-f54a-78cc-a3a6-1de605efb9d9 | no | No uploaded PO documents |
| 2026-04-23 03:39:37Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | 019db86b-f54a-78cc-a3a6-1de605efb9d9 | — | |
| 2026-04-23 03:39:39Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:39:54Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | 019db86c-3ed2-76c3-a0ef-7d693cc2e8ca | no | No uploaded PO documents |
| 2026-04-23 03:39:56Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | 019db86c-3ed2-76c3-a0ef-7d693cc2e8ca | — |
Email Evidence
Section titled “Email Evidence”4 notification email(s) were captured during this test run. Each email is rendered as a screenshot for compliance review.
1. New Bill-Only Order - 2/22/2026 - ZuriMED BO-1
Section titled “1. New Bill-Only Order - 2/22/2026 - ZuriMED BO-1”Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1
2. New Bill-Only Order - 2/22/2026 - ZuriMED BO-2
Section titled “2. New Bill-Only Order - 2/22/2026 - ZuriMED BO-2”Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2
3. New Bill-Only Order - 2/22/2026 - ZuriMED BO-3
Section titled “3. New Bill-Only Order - 2/22/2026 - ZuriMED BO-3”Template: New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3
4. New Bill-Only Order - 2/17/2026 - ZuriMED BO-4
Section titled “4. New Bill-Only Order - 2/17/2026 - ZuriMED BO-4”Template: New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4