EDGEBIC + Epicor: The Complete Scheduling Integration Guide

Integrating Epicor with EDGEBIC means moving the items, work centers, routings, and open orders Epicor already holds into EDGEBIC through reusable import masks (Excel, CSV, or a database source), scheduling that work against true finite capacity, and exporting realistic dates back for Epicor and your customers. No certified connector, no middleware layer, no consulting project that outlives its sponsors: the exports your ERP already produces are the whole interface.

EDGEBIC by User Solutions comes from a lineage that has integrated scheduling with ERPs since 1991, across 35+ years and names like the US Navy, GE, BAE Systems, and Cummins. This guide covers the Epicor case end to end: what to export, how the masks and the two-pass routing import work, which EDGEBIC engine features map to Epicor concepts like resource groups, and what the return trip looks like.

Why Epicor shops add a scheduling layer

Epicor Kinetic is a deep manufacturing ERP, and its scheduling tooling is more capable than most ERP modules. Even so, many plants find the generated plans drift from what the floor can execute, especially where multi-shift and multi-instance work centers, shared machine pools, and sequence-dependent setups pile up. Planners end up supplementing the module with spreadsheets and judgment calls, which is the tell that a gap exists. The gap analysis has its own posts: the generic version in Epicor Kinetic scheduling gaps and how to fix them, and the EDGEBIC-specific version in Epicor Kinetic scheduling gaps and how EDGEBIC fills them.

The pattern that works is complementary, not competitive: Epicor stays the system of record for orders, inventory, purchasing, and financials, and a dedicated finite capacity layer beside the ERP owns sequencing. What makes the pattern practical is the integration cost, which is where the import masks earn their keep.

The integration architecture in one table

The EDGEBIC ERP integration approach is identical for every ERP; only the export files differ:

An import mask is a saved column mapping. You point it at your Epicor export once, drag each source column heading onto the matching EDGEBIC field, set any options, and save. From then on the weekly run is two clicks. Each row of every run resolves to exactly one outcome (Created, Updated, Reused, or Failed), the result dialog shows the counts, and a per-run log file records every row and every failure reason. Nothing imports halfway in silence.

Three mask behaviors matter most in ERP work:

1. Unit conversion in the mask. If an Epicor export carries setup in minutes, a conversion factor of 0.016667 on that column converts to hours during import: a 30 lands as 0.5. The factor is stored on the mask, so the conversion never depends on anyone remembering it.
2. Blank cells never wipe values on update. Re-importing with updates enabled changes only the columns your file carries; a blank cell preserves the existing value. A price-only refresh file is safe by construction.
3. Safe defaults. Matching records come back Reused (untouched) unless you explicitly enable updates, and a bad row fails individually without aborting the other 199 rows unless you choose strict mode.

The two-pass routing import

Routings are the hard part of any scheduling integration because operations reference each other. EDGEBIC's routing import solves the ordering problem in two passes. Pass one validates each row, auto-creates any work centers or products the file names that do not exist yet, and buffers the steps. Pass two sorts each product's steps by sequence number, saves them, then wires the links: step 10 to 20, 20 to 30, and the terminal step to the finished product, so the routing arrives as one connected flow in the graphical routing designer.

Conventions worth adopting on day one:

• Sequence numbers in gaps of 10 (10, 20, 30) so later inserts need no renumbering.
• All of one product's steps in one file. Re-importing a routing wipes and recreates that product's steps within the run, which keeps re-imports idempotent; splitting one routing across two runs loses the first run's steps.
• Running jobs are immune. Every scheduled job carries a frozen snapshot of the routing it was planned with, so a routing re-import affects future jobs only. Work in progress does not move, and completed operations are never rescheduled at all.

Mapping Epicor concepts to the EDGEBIC engine

Once the data is in, the part Epicor shops care about is whether the engine models their reality. The mappings that come up in every evaluation:

Resource groups → work center groups. Epicor planners think in pools of interchangeable machines. EDGEBIC's work center groups model the same idea with one addition that changes outcomes: a group-bound operation re-shops the entire pool on every reschedule, choosing the member by strategy (earliest completion, primary first, earliest start) and applying per-member efficiency factors, so a machine that runs a job 40 percent slower is chosen only when it still finishes first. Operations already started keep their machine; actuals are never disturbed.

Multi-shift, multi-instance capacity. Work centers carry instance counts, shift calendars, efficiency, and utilization caps. A three-machine cell on two shifts is 6 machine-shifts of real capacity, not one number in a field. That is the core of finite versus infinite capacity scheduling, and it is the difference between dates you publish and dates you apologize for.

Sequence-dependent setups. A setup matrix per work center (organized into setup families so it stays maintainable) lets the optimizer sequence jobs to cut changeover time: mathematical optimization with a proven optimality gap, plus a multi-run layer guaranteed never worse than the baseline schedule.

Constraints. Flag a work center as a bottleneck and the engine anchors the schedule around it, backward into the constraint and forward out of it with protective buffers.

The full engine map lives on the EDGEBIC product overview and in the complete EDGEBIC guide.

Orders in, dates back out

The jobs import carries product, quantity, reference, and dates. Rows that share an order reference group under one sales order with jobs auto-numbered {Ref}-{line}. And one deliberate rule governs everything: imports never schedule. Imported jobs land as unscheduled demand; you then run the scheduler, which reports how many new and existing jobs are in scope before planning, so fresh work slots around existing commitments. Data movement and planning stay separate so that an import can never silently rearrange your floor.

The return trip is Excel. Job View exports the schedule grid (colored cells plus a legend sheet) as a workbook; every report dialog exports to Excel or PDF with your saved column layout. Updated dates flow back into Epicor through whatever date-maintenance path your team already uses, and dispatch lists go to the supervisors. Epicor's workflows stay untouched.

If you also want shop-floor reality flowing in, the actuals import takes hours and piece counts per job, work center, and day (from Epicor labor data or a supervisor spreadsheet) and is safe to re-run: the dates a file carries are always overwritten, so a corrected file fixes numbers without double-counting. The next reschedule plans remaining work from where the shop actually is, and completed work never moves.

Common pitfalls, each with a one-line fix

Integrations fail on small mechanical details more often than on architecture. The recurring ones, from decades of doing this:

The pattern behind the fixes: the import system is built to be re-run. A corrected file imported again converges on the right data, because master records come back Reused or Updated (never duplicated), routing re-imports wipe and recreate rather than accumulate, and actuals overwrite the dates they carry rather than double-count.

The first week, day by day

The methodology is inherited from a documented case in the User Solutions lineage: the Fourth Shift ERP vendor recommended the User Solutions scheduler to its own customers, and the Plastilite integration ran Monday to Friday, from first export to a complete optimized schedule. Applied to Epicor:

Starting from an empty EDGEBIC database? The green-field setup walkthrough sequences the whole build.

Test it with your own export

Feature tables do not answer "will my dates be right?" Your own data does. Export this week's open jobs and your routing file from Epicor, and bring both to a demo. Mapping them live takes minutes, and you leave having watched your own shop scheduled against its own capacity.