What it is
One row = one procurement decision per tracked SKU. Filteraction_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.
