> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # Jobs > One run of production, covering a single item, a quantity to make, and its own copy of the method. A **job** is a production order for one item, quantity, location, and due date. It contains a job-specific copy of the manufacturing method, including materials and operations, so later changes to the item master do not alter released work. The schedule places a job's operations; operators issue material and record time against it; and costs accumulate in work-in-process. Make-to-order sales order lines and planning shortages can create jobs. ## Fields FieldType
**Job ID**`text` A readable id assigned from the job sequence (prefix and format under **Settings → Sequences**), or a custom id you type. Read-only once the job exists.
**Item**`reference` What's being made. The job copies this item's method on release.
**Quantity**`number` Good units to produce.
**Estimated scrap quantity**`number` Units expected lost; `production quantity` = quantity + scrap.
**Quantity complete**`number` Good units finished so far.
**Location**`reference` The site the job runs at and receives into.
**Complete to**`enum` Where finished output goes: **Inventory**, or a **Fixed Asset Class** (making an asset in house).
**Due date**`date` When it's needed, paired with the deadline type below.
**Deadline type**`enum` How hard the due date is: `ASAP`, `Hard Deadline`, `Soft Deadline`, or `No Deadline`. The scheduler treats each differently.
**Source**`reference` The sales order line or quote line it was raised for, if any.
**Assignee**`reference` The person responsible for the job.
**Released / Completed date**`date` Stamped when the job moves to **Ready** and to **Completed**. The span between them is its actual production time.
## Status lifecycle A job's status drives what you can do with it and what the floor sees.
**Draft** Created and editable; not yet planned or scheduled.
**Planned** Demand is visible to planning, but no work is on the board yet.
**Ready** Released: operations are scheduled and material requirements raised.
**In Progress** The first production event has been logged against it.
**Paused** Work is temporarily halted.
**Completed** Every operation is done; finished goods have been received into inventory.
**Closed** The books are settled. Any residual work-in-process is swept to variance.
**Cancelled** Abandoned before completion.
NOTE A **Completed**, **Closed**, or **Cancelled** job is locked. Its method, quantity, and dates can no longer be edited. Closing is what makes a job's work-in-process provably zero. NOTE In the Jobs list, the **Ready** status is labelled **"Released"** — the underlying value is still `Ready`. Note also the spelling: a job is **Cancelled** (two L's), but a job *operation* is **Canceled** (one L). Different enums, different spelling. To release several jobs at once, select them in the Jobs list and choose **"Release Jobs"** from the actions menu. Only **Draft** and **Planned** jobs in the selection are released. There is no dialog here: a job that needs fixing, or whose outside operations go to a supplier that already has a draft purchase order to choose from, is skipped and named in the summary. Release those from the job itself. ## Operations The job's routing is copied into job-specific **operations** on release, each a process on a work center, carrying its own setup, labor, and machine time. The floor runs the job by running its operations, and each carries its own status. A job reads **"In Progress"** the moment any single operation does.
**Todo** Not yet worked, and not necessarily unblocked.
**Ready** Every operation it depends on is **Done**; this one can start.
**Waiting** An upstream dependency isn't finished, so it's blocked. It flips to **Ready** on its own once the last one completes.
**In Progress** A production event is open while someone runs it.
**Paused** Halted; time isn't accruing, but it isn't finished.
**Done** Finished. Completing it closes any open events and promotes downstream operations whose dependencies are now all done.
**Canceled** Won't run.
### Operation type Each operation carries an operation type: **Process**, **Assembly**, **Inspection**, or **Outside Processing**. The first three run in-house on one of your work centers and price against its rates, and the type decides which execution view the operator sees on the shop floor. A plain **Process** operation runs the standard operation view. An **Assembly** operation opens a guided, step-by-step build view: 3D animated work instructions play each step's insertion motion, with the parts, tools, and reference images scoped to the step in front of the operator. An **Inspection** operation runs a quality check, recording measured features against a ballooned drawing (the same execution screen the quality module uses for received goods). An **Outside Processing** operation is subcontracted: instead of a work center it points at a supplier process, copies that supplier's cost and lead time, and drives an outside-processing purchase order. The process you pick carries the same type and defaults it on new operations. HEADS UP An Outside Processing operation's cost and lead time are copied when you set the supplier process, not linked live. If the supplier's pricing changes, re-select the supplier process to refresh it. ### Sequencing The **order** field sets each operation's position, and operation order (*After Previous* or *With Previous*) says whether it waits for the prior step or runs alongside it. Explicit **dependencies** are what gate a start: an operation can't reach **Ready** until every operation it depends on is **Done**, and finishing one re-checks everything downstream. Two operations with no dependency between them can be **Ready** at once and run in parallel. ### Time and output The floor records time and output separately. A production event records **Setup**, **Labor**, or **Machine** time with start, end, and employee. A production quantity records **Production**, [**Scrap**](/docs/reference/scrap.md), or **Rework** units and updates operation totals. Scrap does not satisfy the target quantity. Untracked materials are backflushed when output is reported; tracked materials are issued explicitly. [Backflush and Pull From](/docs/reference/strict-backflush.md) explains where each material is drawn from. ### Procedures Each operation can attach a procedure: a reusable set of work instructions keyed to a process. A procedure carries an ordered list of typed **steps** the operator completes (a task, a value, a measurement with a min/max range, a checkbox, a list choice, a timestamp, a person, a file, or an inspection), any of which can be marked required. It also carries **parameters**, the process settings the work runs at, such as a temperature or speed. Separately, the operation lists the **tools** it requires. A material or tool can be assigned to a single step, or left to apply across the whole operation — so an assembly view shows the operator exactly the parts and tools each step needs as they advance. Because a procedure is keyed by process, you author it once and every operation running that process can attach it. It's versioned, moving through **Draft** while it's written, **Active** once ready for live work, and **Archived** when retired. NOTE Revising a procedure bumps its version. A job already released keeps the version it was built with, so a change to the master never rewrites instructions on work in flight. Each step is captured as the operator fills it in, giving the finished job a recorded answer for every one it was built with. ## Make to order vs. make to stock A job is identical whichever way it's raised. Only its source differs. A **make-to-order** job links back to a sales order line; a **make-to-stock** job comes from planning with no order behind it. Unless the job completes to a fixed asset class, it completes into inventory first, and the sale (if any) ships from stock — the job never ships directly to a customer. NOTE Releasing a job copies the part's method into a job-specific copy. Editing that copy never touches the part master, and updating the part never disturbs a job already in flight. ## Related **Routings** The operations a job schedules onto the floor, before it copies them. [Open](/docs/reference/routings.md) **Work centers** The stations and rates that cost and schedule its operations. [Open](/docs/reference/work-centers.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.