ERP Integration (EDGEBIC)

A Monthly ERP to EDGEBIC Data Audit

User Solutions TeamUser Solutions Team
|
8 min read

A monthly ERP to EDGEBIC audit catches what a per-import check cannot: values that reverted through a mapped column, jobs that closed in the ERP and stayed on the schedule, phantom work centers created by a routing file, and standard times the shop floor has quietly outgrown. Each of those is invisible in any single import and obvious across a quarter. Budget 45 minutes, run it on the same day each month, and the integration stays trustworthy instead of slowly decaying.

EDGEBIC by User Solutions has run ERP data through import masks since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the pattern is consistent: integrations rarely break. They erode. The audit is what turns erosion into a short list of fixes.

What this is not

Two other checks already exist and this does not replace either.

The import reconciliation checklist runs after every import and answers "did this file land correctly". The pre-migration data quality audit runs once before go-live and answers "is this data fit to start with". The monthly audit answers a third question: has anything drifted since last month.

Check 1: phantom work centers and products

The routing import auto-creates any work center or product a file names that does not already exist. That behavior lets a routing file stand up a skeleton model on day one, and it is also the most common source of records nobody asked for.

Open the work center list and sort by shift assignment. Centers with no shifts and no instance count are the auto-created ones, and each is usually a spelling variant of a real machine.

Fix the spelling at the source, re-import the routing, then delete the orphan. This matters more than it looks: a center with no shifts and no instance count still schedules against defaults, so it produces optimistic dates on every job routed through it.

Target state: zero orphans.

Check 2: jobs that closed in the ERP and stayed here

An import adds and updates. It never deletes records that are absent from the file, which is a deliberate safety property, because a filter mistake in an export should never wipe your schedule.

The consequence is that a work order closed in the ERP simply stops appearing, and its job stays in EDGEBIC consuming capacity. Compare the job list against this month's open work order export and close whatever is missing.

Phantom jobs are worse than untidy. They hold hours on machines that are genuinely free, so capacity reads pessimistic, the bottleneck report names the wrong machine, and new promise dates drift outward for no real reason.

Target state: the stale list is under five and shrinking.

Check 3: EDGEBIC-owned values that reverted

This is the check that pays for the audit.

Pick three work centers you know the shop runs as multi-machine cells and read their instance counts. If a four-machine cell says one, a mapped column is resetting it on every import, because most ERPs model a work center as one resource with a capacity figure.

Do the same for efficiency, default setup, and bottleneck flags. The fix is not to re-enter the values: it is to remove the column from the mask, because an import writes only the fields you mapped. The full ownership map is in choosing the system of record for each scheduling field.

Target state: every value a planner set is still the value a planner set.

Check 4: do the standards still describe the shop

Take five jobs that finished last month and compare planned hours against logged hours per operation.

Pattern in the varianceWhat it usually means
One work center consistently over by 20 to 40 percentThe standard is stale, or efficiency is not modeled
Small jobs over, large jobs underSetup is folded into run time somewhere
A gap near a factor of 60 or 100A unit conversion is missing on a column
Scattered noise with no patternNormal variation, leave it alone

Patterns are actionable, noise is not. Where standards are ERP-owned, correct them in the ERP and let the routing import carry the fix into every future schedule. The unit cases are in mapping your ERP's units of measure and the setup split is in handling combined setup and run time.

Target state: no work center consistently off by more than about 15 percent.

Check 5: has the export changed shape

Cloud and on-premise ERPs both get upgraded, and a renamed or inserted column is the one thing that genuinely breaks a file-based integration. The fix is small, re-mapping one row in a mask, but only if you notice.

Open this month's export beside last month's and compare the heading row. Then confirm each saved mask still runs without a mandatory field warning, since an unmapped mandatory field aborts the run before a single row is read.

Target state: heading rows identical, or the difference is known and mapped.

Check 6: the calendar has runway

Every scheduled date is computed against your shifts and plant holidays, and both are EDGEBIC-owned because no ERP models a plant calendar at the grain a scheduler needs.

Confirm the holiday list covers at least the next two quarters and that any shift pattern change agreed with operations has actually been entered. A missing holiday two months out is harmless today and produces a whole week of wrong dates the moment your horizon reaches it.

Target state: at least six months of calendar ahead of the longest job on the board.

Check 7: identifier hygiene, read from the counts

You do not need a separate test for this. Look back at the result dialogs from the last month of routine imports.

On a repeat import of stable master data, most rows should come back Reused. A weekly product refresh reporting 34 Created and 240 Reused is healthy. The same refresh reporting 274 Created means the matching key stopped matching, which is identifier drift: a leading apostrophe from a spreadsheet, a trailing space, a changed prefix, or a column that shifted one position. The discipline is covered in keeping product masters in sync.

Target state: Created stays low on repeat runs of unchanged data.

Check 8: does the model still match the floor

The last check is a conversation rather than a query. Ask whoever runs the floor whether anything changed that the model does not know about: a machine added or retired, a work center group that no longer has the same members, an operator who left the skill roster, a cell that moved to two shifts.

None of this arrives in an ERP export, because none of it exists there. It reaches the schedule only when somebody tells it.

Target state: no surprises, and any that surface get entered the same day.

The audit on one page

#CheckWhere to lookTime
1Phantom work centers and productsWork center list, sorted by shift assignment5 min
2Jobs closed in the ERP but still hereJob list against this month's export10 min
3Reverted instance counts, setups, flagsThree known multi-machine cells5 min
4Planned versus logged hoursFive finished jobs10 min
5Export shape and mask healthHeading rows, mandatory field warnings5 min
6Calendar runwayShift and holiday lists5 min
7Created versus Reused trendLast month's result dialogs2 min
8Model against realityA short conversation5 min

What a clean audit protects

With the data holding steady, the engine can be trusted to 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, and the ERP integration architecture shows the import layer every ERP shares. The faster loops around this one are the weekly sync routine and the nightly export routine.

Run your first one with help

Bring a month of exports and your current job list to a demo and run the audit live. The first pass nearly always finds a stale job list and at least one reverted value, and both are fixed in the same session.

They catch different failures. The per-import check confirms this file landed correctly: counts add up, no orphans, one job's hours reconcile. The monthly audit catches slow drift that no single import reveals, such as instance counts that reverted through a mapped column, closed jobs still consuming capacity, standard times that reality has moved past, and a calendar that has run out of holidays. Drift is invisible per run and obvious per quarter.

About 45 minutes once the routine is established, and longer only in the first month or two while you clear a backlog. Each check is a list you scan rather than a calculation you perform. The first pass usually surfaces a handful of phantom work centers and a pile of jobs that shipped weeks ago, and clearing those is most of the initial time. After that the lists are short and the audit is mostly confirmation.

Comparing planned hours to logged hours on a sample of finished jobs, because it tells you whether your imported standard times still describe the shop. A work center that consistently runs 30 percent over its standard is quietly pushing every promise date on every job that touches it. Fix the standards in the ERP where they are ERP-owned, and the correction flows into every future schedule through the routing import.

Expert Q&A: Deep Dive

Q: Our first monthly audit turned up 31 jobs on the schedule that were closed in the ERP weeks ago. How much was that actually costing us?

A: More than most planners expect, because phantom jobs occupy machines that are genuinely free. Every one of those 31 jobs was still holding hours on a work center, so capacity looked tighter than it was and every new job scheduled behind work that does not exist. The visible symptom is promise dates that drift outward with no explanation and a bottleneck report that names a machine the floor says is not busy. Clearing them once is the big win; keeping them clear costs a couple of minutes a week. Add a step to the weekly routine that lists jobs absent from this week's open work order export and closes them, because an import adds and updates but never deletes what fell out of the file.

Q: We keep finding work centers in EDGEBIC that nobody created. Where do they come from and how do we stop it?

A: The routing import auto-creates any work center or product a file names that does not already exist, which is genuinely useful on day one and a nuisance afterwards. Each phantom is normally a spelling variant of a real machine: DEBURR-1 against Deburr 1, or MILL2 against Mill-2. They are easy to spot because they have no shift assignment and no instance count, so sorting the work center list by shift assignment groups them together. Fix the spelling at the source in the ERP export or normalize it in the mask, re-import the routing, then delete the orphan. Doing it monthly keeps the list at zero or one, and it matters because an empty center still schedules against defaults and produces flattering dates.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together