> ## Documentation Index > Fetch the complete documentation index at: https://docs.spherecast.ai/llms.txt > Use this file to discover all available pages before exploring further. # Work orders > How a work order builds a finished good from its bill of materials, and how to read built vs. planned and committed vs. needed. ## What this page is for A **Work Order (WO)** is an order to **manufacture a finished good** — usually at a co-manufacturer (a "co-man," a factory that builds product for you) — by consuming the components listed in its recipe. When the build finishes, the finished good lands in a **destination warehouse** ready to ship or sell. This page explains the two numbers planners ask about most: how much you asked to be built versus how much has actually been made, and, for each component, how much is reserved to the order versus how much the order still needs. Get those straight and a work order reads at a glance. ## The header fields | Field | What it means | | ---------------------- | ---------------------------------------------------------------------------------------------------- | | **Number** | The work order's identifier. | | **Produced product** | The finished good this order builds. | | **Bill of materials** | The recipe (BOM) used for the build — the components and how many of each go into one finished good. | | **Quantity** | The **planned** quantity to build — the target output you ordered. | | **Built** | How much has **actually** been produced so far. Starts empty and grows as the co-man reports output. | | **Supplier** | The co-manufacturer doing the build. | | **Destination** | The warehouse where the finished good is stored when it is done. | | **Start date** | When production begins. Must be before the end date. | | **End date** | When production is due. | | **Notes** | Free-text notes for your team. | | **Assignee / Creator** | Who owns the order and who created it. | A **BOM (Bill of Materials)** is the recipe: the components consumed and the count of each per one finished good. ## Quantities explained: built vs. planned This is the distinction to lock in: * **Quantity is what you asked to be built.** It is the target — the order you placed with the co-man. * **Built is what has actually been made.** It starts at zero and climbs as production reports output. Built is what moves the order through its production statuses. As soon as any units are reported, the order becomes **Partially Built**; once Built reaches Quantity, it is **Built**. You watch Built to know whether the run is on track, behind, or complete — Quantity never changes on its own, but Built tells you the real story on the floor. ## The components table Beneath the header, each component in the BOM gets a row. The columns tell you whether the build can actually be supplied: | Column | What it means | | ------------- | -------------------------------------------------------------------------------------------------------------- | | **Committed** | The amount of that component already **reserved/allocated to this work order**, so it can't be used elsewhere. | | **Needed** | How much this order requires = the BOM's units-per-finished-good × the build quantity. | | **Available** | How much of the component is on hand **at this order's manufacturer**. | | **Others** | Stock of the component at **other manufacturer locations**. | | **Supplier** | The source that provides the component. | Two more numbers help you spot a gap: * **On order** — component stock already inbound to this manufacturer (a purchase or transfer on its way). * **Back order** — the shortfall the order still can't cover: **back order = max(0, Needed − Committed − Available)**. If that comes out to zero, the component is covered; if it is positive, you are short by that amount. A per-order **availability indicator** summarizes all of this at a glance: **all components covered**, **at least one component short**, or **not computable (n.a.)** when the numbers can't be worked out yet. To close a shortfall, a work order can be **mapped** (linked) to the Purchase Orders and Transfer Orders that replenish its components, and to **predecessor / successor work orders** when one build feeds another. ## Statuses Before a work order is written to your ERP it carries a **Spherecast-only** status; after it is written it takes on a real status from your ERP. (An **ERP** is your company's system of record. The status names below are NetSuite-style examples — the exact wording varies by company.) | Status | What it means | | -------------------- | --------------------------------------------------------------------- | | **Recommended** | A system proposal. Not a real order yet. | | **Draft** | You started an order but haven't submitted it. Still Spherecast-only. | | **Pending Approval** | Waiting for a supervisor's sign-off. | | **Released** | Approved and on the shop floor at the co-man. | | **Partially Built** | Some units have been produced (Built is above zero, below Quantity). | | **Built** | Built has reached Quantity — the run is complete. | | **Closed** | Finished and settled; no further activity expected. | | **Cancelled** | The order was called off. | Every work order also belongs to a **scenario** — the live plan or a what-if copy — and shows a **warning** if its last write to the ERP failed. ## Step by step: create and track a work order 1. From the supply grid or the work-orders list, create a work order for the finished good you need to build. 2. Set the **Quantity** (target output), the **Supplier** (co-man), the **Destination** warehouse, and the **Start** and **End** dates. 3. Check the **components table**: confirm **Needed** looks right and read the **availability indicator**. If a component shows a back order, map the order to a Purchase or Transfer Order that replenishes it. 4. Route the order for approval (**Pending Approval**), then approve it and **write it to your ERP** so it becomes real. See [Writing to your ERP](/guide/supply-planning/writing-to-erp). 5. As the co-man reports output, watch **Built** climb — the order moves to **Partially Built**, then **Built** when Built equals Quantity. ## Example You create a work order to build **1,000 units** of a finished good. The BOM uses **2 units of Component A per finished good**, so: * **Needed** = 2 × 1,000 = **2,000**. * Say **1,500** are already **Committed** to this order and **300** are **Available** at the co-man. * **Back order** = max(0, 2,000 − 1,500 − 300) = **200**. You are 200 short, so the availability indicator flags the order as short until you cover it — for example by mapping in a purchase order for Component A. Once production starts, **Built** climbs from **0** to **600** (the order shows **Partially Built**) and later to **1,000** (the order shows **Built**). Quantity stayed at 1,000 the whole time — Built is what told you where the run actually stood. > **Tip:** When a work order shows "at least one component short," don't wait — map it to the Purchase Order or Transfer Order that brings that component in. See [Raw-material planning](/guide/supply-planning/raw-material-planning), [Products, SKUs & BOMs](/guide/network/products-skus-boms), and [Purchase orders](/guide/supply-planning/purchase-orders).