URS-018 · Upload PO to an Existing Order

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

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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

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

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”

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

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

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

Downloads

• audit-events.json
• report.md
• result.json
• screenshots-index.json
• step-timings.json

Feedback