Repository navigation
WIP, yield and throughput dashboard tiles #343
Description
Activity
One more definition to settle before the yield tile, from a food-processing deployment (fresh
vegetable peeling) where "yield" means something else again.There is already a third "yield" in core
The work order report labels produced ÷ planned as "Yield"
(resources/js/Pages/admin/reports/Show.jsx:59), andlang/pl.jsontranslates it as "Uzysk".
In food processing "uzysk" / "yield" is the mass yield: kg of finished product per kg of raw
material consumed. For an order we reproduce in our test setup — 2 700 kg of peeled onion from
5 781 kg of raw onion, i.e. a plant yield of 46.7 % — the report's "Yield" works out to
135 %, because the planned quantity there is a technical figure (2 000 kg). The two words
already mean different things on screen — so whatever definition the tile gets, it would help to
fix the label in the report too.Suggestion: three named measures instead of one "yield"
Measure Formula Data in core Quality yield (good rate) (produced − scrap) ÷ produced produced_qty,scrap_qty(batch; per step since the flow ledger)Plan attainment produced ÷ planned produced_qty,planned_qty— what the report calls "Yield" todayMaterial (mass) yield output ÷ Σ consumed input work_orders.produced_qty÷ Σmaterial_allocations.consumed_qtyof the orderEach with its own translation key, so no locale can map two of them to the same word.
Notes on material yield:
- Only when the units agree — product and consumed materials in the same unit (kg/kg).
Core does not convert units (material_sources.unit_mapping/conversion_factorare not used
by any service), so a pcs product over kg materials should show "n/a", not a number. material_allocations.consumed_qtyexists with or without lot tracking. With lot tracking on,
batch_step_lot_consumption.quantity_consumedgives the same total per lot, which allows a
breakdown by supplier lot later — not needed for the tile.- Typical values are far from 100 % (peeling loses 35–55 %), so tile thresholds or colours tuned
for quality yield would mark every order red. Thresholds per product would be needed, or none. - Same shift-boundary rule as throughput: a night shift's consumption and output belong to the
day the shift started.
Happy to check the tile against our data (orders with lot-level consumption) once there is a branch.
- Only when the units agree — product and consumed materials in the same unit (kg/kg).
Source: medical device customer's capability tracker — "Real-time view of WIP / Yield / Throughput / Downtime", marked Partial. Moved here from
Mes-Open/OpenMes-Enterprise#49; the dashboard is core.Today
Downtime is complete:
ProductionDowntime,DowntimeReason, classification, escalation and the shift monitor. The dashboard shows OEE, work orders, pending inspections, materials, inbound QC and scrap.The data behind the other three is already captured —
produced_qty,scrap_qty, step states,duration_minutes,actual_setup_minutes,actual_run_minutes,actual_elapsed_minutes. Grep finds no tile, controller method or page computing WIP, yield or throughput.So this is presentation, not a data model change.
Where it plugs in
DashboardControlleralready has the shape for this. Tiles are gated onDashboardWidget::enabled()->pluck('widget_id')(line 48) and each statistic is a lazy Inertia prop that takes$enabledWidgetsand returns early when its widget is off (scrapStats,materialsStats,inboundQcStats, …). A new tile is awidget_id, one method following that pattern, and a block inPages/admin/dashboard-widgets/Index.jsx.Being lazy props, tiles nobody enabled cost nothing — which matters here, because the throughput trend is the most expensive query of the three.
To build
Watch for
produced_qtyagainstscrap_qtyandproduced_qtyagainst the order quantity give different numbers, and a customer who compares the tile with their own report will not accept "it depends which you meant".