Skip to content

Reporting

theGreenGuy edited this page Jun 12, 2026 · 6 revisions

Reporting

A dedicated Reporting category in the sidebar (collapsible, like Operations / Engineering) with five report screens, fed by aggregate endpoints in the owning services. History accumulates from deployment day (daily counters and snapshots); 90-day windows fill over time, and 14-day forecasts use a weekday-seasonal moving average rendered as a dashed continuation.

Screen What it shows Data source
Material Flow Scans / no-reads / unknowns per scan point per day; a "scanners needing attention" table (error rate, trend slope, sparkline; flagged at >2% or rising); transit-time p50/p95 per day; a 3D conveyor traffic heatmap (the editor/twin scene with sections tinted by traffic) flow GET /api/flow/reports/scan-quality, /traffic, /transit-times (live counters bumped inside the per-scan routing decision: scan_stat, edge_traffic)
ASRS Storage density in figures and % per block, 90-day history + 14-day forecast; a 3D rack-cell movement heatmap; storage movements per device (shuttle/crane/...) inventory GET /api/inventory/reports/storage-density (daily ShedLock snapshot sweeper + on-demand today), flow /storage-movements, /device-movements
Stock Per-SKU quantities split available / allocated / unavailable (UNKNOWN-location stock counts as unavailable) inventory GET /api/inventory/reports/stock-by-sku
Inbound Expected (received, no work yet) vs started vs active; per-day received/started/completed over 90 days; 24-hour day map with peak hours order-management GET /api/orders/reports/flow?direction=INBOUND
Outbound Same shape for outbound (expected = received but not released) ...?direction=OUTBOUND

Spec: docs/reportingScope.md (product minimum set + research enrichment). Demo-mode reset purges the flow counters so reports stay consistent after a reset. The outbound "completed" series approximates with the order's last update timestamp (no dispatch timestamp exists yet; tracked as a follow-up).

Clone this wiki locally