📦 Allocation
Soft Allocation Status
Each open shipment has a soft_allocation_status field with 3 possible values:
| Value | Label | Meaning |
|---|
| 1 | No Allocation | No stock has been reserved for any line in this order |
| 2 | Partial | Some but not all lines have stock reserved |
| 3 | Fully Allocated | All lines have sufficient stock reserved to fulfil the order |
Leading Status (Outbound Flow)
| ID | Status | Meaning |
|---|
| 1 | In Pool | Order created, not yet waved |
| 2 | In Wave | Included in a pick wave |
| 3 | Pick Pending | Pick job created, awaiting picker |
| 4 | Consolidation Pending | Picking done, awaiting consolidation |
| 5 | Pack Pending | Ready to pack |
| 6 | Staging Pending | Packed, awaiting staging to dispatch area |
| 7 | Consigning Pending | Staged, awaiting carrier consignment |
| 8 | Awaiting Dispatch / Loading Pending | Consigned, awaiting physical loading onto vehicle |
| 9 | Closed | Order dispatched and closed, only terminal status |
Fully Allocated % (thresholds)
Fully Allocated % = fully allocated orders ÷ total open orders × 100
| Threshold | Status |
|---|
| ≥ 85% | 🟢 ON TARGET |
| 70–84% | 🟡 WATCH |
| < 70% | 🔴 ALERT |
Shipments are fetched in pages of 100, up to 2000 rows per load. To see all shipments beyond 2000, use date filters to scope to a smaller window.
📈 Fulfilment Performance
Fulfillable Revenue (Revenue-Weighted)
Fulfillable Revenue ÷ Total Revenue × 100. Only fully allocated orders contribute to Fulfillable Revenue. This is the primary fulfilment metric as it weights by order value.
Fulfillable Order Volume
Fully Allocated Orders ÷ Total Open Orders × 100. Unweighted: each order counts equally regardless of value.
Pergola Revenue (80%) / Addon Revenue (20%)
Total revenue is split 80/20 between core pergola products and add-ons. Used for margin analysis but not for the fulfilment calculation itself.
SKU Allocation Performance
Built live from open shipment-detail lines (statuses 1–8), aggregated per SKU per warehouse:
| Field | Calculation |
|---|
| Total Units | Σ line quantity |
| Allocated Units | Σ soft_allocated_qty (clamped to line quantity) |
| Pooled Units | Σ (quantity − soft_allocated_qty), ordered but not yet allocated |
| Allocation Rate % | Allocated Units ÷ Total Units × 100 (unit-weighted) |
| Lines Allocated | count of fully-allocated lines (soft_allocated_qty ≥ quantity) |
| Line Allocation % | Lines Allocated ÷ Detail Lines × 100 (line-weighted, differs from the unit-weighted rate) |
| Orders Containing SKU | distinct shipment headers containing the SKU |
This is order-line SKU level (the SKU as it appears on the order line). It is not BOM-exploded to child components. That requires the item-assembly-component expansion which runs in the GAS pipeline, not the browser.
Fulfilment thresholds
| Threshold | Status |
|---|
| ≥ 90% | 🟢 ON TARGET |
| 80–89% | 🟡 WATCH |
| < 80% | 🔴 ALERT |
🔄 Cycle Count
Accuracy %
Accurate Lines ÷ Count Lines × 100. A line is accurate when the physical count matches the system quantity exactly (zero variance).
Unit Variance
Absolute difference between counted quantity and system quantity, summed across all lines in the plan. Positive = surplus; negative = deficit.
Unit Accuracy % (IRA)
Inventory Record Accuracy, unit-weighted: (System Units − Shortfall Units − Overage Units) ÷ System Units × 100. Where line Accuracy % scores each line right or wrong, Unit Accuracy weights by how many units were off, so one large miscount is penalised more than a single-unit slip. Shown per warehouse in the CC Warehouse Summary and per plan in the CC Plan Detail.
Shortfall & Overage Units
Shortfall = units the system expected that were not physically there (counted < system; missing stock). Overage = units physically present beyond the system count (counted > system; surplus). Unit Variance is the net of the two; splitting it into shortfall and overage shows the direction of the error, which nets out in a plain variance total.
Inventory vs User-Initiated Counts
Cycle counts split into two types by their number of locations:
| Type | Definition |
|---|
| Open Inventory Cycle Counts | Planned multi-location counts (more than 1 location). These are the substantive counts shown in the CC Plan Detail list. |
| User-Initiated Cycle Counts | Single-location spot checks (1 location), typically triggered ad-hoc by an operator. Summarised in the KPI cards but excluded from the detail list to keep it readable. |
| Total Open Cycle Counts | Sum of the two above, for plans not yet Closed. |
Short-Pick Frequency (User-Initiated zone)
Single-location user-initiated counts are typically raised when an item can't be found at its pick face (a short-pick), triggering a recount of that position. There is no WMS reason field and these plans record no quantities, so the amber "User-Initiated Counts" zone tracks frequency only (how often, and which locations recur, per ISO week) as an inferred operational signal. It is deliberately kept separate from the inventory-count accuracy metrics, which measure counting correctness rather than pick-face reliability.
Plans With Counting & Weighting
All plans (including single-location spot checks) are counted in the plan totals. Accuracy is a line-weighted average: each plan contributes to the overall accuracy in proportion to its number of counted lines. A 1-line spot check therefore moves the number far less than a 2,000-line full count. Plans with zero counted lines are still counted as plans but add no weight to the accuracy figure (they contribute 0 to both accurate lines and total lines).
Accuracy % = Σ(accurate lines across all plans) ÷ Σ(counted lines across all plans) × 100. This is mathematically a weighted average where the weight is each plan's line count.
Days to Complete
Date Completed − Plan Created Date. Measures how long from plan creation to the plan reaching Closed status.
CC Accuracy thresholds
| Threshold | Status |
|---|
| ≥ 95% | 🟢 ON TARGET |
| 90–94% | 🟡 WATCH |
| < 90% | 🔴 ALERT |
⚙️ Job Performance
Job Timing (Duration)
Each job in the Job Enquiry data is a unit of work for a specific order, job class and job type. Its duration is computed directly from the job's own timestamps:
Duration = updated_at − created_at
created_at is when the job was created (this matches the creation timestamp in the process log). updated_at is when the job reached its final state, i.e. completed/closed. The difference is the real time that specific job took, attributed to the user who completed it.
Stale jobs: jobs whose age from creation exceeds 3 days (still open, or closed long after creation). These are flagged "stale", counted in the Stale Tasks KPI, and excluded from average/median duration so they don't distort throughput. They still appear in detail lists.
Performance KPIs
| KPI | Meaning |
|---|
| Total Jobs | Count of jobs for the current filters, split into open and closed |
| Stale Tasks | Count of jobs older than 3 days from creation |
The per-job duration KPIs (Median / Average Process Time and Duration Trend), the Avg Processing Time by Type chart, and the Avg Time columns were removed from this tab: job updated_at − created_at is wave/batch-distorted and misleading. Use the Work Time tab for trustworthy hands-on timing. (Duration still underlies the Stale Tasks flag, and the completion-time figures on the User Performance and Historical Trends tabs.)
User Performance Summary
A per-user log on the Job Performance tab, toggle between User × Job Type (one row per user per job type) and User only (one row per user, all types combined). For each group it shows jobs done (closed), open jobs, total instructions, and stale count. Respects the warehouse, date, and job-type filters. Export to CSV for record-keeping. This is the recommended format for a job-performance log: one row per user(×type) with counts. No order-level detail needed.
Job Type as primary dimension
The Job Type filter in the top bar drives every job metric (Job Performance, User Performance, and the Fulfilment job tables/trends), alongside the warehouse and date filters. Job type (Shipment Picking, Packing, Consolidation, Dispatching, Staging, etc.) is the most granular way to identify what work an order required.
User Created Job: when a job has no assignee set, it is labelled "User Created Job" rather than left blank. These are typically ad-hoc jobs initiated directly by an operator.
Closed Jobs
A job is considered closed when it is present in the all-jobs response (close=0) but absent from the open-jobs response (close=1). The updated_at timestamp of a closed job is used as the closed_at proxy.
Instructions
jobInstruction = number of pick/pack/move steps completed within the job. Higher = more complex job (multi-line or multi-location).
🚚 Fulfilment Snapshot
Orders by Stage
| Row | Leading Status |
|---|
| In Pool / Pending | status 1 |
| In Wave / Planned | status 2 |
| Being Processed | statuses 3–7 (Pick Pending → Consigning Pending) |
| Awaiting Dispatch (pick-up pending) | status 8 |
| Total Open Orders | statuses 1–8 (excludes closed) |
Order / Job Volume Trend
Orders created (or jobs closed) per day over the selected trend window (7, 14, or 30 days, set via the selector at the top of the tab), per warehouse. Order volume includes closed orders (status 9) fetched via an updated-date window covering 30 days, so the trend reflects true daily volume, not just currently-open orders.
Jobs
| Row | Definition |
|---|
| Jobs Pending | open jobs with no assignee |
| Jobs Assigned | open jobs with an assignee |
| Jobs Completed Today | jobs closed since midnight today |
| Total Open Jobs | all jobs not yet closed |
Shipping Volume per Warehouse
Every SKU ranked by Total Units across open shipment-detail lines, filtered by the global warehouse chips (paginated). Reflects current open-order demand by SKU.
Uses open-order demand (shipment-detail for statuses 1–8). It is not historical shipped volume. That would require pulling closed-order detail lines, which is a much larger fetch.
📅 Historical Trends
Reads accumulated daily snapshots from the Supabase job_perf_daily table (written each day by the collector). Unlike the live tabs, this shows performance over time.
| Element | Meaning |
|---|
| Jobs Completed per Day | Sum of closed jobs per day across the selected user/type filters |
| Median / Average Time Trend | Daily completion time, weighted by jobs done so busy days count proportionally |
| Volume Trend | Second half of the period vs first half. ▲ green = doing more, ▼ red = doing less |
| Stale (period) | Total jobs older than 3 days from creation across the window |
Data accumulates from the day the collector started running. Each daily snapshot is immutable history: a job's duration is recorded as it was that day, so later bulk-updates don't rewrite the past.
👤 User Performance
Worker Attribution (Updated By)
Per-user performance is attributed to the Updated By user, the operative who completed the job. This field is populated on virtually every job, whereas the assignee field is only set about half the time, so Updated By gives complete and reliable attribution of who actually did the work. (The Jobs tab's "Jobs Assigned / Pending" split still uses the assignee field, since that reflects live assignment state.)
Closed (lookback)
Number of jobs closed by this user within the selected lookback window. Used to measure throughput.
Avg Close Time
Average processing duration across all closed jobs for this user within the lookback window. Colour coded: green <5min, amber <1h, red ≥1h.
Instructions
Total instruction steps completed by this user. A proxy for workload volume when job counts alone don't capture complexity.
