Confirming a Sub-Assembly Versus the End Product in EDGEBIC

In EDGEBIC by User Solutions, reporting a produced quantity on the End Product node and reporting a received quantity on a Sub-Assembly node use the same dialog and run on completely different mechanisms. To a planner it is one feature. In the arithmetic they are two, and treating them as one is the single easiest way to misread what the schedule does next.

This article draws the line, in both directions.

Two Statements, Not One

Start with what each number is a statement about.

An end-product confirmation says: this many good units of the order already exist. That is a yield statement about the job's own output. The remaining build is reduced directly, and nothing is issued out of stock, for the reasons set out in why an end-product confirmation does not consume stock.

A sub-assembly confirmation says: this many of the component are on the shelf. That is a stock statement about a part. It adds the component to inventory and stops there. Everything that happens next is the machinery that already existed for handling stock.

Why the Sub-Assembly Case Needed No New Machinery

Once a sub-assembly's receipt is posted, those units are indistinguishable from stock of that product that arrived by any other route. A previous run built them, a sister job over-produced, somebody bought them in. It does not matter. They are on-hand.

From there the existing component logic does everything by itself. Before the routing explodes a sub-assembly branch into work center steps, it asks whether on-hand covers the requirement:

• Full cover. The branch never explodes. The node stays a plain component and the schedule reserves no machine time for it at all.
• Partial cover. The branch splits. The covered portion needs no manufacturing, and only the shortfall explodes into operations.
• No cover. The branch explodes in full, exactly as it always did.

For the mechanics of that decision see EDGEBIC sub-assembly scheduling explained and how a sub-assembly feeds its parent job.

The Issue That Follows Is Legitimate

When the parent build eventually draws the sub-assembly out of stock, an issue posts against the component. That looks superficially like the consumption forbidden on the end product, and it is not the same thing at all.

The forbidden pattern is consuming finished goods in order to build more of those same finished goods, which describes a round trip that never happened. Here, the product issued is the sub-assembly and the product being built is the parent. That is ordinary bill-of-material consumption, the most routine transaction in manufacturing.

The rule to carry: the identity of the product decides. Same product on both sides is nonsense. Different products is a bill of material doing its job.

A Worked Comparison

One parent, one sub-assembly, and the same number reported in two places.

Setup. Parent PA, order for 50. Each parent needs one sub-assembly SA. The SA branch is three operations, four hours per unit.

Case 1: report 20 on the End Product node.

The parent's remaining build drops from 50 to 30. Every operation in the parent's routing, including the whole SA branch beneath it, sizes against 30 parents. Twenty parents are finished goods and are no longer planned in any form.

Case 2: report 20 on the Sub-Assembly node.

The parent still owes 50. On-hand for SA rises by 20. On the next run, netting sees 20 of the 50 SA units covered, so the branch splits: 20 need no manufacturing and 30 explode into operations. The parent's own final assembly still runs for 50, because 50 parents still have to be assembled.

Read the third row carefully. It is the one that catches people out. Confirming components does not reduce what the customer is owed. It reduces how much of one branch has to be made.

Choosing the Node

The routing diagram on the Actual Live screen makes the choice visible, and the node you double-click is the whole decision.

• End Product node, the card at the top. Use it when finished units of the order exist.
• Sub-Assembly node, a component that has its own routing beneath it. Use it when finished components exist.
• Work center steps. These are not confirmation targets. Reporting what happened at a machine is the per-operation actuals flow, and it records hours or pieces on that step. See logging actuals from the planner.

On a sub-assembly node the system asks which of two things you meant: report a received quantity for the sub-assembly, or log per-operation actuals for one of its steps. That prompt exists because the two are genuinely easy to confuse, and answering it wrongly produces a plausible-looking schedule built on the wrong statement.

For the step-by-step versions, see how to report produced quantity on a job and how to report a sub-assembly as received.

Do Not Merge the Two Paths

It is worth stating what happens if the distinction is collapsed, because both directions produce quiet, expensive errors.

Make the end-product case behave like the sub-assembly case, and you reintroduce the round trip: a receipt and an issue that cancel each other, no remaining-quantity reduction, and a stock movement that describes nothing real.

Make the sub-assembly case behave like the end-product case, and the arithmetic goes somewhere worse. A child arriving would reduce the parent's build quantity, so receiving 20 sub-assemblies against an order for 50 parents would silently drop the parent to 30 and short-ship the customer by 20 units.

Both mistakes compile. Neither announces itself. That is why the two remain separate paths under one dialog.

The Bottom Line

The dialog is shared because the planner's gesture is shared: double-click a node, type a number, press Report. What the number means is decided by which node you clicked. End product is a yield statement that cuts the build. Sub-assembly is a stock statement that lets netting cut the branch. Keep those apart and every downstream figure lands where you expect.

More of the execution loop is in the shop floor execution guide, and the platform overview is at EDGEBIC.