EDGEBIC + Epicor Integration FAQ: 12 Questions Plants Ask First

The questions Epicor plants ask before an EDGEBIC project, answered plainly: there is no certified connector, nothing installs inside Epicor, resource groups map onto work center groups with per-machine efficiency, and a first finite capacity schedule usually lands in the first working session. Each answer is written to stand on its own.

EDGEBIC by User Solutions is a finite capacity scheduling platform that runs beside your ERP. The end-to-end version is the complete Epicor integration guide, and the field-level detail is in the Epicor mapping reference.

Is EDGEBIC a certified Epicor connector?

No. EDGEBIC integrates through reusable import masks that read Excel, CSV, delimited text, or a database source, not through a per-ERP connector. You map an export's columns onto EDGEBIC's fields once and save it; every run after that is two clicks. The same architecture serves Epicor, JobBOSS, Fourth Shift, and internal systems identically. The benefit shows up on upgrade weekends: there is no connector version to match and nothing to re-certify when either product moves.

Do we have to stop using Epicor's scheduling?

No. Nothing inside Epicor is switched off, and its scheduling data stays exactly where it is. EDGEBIC reads exports and produces its own finite capacity plan, which most plants then adopt as the operational schedule while Epicor keeps the commercial and financial record. Running both in parallel for a few weeks is the normal evaluation path, and it is the honest one: compare the two plans against what the floor actually did. The gap analysis is covered in Epicor Kinetic scheduling gaps and how EDGEBIC fills them.

Does anything get installed inside Epicor?

No. The interface is a file. There is nothing to install, no schema extension, no integration user, and no service writing into the ERP. Your team builds saved extracts using Epicor's normal reporting, and EDGEBIC reads what they produce. This is usually what makes an IT review short: the ERP's upgrade path, backup regime, and security model are untouched, and the only thing to govern is where the export files land and who can read them.

How do Epicor resource groups map across?

Import the individual resources as work centers, then create a work center group inside EDGEBIC and add them. A group models the same idea as a resource group with one difference that changes outcomes: an operation bound to a group re-evaluates every member on each reschedule, selecting by strategy (earliest completion, primary first, or earliest start) and applying a per-member efficiency factor, so a slower machine is chosen only when it still finishes soonest. Started operations keep their machine, because recorded work is never moved.

What if our machines are not really equivalent?

That is exactly what per-member efficiency factors are for. Set a factor that stretches an operation's hours on the slower machine (a 2.0-hour job becoming 2.8 hours at a factor that reflects 40 percent slower running) and leave the others at 1.0. The scheduler compares real finish times rather than rotating work around the pool. Where a machine cannot run a part at all, leave it out of that step's pool or express the constraint as an alternate on the routing step instead.

How much data can one import handle?

More than a plant produces, in practice. Files are streamed row by row rather than loaded whole, so a wide export with thousands of rows is routine, and unmapped columns are ignored entirely so there is no penalty for exporting more than you need. The real limits are human: reviewing a run with hundreds of failed rows takes longer than fixing the source file. Daily volume is small in any case, because only open jobs and labor change every day.

Should a multi-plant Epicor instance import into one EDGEBIC database?

Start with one plant. A single-plant scope proves your masks, your capacity data, and your dates within a week instead of a quarter, and none of the work is wasted: the same masks run against the second plant's export with only the file changed. Work centers carry a department field so multi-site data can coexist once you are confident, and transit days between routing steps model movement between locations. What you want to avoid on day one is debugging a mapping problem and a cross-site routing question simultaneously.

Can we automate the export and import?

The export side, yes: a scheduled Epicor extract writing to a known folder with a stable file name is normal practice, and masks remember the last file path so a stable name keeps the import to two clicks. The import and scheduling side stays deliberately manual, because a planner should see the row counts before the data lands and the job counts before the plan changes. Automating the step where a human catches a bad export is a false economy.

Do imported jobs schedule themselves?

No. Imports change data; the scheduler changes the plan. Imported jobs appear as unscheduled demand and stay there until you run the scheduler, and before the run starts a confirmation dialog states how many jobs are being scheduled for the first time and how many existing jobs are being rescheduled. Cancelling mid-run is always safe: nothing partial is kept and the previous plan stands. An import can never quietly rearrange the floor.

Can a re-import disturb work in progress?

No, for two separate reasons. Every scheduled job carries a frozen snapshot of the routing it was planned with, so re-importing a changed method affects future jobs only. And recorded work is never moved: an operation with an actual start and end is historical fact that no run, mode, or setting will shift. Actuals imports are equally safe to re-run, because the days a file carries are always overwritten rather than added, so a corrected labor extract fixes numbers instead of doubling them.

How do schedules get back into Epicor?

As Excel, through whatever date-maintenance path your team already uses. The Job View grid exports the whole schedule as a workbook with colored cells and a legend sheet. The work center schedule exports the same way, and every report dialog exports to Excel or PDF using the column layout you saved, which makes each supervisor's dispatch list a saved report rather than a document someone assembles. There is no automated write-back into the ERP, which keeps changes to Epicor data under your team's control.

What does import never bring, and why does it matter?

The settings that most change the shape of a schedule, because no ERP export has a column for them: work center group strategies and efficiency factors, the sequence-dependent setup matrix, operator skills and certifications, bottleneck anchoring, and lot streaming with transfer batches. Those are configured once inside EDGEBIC and then apply to every job that arrives afterwards. That division is the point of the ERP integration architecture: the ERP supplies facts, EDGEBIC supplies the scheduling model. The engine itself is mapped on the EDGEBIC product overview.

What does a normal week look like afterwards?

Twenty minutes each morning: export open jobs and labor, run the saved masks, run the scheduler, publish dispatch lists and dates. The daily Epicor and EDGEBIC scheduling workflow walks the loop step by step, and an Epicor plant's first week with EDGEBIC covers how a plant gets from a first export to that routine. If you want to settle any of this with your own data, export this week's jobs and one routing file and bring them to a demo.