Deliveries & inventory

A delivery is booked as a point on the plan with a window, so a lift never lands on top of live work. What happens after the vehicle arrives is a different question, and it is the one that decides whether the site knows what it has. SimOps answers it with one gesture: Receive — the sign-off taken at the gate, line by line, at the quantities that actually came off the truck. That gesture is what mints stock. Nothing else does.

Manifest, receipt, ledger

Three nouns, kept deliberately apart:

• A Delivery line item is one row of the manifest — what the load says it carries. Free-text description, a quantity, a unit, and optionally a link to the site's thin Material catalogue.
• A Stock lot is the received instance of that line — the parcel that is physically somewhere. It carries a location and a self-describing snapshot of the line, so it stays readable after the manifest is edited.
• A Stock event is one signed entry in the site's append-only ledger: delivery_in, consumption, loss, transfer, adjustment. A lot has no quantity column — its balance is always the sum of its events.

Because the ledger is append-only, a correction is a compensating entry, never an edit. The number nobody typed is the number you can audit.

What it does for you

• Sign-off is the receive. There is no "confirm the paperwork, then post the stock" — one action, one transaction. Where a delivered bill was uploaded and read into a draft, confirming that draft is the receipt; the document is stamped confirmed atomically with the stock it posted (see Document intake).
• A load can arrive in pieces. Receipts are repeatable: tick the lines that came, at their actual quantities, and take the next lot on the next visit. The load is closed by an explicit human "load complete" — a receipt after that is refused rather than quietly appended.
• Where it went is not optional. Every receipt names exactly one destination: a laydown ActiveArea, a point on the map (carrying its Position provenance), or a building and level. There is no unassigned landing. A parcel with no known location is not inventory, it is a rumour.
• A shortfall stays visibly short. Received-so-far is derived against the manifest per line and shown as short / in full / over — nothing is quietly corrected to make the paperwork tidy.
• Damage and wrong-item get their own row. A receive exception is captured inside the same gesture: a kind, the affected quantity, a note, and a photograph. It is deliberately not a stock event — a wrong-item delivery may stock nothing at all, and a damaged parcel may still be signed at full quantity.
• Balances by material, by place, by contractor. The ledger reads back as an on-hand roll-up, a per-place distribution, and a per-contractor position — all derived, none authored.
• Running low tells you before it stops you. A member can set a low-stock alert on their own contractor's (material, unit) and get told when the balance crosses it.

What it deliberately does not do

Completion is not receipt. Moving a delivery to completed posts no stock whatsoever; the status spine (scheduled → in_progress → completed, with cancelled as the off-ramp) and the ledger are separate questions on purpose, and a receipt never touches the status.

Units never convert. A unit is a free string with per-site suggestions; two lots merge into one balance only when material and unit match exactly. Inventing a conversion table is how a system starts lying about tonnes.

Nothing reserves, nothing auto-consumes. Material is tied to work at close-out through the token that used it, not by a booking made in advance. And short and delayed are not exception kinds — both are already derivable (received-so-far against the manifest; the delivery_in time against the scheduled window), so only the two facts nothing else in the system could state get a row of their own.

Where to find it

• On the plan. Select a delivery pin: its properties panel carries the manifest editor (with the per-line variance) and the Receive form.
• Commercial home (I) → Inventory. The site-wide reading of the ledger — the stock roll-up, the needs-placing queue, and the delivery documents — with a place chip that hands back to the map.

Reading the ledger is the ordinary entity_view band; receiving and every other ledger write is entity_edit plus the delivery's own contractor ownership check behind it. Low-stock alerts are the one deliberate break in the admin-only notification-rule monopoly: stock_threshold_author lets a member author them, always stamped to their own Contractor.

See it / try it

Where to go next

• Receiving a delivery — the how-to: the manifest, the sign-off, short loads, damage, and where the stock landed.
• For contractors — booking the load onto the plan in the first place.