Two Jobs Landed on the Same One-Per-Day Machine: Causes and Fixes

When a one-job-per-day machine unit shows two different jobs on the same date, the rule was not relaxed: a booking already existed on that unit when the engine placed the second job. EDGEBIC by User Solutions enforces the one-job-per-day contract per machine unit and per calendar date, and the allocator satisfies it by searching for a unit that carries no other job that day. A violation therefore means either a stale allocation survived a reschedule, a synchronized mirror wrote onto an occupied unit, or the work center has fewer units than the day needs.

This post is the detailed version of the one-job-per-day symptom in the EDGEBIC troubleshooting guide. For the underlying behavior, machine instances explained covers how units are counted, and what the anomaly checks actually look for covers the family this finding belongs to.

What You Are Seeing

The anomaly report shows a one-job-per-day finding naming a work center, a date, a unit, and the jobs involved. On the schedule board the same unit carries two operations from two different jobs on that date, even though the machine is configured to give a whole day to one job.

Before anything else, confirm you are looking at a real violation. The rule is scoped to a single unit. Two jobs on the same work center but on different units on the same date is correct behavior, and a machine with four units is meant to accept four jobs a day. The check only fires when one unit hosts two different jobs.

Why It Happens

Cause 1: A Reschedule Re-Booked Without Clearing the Prior Allocation

The allocator picks a unit by looking for one with no prior booking on the target date. If a previous allocation for that unit and date was still in the picture when the run placed the second job, the search saw an occupied unit as free and assigned it anyway.

How to tell: the job was rescheduled recently, both operations look normal on their own, and neither is part of a parallel configuration.

Cause 2: A Synchronized Mirror Landed on an Occupied Unit

When a step is configured so two machines must run in exact lockstep, the mirrored booking is written deliberately without a capacity check, because the physics of the operation demands both machines regardless of what else is planned. If the mirror's unit already carried an independent job that day, the one-job-per-day contract is broken by a booking that was never asked to respect it.

How to tell: one of the two operations belongs to a step with synchronized parallel machines, and the machine in the finding is the mirror rather than the primary.

Cause 3: The Day Genuinely Needs More Units Than the Machine Has

A one-job-per-day machine with two units can accept two jobs on a date. A third job that must run that day has nowhere legal to go. If a stale allocation is not the cause and the finding survives a clean run, the constraint and the workload are simply incompatible for that date.

How to tell: the number of jobs competing for that date is greater than the unit count, and every unit is already carrying one job.

A Related Case: the Rule Is on the Wrong Object

The one-job-per-day rule exists on the work center and on the individual routing step. The machine-level version applies the dedicated-day cost to every product that touches the machine. If the constraint really belongs to one part number, the machine-level flag is over-applied, and the schedule pressure that produced the collision is self-inflicted.

How to Fix It

• For a stale allocation: run scheduling again for both jobs named in the finding. A clean run rebuilds the day's unit assignments from scratch and the collision clears.
• For a synchronized mirror: keep the mirror machine free of independent load in the windows where the lockstep step runs. The mirror booking is correct and so is the configuration; what has to change is the other work planned onto that machine.
• For a genuine shortage: add a unit to the work center so there are enough unit-days for the jobs that must share the date, or move one of the jobs to another date.
• For an over-applied rule: move the one-job-per-day setting from the work center to the routing step that needs it, as described in how a step-level one-per-day rule overrides the machine. The rest of the machine returns to normal allocation.

How to Diagnose It, in Order

1. Confirm the two operations share a unit, not just a work center. Different units on one date is correct.
2. Check whether either operation is a synchronized mirror. If it is, the finding is explained and the fix is load planning, not a reschedule.
3. Re-run scheduling for both jobs. A stale allocation clears here, and this is the single most productive step.
4. Count the jobs against the units for that date. More jobs than units means the finding will return no matter how many times you re-run.
5. Check where the rule is set. A machine-level flag that should have been a step-level flag is a common source of avoidable pressure.

How to Prevent It

• Reserve mirror machines. A machine used as a synchronized mirror should not also carry ordinary independent work in the same windows, because the mirror is booked without a capacity check by design.
• Size the unit count to the day. One-job-per-day converts a question about free hours into a question about free unit-days, and those are very different on a busy machine. How a job sticks to the same machine unit covers the related consistency behavior.
• Put the rule where the constraint lives. Equipment constraints belong on the machine; product constraints belong on the step. Running a dedicated day with one-per-day walks a worked setup.
• Re-run the anomaly report after the fix and confirm the one-job-per-day finding returns zero rows for the date, rather than assuming the reschedule did it.