Why the Promised Date Matters More Than the Order Date

A purchase order carries two dates, and only the promised date changes anything: it is the date the scheduler plans against, and the order date is bookkeeping. The order date says when you asked. The promised date says when the goods land on your dock. In EDGEBIC by User Solutions, every job the scheduler moves for material reasons, it moves because of the promise, which makes that one field the highest-leverage number on the whole purchasing screen.

This post explains why the promise is load-bearing, why EDGEBIC will not calculate it for you, and what to do when a supplier moves it. It sits under the EDGEBIC planning guide and follows what material pegging means, in plain terms.

Two Dates, One of Them Load-Bearing

The Order date on a purchase order header records when the order was placed. It is useful for audit, for supplier conversations, and for working out how long a vendor takes in practice. The scheduler never reads it.

The Promised date on each line is the supplier's statement about when the material arrives. That date is what the inbound supply timeline is built from, what a job's peg is dated at, and what the material row on a routing stretches out to.

The asymmetry is not an oddity. It follows from what a schedule is for. A schedule answers "when can this job run," and a job can run when its material is there, not when somebody sent an order. Planning against the order date would produce a plan that is confidently early by exactly the supplier's lead time, at every job, on every material.

Lead Days Are a Starting Point, Not an Answer

The supplier record carries a Lead days figure: the supplier's typical lead time. It is deliberately reference information rather than an input to a calculation.

EDGEBIC does not compute the promise from it, and the reason is worth stating. A calculated promise looks exactly as authoritative on the Gantt as a real one, but it is nobody's commitment. A supplier who normally takes ten days and has told you fourteen this time has given you a fact; the average has given you an assumption dressed as a fact.

So the workflow is: read the lead days to pick a plausible date, then overwrite it with whatever the supplier actually confirmed. If nobody has confirmed anything yet, put in your best estimate and treat it as provisional, because the plan built on it is provisional too. For the general concept see the supplier lead time glossary entry.

A Worked Comparison: The Same Order, Two Promises

A job needs 50 plates and has 20 on hand, so it is 30 short. Its first sawing operation would otherwise run on Monday 6 July. A buyer raises an order for 30 plates on 1 July.

The order is identical in both columns. The purchase, the quantity, the supplier, the price and the order date are the same. Everything the plant experiences differs, and it differs because of one field.

Now imagine the promise had been left at a default a week out while the supplier had actually said the 13th. The plan would show sawing on the 8th, the shop would set up for it, and the steel would not be there. Nothing in the system would have been wrong; the number typed into it would have been.

When the Promise Sits Before the Need Date

Sometimes a purchase order is Open, the promise is in the future, and no peg forms at all. This confuses people, and it is usually correct.

If the promised date falls on or before the date the job needs the material, the quantity is counted as supply that will simply be available, not as something the job has to wait for. There is nothing to peg, so no reference appears and no amber marker is drawn.

The tell is the material row's own end date. If the material row ends where you expect and the following operation starts on time, the plan already accounts for that supply. Nothing needs fixing. If the promise is genuinely later than the need date and there is still no peg, the cause lies elsewhere, and my job will not start and I cannot see why walks the possibilities in order.

When the Promise Slips

A supplier missing a date is not an exception, it is Tuesday. What matters is what the plan does about it.

The line is marked overdue and drawn in amber on the Purchasing screen. The Scheduled Receipts report sorts overdue lines to the top and shows a days-late count against each.

What does not happen is automatic rescheduling. The plan keeps treating that supply as available, so the projected balance reads better than the rack does until somebody intervenes. That is a deliberate choice rather than an oversight: a system that silently reschedules a plant every time a promise slips produces a plan nobody recognizes from one morning to the next.

The intervention is small. Get the new commitment from the supplier, put it in the Promised field, save, and run the schedule. The plan tells the truth again, the pegged jobs move to the new date, and the amber on the receipts report clears.

A stale promise is worse than no promise, because it is a number the plan trusts.

Two Clocks on This Screen

Purchasing writes land on two different clocks, and knowing which is which prevents a lot of confusion.

Nothing already on the Gantt moves when you press Save. Purchasing edits change what the scheduler will believe, not what it has already committed. This is the source of most "we changed the date and nothing happened" questions, and the fix is always the same: run the schedule.

The Habits That Follow

Three practices fall out of all of this, and together they prevent most material surprises.

Treat the promise as a commitment, not an estimate. It is the number that moves the plant. Update it the moment the supplier tells you something different.

Record the supplier on every order. Without it, neither purchasing report can tell you whose promise slipped, and the days-late column loses most of its value.

Review overdue receipts before publishing a schedule. The report sorts them to the top for exactly this reason. Chase the promise before the shop floor discovers the gap, a routine covered in the Scheduled Receipts report as a pre-publish routine.