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.
Some processes physically run several jobs at once: a laser table nests parts from many work orders on one sheet, a furnace treats many jobs in one cycle, a plating bath coats whatever fits. An models that run. It groups unstarted from different jobs, all on the same batchable process, to run together at one , with one shared setup and one shared timer.
The jobs are never merged and no BOM changes: each member stays a first-class operation on its own job, and at completion the shared time is sliced back per member in proportion to its quantity, so job costing and the GL post per job with nothing special-cased.
Not the same as batch tracking
An operation batch (BAT000001) is a production-run concept. It is unrelated to the lot/batch numbers that trace quantities through inventory — see traceability. Same word, different feature.
Making a process batchable
Batching is switched on per process, not per item or method. On the process form (Resources → Processes), turn on "Batchable" and pick a "Batch type": "Sequential" (parts run one after another, like a saw or laser table) or "Simultaneous" (parts run together in one load, like a furnace, oven, or plating bath). The type drives the run-time estimate: sequential sums the members' times, simultaneous takes the longest.
The same card holds the "Compatibility rules": how strictly each material property must match for operations to share a batch. Six dimensions (material, substance, grade, dimension, form, finish), each set to "Require Match", "Suggest Match", or "Ignore". By default substance, grade, and dimension suggest a match and the rest are ignored.
Only "Require Match" ever blocks anything; a suggested mismatch just warns. A work center can additionally carry an advisory "Batch Capacity" and "Minimum Batch Quantity"; the builder shows a fill bar against them but never refuses a batch over them.
Building a batch
Open Production → Batches and press "New Batch" (the production dashboard's "Unbatched Operations" card and a job header's "N awaiting batching" badge lead to the same place). Pick a Location and a Batchable process, and the builder lists every eligible operation: unstarted, not already in a batch, on that process, with no production recorded.
Operations whose "Require Match" dimensions clash with your selection stay visible but locked, and mixed "Suggest Match" materials get an amber tag plus a warning to confirm they nest together on this run.
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. Finish with "Create batch" (the batch waits as "Planned") or "Create & Release" (it goes straight to the floor). A work center is optional at this point: leave it blank and the scheduler auto-assigns the earliest-finishing candidate on release, writing it to the batch and every member.
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
The moment a single timer event is recorded against the batch, membership is permanent: adding, removing, changing the work center, unreleasing, and dissolving are all refused, and the only exit is completing it. Decide the composition before work starts.
Release pulls member jobs onto the floor
A batched operation is visible to operators when its batch is released, even if its own job is still "Draft" or "Planned"; the batch's schedule outranks the job's. Releasing recalculates requirements for those unreleased member jobs first, so materials are known, but it does not run MRP. The same job's other, unbatched operations stay hidden until the job itself is released.
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
There is no separate batch screen in the shop floor app: any member's operation view is the batch UI. A batch chip shows the BAT… number, the member jobs, and a "Print batch list" action; the timer is shared, so starting it runs one clock for the whole batch, and planned time shows the batch total.
Completion happens once, for the whole batch, in the "Complete Batch" modal: one row per member with Quantity and Scrap, pre-filled with each operation's remaining quantity. Leave a row at zero to skip that operation — it detaches and returns to the schedule un-run, with no time or quantity recorded.
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, 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.