Epicor to EDGEBIC: The Data Mapping Reference

Mapping Epicor data into EDGEBIC means exporting the parts, resources, methods of manufacture, and open jobs Epicor already holds to Excel or CSV, then mapping each column once into a saved import mask that runs in two clicks from then on. This reference covers what maps to which field, which columns are mandatory, how Epicor concepts like resource groups land on the EDGEBIC side, and what happens on the second and hundredth run.

EDGEBIC by User Solutions connects to Epicor through those import masks rather than a certified connector, which is a design decision rather than a limitation: nothing has to be re-certified when either system upgrades. The end-to-end version of this story is the complete Epicor integration guide. This post is the field reference you keep open while building masks.

The load order

Two entity types have no Epicor origin and are built from a spreadsheet you write: Shift (one row per shift, with a start and end pair per weekday, and a blank pair meaning the day is off) and PlantHoliday (closures by name and date). These two carry the calendar the whole schedule is planned against, so they are worth ten careful minutes.

Auto-create is on by default, so a routing file naming a resource that has not been imported yet creates it on the fly. Useful as a safety net, poor as a strategy: an auto-created work center has a name and nothing else, which means one machine, no shift assignment, and no efficiency. Load resources properly first.

Parts to Product

Only the part number is required. Everything else can arrive later through a second, narrower refresh file, because blank cells preserve existing values on an update.

Resources to Workcenter

Epicor exports resources with a good deal of capacity detail, and this is the file where that detail earns its keep.

The single highest-value column here is Number_Of_Instances. A cell of four identical machines scheduled as one work center with one instance produces a plan four times too long, and it is a quiet failure: nothing errors, the dates are simply wrong. Fill it deliberately for every multi-machine center.

Resource groups to work center groups

Epicor planners think in pools of interchangeable machines. EDGEBIC models the same idea as a work center group, and there is one deliberate difference: the pool is not a static assignment. A routing step bound to a group re-evaluates every member on each reschedule, picks by strategy (earliest completion, primary first, or earliest start), and applies a per-member efficiency factor so a slower machine is chosen only when it still finishes first. Operations already started keep their machine, because recorded work is never moved.

None of that fits in an export column. So: import the members as ordinary work centers, then create the group inside EDGEBIC and add them. It is a one-time configuration per pool, and it is one of the settings that most changes what the schedule looks like.

Methods of manufacture to BOR

The two passes, and why they exist

A routing import cannot be written row by row, because step 10 must point at step 20 and step 20 does not exist yet. So the import runs in two passes. Pass one validates each row, resolves or creates the parts and work centers it names, and buffers the row. Pass two groups the buffer by end product, sorts by sequence number, writes the steps, and then wires the chain: 10 to 20, 20 to 30, and the terminal step to the finished part so the whole routing renders connected in the graphical designer. The visual result is worth checking after the first import: a routing missing its final link draws as a chain floating free of the part it builds.

Subcontract operations, where they exist in your method, map cleanly enough as an operation row on a work center that represents the vendor, with the turnaround expressed as transit days. That keeps the outside time visible on the Gantt instead of hidden inside a single long step.

Jobs to SalesOrder

Two options control the date logic when your export carries only one date: one treats the job date as the due date, the other derives the job date backwards from the due date. Pick the one that matches how your export is built, once, on the mask.

Actuals

Job number, work center id, and actual date are mandatory; hours and pieces are optional and either one can be derived from the other using the operation's rate. A Complete column marks the operation finished. The import always overwrites the days the file carries, so re-running a corrected extract fixes numbers rather than doubling them. Days the file does not mention are preserved unless you explicitly ask for them to be cleared.

Actuals import last because each row has to find an operation on a job that is already scheduled.

Conversions, blanks, and zeros

What the outcomes tell you

Every row resolves to Created, Updated, Reused, or Failed. Reused is the default for a record that already exists, which means a weekly parts file of 4,000 rows reports something like Created 12, Reused 3,988 and touches nothing else. That is the desired result, not a failure. When counts look wrong, the per-run log file has one line per row with the exact reason for every failure.

What import cannot bring, and why it matters

The settings that most differentiate the schedule have no column in any ERP export: the sequence-dependent setup matrix, operator skills and certifications, work center group strategies, bottleneck anchoring, and lot streaming transfer batches. Those are configured once in EDGEBIC and then apply to every imported job forever. The EDGEBIC product overview maps the engine, and the ERP integration architecture explains why the same mask design serves every ERP.

For the week-to-week rhythm once the masks exist, see the daily Epicor and EDGEBIC scheduling workflow. For the questions that come up before a project starts, the Epicor integration FAQ collects them, and the JobBOSS mapping reference shows how little the method changes from one ERP to the next.