# Validation Report: URS-018

**Title:** Upload PO to an Existing Order
**Date:** 2026-04-23T03:36:53.669Z
**Duration:** 60.1s
**Overall Status:** ✅ PASS

## User Requirement

> The system shall allow uploading a PO to an existing order when missing.

*Source: `User_Requirement_Specifications_ZuriMED_DeviceFlow.xlsx` — the run below proves the system meets this requirement.*

## Environment

- **Inbox URL:** http://localhost:62804
- **Database:** localhost:62805/cc_repinbox_dev

## Setup

Status: ✅ PASS

## Input Files Used in This Test

The following files were used as test inputs. Auditors can review these to verify what data was submitted to the system during validation.

### Sample Purchase Order (PO) Document

**Description:** A sample PDF purchase order used in Step 3 to demonstrate attaching a PO document to an existing order. This file is uploaded via the UI in the test.
**File:** [test-po.pdf](../../../testing/validations/urs-018-upload-po-existing-order/fixtures/test-po.pdf)

## 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: Create order without PO — ✅ PASS

**What this step proves:**

Creates a direct order through the full multi-step form without attaching any PO document during submission. This proves the system accepts orders in the absence of PO documentation and that the upload step is optional at order creation time.

**Audit events generated by this step:**

*(Evidence scoped to step execution window: 2026-04-23T03:37:04.796Z → 2026-04-23T03:37:17.338Z)*

| Time | Type | Action | User | Org | Performed |
|------|------|--------|------|-----|-----------|
| 2026-04-23 03:37:17Z | decision | order_request_created | bob.kauffman@stellartech.com | ZuriMED | yes |

**Screenshots:**

![step 01 order type selected](screenshots/step-01-order-type-selected.png)

![step 01 products no po](screenshots/step-01-products-no-po.png)

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

![step 01 order submitted](screenshots/step-01-order-submitted.png)

**Video recording:**

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

---

### 2. Step 2: No documents linked — ✅ PASS

**What this step proves:**

Navigates to the order detail page of the newly created order and confirms the Source Documents section displays "no linked documents yet" alongside a visible PO upload area. This proves the UI correctly exposes the post-creation upload capability at the right location.

**Screenshots:**

![step 02 no documents](screenshots/step-02-no-documents.png)

![step 02 upload area visible](screenshots/step-02-upload-area-visible.png)

**Video recording:**

[▶ Watch step recording](videos/step-02-no-documents.webm)

---

### 3. Step 3: PO document attached — ✅ PASS

**What this step proves:**

Uses the file uploader to attach test-po.pdf to the existing order via the Source Documents UI. After upload the "no linked documents" message disappears and the filename, uploader attribution, and a View link appear. This proves a PDF PO can be attached to an order after it has already been created.

**Screenshots:**

![step 03 po document visible](screenshots/step-03-po-document-visible.png)

![step 03 document details](screenshots/step-03-document-details.png)

**Video recording:**

[▶ Watch step recording](videos/step-03-po-attached.webm)

---

### 4. Step 4: PO persists after reload — ✅ PASS

**What this step proves:**

Reloads the order detail page in a fresh browser context and confirms the attached PO document is still listed with its View link, and that the "no linked documents" message is absent. This proves the upload is durably stored and survives a full page reload.

**Screenshots:**

![step 04 po persisted](screenshots/step-04-po-persisted.png)

**Video recording:**

[▶ Watch step recording](videos/step-04-verify-persistence.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.

### Test order created — ✅ PASS

**Assertion:** An order should have been created during the test

```sql
SELECT id, request_number, order_type, status, created_at
      FROM order_requests
      WHERE requested_by_user_id = $1
        AND notes LIKE $2
      ORDER BY created_at DESC
      LIMIT 1
```

| id | request_number | order_type | status | created_at |
| --- | --- | --- | --- | --- |
| 019db869-d6cb-76d7-a35e-2487c170eecf | OR-1 | direct | submitted | 2026-04-23T03:37:17.244Z |

### PO document linked to order — ✅ PASS

**Assertion:** At least one PO document should be linked to the test order

```sql
SELECT ord.id, ord.order_request_id, d.filename, d.mime_type, d.category, ord.created_at
      FROM order_request_documents ord
      JOIN documents d ON d.id = ord.document_id
      WHERE ord.order_request_id IN (
        SELECT id FROM order_requests
        WHERE requested_by_user_id = $1
          AND notes LIKE $2
      )
      ORDER BY ord.created_at DESC
```

| id | order_request_id | filename | mime_type | category | created_at |
| --- | --- | --- | --- | --- | --- |
| 019db86a-2ca6-75a3-a374-ab7a76db98c1 | 019db869-d6cb-76d7-a35e-2487c170eecf | test-po.pdf | application/pdf | direct_order | 2026-04-23T03:37:39.205Z |

### Document has correct category — ✅ PASS

**Assertion:** Uploaded PO document should have category "direct_order"

```sql
SELECT d.id, d.filename, d.category, d.mime_type, d.size
      FROM documents d
      JOIN order_request_documents ord ON ord.document_id = d.id
      WHERE ord.order_request_id IN (
        SELECT id FROM order_requests
        WHERE requested_by_user_id = $1
          AND notes LIKE $2
      )
      ORDER BY d.created_at DESC
      LIMIT 1
```

| id | filename | category | mime_type | size |
| --- | --- | --- | --- | --- |
| 019db86a-2ca5-7026-b1fd-f52d84b44cc3 | test-po.pdf | direct_order | application/pdf | 582 |

## 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 1: Create order without PO | `user_log:user:login` | ✅ |

## 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:36:51.749Z

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

5 event(s) captured:

| Time | Type | Action | User | Org | Object ID | Performed | Reason |
|------|------|--------|------|-----|-----------|-----------|--------|
| 2026-04-23 03:36:56Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |
| 2026-04-23 03:37:17Z | decision | order_request_created | bob.kauffman@stellartech.com | ZuriMED | 019db869-d6cb-76d7-a35e-2487c170eecf | yes | Order request OR-1 created (importSource=manual) |
| 2026-04-23 03:37:21Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |
| 2026-04-23 03:37:32Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |
| 2026-04-23 03:37:44Z | user_log | user:login | bob.kauffman@stellartech.com | StellarTech Medical Solutions | — | — |  |