How Forward Netting Connects a Producer to a Consumer in EDGEBIC

Forward netting lets a consuming order net against the projected receipt of a build-to-stock producer scheduled in the same run, so the consumer sees the incoming supply the run is itself creating and does not build a second time. In EDGEBIC by User Solutions, this closes a specific gap: when one run contains both an order that builds a part and an order that needs it, forward netting stops the plant from producing twice as much as it needs. It is a time-phased extension of the ordinary consume-from-stock decision.

This post explains the double-build problem, how forward netting solves it with dated supply events, and how to confirm it worked. It sits under the EDGEBIC planning guide and extends how EDGEBIC nets demand against stock.

The double-build problem

Ordinary netting compares a demand to the stock on hand at the start of the run. That works when supply already exists. It breaks when the supply is being created in the same run.

Picture a run with two orders for the same bracket. One is a build-to-stock order for 100 units, completing on the tenth. The other is a customer order for 60 units, starting on the twelfth. At the start of the run, on-hand is zero. The consumer looks at zero stock, decides it must build, and produces its own 60. The producer builds its 100. The plant makes 160 brackets when 100 would have covered both. Nobody set out to over-build; the consumer simply could not see the supply arriving two days before it needed it.

What forward netting adds: dated supply events

Forward netting gives the run a memory of incoming supply. Instead of tracking only a single point-in-time on-hand figure, the engine keeps a time-phased list of supply events for each product. Opening on-hand is one such event, dated at the start. Then, as each build-to-stock producer is scheduled, its projected output is registered as another supply event dated at the producer's completion.

A consumer no longer asks "how much is on hand now." It asks "how much supply is available as of my need date," summing every supply event dated on or before that date. A producer completing on the tenth is visible to a consumer that needs stock on the twelfth. The supply is drawn down oldest-first, so the projection stays honest across several consumers.

This works alongside the supply-before-consumer sort, which schedules producers before their consumers so the supply events are registered before any consumer inspects them. That ordering plus the dated events is what lets the consumer see what the run is building. The rationing among consumers is handled by the inventory reservation map.

A worked run: 100 built, 60 consumed, same run

Take a bracket with zero opening on-hand. Two orders in one run:

• Producer: build 100 brackets, completing on the tenth.
• Consumer: need 60 brackets, starting on the twelfth.

Producer scheduled first (supply-before-consumer sort). It builds 100 and registers a supply event: 100 units available as of the tenth.

Consumer evaluated next. Its need date is the twelfth. Available supply as of the twelfth = the tenth's event = 100. Since 100 covers 60, the consumer nets 60, is satisfied from stock, and builds nothing. The supply event draws down to 40 remaining.

The producer builds exactly 100, the consumer builds 0, and after both complete on-hand is 100 − 60 = 40. Compare that to the no-forward-netting outcome, where both build and the plant produces 160. Same orders, same dates; the difference is whether the consumer could see the incoming supply.

Timing matters: the need date must fall on or after the receipt

Forward netting respects dates, so it does not conjure supply from thin air. If the consumer needed the brackets on the ninth, one day before the producer completes, the tenth's supply event would not yet be available, and the consumer would build its own units. That is correct: you cannot consume stock that has not been produced yet. Forward netting only lets a consumer draw from supply that lands on or before its need date, which is exactly what a real transfer of finished goods requires.

Confirming it worked

Two places tell you a consumer netted against same-run supply.

The netting diagnostic logs each decision: the order, the product, the need, the available supply as of the need date, the quantity used from inventory, whether the order was built, and a satisfied-from-stock flag. A satisfied-from-stock true line with a non-zero used figure confirms the consumer drew from stock rather than building.

The ledger shows the honest result: the consumer posts a consume issue and creates no work-center operations, while the producer posts its build receipt on completion. Two orders, one build, one consumption. This is the same append-only ledger that records every movement, described in why inventory transactions are append-only.

When the over-build is intentional

Without forward netting, the over-build is not a hidden bug; it is a visible, documented behavior. The netting diagnostic even reports how many units a same-run producer would have supplied if forward netting were on, so a planner can see the cost of leaving it off. Some plants prefer the simpler point-in-time behavior; others want the tighter same-run netting. Forward netting is the setting that chooses between them, and when a run mixes a build-to-stock producer with a consumer of the same part, it is what keeps the plan from building supply it is already building.

For a planner, the value is concrete. Forward netting is what lets a single planning run contain both "build 100 to stock" and "ship 60 to a customer" and resolve them correctly, producing 100 and consuming 60, rather than producing 160 and leaving 100 aging on the shelf. It is the same connect-the-plan-to-the-floor discipline behind production scheduling in EDGEBIC: the plan should account for the supply it creates, not ignore it. That is also a core lesson of sound material requirements planning, where supply and demand must be netted against each other rather than planned in isolation.

See forward netting resolve a producer and consumer in one run in the EDGEBIC platform overview, or contact US for a demo.