- Home
- Blog
- EDGEBIC Platform
- 8 Projection and Available to Promise Mistakes Tha…
8 Projection and Available to Promise Mistakes That Cost You Orders
Available to promise mistakes and projection misreadings almost never come from bad arithmetic. They come from reading a correct number as though it answered a different question. In EDGEBIC by User Solutions every figure on the projection has a precise and narrow meaning, and these eight confusions are the ones that recur.
If the underlying calculations are unfamiliar, projected available balance explained and available to promise in EDGEBIC cover them. This post is about the traps.
1. Expecting a Suggestion To Lift the Balance
The symptom. Three consecutive buckets show a replenishment suggestion. A planner firms the first one, expects the other two to disappear, and finds them still sitting there before the next scheduling run.
What is happening. The suggested quantity is displayed on its row and deliberately excluded from the balances carried forward. The projection counts supply that exists, and a suggestion nobody acted on is not supply.
Why that is right. The alternative is a projection that looks healthy because of a button nobody pressed. A plan built on hypothetical receipts is the classic way a planning screen becomes something people stop trusting.
What to do. Firm the suggestion. On the next projection the resulting build-to-stock order appears as a scheduled receipt in its completion bucket, the balance rises from there onward, and the suggestion for that bucket clears. The firming step is covered in how to enter forecasts and firm suggestions.
2. Quoting the Discrete ATP Column
The symptom. A salesperson reads zero available in week three and declines an order the shop could easily have taken.
What is happening. Discrete available-to-promise appears only at supply points: the first forward bucket carrying current on-hand, and each bucket with a scheduled receipt. Every other bucket reads zero, which means "no new supply arrived here", not "nothing available".
What to do. Read the cumulative column, which carries the running promise capacity forward across non-supply buckets. To answer "can I promise 150 by a date", find the earliest bucket whose cumulative figure reaches 150 and quote that bucket.
A useful habit. Hide or ignore the discrete column entirely during a promising conversation. It is a diagnostic figure that explains where capacity came from, not a quoting figure.
3. Misreading the First Bucket's Receipt
The symptom. Today's bucket shows a scheduled receipt far larger than any single build order, and nobody can find the order behind it.
What is happening. Overdue open orders are clamped into the current bucket rather than left in a past bucket where nobody would act on them. Six late build orders show as one combined figure.
Why that is right. The alternative is late supply disappearing into history buckets, which suppress planned supply and demand entirely. Overdue work would silently vanish from the plan.
What to do. Treat a large first-bucket receipt as a prompt. Open the order list, check which of those orders are genuinely going to land and when, and promise against the ones you believe. The same clamping applies to overdue demand, so a large first-bucket demand figure deserves the same scrutiny.
4. Assuming Safety Stock Is a Floor
The symptom. A plan ends every period at exactly safety stock, the planner feels covered, and one rush order produces a stockout.
What is happening. Safety stock is a replenishment trigger by default, not a consumption floor. It flags the row and fires a suggestion, and it does not prevent consumption below the level or block a negative balance.
Why it is designed that way. Refusing to plan below safety stock would hide a real commitment rather than resolve it, in the same spirit that negative ATP is shown rather than suppressed.
What to do. Treat safety stock as the level at which you want to be told, and set your reorder trigger above it so the build starts before you eat into the cushion. A product can carry a reorder point of 50 and a safety stock of 20 quite reasonably. For sizing the level itself, safety stock calculation covers the statistics. A per-product option to enforce safety stock as a genuine floor exists for the rare cases that need one.
5. Reading a Deficit as Cured by the Next Receipt
The symptom. Week 2 goes negative, a receipt lands in week 3, and everyone relaxes. Week 4 is still negative.
What is happening. The negative carries forward. A shortfall is only resolved by supply larger than the accumulated gap plus the demand that follows it.
What to do. Read down the balance column to the end of the horizon rather than stopping at the first big receipt. The size of the remaining negative is the size of the decision you still have to make, quantified for you.
6. Expecting Forecast To Drive a Make-to-Order Product
The symptom. Forecast rows exist for a product and the projected balance never reacts to them.
What is happening. For a make-to-order product, gross requirements are committed demand alone. Forecast rows are stored and displayed on the forecast tab, and contribute nothing to the balance.
Why that is right. A part built only when a customer orders it should not be planned to stock against a prediction. Custom work is the whole reason make-to-order exists.
What to do. Decide which the product genuinely is. If it should be planned to stock, change its build method and the stored forecasts start participating on the very next projection with no re-entry required. The policy resolution is covered in make to stock vs make to order.
7. Comparing a History Bucket to a Forward Bucket
The symptom. A planner sets the horizon start to a past date, sees zeroes in the forecast and demand columns of the early rows, and concludes data is missing.
What is happening. A bucket whose end date falls entirely before today is a history bucket. It ignores planned supply and demand and moves only by realised ledger movement, because a plan for last Tuesday is no longer a forecast: it either happened or it did not, and the ledger already knows.
What to do. Use history buckets for what they are good at, which is calibration. Run the window back thirty days and compare what the plan said against what the ledger recorded. That comparison is the fastest way to learn whether your forecasts are systematically high, low, or badly timed. Do not read those rows as a broken forward plan.
8. Fighting the Horizon Instead of the Bucket
The symptom. Setting a two-year range on the matrix produces a warning about too many buckets, and someone concludes the horizon is limited.
What is happening. The matrix derives its column count from the span between its start and end dates, and a very wide daily range exceeds the column cap it enforces.
What to do. Change the bucket width rather than the range. Weekly buckets cover the same two years in roughly a hundred columns, and monthly periods in twenty-four. You lose within-bucket timing detail, which is the correct trade at that horizon: nobody plans a specific Tuesday eighteen months out. Keep daily buckets for the next four to eight weeks where timing genuinely matters. Reading the two screens is covered in how to read the projection.
9. Treating Days of Cover as a Policy Number
The symptom. Someone sets a target days-of-cover figure for a class of parts and manages to it, and the plan is worse than before.
What is happening. Days of cover divides current on-hand by average demand per day across the horizon. The word doing the damage is average. A part with 200 units and 400 units of demand concentrated in a single week three weeks out shows a comfortable days-of-cover figure right up to the moment it does not.
What to do. Use days of cover as a sorting key, not a target. It is excellent for ranking a catalog by which parts deserve attention first, and it is a poor basis for a stocking policy. The projected stockout date is the figure to manage against, because it comes from the actual demand shape rather than its mean. A blank days-of-cover value, incidentally, means no demand in the horizon rather than an error.
The Meta-Mistake: Promising on Materials Alone
Worth naming separately because it is the expensive one. Available-to-promise is a materials answer. It says uncommitted units exist or are scheduled to arrive. It says nothing about whether a work center is free, whether the certified operator is rostered, or whether your bottleneck is already three weeks deep.
A promise worth making uses both sides: the ATP figure for the material position, and a quote simulation against the finite capacity schedule for the timing. When they disagree, the disagreement is the answer. The capacity side is covered in the quoting guide.
The Habits That Prevent Most of This
Refresh before you read, because switching matrix lenses re-pivots data already loaded rather than fetching new data. Quote cumulative, never discrete. Check that scheduled receipts come from orders you believe. Read the balance column to the end of the horizon. And when a figure surprises you, double-click the cell and read the breakdown rather than guessing, because every number on that row comes from a named input.
For the wider planning layer see the inventory and planning guide, and for the inventory configuration errors that distort these screens before you ever read them, inventory tracking mistakes. The platform tour is in the complete guide to EDGEBIC. To pressure-test these numbers against your own commitments, bring a demand and receipts export to a demo and ask User Solutions to run it on your data.
Expert Q&A: Deep Dive
Q: We show forecast demand on a product but the projected balance never moves for it. Is the forecast broken?
A: The forecast is stored correctly and being ignored on purpose, because the product is make-to-order. For a make-to-order item, gross requirements come from committed demand alone and forecast rows contribute nothing, which is the right behavior for custom work: you do not plan stock against a prediction for a part that is only built when someone orders it. The rows still display on the forecast tab, which is what makes it look broken. If the product genuinely should be planned to stock, change its build method and the stored forecasts start participating in the very next projection with no re-entry needed.
Q: A shortage appeared in week 2 and there is a big receipt in week 3, so why is week 4 still negative?
A: Because a deficit carries forward and is only cured by supply that exceeds the accumulated gap, not by any supply at all. If week 2 ends at minus 80 and week 3 brings in a receipt of 100 against 60 of demand, week 3 ends at minus 40, and week 4's own demand takes it lower again. The projection is telling you the receipt is too small or too late, and it is telling you by exactly how much: the size of the remaining negative is the size of the second decision you still have to make. Read down the balance column rather than looking for the first big receipt and relaxing.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
How an Open EDGEBIC Screen Notices Someone Else's Edit
On a shared database, a change made on one workstation reaches every other open screen within a few seconds, without anybody pressing anything. How the change signal works and why your selection survives it.
What Changes When EDGEBIC Moves to a Shared Database
Moving EDGEBIC from one workstation to a shared SQL Server changes three assumptions at once: who may overwrite whom, how an open screen stays current, and who may run the scheduler.
What the EDGEBIC Refresh Button Actually Does
The refresh button forces a full re-read from the database, which is not the same as closing a screen and reopening it. Why the distinction matters on a shared database, and when to press it.
