URS-019 · Bill-Only without PO for Approved Accounts
Title: Bill-Only without PO for Approved Accounts Date: 2026-04-23T03:37:40.853Z Duration: 62.0s Overall Status: ✅ PASS
User Requirement
Section titled “User Requirement”The system shall support “Bill‑Only without PO” only for accounts approved by ZuriMED.
Source: User_Requirement_Specifications_ZuriMED_DeviceFlow.xlsx — the run below proves the system meets this requirement.
Environment
Section titled “Environment”- Inbox URL: http://localhost:63054
- Database: localhost:63055/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 — ✅ PASS
Section titled “1. Step 1: Login — ✅ PASS”What this step proves:
Proves that Bob Kauffman (StellarTech Sales Rep) can authenticate and reach the application. Establishes the user context for all subsequent steps.
Audit events generated by this step:
(Evidence matched by declared name — step timing not available or no events fell in window)
| Time | Type | Action | User | Org | Performed |
|---|---|---|---|---|---|
| 2026-04-23 03:37:47Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — |
| 2026-04-23 03:37:52Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — |
| 2026-04-23 03:37:58Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — |
| 2026-04-23 03:38:10Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — |
| 2026-04-23 03:38:33Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — |
Screenshots:

Video recording:
2. Step 2: Billing form — ✅ PASS
Section titled “2. Step 2: Billing form — ✅ PASS”What this step proves:
Confirms Bob can navigate to the new bill-only order creation form and reach the account selection step (Step 2). Verifies the billing feature is accessible to the sales rep role.
Screenshots:

Video recording:
3. Step 3: Unapproved account hidden — ✅ PASS
Section titled “3. Step 3: Unapproved account hidden — ✅ PASS”What this step proves:
The system enforces the approval gate at the UI level: the account selector only shows accounts with status=“active” (approved by ZuriMED). Copley Hospital Account Request, which is set to status=“proposed” (unapproved) by the test setup, does not appear as a selectable option. BOSS Surgical Account Request (active/approved) is visible, confirming the selector works correctly. This is the negative test — it proves the approval gate is enforced.
Screenshots:



Video recording:
4. Step 4: Create order — ✅ PASS
Section titled “4. Step 4: Create order — ✅ PASS”What this step proves:
An approved account (BOSS Surgical Account Request, status=“active”) can successfully complete the full bill-only order submission flow — including leaving the PO field empty. The order is accepted and a BO-XXXX order number is assigned. This is the positive test proving that approved accounts can submit Bill-Only without PO.
Audit events generated by this step:
(Evidence scoped to step execution window: 2026-04-23T03:38:17.304Z → 2026-04-23T03:38:30.412Z)
| Time | Type | Action | User | Org | Performed |
|---|---|---|---|---|---|
| 2026-04-23 03:38:30Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | no |
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 - 1/15/2025 - ZuriMED BO-1
Template: New_Bill-Only_Order_-_1_15_2025_-_ZuriMED_BO-1

Screenshots:





Video recording:
5. Step 5: Verify order — ✅ PASS
Section titled “5. Step 5: Verify order — ✅ PASS”What this step proves:
The newly created bill-only order appears on the billing list, confirming it was persisted correctly. The specific order number captured in Step 4 is visible, providing end-to-end traceability from form submission to database record.
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.
Approved account has active status — ✅ PASS
Section titled “Approved account has active status — ✅ PASS”Assertion: BOSS Hospital should have status=‘active’ (approved)
SELECT id, name, status FROM sales_accounts WHERE id = ANY($1) ORDER BY name| id | name | status |
|---|---|---|
| fea7b8c9-d0e1-2345-0123-456789012345 | BOSS Surgical Account Request | active |
| 1fb8c9d0-e1f2-3456-1234-567890123456 | Copley Hospital Account Request | proposed |
Unapproved account has proposed status — ✅ PASS
Section titled “Unapproved account has proposed status — ✅ PASS”Assertion: Copley Healthcare should have status=‘proposed’ (unapproved)
SELECT id, name, status FROM sales_accounts WHERE id = ANY($1) ORDER BY name| id | name | status |
|---|---|---|
| fea7b8c9-d0e1-2345-0123-456789012345 | BOSS Surgical Account Request | active |
| 1fb8c9d0-e1f2-3456-1234-567890123456 | Copley Hospital Account Request | proposed |
New billing order BO-1 exists for approved account — ✅ PASS
Section titled “New billing order BO-1 exists for approved account — ✅ PASS”Assertion: Order BO-1 should exist for BOSS Hospital (approved account)
SELECT id, order_number, status, sales_account_id, created_at FROM billing_orders WHERE sales_account_id = 'fea7b8c9-d0e1-2345-0123-456789012345' AND order_number = 'BO-1'| id | order_number | status | sales_account_id | created_at |
|---|---|---|---|---|
| 019db86a-f348-7b04-a15e-1d1c3d78889a | BO-1 | submitted | fea7b8c9-d0e1-2345-0123-456789012345 | 2026-04-23T03:38:30.026Z |
No new billing orders for unapproved account — ✅ PASS
Section titled “No new billing orders for unapproved account — ✅ PASS”Assertion: No billing orders should have been created for Copley Healthcare (unapproved account) during the test
SELECT id, order_number, status, created_at FROM billing_orders WHERE sales_account_id = '1fb8c9d0-e1f2-3456-1234-567890123456' AND created_at > NOW() - INTERVAL '10 minutes' ORDER BY created_at DESCNo rows returned
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 1: Login | user_log:user:login | ✅ |
| Step 4: Create order | 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 4: Create order | 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:38.919Z
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 ASC7 event(s) captured:
| Time | Type | Action | User | Org | Object ID | Performed | Reason |
|---|---|---|---|---|---|---|---|
| 2026-04-23 03:37:47Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:37:52Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:37:58Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:38:10Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — | |
| 2026-04-23 03:38:30Z | decision | bill_only_order.enqueue_upload_classification | bob.kauffman@stellartech.com | ZuriMED | 019db86a-f348-7b04-a15e-1d1c3d78889a | no | No uploaded PO documents |
| 2026-04-23 03:38:32Z | transactional_email | new_bill_only | — | StellarTech Medical Solutions | 019db86a-f348-7b04-a15e-1d1c3d78889a | — | |
| 2026-04-23 03:38:33Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |
Email Evidence
Section titled “Email Evidence”1 notification email(s) were captured during this test run. Each email is rendered as a screenshot for compliance review.
1. New Bill-Only Order - 1/15/2025 - ZuriMED BO-1
Section titled “1. New Bill-Only Order - 1/15/2025 - ZuriMED BO-1”Template: New_Bill-Only_Order_-_1_15_2025_-_ZuriMED_BO-1
