Closing ERP Work Orders That EDGEBIC Still Thinks Are Open

Your ERP closing a work order is completely invisible to EDGEBIC, because the sales order import mask has no status or completion column and an import never deletes what is missing from a file. In EDGEBIC by User Solutions the plan keeps every job it was ever given until somebody closes it there. Left alone, that residue does not corrupt your schedule so much as your reporting, which is the harder problem to notice.

Closure is not something the order file can say

Look at what a sales order row actually carries. The mandatory columns are the product, the quantity, and the job date. The optional ones are an order reference, a job number, a customer name, a due date, an order date, a priority, a unit price, and free-text notes.

There is no status field in that list, and no completion flag. The mask was built to describe demand, not to describe the life cycle of demand. So even if your ERP export includes a status column and you would happily map it, there is nothing on the EDGEBIC side for it to land on.

That is the first half of the problem. The second half is the import model itself: every row ends as Created, Updated, Reused, or Failed. There is no Deleted. A job that disappears from this week's export is not removed; it simply stops being mentioned, keeps whatever it had, and stays in the plan. The consequence for export design is covered in deciding which ERP work orders to import. The consequence for the jobs already sitting in EDGEBIC is this post.

The one closure signal that can ride in on a file

There is exactly one, and it comes in on a different mask.

The actuals import carries an optional Complete column, and a truthy value in it marks that operation finished. The mask options also include MarkCompleteOnImport, which marks every imported operation complete, with the per-row Complete column overriding it row by row.

So if your ERP produces labor transactions with an operation-complete flag, you can close operations from a file. That is genuinely useful, and it is the reason a shop with good labor reporting sees far less residue than one without.

But read what it closes. It closes operations, not jobs. Which brings us to the trap.

A job with every step done is not a closed job

The Completed? checkbox on a manufacturing order shows ticked when either the order is formally closed or every work center reports complete. That is helpful on screen and misleading in the mind, because those two states are not the same thing.

A job that is derived-complete, meaning all of its steps report done, is not auto-closed. It stays schedulable until somebody clicks the checkbox and confirms the completion date.

So the sequence that produces silent residue looks like this:

1. The ERP export drops the work order, because it closed there.
2. The actuals feed, or the kiosk, marks the last operation complete.
3. The grid shows a ticked Completed? box.
4. Everyone assumes the job is closed.
5. It is not. Nobody clicks the box.

Nothing looks wrong at any step. That is exactly why it accumulates.

What the residue costs

The first row is the one that bites hardest, because a late-job count that reads high for a reason nobody can explain is the fastest way to lose a management audience. Closing jobs promptly is a documented best practice precisely because open-but-done work distorts Days Late and dashboard status counts.

Note that none of these are schedule corruption. A finished job with all its actuals recorded will not steal capacity from live work on a reschedule, because completed operations are preserved rather than replanned. The damage is entirely to the numbers people read.

The weekly closing pass

Fold this into the routine you already run rather than making it its own ceremony. Ten minutes a week is the right size.

Compare the two open lists. Your export filter defines what your ERP considers live. Anything in the EDGEBIC plan that was not in this week's file is a candidate for closing. This check only works if your export filters on status rather than a rolling date window, because a job can leave a date window without closing, and you cannot tell the two cases apart.

Close what is genuinely finished. Tick the Completed? checkbox and confirm the completion date. Use the real finish date rather than today, because the completion date is what the record keeps.

Investigate what is left. A job that vanished from the export while still carrying unfinished operations is a genuine question, not housekeeping. Usually it is a canceled order that nobody told the floor about, or a status code the export filter does not recognize.

Write down who does it. This is the step that decides whether the routine survives contact with a busy month. The general argument for a named owner is in who owns the ERP import routine on your team, and the closing pass belongs to the same person.

Close, do not delete

Two mechanics are worth knowing before somebody tidies up enthusiastically.

Deleting an order deletes its production schedules with it, and it cannot be undone. The confirmation says so. That takes the recorded hours and actual dates with it, so any backward-looking report covering that period quietly loses rows.

Clearing a schedule resets the Completed? flag. If you only want a job out of the current plan while keeping the order, clearing its schedule does that. But a closed job you clear becomes open again, so it needs closing a second time. This matters most for anyone who clears schedules as part of a periodic reset.

The rule is short: close finished work, clear work you want replanned, and delete almost nothing.

Where this fits in the sync routine

Closing is the fourth step in a cycle most shops only run three steps of. Export from the ERP, import through the mask, run the scheduler, and then close what the file stopped mentioning. The first three are in the weekly ERP sync routine; the count check that surfaces the divergence sits naturally alongside an ERP import reconciliation checklist, and a wider quarterly sweep is in a monthly ERP to EDGEBIC data audit.

The takeaway

An ERP work order closing does not close the EDGEBIC job, because the sales order mask has no status column and an import never deletes an absent row. The only closure signal that arrives in a file is the actuals import's Complete column, and that closes operations rather than jobs. A job whose every step reports complete still shows a ticked Completed? box while remaining open and schedulable until somebody confirms the completion date. Left alone that residue does not break the plan, it breaks Days Late and your dashboard counts. Run a weekly pass comparing the export against the plan, close what finished, and never delete an order when clearing or closing will do. See the engine on the EDGEBIC product overview, the shared import layer on the ERP integration architecture, and bring a work order export and a job list to a working session to see how far apart they currently are.