URS-080 · Par-level replenishment

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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:

Video recording:

---

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:

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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

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

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

Downloads

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

Feedback