Deciding Which ERP Work Orders to Import

A work order export for scheduling should carry the demand somebody has authorized, filtered by status rather than by a date window: released and in-process orders always, firm planned orders in most shops, and nothing that is closed, canceled, or still only an MRP suggestion. The filter decision is worth ten minutes at the start, because an import adds and updates but never deletes what is absent from a file, so a sloppy filter leaves work in the plan that nobody can account for.

EDGEBIC by User Solutions has consumed ERP work order exports since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the export filter is the setting that most often gets built once, by whoever was available, and never revisited.

What an imported work order becomes

An imported work order is demand, not a plan. It arrives as unscheduled work and stays there until a planner runs the scheduler, which states how many jobs are new and how many are being rescheduled before it plans anything. Data movement and planning are separate acts on purpose, so an import can never silently rearrange the floor.

That separation is also why an over-inclusive export is not immediately obvious. The extra jobs sit quietly until the next schedule run, then consume capacity exactly as if they were real.

Status by status

Names vary, so match on meaning:

The most consequential row is the MRP suggestion.

Why MRP planned orders usually stay out

A planned order is a calculation, not a commitment. MRP recreates, renumbers, and withdraws planned orders on every run, so importing them means an overnight calculation rewrites your production schedule before anybody has looked at it.

Three practical problems follow:

• Churn. Identifiers that change between runs create rather than update, so the job list grows and the Created count on a routine import climbs for no real reason.
• False load. Machines look busy with work nobody agreed to make, which pushes genuine promise dates outward.
• Lost trust. A planner who finds yesterday's plan rearranged by a suggestion stops relying on the plan.

The useful version of the same question is a deliberate one: when you want to know what a batch of proposed orders would do to capacity, run it as a what-if and read the effect on the constraint before anyone commits. Quote simulation exists precisely for the promise-date version of that question.

Firm planned orders: usually yes

Firm planned work is authorized: somebody decided it is happening even though the paperwork has not released. Including it makes the load picture honest several weeks out, which is where a finite capacity plan earns its keep.

Two conditions make it work:

1. The identifiers are stable. A firm planned order that keeps its number when it releases updates cleanly. One that gets a new number on release creates a duplicate, and you will see it in the Created count.
2. They are distinguishable. Carry the status through into the export so a planner can tell released work from authorized-but-unreleased work on the board.

If firm planned orders in your ERP are really MRP suggestions with a flag flipped, treat them as suggestions.

On hold: the trap in the middle

Excluding held orders makes them invisible, so the capacity they will need looks free and every other job schedules into it. When the hold lifts, the work arrives with nowhere to go.

Including them without any marking is not much better, because held work occupies machines that could be doing something real.

Two workable approaches:

• Include them with a visible status and let the planner decide, which is the honest option in most shops.
• Exclude them and keep a short list of what is held and roughly how many hours it represents, reviewed weekly.

What does not work is excluding them silently and rediscovering them later.

Status filter beats a date window

A rolling date window on the due date is a tempting way to keep the file small. It causes a specific, confusing failure.

An import never deletes records absent from a file. So a job whose due date slips past the window boundary simply stops appearing, keeps whatever it had, and stays in the plan. Later it drifts back into the window and updates. Meanwhile, a job that genuinely closed also stops appearing, and you cannot tell the two apart.

Filtering on status fixes both. A job leaves the file because its status changed, which is a reason you can reconcile, and the check becomes meaningful: anything in the plan that was not in this week's export is a candidate for closing. The reconciliation habit is in reconciling ERP work order quantities after partial completion.

Rows to drop even when the status is right

Three more filters are worth building into the export:

Zero quantity rows. A zero is a value, not a blank, so an order exported with zero open quantity sets that job's quantity to zero and it schedules as setup only. Filter the row out rather than exporting a zero you do not mean.

Orders for products with no routing. These import cleanly and schedule as nothing, because there are no operations to place. They are worth knowing about rather than hiding, and the fix is covered in scheduling when your ERP has no routing data.

Double-counted subassemblies. If a parent routing already contains the subassembly operations and you also import child work orders for that subassembly, the same work is planned twice. Pick one model per product family. The alternatives are set out in importing subassembly routings from your ERP.

Keep the order reference

One column pays for itself. When the export carries an order reference, rows sharing that reference group under one sales order and their jobs auto-number as {Ref}-{line}, so a multi-line order stays together on the board instead of arriving as unrelated jobs. Confirming that grouping actually happened is on the import reconciliation checklist, and the naming conventions are in keeping job numbers aligned between ERP and EDGEBIC.

Write the filter down beside the mask

Name the saved export and the mask after the rule they implement, such as Open Work Orders (released, in process, firm planned). Then anyone looking at an unexpected job list can check the filter before they start hunting through data.

Review the filter whenever the ERP is upgraded or the status codes change, and once a quarter regardless, as part of a monthly ERP to EDGEBIC data audit.

What a clean demand list buys

With only authorized work in the plan, the capacity picture is real, and the engine can do the rest: finite capacity across shifts and machine instances, work center groups that re-shop the machine pool on every reschedule, sequence-dependent setups, lot streaming with transfer batches, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine, the import layer every ERP shares sits under the ERP integration architecture, and the recurring rhythm is in the weekly ERP sync routine.

Bring your current export

Bring this week's work order export and the query behind it to a demo. Reading the filter out loud takes five minutes and often explains a discrepancy the planning team has been living with for months.