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 groups unstarted from multiple jobs into one production run. All members use the same batchable process and , 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, Carbon allocates shared time to members in proportion to quantity, then posts job costs and ledger entries per job.
Not the same as batch tracking
An operation batch (BAT000001) represents a production run. It is separate from lot or batch numbers used for inventory traceability.
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 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.
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
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".
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.
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, 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.
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 material issues it to every member at once. The quantity defaults to the batch's outstanding requirement, and Carbon divides what you pick across the members in proportion to what each still needs. Costing and lot traceability stay per job; only the operator's trip to the shelf is pooled.
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
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".
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.
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.