Glossary (EDGEBIC)

What Is the Job End Date on a Job?

User Solutions TeamUser Solutions Team
|
6 min read

The Job End date on a manufacturing order is the delivery-ready date: the moment the last work-center operation finishes, plus the product's end-item lead time in calendar days. In EDGEBIC by User Solutions this is the single date every lateness judgment is made against, on the schedule grid, on the dashboard, and in the Gantt's coloring, which is why a job whose machines finished on Thursday can still be correctly reported as late against a Friday promise when the product carries a two-day pack-and-ship tail.

This entry is part of the EDGEBIC glossary series; for the broader vocabulary of production planning, see the manufacturing glossary.

How Job End Works

The formula is short: Job End equals Item Start plus the product's lead time, applied forward in calendar days.

Each half of that deserves a note.

Item Start is the end of the job's last work-center operation, excluding material rows. It is the moment the manufactured item physically exists.

The lead time is a product-level field measured in calendar days rather than working hours. It represents everything that must happen after the last machine before the item is deliverable: curing, drying, packing, inspection hold, freight to the customer. It consumes no work-center capacity, which is the reason it is modeled as a separate tail rather than as another routing step. There is no machine to book and no shift to respect; two calendar days of cure pass at the same rate on a Saturday as on a Tuesday.

The result is a date that answers a different question from any operation-level date on the schedule. Every other date in the plan tells you about the shop. Job End tells you about the customer.

A Worked Example

From the documentation's sample plant, two jobs show the pair working in opposite directions.

JOB-2026-0101 builds Widget-A, which carries a Lead Time of 2 days. Its last operation on Assembly-1 finishes Thursday at 14:00, so Item Start is Thursday 14:00 and Job End is Saturday 14:00. The due date is Friday. Days Late is not zero, because the two days of packing push delivery-readiness past the promise even though every machine finished a day early. A plant reading only the machine date would have called this job a success right up to the loading dock.

JOB-2026-0102 builds Bracket-B with one day of lead time. Its mill work ends Tuesday July 21 at 10:00, so Item Start is Tuesday and Job End is Wednesday July 22. The due date is Wednesday July 22, so Days Late reads 0. Here the tail fits inside the promise and nobody needs to think about it.

Now change one product record. Set Bracket-B's Lead Time from 0 to 1 and every Bracket-B job's Job End shifts one day past its Item Start immediately, and a borderline job on the dashboard can flip from on-time to at-risk. No work-center booking moved. The delivery-ready date simply caught up with a truth the plan had not been carrying.

How EDGEBIC Uses Job End

Job End is not a decorative column; it is the reference date for a whole family of judgments:

  • Days Late is computed from it. For an open job, the figure is the larger of projected lateness, meaning Job End past the due date, and calendar days already elapsed past the due date. Closed jobs always read 0.
  • The dashboard job status buckets classify against it. Late, Overdue, On time, and Early are assigned by priority, and all of them use the delivery-ready date so that every surface agrees. See job status buckets on a dashboard.
  • The Gantt draws the tail. The lead-time band appears after the last operation bar, so the gap between production finishing and the job being deliverable is visible rather than implied.
  • Backward scheduling reserves it in front of the due date. A backward pass places the tail first and then targets the last operation early enough for the tail to fit, which is precisely the case forward scheduling handles badly on tight jobs.
  • A blank due date is filled from it once. The scheduler fills an empty due date from the job's first planned end and then never moves it, so subsequent runs measure against a stable promise rather than a moving one.
  • Quotes carry it through. The simulated end date a quote reports is a delivery-ready figure, which is what makes it safe to send to a customer.

The discipline worth adopting is simple: Job End is the external number. Anyone speaking to a customer, filling in an acknowledgment, or judging whether a promise is at risk should be reading Job End. Item Start is the internal number for the floor. Keeping those two audiences on two columns removes most of the confusion the pair ever causes. For the mechanics of the tail itself see end-item lead time in scheduling, and for how lateness is read day to day see days late on a job and the rescheduling explainer.

Job End is the delivery-ready date: the moment the last work-center operation finishes, plus the product's end-item lead time in calendar days. It is the date the item can actually leave the building, not the date the machines stop. Every lateness figure in the application, on the grid, on the dashboard, and in the Gantt coloring, is judged against Job End so that all surfaces agree.

Job End is what the plan produces; the due date is what was promised. Lateness is the comparison between them. A job whose Job End falls on or before its due date is on time, and one whose Job End falls after it is late, whether or not the calendar has passed the due date yet. That is why a lateness figure can appear days before anything has actually gone wrong.

Because the product carries no end-item lead time. When lead time is zero, the tail disappears and the delivery-ready date is the same instant the last machine finishes. Plants with no cure, pack, or freight leg on their products see the two columns show identical values on every job, which is correct rather than a display fault.

It is the system doing its job early. Days Late for an open job takes the larger of two numbers: projected lateness, meaning how far the current Job End falls past the due date, and calendar days already elapsed past the due date. Your job is showing the first of those. The plan, as it stands right now, finishes two days past the promise, so you are being told while there is still a week to react. That warning is worth far more than the same figure appearing after the due date has passed, when overtime, an alternate work center, a priority change, or an honest conversation with the customer all cost more and achieve less. Treat an early red as a work item rather than an error report.

Only if the tail genuinely does not exist. Setting lead time to zero does not remove the two days of cure or the freight leg from reality; it removes them from the plan, which means the plan starts promising dates the shipping dock cannot meet. The gap you are describing is a visibility problem rather than a data problem, and the honest fix is the reverse of what it feels like: keep the lead time accurate and make sure everyone talking to customers reads Job End rather than Item Start. If the tail is causing genuine lateness on tight jobs, the useful lever is backward scheduling on those products, because a backward pass reserves the tail in front of the due date and targets the last operation early enough for it to fit.

Expert Q&A: Deep Dive

Q: A job shows Days Late 2 but the due date is still a week away and nothing has gone wrong. Is that a bug?

A: It is the system doing its job early. Days Late for an open job takes the larger of two numbers: projected lateness, meaning how far the current Job End falls past the due date, and calendar days already elapsed past the due date. Your job is showing the first of those. The plan, as it stands right now, finishes two days past the promise, so you are being told while there is still a week to react. That warning is worth far more than the same figure appearing after the due date has passed, when overtime, an alternate work center, a priority change, or an honest conversation with the customer all cost more and achieve less. Treat an early red as a work item rather than an error report.

Q: We keep getting caught out because Job End includes a lead time nobody on the floor thinks about. Should we just set lead time to zero?

A: Only if the tail genuinely does not exist. Setting lead time to zero does not remove the two days of cure or the freight leg from reality; it removes them from the plan, which means the plan starts promising dates the shipping dock cannot meet. The gap you are describing is a visibility problem rather than a data problem, and the honest fix is the reverse of what it feels like: keep the lead time accurate and make sure everyone talking to customers reads Job End rather than Item Start. If the tail is causing genuine lateness on tight jobs, the useful lever is backward scheduling on those products, because a backward pass reserves the tail in front of the due date and targets the last operation early enough for it to fit.

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

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.

Let's Solve Your Challenges Together