How a job becomes finished goods

Production is the path a made item travels from "we need to build this" to a finished good on the shelf. Workcell models that path as a chain of records, each one decomposing into the next until you reach steps an operator can run at a machine. This primer explains the model and why it is shaped this way; the how-to docs cover the clicks.

The stages

1. Demand (Planning)

It starts with demand, usually a released sales order asking for something you make. Planning reads that demand against what you already have on hand and on order, then proposes the orders needed to cover the gap. Each proposal is a planned order, tagged Make (you produce it) or Buy (you purchase it). You review the list and commit the ones you want.

2. Intent (Job)

When you release a Make order, it becomes a job: the unit of production intent. A job is always tied to a sales order, so it carries a clear answer to "why are we building this?" It names the item, the quantity, and the due date. On its own a job is still just intent. Nothing is reserved and no steps exist until you release it.

3. Execution units (Work orders)

Releasing a job creates its work orders. A work order produces exactly one item, and it is where the abstract intent of the job becomes a concrete build. A simple job has one work order; a job that builds an assembly out of sub-parts has several, each producing one piece of the whole.

4. Steps (Operations)

Releasing a work order resolves the item's BOM and routing into two lists: the components it will consume, and the operations that make it. An operation is a single step, run in sequence at a resource, the machine or station that does the work. This is the level the shop floor actually touches: an operator starts a step, reports the quantity complete and any scrap, and completes it.

5. Finished goods (Completion)

When a work order's operations are done, completing it consumes the reserved components and receives the planned outputs, the finished good plus any co-products or by-products, into inventory. Once every work order under a job is complete, the job itself completes, and closing it leaves a permanent, read-only record.

Where scheduling fits

Planning answers what to make; scheduling answers when and where. Once operations exist, the schedule places each one on a resource over time. Workcell generates a proposed timeline you can accept or reject, and the live shop-floor view tracks the work as it runs. Scheduling does not change what gets built; it sequences the steps that planning and release already defined.

Why it decomposes this way

Each level answers a different question and has a different owner. The job answers "what demand are we satisfying?" The work order answers "what single item are we building, from which BOM and routing?" The operation answers "what step runs at which resource, and who ran it?" Splitting these apart means a planner can commit demand without touching the floor, the floor can report a step without re-deciding the plan, and you can always trace a finished good back to the order that asked for it.

Ready to walk it? Start with Plan production, then Release a job.