EDGEBIC ERP Integration: The Complete Guide

EDGEBIC ERP integration means one thing, consistently: your ERP produces a file or a read-only query, EDGEBIC reads it through a saved import mask, and the finite capacity schedule that comes out goes back to your team as a plan the floor can follow. There is no native connector, no certified plugin, and nothing installed inside your ERP. EDGEBIC by User Solutions connects to every ERP the same way, which is precisely why the method survives an ERP version upgrade, a second plant, or a switch to a different ERP entirely.

This guide is the map of that subject. It covers what the import masks actually cover, the three ways data can reach EDGEBIC, how to map your ERP's fields, what you can never import and must therefore plan for, and the weekly rhythm that keeps a schedule current without turning into a project.

The Architecture, Stated Plainly

User Solutions has been building scheduling tools for manufacturers since 1991, across the RMDB lineage and now EDGEBIC. The integration approach has not changed because it has not needed to: EDGEBIC connects to every ERP the same way, through files and queries rather than through a connector that has to be written, certified, and maintained per system.

Three consequences fall out of that, and they are worth stating before you plan anything:

1. Nothing is installed in your ERP. Your ERP team is asked for a report or a read-only view, not for a development project. Specifying the export you need from IT is usually a single conversation.
2. An ERP upgrade does not break the integration. If the export still produces the same columns, nothing changes. If the column order shifts, handling an export that changed column order is a mask edit, not a rebuild. There is a short list of things to check after an ERP version upgrade.
3. Replacing the ERP does not mean replacing the schedule. What changes in EDGEBIC when you replace your ERP is mostly the masks. The routings, work centers, and history stay put.

The Eight Import Masks

This is the single most important fact in this guide, and the one most integration plans get wrong. The import masks cover exactly eight entity types: Product, Workcenter, Customer, SalesOrder, BOR, Actuals, PlantHoliday, and Shift.

An import mask is a saved recipe. It remembers the entity type, the file format, whether the first row is headings, and how each column in your file maps to a field in EDGEBIC. You build it once, and every run after that is two clicks. Every row lands as Created, Updated, Reused, or Failed, and the per-run import log records each outcome.

Start by working out which ERP fields EDGEBIC needs to build a finite capacity schedule, then decide how many import masks your shop actually needs. Most shops need four, not eight.

Everything outside those eight is hand-entered: departments, work center groups and their members, operators with their skills and certifications and rosters, the sequence-dependent setup matrix, quotes, and scenarios. That is a real cost and you should budget it rather than discover it, which is what what EDGEBIC cannot import, and how to handle it exists to cover.

Two behaviors deserve emphasis because they surprise people:

• A BOR re-import replaces that product's entire routing per run. All of one product's steps must be in one file. That is safe by design, and it is also how engineering changes travel through a routing re-import.
• Imports never schedule. Loading data and building a plan are separate actions. A nightly refresh cannot quietly rewrite a plan the floor is working to.

Three Ways Data Gets In

Manual file import. Export from the ERP, open Import in Settings, run the saved mask. This is where every integration starts and where many stay.

A watched file. The Integration tab turns an existing mask into a repeating sync. Your ERP drops a file on a share, EDGEBIC notices, waits for the file to stop changing, and runs the mask. See scheduling a nightly ERP export and import routine, and then reading the import log after a nightly run, which is the discipline that keeps automation honest.

A read-only external SQL query. The same Integration tab can read a result set directly from an external SQL Server on an interval. Connecting EDGEBIC to your ERP database with a SQL source walks it through. The mask is unchanged: a query's columns are treated exactly like a file's headings.

Choosing between them is a real decision with real tradeoffs, covered in CSV vs database view. A related decision is how often each data type should be imported, because routings and orders do not need the same cadence.

Mapping Your ERP's Fields

The mapping work is where integrations succeed or stall, and almost all of the difficulty is in routings. The recurring problems are well documented:

• Mapping routings vs operations from your ERP, which is the shape question you answer first
• Importing your ERP's operation sequence numbers
• Handling an export with combined setup and run time
• When your ERP exports setup as its own operation row
• Mapping your ERP's units of measure for scheduling, where a conversion factor turns minutes into hours during the import
• Splitting one ERP operation into multiple EDGEBIC steps
• Mapping alternate work centers from your ERP
• Importing sub-assembly routings

On the resource side, when two ERP rows map to one EDGEBIC work center is common in shops whose ERP models a cell as several cost centers, and building a work center list when your ERP has none covers the case where the ERP simply has no resource model.

On the demand side, decide early which work orders to import, how to treat customer due dates versus internal need dates, and how ERP order priority maps into your schedule. Keep job numbers aligned between the two systems from day one, because retrofitting that is painful.

Two questions that look technical but are actually governance: choosing the system of record for each scheduling field, and whether to trust your ERP's standard times. Neither has a universal answer, and getting them wrong produces a schedule nobody believes.

Calendars are the one place plans routinely go wrong in the other direction. PlantHoliday and Shift are two of the eight masks, so importing your ERP's manufacturing calendar is available, and hand-entry is a legitimate choice when you have only a few shift patterns rather than a requirement.

Your ERP, Specifically

Per-ERP coverage follows one shape: the integration guide, a data mapping reference naming the fields, and a scheduling-gap analysis explaining what that ERP's own planning does and does not do.

Also covered: Fourth Shift, Syteline, SYSPRO, Made2Manage, MIE Trak Pro, Odoo, Fishbowl, QuickBooks, Acumatica, Katana, MRPeasy, ERPNext, ECI M1, Genius ERP, Rootstock, Realtrac, Statii, Fulcrum, Cetec ERP, Prodsmart, and xTuple.

The heritage case that shaped the whole approach is the 5-day Fourth Shift integration story, and the day-to-day shape is easiest to see in a worked example such as a JobBOSS shop's first week or the daily Epicor and EDGEBIC workflow.

Going Live, Then Staying Live

Getting started is bounded work. Follow the first-week ERP integration checklist, then the go-live cutover plan. Before the first live run, test any mask change before the live run, and afterwards work the import reconciliation checklist so counts are verified rather than assumed.

Steady state is a rhythm, not a project. The weekly import routine is the baseline, keeping product masters in sync is the recurring maintenance, and a monthly ERP to EDGEBIC data audit catches the drift a weekly run does not. Assign it: who owns the import routine on your team is a governance question with a real answer, and keeping a change log of mask edits is what makes an integration survive a personnel change.

Actuals flow the other way. Importing ERP labor transactions as scheduling actuals is the alternative to kiosk entry, with a known edge case in when your ERP labor file starts mid-routing. Then reconciling work order quantities after partial completion and closing ERP work orders that EDGEBIC still thinks are open close the loop.

Sending the plan back out is a grid export, not a round-trip module: exporting the EDGEBIC schedule back to your ERP explains what that means in practice. A grid export snapshot is for sharing and analysis and is deliberately not an import file.

The Harder Cases

Some shops do not fit the standard shape. Scheduling when your ERP has no routing data is more common than vendors admit. Handling multi-plant exports and onboarding a second plant into the same database cover growth. Scheduling a shop that runs two ERPs covers the aftermath of an acquisition. Running EDGEBIC alongside your ERP's scheduling module covers the political reality of not switching everything at once.

When something goes wrong, most of it is mundane: what to do when the ERP export is late or missing, and handling part number revisions on import. Two decisions sit outside the software entirely: who should see your ERP export files, and what an ERP integration costs in hours per week, which is the number to quote when someone asks.

Finally, the honest limit: what your ERP export cannot tell you about the floor. A file carries the data the ERP holds, and the ERP does not hold the reason a machine sat idle on Tuesday. That gap is closed by logging actuals, which the shop floor guide covers, not by a better mask.

Where This Fits

Integration is plumbing in service of a plan. Once data is in, the scheduling engine guide explains how the finite capacity plan is built, the optimizer guide covers improving it, and the complete EDGEBIC guide maps the whole platform. If your ERP export cannot make the forward-versus-backward decision for you, and it cannot, the direction decision your ERP export cannot make explains why that stays with the planner.

For the product-level view, see the EDGEBIC ERP integration page. If you want to see your own export file mapped, contact US with a sample. The mask is built in front of you, and you will know within an hour whether your data can carry a finite capacity schedule.