Keeping Job Numbers Aligned Between Your ERP and EDGEBIC

Carry your ERP's work order number through to EDGEBIC unchanged: it is the natural key that imports match on, so a stable identifier means repeat imports update the right job instead of creating duplicates, and one number identifies the work in planning, on the floor, and back in the ERP. Identifier drift is the quietest and most expensive integration problem, because nothing errors. You just accumulate two of everything.

EDGEBIC by User Solutions has run file-based ERP integrations since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the shops with the smoothest daily rhythm are always the ones where a single number means the same job everywhere.

Why the identifier does more work than it looks

An import mask matches rows against existing records on an identifier, case-insensitively. WO-4471 finds wo-4471. That single behavior is what makes re-importing safe: run the same file twice and the second run reports Updated or Reused rather than doubling your data.

Everything downstream depends on it:

• Repeat imports are idempotent. A nightly or weekly refresh corrects and completes existing jobs instead of stacking new ones.
• Actuals attach to the right job. Hours logged from the floor or imported from the ERP need a job to land on.
• Dates go back cleanly. When you export the schedule to Excel and update your ERP, the number in the workbook is the number in the ERP.
• People communicate. Customer service, planning, and the floor say one number.

The product master sync post covers the same principle for item identifiers, where the stakes are identical.

The four outcomes tell you if alignment is holding

Every row produces exactly one outcome: Created, Updated, Reused, or Failed. On a repeat import of open orders, the healthy shape is mostly Updated and Reused with a handful of Created for genuinely new orders.

A repeat import that reports almost everything Created is telling you the key did not match. The usual causes:

The import reconciliation checklist makes this a ten-second check after every run.

Rule 1: the identifier must be stable for the life of the order

This is the rule that breaks most often, and always for the same reason: something that changes has been baked into the number.

Revision suffixes, status codes, release flags, and re-planned markers all belong in a separate column, not in the identifier. If WO-4471 can become WO-4471-R2 next week, the matcher sees a different job and creates one.

Export the stable root as the identifier and carry the changeable part as a description or a separate field where planners can still see it.

Rule 2: do not invent a second numbering scheme

It is tempting to give scheduling jobs their own sequence, especially when the ERP numbers look unwieldy. Resist it. A second scheme means a permanent lookup between two systems, maintained by hand, consulted by everyone, and wrong within a month.

If the ERP number is genuinely unusable on a dispatch list, keep the ERP number as the identifier and put a friendlier label in the description. Displays can differ. Keys cannot.

Rule 3: use the order reference for multi-line orders

When your work order export carries an order reference, rows sharing that reference group under one sales order and their jobs auto-number as the reference followed by a line number. A three-line customer order becomes three related jobs rather than three unrelated ones.

This is worth setting up deliberately, because it changes what a planner can see at a glance. A customer calling about their order gets an answer covering every line, not the one line somebody happened to look at. The grouping also keeps a multi-line order visible as a unit on the job schedule views you export back.

Rule 4: decide early what an ERP job means to you

Some ERPs issue one work order per end item. Others issue one per operation, or split a quantity across several releases. Before your first import, decide how those map:

• One work order equals one job. The default and the simplest. Works when the ERP issues per end item.
• Several ERP releases equal several jobs. Correct when the shop genuinely runs them as separate lots with separate setups.
• Operation-level work orders roll up into one job. Correct when the ERP splits by operation but the shop runs the part as one flow. The routing versus operations mapping guide covers how operations reassemble into a routing, and splitting one ERP operation into EDGEBIC steps covers the reverse case.

Whichever you pick, apply it consistently. A mixed convention is worse than either pure one.

Rule 5: normalize in the mask, not in the file

Every fix described here belongs in the saved import mask rather than in a hand-edited copy of the export. A mask that strips a prefix or handles quoting applies on every future run automatically, while a hand-edited file is a step someone will skip on a Friday.

The mask's text-enclosed-in-quotes setting handles RFC-4180 style quoting so values with embedded commas parse correctly rather than splitting into phantom columns, which is a common source of apparently-corrupt identifiers. The full option list is in import masks explained.

When numbers do have to change

Renumbering happens: an ERP upgrade, a merged division, a new numbering standard. Treat it as a cutover rather than an ordinary import.

1. Let jobs already started finish under their old identifiers. Their actuals stay attached and completed work is never moved by a reschedule.
2. Import the new numbering for open, not-yet-started work only.
3. Reconcile immediately. A renumber is the one event where a large Created count is correct, and you want to confirm it matches the count of genuinely open orders rather than exceeding it.

The wider sequencing for a change of this size is in the ERP and EDGEBIC go-live cutover plan.

The payoff is a shorter day

Aligned identifiers are what make the recurring routine take twenty minutes instead of an afternoon: export, pick the mask, run, read the counts, schedule, export the dates back. Nobody reconciles anything by hand because there is nothing to reconcile.

From there the engine does the work: finite capacity across shifts and machine instances, work center groups, sequence-dependent setups, lot streaming, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine, the ERP integration architecture shows the import layer, and the weekly sync routine has the cadence.

Check your own numbering

Bring one work order export to a demo. Looking at the identifier column together takes two minutes and usually settles the convention question for good.