Projects & the Buying Sheet

Every line on a project has an acquisition mode, set on the item:

• Purchase — bought new for this project.
• Rental — rented for the run and due back afterward.
• Owned — pulled from your own Inventory.
• Client Supplied — provided by the client, tracked but not bought.
• Other — anything that doesn't fit the above.

A line moves through status as the real-world work happens:

• Needed — identified as a requirement.
• Proposed — suggested, awaiting approval.
• Approved — signed off to acquire.
• Claimed — an owned item allocated from Inventory.
• Ordered — a purchase or rental placed.
• Shipped — on its way.
• Received — in hand.
• Installed — in place on site.
• Due Back — a rental's return window.
• Returned — sent back.
• Cancelled — no longer needed.

The dense, all-columns view of the buying sheet — every line, its status, quantity, unit cost, vendor, and acquisition mode. This is where most editing happens. Quantity always counts units. If a library item is sold as a pack (a 20-pack of cable ties, a reel of 100 connectors), the row shows how many packs that quantity works out to — '8' with '1pk' beside it — the price is per pack, and the line total is for whole packs. The wiring diagram, pick list and docs keep counting units; only the ordering math knows about packs.

A kit added to a project lands as its individual parts, not one row — each part is bought and tracked separately. A small amber kit icon next to a part's name (hover it to see which kit) is the only thing marking it as part of a bundle; group the whole sheet by kit from Group by → By kit to see every bundle's parts together.

A purchasing-focused cut of the same data: what still needs to be ordered, grouped for the person actually placing orders. This is also the view a purchasing-only share link shows a freelancer or contractor who shouldn't see the whole project.

Buy… on a line asks the one question that matters: how many did you actually get? Buy all of them and the line advances like any status change. Buy fewer — 6 of the 10 you need — and the line splits: the bought 6 become their own row (Ordered, or Received if you check "Already in hand"), and the other 4 stay behind as Needed. Nothing gets lost between "we ordered some" and "we still need the rest."

If the item is sold in packs, the dialog does the pack math for you as you type — how many packs that many units works out to, the spares you'd end up with, and the cheapest pack combination when the library has pack variants for it.

Kits work the same way one level up. Buy kit… on a kit's group header (or a selection of its rows) asks how many kits you're buying — need 10 but buying 3 for testing? Type 3, and every part line is set to three kits' worth, splitting each row as needed. You can still fine-tune any line before confirming.

The Acquired column on the Spreadsheet keeps the whole requirement readable after a split: both halves of "6 Ordered / 4 Needed" show the same 0 / 10 — climbing to 6 / 10 the moment those 6 arrive. To split a row by hand without buying anything, open it and use Split… next to Delete.

On plans that include subprojects, break a large production into smaller scoped pieces — a per-venue or per-department split, or one subproject per client site — while keeping a single project umbrella for the totals. Add one from Overview → New subproject.

A subproject's items aren't siloed off: they roll straight up into the parent's Spreadsheet, Buying view, and Pick List, automatically grouped by subproject, so you can review, buy, and manage everything from the top without opening each subproject on its own. Every edit still writes back to the item's own subproject — the parent is a lens on the whole tree, not a second copy of anything.

The Settings tab is where a project's own details live: its name, code, description and client, its status and visibility, its budget, and the dates the build runs to — design freeze, purchasing deadline, load-in, opening and strike. Each section saves on its own, so changing the status doesn't mean re-submitting everything else.

A project's budget is the umbrella over everything beneath it. A subproject's own budget is a slice of the parent's, not money on top — so breaking a build into subprojects never makes it look better funded than it is. Settings shows how much the subprojects have claimed, and says so if they add up to more than the parent has.

Readiness and spend on a project card are running totals, kept current as items move through status rather than recalculated from scratch on every view — fast, but it means a total can occasionally drift out of sync with the real items behind it, especially with subprojects involved.

If a project's numbers ever look off, open Recalculate stats from the ⋮ menu — on the project's Overview page, or on its card in the projects list. It rebuilds the numbers from the actual items on file and tells you what changed.