How to See Why a Job Is Late in EDGEBIC

To see why a job is late in EDGEBIC, work a five-check list in order: someone took the capacity first, the calendar has no hours there, the work center offers less than you think, the routing adds waiting on purpose, or the job resumed from reality. The vast majority of "the date looks wrong" questions resolve on the first two checks. EDGEBIC by User Solutions is a finite capacity scheduler, so a late job is almost never a bug: it is the plan telling you the truth about a plant that cannot be in two places at once.

This post is the diagnostic. For what the columns mean, how to run the scheduler explains Item Start, Job End and Days Late; every task guide is at the EDGEBIC how-to hub.

Before You Start

• The job is scheduled. Days Late only means something once a job has a planned Job End to compare against a due date.
• You can open the Job View tab to read the job's per-operation rows.
• You know the job's priority and its routing, or you know where to find them.

First, Read Days Late Correctly

Days Late on an open job is the larger of two figures: calendar days already past the due date, and projected lateness where the plan's Job End lands past the Due Date. A number shown before the date passes is a projection, not a failure that already happened. It is red on purpose, so you act while there is still runway. Closed jobs always read 0.

Remember the target of the comparison. Job End is Item Start plus the product's lead time in calendar days. A job whose last operation finishes on the due date but whose product carries a two day tail is delivery-ready two days late, and Days Late says so correctly.

The Five Checks, In Order

1. Someone else got the capacity first

Higher-priority jobs (lower numbers) and jobs you did not select keep their reservations, and your job fits around them. Look at the Priority column and at the constrained work center's load. A priority-1 job sitting on the busiest machine all week is the single most common reason another job lands late.

2. The calendar has no hours there

Weekends, holidays at the plant, shift or work center level, downtime, or a shift that simply is not assigned to that work center all create gaps the job jumps over. If the job "skips" Saturday and Sunday, that is a calendar with no hours, working as designed.

3. The work center offers less than you think

Utilization below 100 percent, fewer machine instances than you assumed, a per-day capacity override, or a one-job-per-day rule on that work center all shrink what is actually available. An 80 percent utilization turns an eight hour shift into 6.4 plannable hours, and that difference compounds across days.

4. The routing adds waiting on purpose

Queue time after a step, transit days between operations, material lead times, or a predecessor that itself ran late all push a step out with intent. Read the job's operation rows in Job View: a four hour queue time after milling pushes welding into the next shift, and the routing meant it to.

5. The job resumed from reality, not its old plan

Once actuals exist, the remaining steps schedule forward from where the floor actually is, never earlier. If step 1 finished two days late, steps 2 and 3 moved out with it. A backward job that could no longer fit also falls back to forward scheduling. Check the Actuals Logged? column and the Actual Start and Actual End values on the operation rows.

Where to Look for Each Check

Common Mistakes

Reading Days Late as history when it is a projection. A positive number a week before the due date is a forecast that the plan cannot make the promise. Treat it as a warning to act, not as a record of a miss that already happened.

Blaming the engine for a calendar gap. A job that skips a weekend is not scheduled wrong; there are no working hours on the weekend. Check the calendars before you check anything harder.

Forgetting the start time. A start time of 09:30 forbids the whole 08:00 to 09:30 window on day one, which quietly costs the job a chunk of its first day. Reset it to midnight unless a real constraint says otherwise.

Comparing against Item Start instead of Job End. Lateness is measured against the delivery-ready date, which includes the product's lead-time tail. The slate-colored Lead Time band on the Gantt is that tail, and it consumes no capacity but does count against the promise.

What to Do Next

If the answer was capacity, the first lever is the queue: how to set a job priority explains what changing the number does, and how to schedule a rush order walks the full urgent-job sequence. If the constraint is a genuine bottleneck, how to flag and schedule around a bottleneck covers anchoring it. For the concept behind the lead-time tail, end-item lead time: Item Start vs Job End is the companion read, and the EDGEBIC product page covers the platform.