# Validation Report: URS-020

**Title:** Duplicate Delivered Order Form (DOF / Bill-Only) Detection
**Date:** 2026-04-23T03:37:55.647Z
**Duration:** 129.1s
**Overall Status:** ✅ PASS

## 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

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` (in `modules/bill_only/src/services/billing-order-queries.ts`) detects duplicates on `sales_account_id` + `procedure_date` only, 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

- **Inbox URL:** http://localhost:63168
- **Database:** localhost:63169/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: 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:**

![step 01 logged in](screenshots/step-01-logged-in.png)

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

**Video recording:**

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

---

### 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`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-1](screenshots/emails/2026-04-23T03-38-24-518Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1.png)

**Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-2](screenshots/emails/2026-04-23T03-38-49-090Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2.png)

**Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-3](screenshots/emails/2026-04-23T03-39-37-672Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3.png)

**Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4**

Template: `New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4`

![New Bill-Only Order - 2/17/2026 - ZuriMED BO-4](screenshots/emails/2026-04-23T03-39-56-222Z-New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4.png)

**Screenshots:**

![step 02 reference step2](screenshots/step-02-reference-step2.png)

![step 02 reference review](screenshots/step-02-reference-review.png)

![step 02 reference submitted](screenshots/step-02-reference-submitted.png)

**Video recording:**

[▶ Watch step recording](videos/step-02-reference-order.webm)

---

### 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`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-1](screenshots/emails/2026-04-23T03-38-24-518Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1.png)

**Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-2](screenshots/emails/2026-04-23T03-38-49-090Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2.png)

**Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-3](screenshots/emails/2026-04-23T03-39-37-672Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3.png)

**Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4**

Template: `New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4`

![New Bill-Only Order - 2/17/2026 - ZuriMED BO-4](screenshots/emails/2026-04-23T03-39-56-222Z-New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4.png)

**Screenshots:**

![step 03 warning with both badges](screenshots/step-03-warning-with-both-badges.png)

![step 03 duplicate submitted](screenshots/step-03-duplicate-submitted.png)

**Video recording:**

[▶ Watch step recording](videos/step-03-duplicate-warning.webm)

---

### 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:**

![step 04 alternate date no warning](screenshots/step-04-alternate-date-no-warning.png)

![step 04 date restored warning](screenshots/step-04-date-restored-warning.png)

**Video recording:**

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

---

### 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:**

![step 05 warning last name only](screenshots/step-05-warning-last-name-only.png)

**Video recording:**

[▶ Watch step recording](videos/step-05-clear-patient-id.webm)

---

### 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`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-1](screenshots/emails/2026-04-23T03-38-24-518Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1.png)

**Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-2](screenshots/emails/2026-04-23T03-38-49-090Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2.png)

**Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-3](screenshots/emails/2026-04-23T03-39-37-672Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3.png)

**Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4**

Template: `New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4`

![New Bill-Only Order - 2/17/2026 - ZuriMED BO-4](screenshots/emails/2026-04-23T03-39-56-222Z-New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4.png)

**Screenshots:**

![step 06 different account no warning](screenshots/step-06-different-account-no-warning.png)

![step 06 different account submitted](screenshots/step-06-different-account-submitted.png)

**Video recording:**

[▶ Watch step recording](videos/step-06-different-account.webm)

---

### 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`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-1](screenshots/emails/2026-04-23T03-38-24-518Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1.png)

**Email 2: New Bill-Only Order - 2/22/2026 - ZuriMED BO-2**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-2](screenshots/emails/2026-04-23T03-38-49-090Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2.png)

**Email 3: New Bill-Only Order - 2/22/2026 - ZuriMED BO-3**

Template: `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-3](screenshots/emails/2026-04-23T03-39-37-672Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3.png)

**Email 4: New Bill-Only Order - 2/17/2026 - ZuriMED BO-4**

Template: `New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4`

![New Bill-Only Order - 2/17/2026 - ZuriMED BO-4](screenshots/emails/2026-04-23T03-39-56-222Z-New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4.png)

**Screenshots:**

![step 07 non duplicate step2](screenshots/step-07-non-duplicate-step2.png)

![step 07 non duplicate submitted](screenshots/step-07-non-duplicate-submitted.png)

![step 07 billing list](screenshots/step-07-billing-list.png)

**Video recording:**

[▶ Watch step recording](videos/step-07-non-duplicate.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.

### 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.

```sql
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

**Assertion:** Two URS-020 orders must share the reference sales account and procedure date; that is exactly what `checkDuplicateBillingOrders` uses as its primary key.

```sql
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

**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.

```sql
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

**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.

```sql
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

**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.

```sql
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

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

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

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

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

<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>

15 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

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

**Template:** `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-1](screenshots/emails/2026-04-23T03-38-24-518Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-1.png)

### 2. New Bill-Only Order - 2/22/2026 - ZuriMED BO-2

**Template:** `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-2](screenshots/emails/2026-04-23T03-38-49-090Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-2.png)

### 3. New Bill-Only Order - 2/22/2026 - ZuriMED BO-3

**Template:** `New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3`

![New Bill-Only Order - 2/22/2026 - ZuriMED BO-3](screenshots/emails/2026-04-23T03-39-37-672Z-New_Bill-Only_Order_-_2_22_2026_-_ZuriMED_BO-3.png)

### 4. New Bill-Only Order - 2/17/2026 - ZuriMED BO-4

**Template:** `New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4`

![New Bill-Only Order - 2/17/2026 - ZuriMED BO-4](screenshots/emails/2026-04-23T03-39-56-222Z-New_Bill-Only_Order_-_2_17_2026_-_ZuriMED_BO-4.png)