Nobody set out to keep two. The order said four hundred, the floor finished three hundred and twenty, and the order got closed because the shipment could not wait. The eighty units are still owed to somebody, so they live on now in a note, a whiteboard, a message to the planner, anywhere except the system that knows which components they will need. The next person to ask "what is still open" gets an answer from the ledger and a different answer from the floor, and the gap between them is the size of the run that was closed short.
A manufacturing order that can be closed short without the remainder disappearing. Finishing less than the order asked for splits it: the quantity you did not make carries forward as a new order on the books, with its own components and its own state, or is cancelled explicitly if that is the decision. Either way somebody chose, and the choice is on the record.
The order carries a real lifecycle, draft, confirmed, in progress, to close, done, cancelled, and to close is its own state, so an order that has produced its quantity but has not been posted is a different thing from one that is finished. Component availability is tracked on a second track alongside that state, so "is it ready to start" is a field rather than an inference.
And the order stays editable in flight. It can be split into several smaller orders. It can be produced as a batch with a lot or serial number assigned per finished unit in one pass. It can be reversed entirely: an unbuild order consumes the finished product and produces its components back, linked to the order it came from, rather than being fixed up as a manual inventory adjustment. And how strictly component consumption is enforced against the bill of materials is a setting with three positions, allowed, allowed with a warning at close, or blocked to all but a manager, not a house rule.
All of this is already in Odoo, nothing to add, no upgrade tier to reach, no extra fee per user, running on the deployment you own. There is no paid tier above it that holds the real version; this is the real version.
What this is not: a scheduler. The order holds a start date, a finish date, a deadline and a two-value priority, and those are fields a person sets. Nothing here does finite-capacity scheduling or advanced planning, nothing solves the sequence for you, and this page will not imply otherwise.
A manufacturing order is the record of one production run: what is being made, in what quantity, from which bill of materials, out of which components, and into which stock location. It is the document that turns a product structure into an event, the bill of materials says what a unit is made of in general, and the manufacturing order says that these particular components, in this particular location, become these particular finished units now. Because it names both the components consumed and the goods received, it is also the record the stock movements and the cost of the run hang off, which is why a manufacturing order that lives outside the inventory system creates a second version of the stock position rather than a copy of it.
In a system with backorder handling, closing a manufacturing order for less than its demanded quantity splits the order: the finished quantity closes on the original record, and the unfinished quantity is carried onto a new manufacturing order that stays open on the books, with the option to cancel the remainder outright instead if that is the intent. The distinction matters because those two outcomes are business decisions with different consequences, the remainder is either still owed to someone or it is not, and a system that simply accepts the smaller number and marks the order done has made that decision silently, on behalf of whoever closed the screen. The unfinished eighty units then exist only in whatever someone wrote down, and the ledger and the floor start answering the question "what is still open" differently.
With an unbuild order: a record that consumes the finished product and produces its components back into stock, linked to the manufacturing order it came from, and refused outright unless that order is actually complete. This is worth distinguishing from the alternative, which is an inventory adjustment, someone reducing the finished-goods count and increasing several component counts by hand. Both end at the same stock position, but only one of them leaves a record of why: an adjustment is an unexplained correction to a count, while an unbuild is a reversal that points back at the run it reversed. When rework happens routinely, the difference is between a component history you can read and a series of unexplained count changes.
It should let you decide, per bill of materials, which of three answers applies, and that decision is the interesting part. Consumption above or below the bill of materials is not automatically an error: yields vary, scrap happens, and a shop-floor operator adding two extra fasteners is usually right. But it is also the exact place a bill of materials silently goes stale, because if the real consumption is always higher and nothing ever says so, the standard is wrong for years and the cost of every unit is wrong with it. The useful design is configurable strictness: consumption differences allowed silently where the variance is expected and immaterial, allowed but surfaced as a summary when the order is closed where somebody should be looking, and blocked to all but a manager where the difference means something is wrong upstream. A single global setting cannot be right for every product, which is why the setting belongs on the bill of materials rather than in the system's preferences.