End Item Lead Time: Item Start vs Job End in EDGEBIC

End item lead time is the delivery tail after the last machine stops, and it splits every job's finish into two dates: Item Start when the item physically exists, and Job End when it is ready to deliver. Paint cures, outgoing inspection signs off, freight takes days. Modeling that tail explicitly is what stops different screens disagreeing about whether a job is late, and it is what lets backward scheduling aim at the right target in EDGEBIC by User Solutions.

This post covers the mechanism with worked arithmetic. For the direction that depends on it, read backward scheduling explained; for the setup procedure, how to schedule a job backward from its due date.

The Two Dates

   last operation ends              delivery-ready
          │                               │
  ────────┤███ lead-time tail (display) ██├────────►
          │                               │
    ITEM START                        JOB END
  = last work center                = Item Start
    operation end                     + product lead time

One rule about Item Start is worth stating explicitly: material rows are excluded. A material step consumes no machine capacity and its bar can sit anywhere the procurement timing requires, so counting it would let a material bar masquerade as the manufacturing finish. Item Start is machine work only.

Where the Tail Shows Up

On the Drive Schedule grid. Item Start and Job End sit side by side, next to the due date and Days Late, so the split is visible without opening anything.

On the Gantt. After the job's last operation, a muted band is drawn, captioned with the day count. It is display only in every interaction: it cannot be opened for editing, cannot be dragged or resized, is skipped by drag cascades, and is never treated as a downstream operation. Nothing schedules into it.

In lateness. Every surface that classifies a job as late does so against Job End, which is the subject of the next section.

The whole tail is a display-layer derivation. The scheduler is not involved in producing it and it claims no work center hours. With a lead time of zero, the two dates collapse and nothing about the plan changes.

Lateness Is Judged at Job End, Everywhere

This is the reason the split exists at all. A job whose machining finishes on the due date but carries a two day tail is two days late, because the customer receives it two days after the promise. Measuring against the last machine stop would understate lateness by exactly the length of the tail.

Two properties of the Days Late calculation matter in practice. It is a projection: an open job shows lateness before the due date physically passes, which is the warning arriving while acting is still cheap. And it uses the explicit due date only, never a fallback derived from the schedule's own end, because a self-referential comparison would manufacture phantom lateness equal to the lead time on every job.

Closed jobs always read zero. Lateness is a forward-looking planning signal, not a permanent scar.

How Backward Scheduling Reserves the Tail

Here is where the two features become one story. A backward job right-aligned to the raw due date would finish its last operation on the due date, and then its delivery-ready date would land after it. The job would be born exactly as many days late as its lead time, defeating the entire purpose of backward scheduling.

So the backward pass targets the due date minus the product's lead time:

raw anchor  = end of the due day
target      = raw anchor − product lead time (calendar days)

Work completes early enough for the delivery tail to land on the due date. When the lead time consumes all the slack, so that the target lands at or before the job's earliest allowed start, the ordinary forward fallback fires and the job is reported as one that did not fit.

Forward scheduling is unaffected. The tail is added afterwards for display, never as a placement constraint. Only the backward pass treats it as a target.

Worked Example: Forty Valve Bodies

Direction Backward. Cut off date Monday July 6. Due Friday July 17. Product lead time 2 calendar days. Day shifts Monday to Friday, 08:00 to 16:00, one machine per work center, no other load.

The target. A date-only due date means end of that day, so the raw anchor is midnight at the end of Friday July 17. Subtract the two day lead time and all machining must finish by Thursday July 16 at 00:00, which in practice means the close of Wednesday's shift.

Placing backward, successors first:

• Inspect is the last operation, so its deadline is the target itself. Four hours right-aligned inside the last shift before it: Wednesday July 15, 12:00 to 16:00.
• Deburr must hand off to inspect by Wednesday 12:00, and it carries 4 hours of queue time afterwards, so its effective deadline is Wednesday 08:00. Eight hours right-aligned: Tuesday July 14, 08:00 to 16:00. Verification: finish Tuesday 16:00 plus 4 hours queue equals Wednesday 08:00, which is within the Wednesday 12:00 deadline.
• Machine must finish by deburr's start, Tuesday 08:00. Twenty-two hours right-aligned in eight hour shifts, working backward: Monday July 13 for 8 hours, Friday July 10 for 8 hours, and Thursday July 9 from 10:00 to 16:00 for the last 6. Verification: the finish lands on Monday at 16:00, before Tuesday 08:00, and the start on Thursday July 9 is comfortably after the July 6 floor.

The result:

Jul  6  7  8  9 10 11 12 13 14 15 16 17
Mill        ██ ██       ██
Finish                        ██
QC                               ▓
tail                              ░░░░░  Item Start Wed 16:00 → Job End Fri 17
                                      ▲ due date, delivery-ready on the day

Three days of slack sit in front of the job rather than behind it. Item Start is Wednesday July 15 at 16:00, Job End is Friday July 17, and Days Late reads zero on every surface.

The variant that does not fit. Same job, due Thursday July 9. The anchor becomes end of Friday July 10 minus two days, or Wednesday July 8 at 00:00. The routing needs 34 hours of work plus 4 hours of queue, and only two shifts exist between the Monday July 6 floor and that target. The backward attempt fails, everything it placed is removed, and the whole order schedules forward instead, finishing work on July 9 with a delivery-ready date of July 11. The job is recorded as backward-infeasible with its forward window and two days of projected lateness.

Setting the Field Correctly

Three practical rules:

1. The default is one day, not zero. A brand new product already carries a one day tail. If your items are ready the moment the last operation ends, set it to zero deliberately.
2. Keep it honest per product. Backward reserves it, so an inflated value steals production days from the plan. A missing value makes every surface understate lateness by exactly the tail.
3. Do not confuse it with procurement lead time. A material step's lead time draws that step's bar backward from the point of need, showing the buyer when the purchase order had to be placed. End item lead time is outbound: it delays the finished item becoming deliverable. Different records, opposite directions, never interchangeable.

Auditing the Field Across a Product List

Rolling this out on an existing catalog is a short exercise, and it is worth doing deliberately rather than product by product as complaints arrive.

1. List the products that carry a genuine tail. Painted, cured, plated, heat-treated, outgoing-inspected and freighted items usually do. Machined parts collected at the dock often do not.
2. Put the real number on each. Calendar days, not working days, because the tail runs on the calendar rather than on your shift pattern.
3. Set the rest to zero. Every product left at the default carries a one day tail that nobody chose, and on a backward job that day comes straight out of production time.
4. Re-run the affected jobs. Like every master data change, an edited lead time does not ripple into existing plans on its own.

The payoff is that Days Late becomes a number the whole plant can act on. When the tail is modelled, a red row means the customer will receive the item late. When it is not, a red row means something ambiguous, and ambiguous warnings get ignored.

Reading the Symptoms

For the run-level failure patterns around this, see backward scheduling mistakes. For reading the plan against actuals on the Gantt, see reading the EDGEBIC Gantt, planned versus actual. And for how these dates appear on the grid after a run, see how to run the scheduler.

Why the Split Is Worth the Extra Column

A promise is made about delivery, not about the last machine stop. Systems that report only the manufacturing end make planners do the tail arithmetic in their heads, and different screens then disagree about which jobs are at risk. Naming both dates and judging lateness at one of them makes the whole plant read the same number.

User Solutions has been building schedules against real customer promises since 1991, at organizations from GE Railcar (where on-time delivery moved from 30 percent to 90 percent) to Cummins across 33 locations. The tail was always there. Making it a field is what makes it plannable.

Bring a product with a real cure or freight tail to a demo and we will schedule it backward and show both dates on the grid. Contact US to arrange it, or start at the EDGEBIC product overview.