design

Production Inventory Manager — design notes

Persona surface for the Supply Chain & Parts, Vehicle Operations and Production — Product Specification and §7.10 of the Forge Floor App PRD (FR-FS1 to FR-FS9). Web flow, canonical Atlas shell (1440).

Persona

The Production Inventory Manager stewards one thing: the Production pool at Sango, the shared team stock the Forge floor app draws on. Personal custody is gone — stock is received into the pool, the BOM gate reads the pool, and starting a step draws from the pool — so somebody has to own the pool itself. That is this person.

They sit between two parties who never used to have anything between them: the floor, which raises requests, and the central warehouse, which fulfils them.

Problems being solved

• Any requester could reach the warehouse directly. A technician short of ties raised a request and the warehouse saw it as a peer of every other request, with no one in between who knew whether the pool already held the part. The gate is this console’s first job.
• Nobody owned the pool’s numbers. On-hand, thresholds and the movement history existed per item but had no surface that read them together, so a shortfall was noticed when a step could not start.
• The line was blocked by lead time, not by stock. A procurement request takes days to approve and weeks to deliver. Reading a shortfall on the day a work order opens is reading it far too late. The forecast exists to turn that round: it states the date a line has to be ordered by, not the day it ran out.
• What the floor could not draw again left with no record. A disc run to half, an offcut, a stripped crate — they left the shelf silently, and anything still worth money left with them.

Navigation

Sidebar in three groups: Overview — Dashboard. Inventory — Stock, Requests, Ledger, Recycle. Planning — BOM forecast. Dashboard is the landing view. Stock, Requests and BOM forecast carry a count in the rail; the count turns red when it is critical, waiting on a decision, or already late to order. Stock sits beside the requests that move it, because reading a line and asking for more of it are one habit.

A request is one tab, not four, and one record, not two. The gate, what went to the warehouse, what is going back and what is coming in are one path, so they are four panels of a single Requests page — Approvals · Requests · Outgoing · Incoming, the words the Production and Retrofit Station consoles use — and the gate is the panel it opens on, because deciding is the daily job.

A request is REQ-#### from the floor to the shelf. It does not become a differently-numbered record when it clears the gate; its status moves, exactly as it does on the Production Manager console where REQ-1044 sits With inventory and REQ-1040 reads Requested. The ladder is With inventory → Requested → Awaiting receipt → Fulfilled, with Partially fulfilled and Rejected from the warehouse and Declined from the gate. Returns are numbered RET-####, as the Inventory Manager’s returns desk numbers them.

How a line is read

The console already knows the future — the open work orders and their bills of materials — so nothing here is computed from a trailing average when the schedule can be read instead.

Cover is the day the committed work exhausts a line, taken in due-date order; the fortnight’s draw rate stands in only when no scheduled work draws it, and a line nothing has drawn says “Not drawn lately” rather than a false zero.

Status is the estate’s, not this console’s. A line is classified the way ItemStockStatus classifies one: ATP — what the pool holds plus what the warehouse has fulfilled and the pool has not received yet — read against the line’s two thresholds. At or under zero is Stock out, at or under critical is Critical, at or under low is Below target, otherwise Healthy. The pool sets its own thresholds, line by line, away from the warehouse figures it inherited; it does not get its own vocabulary or its own arithmetic to go with them.

Cover is stated beside the status rather than folded into it, and the dashboard reads the two together: which line runs out before a replacement can land, which committed work order cannot run, and whether the warehouse is the reason.

One set of movements

Every figure on every page is read off one seed. On-hand is an opening balance plus every movement, never a second number held beside the ledger (OPENING, movedOf, ohOf). Burn per day is the draws of the last fourteen days over fourteen; the forecast shortfall is demand against on-hand plus what is already on its way. Logging a leftover, receiving a delivery or returning stock to the warehouse each write a movement, so the stock page moves with them. That last one matters: the ledger’s vocabulary has always named Returned to warehouse, and until the Outgoing panel existed nothing could produce one. A regression test asserts that for every item the seeded on-hand equals its opening balance plus its movements, because the failure this design is most exposed to is two pages stating different numbers for the same fact.

Views

Slug	What it does
dashboard	Numbers and charts, no table — the tables live where the records live. Four KPIs, each read against something: Awaiting my approval (with the date the oldest was raised), Under their thresholds (naming the line that runs out first), Short for planned work over the next eight weeks (of how many open work orders), Recyclable value held (with how many are still in the bay). Then a .chart-row: cover against replacement time, the lines whose days of cover sit closest to the days a replacement takes, as .cbar proportions; beside it warehouse fulfilment, the share of this pool’s requests that came back fulfilled, partially fulfilled or rejected — which is how the pool tells a stock problem from a supply problem.
stock	The pool. KPIs: items on hand, below target, critical (naming what is critical and what is stocked out), awaiting receipt. Table, matched to the Items view the Production and Retrofit Station consoles already ship: the catalogue thumbnail (.it-thumb) beside the item name with its category beneath · tracking (Serialized / Consumable) · on hand with its unit inline · what the warehouse holds, because the first question after “am I short” is “can they even send it” · health as a proportion bar with its badge · days of cover · a per-row Request link. Search plus category, health and tracking filters; Export. Row-click opens the item.
item	The item record (inner page, .pg-back to Stock). A .kv-grid of category, tracking and unit, on hand, awaiting receipt, the low and critical thresholds with the warehouse figure each was inherited from, who set them and when, drawn per day, days of cover, replacement lead time split into approval and delivery, and what the planned work needs over eight weeks. Set thresholds sits in the page head: a pool that goes through four hundred ties a week is not protected by a low point drawn for a warehouse shelf that turns over monthly, so each line can be set away from the figure it inherited. The dialog does the arithmetic rather than leaving it to be guessed — what this pool draws per day, how long a replacement takes, and the quantity drawn while it is in flight — and says so in red when the low point entered sits below that quantity, since such a threshold cannot leave time to order. Critical below low is enforced. Use the warehouse figures puts the line back on what it inherited. Then .pseg tabs: Movements — this item’s slice of the ledger, filterable by kind, with Export — and Units, the serials with their state and what each was drawn against. The Units tab is hidden for a consumable rather than shown empty.
ledger	Append-only. A movement is never edited or deleted. KPIs: movements this week, draws this week and across how many work orders, receipts, and what left the shelf over thirty days. The table reads When · Movement · Item · Quantity · Who · Against, the quantity signed and coloured by what the sign means, the movement kind carrying a dot per class (received, drawn, written off). It answers the three questions §7.10 asks of it — per person, per work order, per item — through a Filters dialog holding movement, item, who and work order, with the date window inline and an active-filter count on the button. Paginated at sixty; CSV export, which is a web feature.
requests	The whole path, in four .pseg panels. Approvals — the gate. The full log, not just the queue: Request · Raised by · Items · For · Outcome · Raised · Decided · View, with outcome, requester and urgency filters. A decision updates the row in place and is retained as history. Opening a request shows what it asked for against what the pool actually holds, line by line, with an uncoverable line in red. Approve raises a warehouse request and the record names what it became; Reject requires a reason, and that reason is what the requester reads. The count of what is waiting rides the tab itself as a .seg-count. Requests — Request · Items · Origin (raised by me, no approval step / approved from the floor, naming the request and the requester) · Status · Raised · Updated. Outgoing — the returns register: stock going back to the warehouse, which is one leg of the same path rather than a stop of its own. Incoming — the fulfilled lines still to reach the shelf, each with Receive. A request is received where it is read: an Awaiting-receipt row on the Requests panel carries its own Receive, which takes the whole request, where Incoming takes one line at a time because that is the grain it lists. Either route writes the movement and raises on-hand for the whole team at once. The shared KPI row reads across the whole path: awaiting my approval · with the warehouse · awaiting receipt · short or rejected. Request from warehouse is a page-head action: a line builder showing what the pool already holds beside each line, a required need-by date and a required reason. It carries no approval step, because the person raising it is the approver.
forecast	The projection, and the reason this console exists: a procurement request takes days to approve and weeks to deliver, so reading a shortfall on the day a work order opens is reading it far too late. Three .pseg panels, because there are three questions. Work orders — the work already committed, one .rq-wo-box per open work order, naming the assembly procedure and version it was raised from, the units still to build and the due date, then every bill-of-materials line multiplied out: per unit · needed · available · short, with a Ready to run or Short N lines badge and, when it is short, Request the N short lines on the card itself. Stock is allocated across these in due-date order, so a card shows what is left for it after the work due before it; handing every work order the whole pool balance is how they all read covered while the line stops. Planned — the work the plan carries that has not been raised yet, plus anything added as a what-if, read card for card like the committed work because that is what it is: work orders not yet raised, each built to a procedure. Stock is allocated among them in due-date order after the committed work has taken its share, so a line reads left after committed work rather than the whole balance. A planned job past its due date says so, because that is the one costing the pool its lead time. Assembly procedures — every procedure’s bill of materials on its own terms: version, step count, and each item it draws per unit against what the pool holds, with a One unit buildable or Short a line badge. Each panel exports from the seed rather than from a hidden table, and the per-item roll-up — need-by from the jobs taken in due-date order, order-by from that minus lead time split into approval and delivery days — is what the page-head export carries rather than a fourth panel restating shortfalls the cards already carry.
recycle	One register, for material the floor cannot draw again. KPIs: still held · resale value held · kept out of scrap. Table: Logged (naming who) · Item (with what is left of it and the work order it came off) · Quantity · Route · Resale value · Status · Mark cleared. Log a leftover takes the quantity off the shelf as a movement and refuses a quantity the pool does not hold. What is left is Offcut · Part-used · Packaging, or Strip-out for a part taken off a chassis, which the field sets itself and locks, because a strip-out is nothing else. The route is Held for resale · Re-used here · Scrapped, and a leftover runs Held until it leaves the bay the way its route said.

What the warehouse decides is not restated here

Damage, expiry and a QA failure are not recycling. They go back on a return, and the warehouse routes them — to repair, to Procurement, or to scrap — on its own returns desk. The pool’s register offers none of those as choices and does not restate their outcomes, so there is one place each fact is decided.

It reads resale, not cost

The register does not price what was lost. This person is not being asked to watch what the estate paid for a part; they are being asked to get something back for it, so the only money on the page is a resale value, where there is one — what a scrap merchant pays for the copper, what a running engine fetches second-hand, what the deposit on a returnable crate is worth. A leftover with no market reads as a dash rather than a zero. Item cost is not in the model at all, so the ledger’s own write-off KPI is a quantity rather than naira.

What this console does not do

It does not plan work orders, author procedures or run the line — those stay with the Production Manager. It does not raise work orders either: noting that one has been raised is how a planned job stops being counted twice, and the note mints nothing, leaves the job in sight and can be undone. It does not hold the catalogue, receive from vendors, or run batches and delivery notes — those stay with the central Inventory Manager. It does not raise purchase orders; it raises requests on the warehouse, and the warehouse goes to Procurement. It captures no lot or batch number: a batch is the warehouse’s record of a production run, not something a pool keys at receipt.

Receiving

A receipt states what was asked for as well as what turned up, so a line the warehouse cut cannot be read as a complete one, and the received quantity defaults to what was actually sent. Serials are captured the way the Inventory Manager’s receiving desk captures them: one field per serialised line taking a scan, a typed serial on Enter, or a CSV of the packing list, with removable chips and a running count. A serial the warehouse did not send is refused and the receipt is blocked while a line is short. A quantity is entered in the unit it is counted in — a poured line steps in tenths, anything counted whole steps in ones.

Notifications

The centre opens from the topbar bell and has no sidebar entry, as the Inventory Manager’s does. It is built from the pool, not seeded beside it: each floor request waiting on a decision, each line that has fallen to critical or run out, each forecast line already past its order-by date, each delivery the warehouse has fulfilled that is not on the shelf yet, each return the warehouse has not accepted, and the last few leftovers logged. Entries group by day, anything needing an action today is unread, and the dot on the bell counts real work rather than decoration.

Two of those also go by email, and the rest do not. A low threshold alert and a passed order-by date are each sent on their own, in-app and by email, because neither can wait for the next sign-in; a request waiting, a delivery to receive, a return in flight and a leftover stay in-app. A line at or below critical is not sent one by one: it goes in the bundled critical alert, one notification and one email on Monday, Wednesday and Friday at 08:00 Africa/Lagos, listing every critical line with its on-hand, its threshold and a link to it (TH-7). The threshold alerts reach the team’s manager as well as this person; the order-by alert reaches this person alone, since raising the request is their call. An alert that has already fired does not fire again until its cause changes, and duplicates within five minutes collapse into one.

Dates and actors

Every date reads as day, date and time and names who did it: “Raised Friday 21 August 2026 · 09:12 · Daniel Orji”. A decision stamps the deciding persona and the moment custody of the decision passed, which is a different fact from when the request came in.

Narrow screens

The console is laid out at 1440, but a pool gets read on the floor as well as at a desk. Below 1100px the rail drops to icons; below 820px the topbar gives up the location pill and the breadcrumb trail, the KPI row folds to two and then one, and the filter bar wraps. A wide table scrolls inside its own card — every table states its own column widths through a <colgroup>, because .tbl is table-layout:fixed and gives its first column 34% otherwise, which squeezed the last column under its own badge.

Cross-links

• The floor raises into this gate from the Forge app (Production team pool).
• An approved request lands on the Inventory Manager’s Requests surface as a facility request.
• The work orders the forecast reads are the ones the Production Manager plans and the floor runs.
• The sibling pool is the Retrofit Station Inventory Manager.