Splitting or Merging Production Orders: Change the Work Plan Without Losing Its Origin

Split a production order when parts of its planned quantity need separate control. Merge orders only when your reviewed process allows them to become one manufacturing instruction. If staff merely want several jobs on the same planning board, grouping may be enough; replacing the orders is a different feature.

This guide helps specify changes to planned production work. It does not authorise combining physical lots, mixing materials or changing product traceability. Start with unstarted orders; work already in progress needs a separately designed process.

What needs to become independent?

Ask why the existing order is inconvenient. Does part of the quantity need a different responsible person, start date or progress record? A split can give each part its own operational identity while keeping its origin discoverable. If all that changes is which rows a supervisor sees together, a filter or planning group may solve the problem without creating replacement orders.

For a fictional workshop, one planned run might need two separately controlled portions. The requirement is not simply a button named “Split.” Staff need to know which portion remains to be done, what each new instruction covers and whether the old instruction can still be acted on.

Keep production order identity separate from physical batch identity. Creating two planning records does not by itself prove that two physical lots exist. Conversely, one combined planning record must not erase actual material distinctions required by the process.

Define compatibility before offering merge

The Odoo 19 split and merge guide allows merging manufacturing orders only when they contain the same product and use the same bill of materials. It also describes assigning quantities to new orders during a split and listing the source references on the merged order.

That is a specific product example, not a complete compatibility policy for your custom app. Decide whether orders must also share the same approved revision, units, permitted production route or other constraints. Have the responsible production specialists define which differences prohibit combination. Matching product names alone should not decide technical compatibility.

Customer commitments can remain distinct even when manufacturing work is combined. Specify how the resulting quantity stays allocated to the originating demand. Do not silently replace separate promised dates with whichever date happened to be on the first selected row.

Show what changes before committing

Ask for a preview of the original order or orders, the resulting records and their quantities. Agree the conservation rule in a common defined unit: a restructuring operation must not silently add or lose planned production. If reducing the plan is intended, give that cancellation a separate reason rather than hiding it inside a split.

The preview should expose carried-forward values and conflicts. A shared note can be copied where appropriate, but conflicting instructions need resolution, not arbitrary selection. Define who can confirm the change and whether an order changed by another user must be rechecked first.

After confirmation, provide navigable links in both directions. A suffix in a reference can help a person recognise a relationship, but the app should retain the relationship explicitly rather than reconstructing it from a naming pattern.

Prevent two active instructions for the same work

Agree what happens to replaced orders: historical visibility, a clear replacement status and restrictions on further execution. Staff following an old printout need a way to identify the current instruction. Merely removing a row from the main list does not explain why it disappeared.

If the process has component reservations or downstream work records, define whether they transfer, are recreated or cause the operation to be refused. Do not assume that changing an order header moves every related commitment correctly. If the first version cannot safely restructure started work, reject that case clearly instead of offering a misleading general-purpose merge.

Accept the relationship, not just the new row

Use invented records in your acceptance walkthrough. Demonstrate a permitted split, a permitted merge, an incompatible pair and a stale confirmation after another user edits an order. Check that quantities reconcile, original demand remains explainable and replaced instructions cannot be executed again under the agreed policy.

Also attempt the operation on started work and show the documented refusal or separately approved path. Check reservations and existing downstream links wherever those are in scope. These are requirements to implement and test, not capabilities certified by the cited documentation.

For a production-workflow app discussion, bring blank job cards and a non-confidential explanation of why quantities need independent control. Request the smallest operation that solves that problem. A planning group is often worth considering before commissioning irreversible order restructuring.

Questions to settle

Does merging production orders merge customer orders?

Not automatically. Define the allocation between manufacturing output and each customer commitment separately.

Can an accidental split simply be undone?

Only under an agreed correction policy that considers subsequent work. Once either part has activity, combining records again must not conceal that history.

Does a merged order mean the materials may be mixed?

No. Software restructuring does not establish physical compatibility, safety or permitted traceability. Those constraints need competent review before the application can enforce them.