How work orders move stock

Which work-order action creates which transaction, and where the movement actually happens.

A work order is one job in Maintain or Production. It carries two parts lists, and closing it is the only thing that moves stock: everything before that is a claim on a shelf, not a withdrawal from it.

The movement itself is performed by the IoTFlows backend, not by the browser or the app. You confirm it, the server does it. That is why this page reads the same whether your technicians close jobs on the web, on iOS or on Android, and why no page tells you to correct a count by hand after a job closes.

This page explains the model. The procedure for closing a maintenance work order is on Complete and confirm materials, and for a production job on Complete the job.

The two bindings

An item reaches a work order in one of two ways, and the difference is where it was written down.

On the work order itself. A work order has a Parts Required section and a Create/Release Parts section. A line in either one names an item, one location, and a quantity. Adding a line here is a decision about this job and nothing else.

On an operation. An operation is one step in making a part, held on the Parts List and reused by every job that runs it. It carries its own required and created items, and those are rules rather than quantities: a rule says how the item scales with the work. Four bolts for every one part, one cutting tube for every 50, or one torque wrench however large the run is.

When a job is raised against that operation, IoTFlows scales each rule to the job's quantity and stages the result as work-order lines. A run of 401 parts at one tube per 50, with rounding on, stages nine tubes.

Editing the staged lines before you submit is expected, and the rule on the operation does not change. The editor is on Bind materials to an operation.

Choose where to bind

Bind on the operation when the item scales with the work and the operation runs more than once. The rule is written once and every future job inherits it, which is the only way the number a planner sees and the number a job reserves stay the same number.

Bind on the work order when the draw is specific to this job: the gasket that failed on this pump, the fixture borrowed for one shift.

You do not need a binding at all. Inventory works as a standalone catalog and ledger, and stock can be received and issued from the item's own detail. Skip bindings if your work orders rarely touch the storeroom, and accept that closing those jobs will move nothing.

Reserved versus on hand

Raising a work order with a required line reserves that quantity. A reservation is a claim on stock that is still physically on the shelf: it writes no transaction, and the on-hand count does not move.

On hand splits into reserved and available. Incoming is counted on its own and is never added into available.

Four figures describe one item, and only two of them count what is physically there.

Figure	What it counts	Changes when
On hand	What is on the shelf right now, summed across locations	A transaction is written
Reserved	The quantity on required lines of open work orders	A line is added, edited or deleted, or the work order closes
Available	On hand minus reserved: what a new job can still take	Either of the two above changes
Incoming	What open work orders that create this item will add	A created line is added, edited or deleted, or the work order closes

Incoming is a forecast, not stock. None of it is on a shelf yet, so IoTFlows keeps it out of available on purpose. A job cannot pull from a quantity that does not exist, and an available figure that quietly included it would let two planners commit the same future delivery.

Where each figure appears

The four columns appear together in the Items tab in list mode. The item's own detail is different: it shows On hand, a green +40 incoming line beneath it, and two cards named Reserved by open work orders and Incoming from open work orders that name the jobs on each side.

There is no Available figure on the item detail, so read the list when that is the number you need. Both surfaces are covered on Adjust stock and track locations.

Read available, not on hand, before you promise a part to a new job. A storeroom with 120 gaskets on the shelf and 30 already claimed can honor an order for 90, and a reader who looks at the wrong column promises 120.

Shortages

Every required line carries its own availability, already net of that work order's own reservation. A negative value is exactly the amount that location is short by, and the completion summary prints short 12 in red beside the line. A created line can never be short, because it adds stock rather than taking it.

What happens on completion

Setting a work order's status to Done is the moment stock moves.

If the work order lists nothing in Parts Required and nothing in Create/Release Parts, it closes immediately and nothing is written. If either list has lines, a read-only summary appears first: a Complete work order dialog in Maintain, and the same summary folded into the session dialog on a production job.

A required line takes stock out when the work order closes and a created line puts it back. A tool travels the same path, as custody out and custody in.

The summary groups the lines the way the movement reads. Parts Consumed is what closing the job deducts, and Added to Inventory is what it adds, split into Produced and Tools Returned when the job does both.

A reusable tool is an item that comes back rather than being used up: a torque wrench, a fixture, a tube. It appears in the second group because closing the job hands it back, not because the job manufactured one.

Selecting Complete flips the status. The backend then consumes the required lines, produces the created ones, writes one inventory transaction per line, and clears the reservation.

Action to transaction

Action	Work order type	Transaction created	Direction
Add a line to Parts Required	Maintain or Production	None. The quantity is reserved	Neither
Add a line to Create/Release Parts	Maintain or Production	None. The quantity becomes incoming	Neither
Delete a line before closing	Maintain or Production	None. The reservation or forecast clears	Neither
Close a job that requires a consumable	Maintain or Production	One row per line, at that line's location	Out
Close a job that requires a tool	Maintain or Production	One row per line: the tool leaves the shelf into the job's custody	Out
Close a job that creates a part	Production, and Maintain where a job rebuilds something	One row per line, at that line's location	In
Close a job that creates a tool	Maintain or Production	One row per line: the tool returns to its shelf	In
Pause a production job	Production	None. A pause moves nothing	Neither

The badge each of these rows prints in the ledger is listed on Transaction types. Every work-order badge begins WO.

Reconcile before you close, not after

The completion summary is read-only, and there is no quantity field on it. It states the consequence of closing and gives you one chance to refuse.

So the reconciliation happens on the work order, not in the dialog. If the technician used six gaskets and the line says four, select Cancel, correct the line in Parts Required, and set the status to Done again. Closing on a line you know is wrong is how counts drift, and no later adjustment will say which job the difference belonged to.

Reopening a closed work order

Nothing in IoTFlows stops a closed work order from being reopened and closed again, and the completion summary appears on every close where the job has parts. Whether the backend writes a second set of transactions on the second close is not confirmed. Until it is, treat a reopen as a reason to check the item's ledger, and prefer a counted correction to a second close.

What happens on a production work order

A scheduler task and a Work Queue job are work orders, so everything above applies to them unchanged. Three things are specific to production.

The lines usually arrive prefilled. Picking an operation in the create modal stages its rules against the quantity you typed, so a planner confirms numbers rather than restating them. A staged line whose shelf cannot be resolved is dropped when the work order is submitted, which is the one way a part you saw in the modal can be missing from the job afterwards.

Created lines are what the scheduler projects output from. The projected-output curve reads the work order's own created lines. Output is declared, never inferred from the shape of the job, so a job that produces something and does not say so contributes nothing to the forecast. See What created parts show you on the scheduler.

Logging parts made is not a stock movement. The count you enter during a session records how many good parts the machine produced, and it writes no inventory transaction. Stock arrives only from a created line at close. Compare Log good parts.

A serialized piece adds one more consequence. Each piece is a capacity-1 resource, so two jobs requiring the same physical bar appear as a conflict on the scheduler with nobody writing a rule. See Violations: piece conflicts.

Reading the result in the ledger

Open Inventory and select the Transactions tab. Each row is one movement: Type, Item, Location, Change, Note, By and Date.

A closed work order shows up as one row per part line, carrying a WO badge and a signed change. A job that consumed four gaskets and produced one rebuilt pump writes two rows, not one, because each line moved a different item at a different location.

The ledger has no work-order column and no work-order filter. To trace a specific job, filter by type, then match on the item, the timestamp of the close, and the person in By. The same rows appear under the item's own detail, which is usually the faster route when you already know which part you are asking about.

When nothing moved

A completion wrote no transaction. The work order had nothing in either parts list, so it closed immediately with a Task completed! toast and no summary. Bind the parts and close it again, or record the movement from the item with Add stock with a receipt.

The close appeared to succeed, then the status came back. The Task completed! toast is shown before the request returns, so a failed close prints it and then the server's own error message, and the board reverts to the previous status. The stock did not move. Try the transition again.

A part you added in the create modal is not on the job. A staged line with no location is dropped at submit, and a line whose rule has no quantity is never staged at all. Add it back on the work order, with a location, before closing.