How to Work the Reconciliation Exception Rows in EDGEBIC

Working a reconciliation exception row in EDGEBIC by User Solutions is three moves: read the reason, drill through, re-run. Every row carries the number that triggered it and the instruction that clears it, so the review is execution rather than investigation.

For how to open the report, see how to run the Schedule Reconciliation report. The task library is at the EDGEBIC how-to hub.

Before You Start

• The schedule is current. Working rows against a stale plan produces fixes for problems that have already moved.
• You have the rights to act on what you find: rescheduling, capacity overrides, and the data screens the anomaly drill-downs land on.
• You will work top down. Both grids sort worst first, so the order is already decided for you.
• You will re-run in batches rather than after each row. A single re-run after several fixes is faster and shows you what actually cleared.

The Order to Take Them In

Jobs before capacity. A missed customer date costs more than an internal capacity problem, and some capacity rows resolve themselves once a job moves.

Within the Jobs grid the sort is worst first, and it means something specific: the single worst thing in the whole schedule is the first row of the first tab. Within the Capacity grid the same holds, with the largest overruns at the top.

Working a Late Row

The reason names the days past due and, where the baseline exists, how far the job has slipped against its originally committed end. That second figure is the useful one: nine days late having slipped six says the plan degraded recently, while nine days late with no slip says it was committed late from the start. Those are different conversations.

Double-click to land on the job in the schedule view. From there the options are the usual three: expedite through re-sequencing, add capacity, or renegotiate the date. If the job simply needs re-planning from where the floor actually is, how to resume a job from where the shop actually is is the route.

One subtlety when cross-checking against the Late Jobs report: a job whose operations are all finished classifies as completed late here rather than late, so it reports "finished late" instead of "will be late". The counts can differ for that reason and both are right.

Working an Anomaly Row

The status says the job carries at least one critical data problem. Only critical findings change a status; warnings are counted and shown alongside and are otherwise inert, so a job can carry several warnings and still read as on track.

Right-click the row and open the anomaly view for that job. The check identifiers tell you which family of problem it is, and each has its own explanation available in the application. Fix the data, then re-run.

Do not read the pace, hours or variance figures on an anomaly row until the data is clean. That is what the status is warning you about. Background is in how to run and read the anomaly report.

Working an Over-Booked Row

The reason names the hours over and tells you the two available fixes: move a job off the day, or raise the daily capacity for it.

Double-click and the per-day capacity dialog opens on that machine and date, on top of the report. That layering is deliberate. Raise the override there, close it, re-run the report, and watch the row disappear without leaving the review. See how a daily capacity override replaces the formula.

The hidden column listing the jobs booked on the bucket tells you what there is to move, and it is the faster fix when capacity genuinely should not change.

Before moving anything on a synchronized machine, check whether the load is mirrored parallel work. Those hours are exempt from this check by design and should never produce a violation row, so if one appears on a cell that runs synchronized operations, read why a dependent-parallel child is exempt from the over-booked check before you start re-sequencing.

Working an Idle Row

The parameter that looks like it belongs on a different report, and the one planners use most after late jobs.

An empty day is only worth flagging in context, so an idle row that matters names the late job whose unfinished operation is queued for that machine. The instruction writes itself: pull that step forward.

Idle rows on machines with no late backlog are worth a glance and rarely worth an action. The ones carrying a job number are recovery opportunities sitting in plain sight.

How to Check It Worked

The row is gone after a re-run. That is the primary check and it is binary.

The headline count fell by what you expect. If you fixed three rows and the count dropped by five, two cleared as side effects, which is normal. If it dropped by one, something you thought you fixed did not take.

Both grids empty with show-all off is the finish line. At that point the plan and the plant agree on every question the checklist asks.

Common Mistakes

Investigating instead of reading. The reason column already carries the triggering number and the next step. Skipping it turns a two-minute row into a research task, which is exactly what the report was built to stop.

Fixing a pace row on a job that also has an anomaly. The job appears once, under its worst status, but the underlying data problem still contaminates the pace figures. Clean the data first.

Re-running after every single row. Batch the fixes. The re-run is not free and the cleared rows are easier to read in groups.

Raising a capacity override to clear a row you should have moved a job off. The override is honest when the machine genuinely can run longer that day and a fiction when it cannot. A fiction clears the row and moves the problem onto the floor.

Treating idle rows as noise. The ones naming a late job are the cheapest recovery available in the whole report.

Stopping when the chips look green. Two counts feed the headline without chips of their own, loaded days and jobs that finished late, so the grids can still hold rows worth reading after the strip is clean.

Next Steps

If the same rows return every morning, the fix is upstream of the report. Recurring over-booked days point at calendars, covered in what is a capacity override. Recurring anomalies point at data entry or import discipline, covered in clearing scheduler anomalies before publishing.

The takeaway

Read, drill, re-run, and take the tabs in order. The report was built so the review is doing rather than deciding, and the reason column is the whole product. When both grids empty out, you have a schedule you can defend line by line rather than one you hope is fine. See the platform at EDGEBIC.