# Validation Report: URS-080

**Title:** Par-level replenishment
**Date:** 2026-09-29T02:31:00.388Z
**Duration:** 98.2s
**Overall Status:** ✅ PASS

## User Requirement

> The system shall let an administrator set a minimum on-hand quantity (par level) per SKU at a location, surface those par levels on the location, the organization-wide par agreements page, and the sales account profile, forecast which SKUs will fall below par by the time a replenishment order would arrive (rounding recommended quantities up to each SKU's minimum shipment size), raise a replenishment task in the responsible user's inbox with a live forecast, prefill a replenishment order from that forecast, and persist the submitted order with full traceability.

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

## Environment

- **Inbox URL:** http://localhost:45893
- **Database:** localhost:43735/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: Admin sets par levels at the location — ✅ PASS

**What this step proves:**

Alex Admin (Vantis manufacturer) opens the seeded consignment location's settings page and, in the Par Agreements editor, adds a par level of 20 for URS080-PLATE and URS080-SCREW by picking each SKU and clicking Add. Each save shows the "Par agreement saved" toast and the row renders the par level next to the SKU's org-wide minimum shipment size (5 for the plate, none for the screw), which the editor exposes read-only. This establishes the par configuration the rest of the chain is driven by and proves par levels are set per (location, SKU) with an audit event per save.

**Audit events generated by this step:**

*(Evidence scoped to step execution window: 2026-09-29T02:31:10.600Z → 2026-09-29T02:31:18.202Z)*

| Time | Type | Action | User | Org | Performed |
|------|------|--------|------|-----|-----------|
| 2026-09-29 02:31:13Z | par_agreement_set | set_par_agreement | alex.admin@vantismedical.com | Vantis | — |
| 2026-09-29 02:31:17Z | par_agreement_set | set_par_agreement | alex.admin@vantismedical.com | Vantis | — |

**Screenshots:**

![step 01 par editor empty](screenshots/step-01-par-editor-empty.png)

![step 01 par levels set](screenshots/step-01-par-levels-set.png)

**Video recording:**

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

---

### 2. Step 2: Org-wide par agreements page lists the location — ✅ PASS

**What this step proves:**

The cross-location par agreements page (/inventory/par-agreements) groups every agreement in the organization by location. The run deep-links to the location's anchor and verifies the location heading, its "2 SKUs" count, and both SKUs at par 20. This proves the agreements set on the location page are the same org-wide records, not a per-page copy.

**Screenshots:**

![step 02 par agreements page](screenshots/step-02-par-agreements-page.png)

**Video recording:**

[▶ Watch step recording](videos/step-02-par-page.webm)

---

### 3. Step 3: Account profile shows par levels — ✅ PASS

**What this step proves:**

The sales account that ships to the location renders a read-only "Par levels" section listing the agreements at its shipping location, with a "View par agreements" link that lands on the location's group on the org-wide page. This proves par levels are visible from the account context where replenishment is discussed with the customer.

**Screenshots:**

![step 03 account par levels](screenshots/step-03-account-par-levels.png)

**Video recording:**

[▶ Watch step recording](videos/step-03-account-widget.webm)

---

### 4. Step 4: Replenishment forecast dashboard shows SKUs below par — ✅ PASS

**What this step proves:**

The par replenishment forecast dashboard recomputes the live forecast for the location: with 12 plates and 6 screws on hand against par 20, no scheduled demand, and nothing inbound, both SKUs are projected below par at the 3-day arrival. The "SKUs below par" KPI reads 2 of 2 and each SKU bar shows its projected-at-arrival count and recommended order (10 for the plate — the deficit of 8 rounded up to the minimum shipment of 5 — and 14 for the screw). This proves the deterministic forecast math and the minimum-shipment rounding.

**Screenshots:**

![step 04 forecast dashboard](screenshots/step-04-forecast-dashboard.png)

**Video recording:**

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

---

### 5. Step 5: Inbox surfaces the replenishment task with a live forecast — ✅ PASS

**What this step proves:**

The "Replenish URS080 Lakeside Surgical Center" task is waiting in Alex's inbox. Its detail panel renders the forecast card, which recomputes the forecast live against current inventory (the same numbers as the dashboard: par 20, projected 12 and 6, recommended 10 and 14), and its "Go to Task" action is a deep link into the new-order form carrying prefillReplenishment=1, the location id, and the explicit supplying manufacturer id. This proves the replenishment work reaches the responsible person with the live recommendation attached. The task itself is seeded by setup because the daily replenishment scan is not scheduled in production; its generation is covered by the module integration tests.

**Screenshots:**

![step 05 task detail](screenshots/step-05-task-detail.png)

![step 05 go to task](screenshots/step-05-go-to-task.png)

**Video recording:**

[▶ Watch step recording](videos/step-05-inbox-task.webm)

---

### 6. Step 6: Prefilled replenishment order form — ✅ PASS

**What this step proves:**

Clicking "Go to Task" opens the new-order form on the products step. The load recomputes the forecast for the location, selects the location and Vantis as its own supplier, and seeds each below-par SKU with its recommended quantity, showing the "Prefilled from par forecast for URS080 Lakeside Surgical Center" banner. The plate reads 10 and the screw 14, both still editable. This proves the handoff from task to order is prefilled end to end from the same forecast.

**Screenshots:**

![step 06 prefilled quantities](screenshots/step-06-prefilled-quantities.png)

**Video recording:**

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

---

### 7. Step 7: Admin submits the replenishment order — ✅ PASS

**What this step proves:**

Alex re-enters through the task, keeps the prefilled quantities, tags the notes with the URS-080 marker, advances to the review step (which lists both SKUs at 10 and 14 units), and submits. Because Vantis is both the requesting and the fulfilling organization, the order is self-fulfilled: it skips the submission grace window and auto-approval resolves inline at creation, writing the order_request_created and auto_approve_order decisions. This closes the chain: a par shortfall becomes a traceable, approved replenishment order.

**Audit events generated by this step:**

*(Evidence scoped to step execution window: 2026-09-29T02:31:57.434Z → 2026-09-29T02:32:00.504Z)*

| Time | Type | Action | User | Org | Performed |
|------|------|--------|------|-----|-----------|
| 2026-09-29 02:32:00Z | decision | representatives.gate_rep_action | alex.admin@vantismedical.com | Vantis | no |
| 2026-09-29 02:32:00Z | decision | order_request_created | alex.admin@vantismedical.com | Vantis | yes |
| 2026-09-29 02:32:00Z | fulfillment_order | status_change | alex.admin@vantismedical.com | Vantis | — |
| 2026-09-29 02:32:00Z | fulfillment_order | status_change | alex.admin@vantismedical.com | Vantis | — |
| 2026-09-29 02:32:00Z | decision | basicErp.deriveSalesOrder | alex.admin@vantismedical.com | Vantis | no |
| 2026-09-29 02:32:00Z | decision | auto_approve_order | alex.admin@vantismedical.com | Vantis | yes |
| 2026-09-29 02:32:00Z | decision | extensiv_order_push.skipped | — | Vantis | no |

**Screenshots:**

![step 07 products with notes](screenshots/step-07-products-with-notes.png)

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

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

**Video recording:**

[▶ Watch step recording](videos/step-07-submit.webm)

---

### 8. Step 8: Admin removes a par agreement — ✅ PASS

**What this step proves:**

Back on the location's settings page, Alex clicks the trash icon on the URS080-SCREW row and confirms Remove. The "Par agreement removed" toast appears and only the URS080-PLATE row remains. This proves par agreements can be withdrawn per (location, SKU) with an audit event that preserves the removed par level.

**Audit events generated by this step:**

*(Evidence scoped to step execution window: 2026-09-29T02:32:36.550Z → 2026-09-29T02:32:37.589Z)*

| Time | Type | Action | User | Org | Performed |
|------|------|--------|------|-----|-----------|
| 2026-09-29 02:32:37Z | par_agreement_deleted | delete_par_agreement | alex.admin@vantismedical.com | Vantis | — |

**Screenshots:**

![step 08 confirm remove](screenshots/step-08-confirm-remove.png)

![step 08 plate remains](screenshots/step-08-plate-remains.png)

**Video recording:**

[▶ Watch step recording](videos/step-08-remove-par.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.

### Plate par agreement persisted at par 20 — ✅ PASS

**Assertion:** A par_agreements row for URS080-PLATE at the location should exist with par_level=20, created during the run.

```sql
SELECT id, org_product_id, par_level, created_at, updated_at
    FROM par_agreements
    WHERE organization_id = $1 AND location_id = $2 AND org_product_id = $3
```

| id | org_product_id | par_level | created_at | updated_at |
| --- | --- | --- | --- | --- |
| 01a0eb00-81b6-72a4-894f-d1fa81dd9699 | 08000000-0000-4000-8000-000000000011 | 20 | 2026-09-29T02:31:13.890Z | 2026-09-29T02:31:13.890Z |

### Screw par agreement removed — ✅ PASS

**Assertion:** No par_agreements row should remain for URS080-SCREW at the location after Step 8.

```sql
SELECT id, par_level FROM par_agreements
    WHERE organization_id = $1 AND location_id = $2 AND org_product_id = $3
```

*No rows returned*

### Minimum shipment sizes unchanged on the products — ✅ PASS

**Assertion:** org_products.min_shipment_quantity should still be 5 for URS080-PLATE and NULL for URS080-SCREW.

```sql
SELECT id, sku, min_shipment_quantity FROM org_products
    WHERE organization_id = $1 AND id IN ($2, $3)
    ORDER BY sku
```

| id | sku | min_shipment_quantity |
| --- | --- | --- |
| 08000000-0000-4000-8000-000000000011 | URS080-PLATE | 5 |
| 08000000-0000-4000-8000-000000000012 | URS080-SCREW | NULL |

### Par agreement set audit events recorded — ✅ PASS

**Assertion:** Setting each par level should write an audit_events row (event_type=par_agreement_set, action=set_par_agreement) by Alex whose payload names the location and whose secondary_object_id is the product.

```sql
SELECT id, action, user_id, secondary_object_id, payload, created_at
    FROM audit_events
    WHERE organization_id = $1
      AND created_at >= $2
      AND event_type = 'par_agreement_set'
      AND action = 'set_par_agreement'
      AND user_id = $3
      AND payload->>'locationId' = $4
    ORDER BY created_at ASC
```

| id | action | user_id | secondary_object_id | payload | created_at |
| --- | --- | --- | --- | --- | --- |
| 01a0eb00-81b8-7dbd-8c25-a02155f665a4 | set_par_agreement | f6a7b8c9-d0e1-2345-f123-456789012345 | 08000000-0000-4000-8000-000000000011 | {"parLevel":20,"locationId":"08000000-0000-4000-8000-000000000001","orgProductId":"08000000-0000-4000-8000-000000000011"} | 2026-09-29T02:31:13.890Z |
| 01a0eb00-8ff4-72a8-a012-ee2346f3703e | set_par_agreement | f6a7b8c9-d0e1-2345-f123-456789012345 | 08000000-0000-4000-8000-000000000012 | {"parLevel":20,"locationId":"08000000-0000-4000-8000-000000000001","orgProductId":"08000000-0000-4000-8000-000000000012"} | 2026-09-29T02:31:17.743Z |

### Par agreement deleted audit event recorded — ✅ PASS

**Assertion:** Removing the screw agreement should write an audit_events row (event_type=par_agreement_deleted, action=delete_par_agreement) by Alex naming the screw product, the location, and the removed par level 20.

```sql
SELECT id, action, user_id, secondary_object_id, payload, created_at
    FROM audit_events
    WHERE organization_id = $1
      AND created_at >= $2
      AND event_type = 'par_agreement_deleted'
      AND action = 'delete_par_agreement'
      AND user_id = $3
      AND secondary_object_id = $4
      AND payload->>'locationId' = $5
    ORDER BY created_at DESC
```

| id | action | user_id | secondary_object_id | payload | created_at |
| --- | --- | --- | --- | --- | --- |
| 01a0eb01-c610-740c-99c6-42df9b1970c0 | delete_par_agreement | f6a7b8c9-d0e1-2345-f123-456789012345 | 08000000-0000-4000-8000-000000000012 | {"parLevel":20,"locationId":"08000000-0000-4000-8000-000000000001","orgProductId":"08000000-0000-4000-8000-000000000012"} | 2026-09-29T02:32:37.132Z |

### Replenishment task linked to the location and supplying manufacturer — ✅ PASS

**Assertion:** The checklist item should have criteria_type=inventory.par_replenishment, manufacturerOrganizationId=<supplying manufacturer> in criteria_config and metadata, linked_object_id=<location>, item_key=par-replenishment-<manufacturer>-<location>, and route /orders/requests/new?prefillReplenishment=1&locationId=<location>&manufacturerId=<manufacturer>.

```sql
SELECT id, status, criteria_type, criteria_config, linked_object_id, route, item_key, metadata
    FROM checklist_items
    WHERE organization_id = $1 AND id = $2
```

| id | status | criteria_type | criteria_config | linked_object_id | route | item_key | metadata |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 08000000-0000-4000-8000-000000000042 | ready | inventory.par_replenishment | `{"type":"inventory.par_replenishment","raisedFor":"2026-09-29","manufacturerOrganizationId":"a1b2c3d4-e5f6-7890-abcd-ef1234567890"}` | 08000000-0000-4000-8000-000000000001 | /orders/requests/new?prefillReplenishment=1&locationId=08000000-0000-4000-8000-000000000001&manufacturerId=a1b2c3d4-e5f6-7890-abcd-ef1234567890 | par-replenishment-a1b2c3d4-e5f6-7890-abcd-ef1234567890-08000000-0000-4000-8000-000000000001 | `{"type":"par_replenishment_item","products":[{"sku":"URS080-PLATE","title":"URS080 Fixation Plate","parLevel":20,"demandSource":"none","orgProductId":"08000000-0000-4000-8000-000000000011","projectedOnHandAtArrival":12,"recommendedOrderQuantity":10},{"sku":"URS080-SCREW","title":"URS080 Bone Screw","parLevel":20,"demandSource":"none","orgProductId":"08000000-0000-4000-8000-000000000012","projectedOnHandAtArrival":6,"recommendedOrderQuantity":14}],"raisedFor":"2026-09-29","locationId":"08000000-0000-4000-8000-000000000001","arrivalDate":"2026-10-02","locationName":"URS080 Lakeside Surgical Center","totalRecommendedUnits":24,"manufacturerOrganizationId":"a1b2c3d4-e5f6-7890-abcd-ef1234567890"}` |

### Replenishment order request created for the location — ✅ PASS

**Assertion:** A URS-080 order request should exist with Vantis as both requesting and fulfilling org, placed by Alex, at the seeded location and sales account, with the account order type the prefill selects (dropship) and no submission grace window (self-fulfilled orders resolve inline).

```sql
SELECT id, request_number, status, order_type, requesting_organization_id,
      fulfilling_organization_id, requested_by_user_id, location_id, sales_account_id,
      submission_grace_until, notes, created_at
    FROM order_requests
    WHERE requesting_organization_id = $1
      AND notes LIKE '%' || $2 || '%'
      AND created_at >= $3
    ORDER BY created_at DESC
```

| id | request_number | status | order_type | requesting_organization_id | fulfilling_organization_id | requested_by_user_id | location_id | sales_account_id | submission_grace_until | notes | created_at |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 01a0eb01-35f2-7235-ae9d-8f03d617fca1 | OR-1 | approved | dropship | a1b2c3d4-e5f6-7890-abcd-ef1234567890 | a1b2c3d4-e5f6-7890-abcd-ef1234567890 | f6a7b8c9-d0e1-2345-f123-456789012345 | 08000000-0000-4000-8000-000000000001 | 08000000-0000-4000-8000-000000000002 | NULL | URS-080 validation run — submitted at 2026-09-29T02:31:56.835Z | 2026-09-29T02:32:00.204Z |

### Order items carry the forecast-recommended quantities — ✅ PASS

**Assertion:** The order should have exactly two items: URS080-PLATE × 10 and URS080-SCREW × 14.

```sql
SELECT oi.id, oi.product_id, p.sku, oi.requested_quantity, oi.approved_quantity,
      oi.pending_quantity, oi.rejected_quantity
    FROM order_request_items oi
    JOIN org_products p ON p.id = oi.product_id
    WHERE oi.order_request_id = $1
    ORDER BY p.sku
```

| id | product_id | sku | requested_quantity | approved_quantity | pending_quantity | rejected_quantity |
| --- | --- | --- | --- | --- | --- | --- |
| 01a0eb01-35f9-7104-8ece-b193c121c18a | 08000000-0000-4000-8000-000000000011 | URS080-PLATE | 10 | 10 | 0 | 0 |
| 01a0eb01-35f9-7104-8ece-b192eedc6441 | 08000000-0000-4000-8000-000000000012 | URS080-SCREW | 14 | 14 | 0 | 0 |

### Self-fulfilled order auto-approved inline — ✅ PASS

**Assertion:** With Vantis fulfilling its own request and no approval threshold on the catalog rows, the order should be status=approved with approved_quantity equal to requested_quantity on every item.

```sql
-- status from the order row and approved_quantity from the item rows above
```

| status | items |
| --- | --- |
| approved | `["URS080-PLATE: 10/10","URS080-SCREW: 14/14"]` |

### Order creation and auto-approval decisions recorded — ✅ PASS

**Assertion:** Submitting should log decision audit rows for the order: action='order_request_created' (performed=true) and action='auto_approve_order' (performed=true).

```sql
SELECT id, action, payload->>'performed' AS performed, payload->>'reason' AS reason, created_at
    FROM audit_events
    WHERE organization_id = $1
      AND created_at >= $2
      AND event_type = 'decision'
      AND action IN ('order_request_created', 'auto_approve_order')
      AND object_id = $3
    ORDER BY created_at ASC
```

| id | action | performed | reason | created_at |
| --- | --- | --- | --- | --- |
| 01a0eb01-3645-765c-aea2-7a3258a1652a | auto_approve_order | true | Auto-approved 2 of 2 items | 2026-09-29T02:32:00.204Z |
| 01a0eb01-35f4-7983-b2cb-c4765132fd65 | order_request_created | true | Order request OR-1 created (importSource=manual) | 2026-09-29T02:32:00.204Z |

### Multi-tenant isolation: Corveta sees no URS-080 rows — ✅ PASS

**Assertion:** Corveta (the other demo org) should own zero par agreements, products, checklist items, or order requests tied to the URS-080 location or SKUs.

```sql
SELECT
      (SELECT COUNT(*)::int FROM par_agreements
        WHERE organization_id = $1 AND location_id = $2) AS corveta_par_agreements,
      (SELECT COUNT(*)::int FROM org_products
        WHERE organization_id = $1 AND sku LIKE 'URS080-%') AS corveta_products,
      (SELECT COUNT(*)::int FROM checklist_items
        WHERE organization_id = $1 AND linked_object_id = $2) AS corveta_checklist_items,
      (SELECT COUNT(*)::int FROM order_requests
        WHERE (requesting_organization_id = $1 OR fulfilling_organization_id = $1)
          AND location_id = $2) AS corveta_order_requests
```

| corveta_par_agreements | corveta_products | corveta_checklist_items | corveta_order_requests |
| --- | --- | --- | --- |
| 0 | 0 | 0 | 0 |

## 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: Admin sets par levels at the location | `par_agreement_set:set_par_agreement` | ✅ |
| Step 7: Admin submits the replenishment order | `decision:order_request_created` | ✅ |
| Step 7: Admin submits the replenishment order | `decision:auto_approve_order` | ✅ |
| Step 8: Admin removes a par agreement | `par_agreement_deleted:delete_par_agreement` | ✅ |

## 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-09-29T02:30:58.660Z

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

19 event(s) captured:

| Time | Type | Action | User | Org | Object ID | Performed | Reason |
|------|------|--------|------|-----|-----------|-----------|--------|
| 2026-09-29 02:31:05Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:31:13Z | par_agreement_set | set_par_agreement | alex.admin@vantismedical.com | Vantis | 01a0eb00-81b6-72a4-894f-d1fa81dd9699 | — |  |
| 2026-09-29 02:31:17Z | par_agreement_set | set_par_agreement | alex.admin@vantismedical.com | Vantis | 01a0eb00-8ff2-78ed-a7b6-cc702f124dc8 | — |  |
| 2026-09-29 02:31:20Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:31:27Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:31:33Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:31:39Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:31:46Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:31:52Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:32:00Z | decision | representatives.gate_rep_action | alex.admin@vantismedical.com | Vantis | a1b2c3d4-e5f6-7890-abcd-ef1234567890 | no | no_blocking_relationship |
| 2026-09-29 02:32:00Z | decision | order_request_created | alex.admin@vantismedical.com | Vantis | 01a0eb01-35f2-7235-ae9d-8f03d617fca1 | yes | Order request OR-1 created (importSource=manual) |
| 2026-09-29 02:32:00Z | fulfillment_order | status_change | alex.admin@vantismedical.com | Vantis | 01a0eb01-3611-789b-84ea-5ec6a41d42ca | — | Fulfillment order created from approved items |
| 2026-09-29 02:32:00Z | fulfillment_order | status_change | alex.admin@vantismedical.com | Vantis | 01a0eb01-3611-789b-84ea-5ec6a41d42ca | — | Order automatically submitted for fulfillment |
| 2026-09-29 02:32:00Z | decision | basicErp.deriveSalesOrder | alex.admin@vantismedical.com | Vantis | 01a0eb01-35f2-7235-ae9d-8f03d617fca1 | no | flag_disabled |
| 2026-09-29 02:32:00Z | decision | auto_approve_order | alex.admin@vantismedical.com | Vantis | 01a0eb01-35f2-7235-ae9d-8f03d617fca1 | yes | Auto-approved 2 of 2 items |
| 2026-09-29 02:32:00Z | decision | extensiv_order_push.skipped | — | Vantis | 01a0eb01-3611-789b-84ea-5ec6a41d42ca | no | wms_feature_flag_disabled |
| 2026-09-29 02:32:02Z | transactional_email | order_created | — | Vantis | 01a0eb01-3611-789b-84ea-5ec6a41d42ca | — |  |
| 2026-09-29 02:32:32Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — |  |
| 2026-09-29 02:32:37Z | par_agreement_deleted | delete_par_agreement | alex.admin@vantismedical.com | Vantis | 01a0eb00-8ff2-78ed-a7b6-cc702f124dc8 | — |  |

## Email Evidence

1 notification email(s) were captured during this test run. Each email is rendered as a screenshot for compliance review.

### 1. Drop-Ship Order Created - OR-1-FO-1

**Template:** `Drop-Ship_Order_Created_-_OR-1-FO-1`

![Drop-Ship Order Created - OR-1-FO-1](screenshots/emails/2026-09-29T02-32-02-203Z-Drop-Ship_Order_Created_-_OR-1-FO-1.png)