Sales, Production, and Consumption: The Three Forecast Types in EDGEBIC

EDGEBIC by User Solutions carries three forecast types on every demand forecast row, Sales, Production, and Consumption, and they add together rather than replace one another, so the type you pick is not cosmetic: it decides how your independent demand stacks up into the gross forecast for each planning bucket. A Sales forecast, a Production forecast, and a Consumption forecast entered for the same product and week are three separate rows that all count, which is powerful when the streams are real and a trap when one is a duplicate.

This post explains what each type means, why the type is part of a forecast row's identity, and how all three feed the same gross requirements the projected available balance reads. For the wider demand picture, start from the EDGEBIC planning guide, and for the concept in general terms see what forecast consumption is.

What Each Type Means

A demand forecast is your estimate of how many units a product will need in a future bucket. It is not a committed order, and you enter it per product, per bucket, at a chosen granularity of day, week, or period. The type labels where that demand comes from.

The three exist so you can separate demand by origin. A finished good's customer demand belongs under Sales. A component you draw down at a steady rate belongs under Consumption. An internal build target that is not a customer order belongs under Production. Choosing the right label keeps the demand readable when you review it later.

Why the Type Is Part of the Identity

Each forecast row is identified by four things together: the product, the bucket size, the bucket date, and the type. That combined key is what tells EDGEBIC whether you are editing an existing row or creating a new one.

The consequence is direct. Enter a Sales forecast of 120 for the week of the sixth, then enter another Sales forecast of 150 for that same week, and the second entry updates the first, because the product, bucket, date, and type all match. No duplicate is created. But enter a Production forecast of 30 for that same week, and it lands as a brand-new row, because the type differs. Same product, same week, different type, different row.

This is exactly why the types are additive. Two rows with different types are two independent pieces of demand, so the plan sums them.

How the Types Add Into Gross Requirements

When the projection runs, it gathers every forecast row for the product in a bucket and adds their quantities into a single forecast figure for that bucket. Sales, Production, and Consumption all pour into the same sum.

Take Assembly-B200 for one week, with three entries:

The gross forecast for that week is 150 plus 30 plus 10, which is 190. That 190 is then combined with any firm committed demand under the product's forecast consumption rule to produce gross requirements, the number the projected balance actually subtracts. The two rules, GreaterOf and MinusConsumed, decide how forecast and firm interact, but they act on the combined forecast, not on any single type.

For a make-to-order product the story is shorter. The projection ignores forecast entirely and counts only firm demand, because a custom job is built to a real order. Your forecast rows still store and display, they simply contribute nothing to the plan until the product is set to make-to-stock.

The Over-Forecasting Trap

Because the types add, the most common mistake is entering the same demand twice under two labels. One planner books 100 units of a week as Sales while another books the same 100 as Production, and the projection now sees 200. Nothing is broken. The math is doing exactly what you told it, and you told it there were two separate streams.

The fix is to decide, per product, which types you actually use. Many plants use Sales only for finished goods and Consumption only for materials, and never touch Production. If a stray row appears, you can update it to zero (the row is kept for audit but adds nothing) or delete it outright, and the gross forecast drops back to the real number. When you want a clean slate for a product, a full purge of its forecasts clears every type at once.

A Worked Example: Materials and Finished Goods on One Plan

Consider a stocked finished good, Bracket-A, and the steel blank it consumes, Blank-S. You forecast Bracket-A customer demand under Sales at 120 a week. Separately, on Blank-S, you forecast usage under Consumption at 120 a week, because each bracket draws one blank.

Both products now carry independent demand that the projection nets against their own supply. Bracket-A's projected balance walks down 120 a week against finished-goods stock and incoming build-to-stock orders. Blank-S's projected balance walks down 120 a week against material on hand and incoming purchases. Each is planned on its own calendar, each with its own reorder settings, and each forecast reads clearly because the type names its origin. If you later add an internal Production run of 20 prototype brackets one week, that lands as a third Bracket-A row and lifts that week's gross forecast to 140, exactly as intended.

Keeping the Types Honest

The forecast is only useful if the numbers under each type mean what the label says. Keep customer demand under Sales, material draw-down under Consumption, and reserve Production for genuine internal builds. Review the forecast by type periodically so a duplicate stream does not quietly double a week's demand.

The forecast is one input to the replenishment loop. Once the projected balance dips below a trigger, EDGEBIC turns the shortfall into a replenishment suggestion, and forecasting inputs are what keep that suggestion honest. Enter each forecast under the right type, and the plan reflects the demand you actually expect. For the general practice of building demand plans, see demand forecasting for manufacturing, and to compare how firm orders consume forecast, read the forecast consumption rules.