> ## 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. # Operation batching > Group identical operations from several jobs to run as one setup and one timer at a work center, with time and cost split back per job by quantity. An operation batch groups unstarted job operations from multiple jobs into one production run. All members use the same batchable process and work center, with one shared setup and timer. Typical uses include nested laser cutting, furnace cycles, and plating baths. Batching does not merge jobs or change their BOMs. Each member remains an operation on its original job. At completion, Alforse allocates shared time to members in proportion to quantity, then posts job costs and ledger entries per job. NOTE **Not the same as batch tracking** An operation batch (numbered `BAT…`) represents a production run. It is separate from lot or batch numbers used for inventory [traceability](/docs/reference/traceability.md). ## Making a process batchable Enable batching per **process**, not per item or method. On **Resources → Processes**, enable **Batchable** and select a **Batch type**. **Sequential** processes run parts one after another and sum member times. **Simultaneous** processes run parts together and use the longest member time. The same card holds the **"Compatibility rules"**: how strictly each dimension must match for operations to share a batch. Six describe the material consumed (material, substance, grade, dimension, form, finish) and a seventh, **"Produced item"**, describes what each job makes. Each is set to **"Require Match"**, **"Suggest Match"**, or **"Ignore"**. By default substance, grade, and dimension suggest a match and the rest are ignored. Requiring a match on "Produced item" keeps a run to a single output item, which is what makes its [output lots](#completing-the-batch) mergeable afterwards. Only **Require Match** blocks selection; **Suggest Match** produces a warning. A work center can also define advisory **Batch Capacity** and **Minimum Batch Quantity** values. The builder displays capacity usage but does not enforce either limit. ## Building a batch Open **Production → Batches** and select **New Batch**. The **Unbatched Operations** dashboard card and a job header's *N awaiting batching* badge open the same builder. Select a **Location** and **Batchable process**. The builder lists operations that are unstarted, use that process, are not already batched, and have no recorded production. Operations that conflict with a **Require Match** rule remain visible but cannot be selected. **Suggest Match** conflicts display an amber tag and warning. Alforse screenshot**The batch builder at Production → Batches → New Batch: scope pickers, the eligible-operations list grouped by material with suggestion banner, and the Review & create panel with setup-saving chip** Suggestions group by material signature and due window; the review panel shows one shared setup instead of one per operation. The builder also proposes ready-made groupings: operations sharing a material signature and due within the same seven-day window, ranked by setup saved, urgency, and capacity fit. When the selected operations produce a lot-tracked item, the review panel adds an **"Output"** section: this is where the run's lot numbers are decided, not on the shop floor. Each job gets its own lot number, pre-filled from the job's current one. When every selected operation makes the same lot-tracked item, **"Combine output into one lot"** replaces them with a single lot number for the whole run. Creating is disabled until every lot number is filled in and no two jobs share one. Select **Create batch** to save the batch as **Planned**, or **Create & Release** to send it to the shop floor. A work center is optional. If omitted, the scheduler assigns the candidate with the earliest finish time on release and applies it to the batch and its members. ## Lifecycle
**Planned** Composed but not on the floor. Members still schedule as individual operations, the batch is invisible in the shop floor app, and it can be freely edited or dissolved.
**Released** On the floor as one unit: one schedule reservation, one shared timer. Members appear in the shop floor app even when their own job isn't released yet.
**Completing** Completion has started: quantities are recorded and time is sliced. If a downstream step fails, the batch stays here and the operator retries from the shop floor.
**Completed** Done. Each member operation is marked "Done" with its own time, quantity, and cost, and the jobs proceed independently.
There is no cancelled state: **"Dissolve Batch"** returns the members to the schedule un-run and deletes the batch, and removing the last member does the same. **"Unrelease Batch"** puts a released batch back to "Planned". HEADS UP **Recorded production freezes the batch** After the first timer event, membership and work-center assignment are fixed. The batch can no longer be unreleased or dissolved; it must be completed. NOTE **Releasing a batch releases its jobs** Member jobs still in "Draft" or "Planned" are released with the batch, exactly as **"Release Job"** would release them: requirements are recalculated, MRP runs, the job becomes "Ready", and its outside operations go on purchase orders. The **"Release"** dialog checks every one of those jobs first — each assembly needs an operation and manufacturing must not be blocked — and a single job that fails keeps the whole batch unreleased until it is fixed. For each supplier you choose a new purchase order or an existing draft, once for the whole batch, so outside operations from every member job land on one order. Bulk **"Release N batches"** on the Batches list has no dialog: a batch whose jobs need fixing, or whose suppliers already have a draft purchase order to choose from, is skipped and named in the summary. Release those from the batch itself. ## On the schedule A released batch is one scheduling unit: it books a single work-center reservation sized by the batch type, placed before the per-job passes so member jobs plan around it. On the [schedule board](/docs/reference/scheduling.md), the batch renders as one card listing its jobs; dragging it to another column reassigns the batch's work center, and reordering it moves every member's priority together. The Batches list also offers bulk actions — select planned batches and **"Release N batches"** in one go, or dissolve several at once. ## On the shop floor The shop floor app has no separate batch page. Open any member operation to access the batch UI. A batch chip shows the `BAT…` number, member jobs, and **Print batch list** action. Starting the timer starts one clock for the entire batch, and planned time shows the batch total. Beside the chip, a **Batch | job** switch picks what the page shows. **"Batch"** (the default) is the whole run: completed quantity across every job, materials issued, scrap, the output lot, one materials table with batch totals, and the list of member jobs. The job switch shows the member's own steps, parameters, materials, and files, as for any operation. Alforse screenshot**A batched operation in the shop floor app with the Batch view selected: Completed, Materials issued, Scrapped, and Output lot cards, the batch materials table, and the Jobs in this batch table** The batch view aggregates the run; the job view is one member's own details. ## Picking materials The run is shared, so the materials list is too. The batch view lists each material once with the batch's total requirement and the split per job beneath it (for example `2 · 4 · 6`), and a **"Pick"** button for what is still outstanding. In the job view each material row carries a second **"Batch"** figure beside the member's own. Picking a lot-tracked material issues it to every member at once. The quantity defaults to the batch's outstanding requirement, and Alforse divides what you pick across the members in proportion to what each still needs. Costing and lot [traceability](/docs/reference/traceability.md) stay per job; only the operator's trip to the shelf is pooled. HEADS UP **Pick the batch quantity, not one job's** The split is proportional, so a smaller pick is divided across every member rather than filling one of them. On a batch needing 4,000 and 2,500, picking 4,000 leaves both members short instead of completing the first. Take the default, which is the batch total. Materials that are not lot-tracked show a batch total for reference only. They are still consumed per job automatically at completion. ## Completing the batch Alforse screenshot**The Complete Batch modal in the shop floor app: one row per member job with Quantity and Scrap inputs, the planned output lot stated above them, and the footnote about leaving a row at zero** Time and cost split across jobs proportionally to quantity; the output lot was set when the batch was planned. Complete the entire batch from the **Complete Batch** modal. Each member has **Quantity** and **Scrap** fields, prefilled with the operation's remaining quantity. Set quantity to zero to detach that member and return it to the schedule without recording time or quantity. The operator never enters a lot number. A combined run states its lot above the rows (*"All output goes to lot …"*); otherwise a read-only **"Lot"** column shows each job's planned lot. A batch created before lot planning existed, with a lot-tracked member that has no lot number, cannot complete: the modal names those jobs, and the fix is the lot number in the job's properties sidebar. On submit, any running timer stops, the shared time is sliced into per-member events in proportion to each member's planned quantity, scrap is recorded per member exactly as typed, each member's output lot is created, materials issue, costs post, and every remaining member is marked **"Done"**. HEADS UP **A partial quantity still completes the operation** Entering less than the pre-filled quantity records less output, but the member operation is marked "Done" regardless. The only way to keep a member open is to zero it out entirely so it leaves the batch. If a downstream step fails mid-completion, the batch parks at "Completing" and the modal's button becomes **"Retry Completion"**. The retry must resubmit the recorded quantities, and corrections happen after completion. Each member first gets its own lot, because each job has its own cost and history. When the batch was planned to combine its output, those lots merge into the planned lot right after completion. Otherwise they stay separate. Completing the batch also completes each member job whose batched operation was its last, so the merged lot's full quantity is on hand immediately; a member with operations still remaining completes later and adds its share then. A completed batch's drawer still offers **"Merge output lots"** for lots kept separate. GOOD TO KNOW **Merging adds history rather than losing it** The merged lot holds the summed quantity and the earliest expiry date of the lots that went into it, and its genealogy still reaches back through every member job to the materials each one consumed. A quality event on it resolves to the exact jobs involved, which a single directly-produced lot could never tell you. ## Related **Scheduling** How a released batch appears on the timeline, and why an estimate-less batch can't be scheduled. [Open](/docs/reference/scheduling.md) **Jobs** The work orders whose operations a batch groups. [Open](/docs/reference/jobs.md) **Work centers** Where a batch runs, and the advisory capacity numbers the builder reads. [Open](/docs/reference/work-centers.md) **MES** The shop floor app where the shared timer runs and completion happens. [Open](/docs/reference/mes.md) **Traceability** The lots a batch consumes and produces, and how a merged lot still traces to every member job. [Open](/docs/reference/traceability.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.