Skip to main content

What it is

One row = one procurement decision per tracked SKU. Filter action_required=true for the order list. Each row combines demand, current stock, open purchase orders, and lead times into a procurement_status: The queue computes a recommendation for every row (recommended_order_quantity, MOQ/multiple-rounded from raw_recommended_order_quantity); only the status flags say “now”. include_in_next_shipment is the ride-along flag: true when the row’s order-by date falls inside its own replenishment window (lead time + buffer + safety), something needs to be ordered, and the row isn’t blocked by data quality or lifecycle — so it rides along with the next shipment even if not yet urgent on its own. Data-freshness columns keep the agent from ordering on stale data.

How it gets data

Computed view — derived automatically from Products, Product Demand, Purchase Order Lines, and Procurement Config. Read-only; no ingest endpoint.

Fields

Identity & stock

Demand (joined from Product Demand)

Coverage & timing

Open supply (purchase orders)

Recommendation & status

Config & freshness inputs (API only)

Not registered as app columns, but returned by queries — the transparency inputs behind the status machine: All columns are read-only. The view also carries tenant_id / workspace_id for tenant isolation — filtered automatically, never selected.

Query it