EDGEBIC + Sage Integration FAQ: 12 Questions Shops Ask First

These are the questions Sage shops ask in the first conversation, answered without hedging: there is no connector for any Sage edition, the interface is your existing exports, IT is involved once, and nothing you import can disturb a job already running. Each answer stands on its own, so skip to whichever one you came for.

EDGEBIC by User Solutions is a finite capacity scheduling platform that sits beside your ERP. The full walkthrough is the complete Sage integration guide, and the field-level detail is in the Sage to EDGEBIC mapping reference.

Is there a connector for our Sage edition?

No, and that is why every edition works. EDGEBIC integrates through reusable import masks that read Excel, CSV, delimited text, or a database source. You map your export's columns onto EDGEBIC's fields once and save the mask; every later run is two clicks. Because the mask maps onto EDGEBIC fields rather than onto a Sage schema, a shop that moves from one Sage product to another re-maps a few column headings instead of commissioning a new integration. A connector is a dependency. A file is not.

Does EDGEBIC replace Sage?

No. Sage stays the system of record for orders, inventory, purchasing, costing, and accounting. EDGEBIC reads exports, builds a finite capacity schedule against real shift hours and real machine counts, and hands dates and dispatch lists back as Excel. Nothing about how your team uses Sage changes. The general case for the split is in why ERP needs a scheduling add-on.

What exactly has to come out of Sage?

Four exports carry a complete scheduling model, and a fifth is optional. Items (an item number is the only mandatory column). Work centers (an identifier, plus capacity detail). Routings (end product, step name, an operation flag, and hours per unit). Open jobs (item, quantity, and a date). Optionally, labor (job number, work center, date, and hours or pieces). Any Sage report or grid that saves to Excel or CSV is a valid source.

Sage does not tell us how many machines a work center holds. What then?

You supply that column yourself, and it is the single most valuable thing you will do during setup. Most ERP data models describe a work center as one capacity number rather than a count of identical machines, and the difference is not cosmetic: a cell of three mills imported as one instance produces a plan roughly three times too long, with nothing erroring to warn you. With 10 to 30 work centers in a typical shop, a hand-built work center file listing identifier, true machine count, default setup, efficiency, shift assignment, and bottleneck flag takes about an hour and then stays stable for months. The arithmetic is in how EDGEBIC calculates work center capacity.

How much IT work is involved?

One task, once. Ask IT or your Sage partner to turn the four exports into saved reports with stable column names landing in a known folder. Nothing is installed inside Sage, no schema is touched, and no database credentials are needed for the file path. After that, the planner owns the routine.

How long until the first real schedule?

Most shops see a first finite capacity schedule from their own data in the first working session, and a tuned one within the week. The documented benchmark in the User Solutions lineage is the Plastilite integration on Fourth Shift: 5 days, Monday to Friday, from first export to a complete optimized schedule with dates synchronized back to the ERP. That figure belongs to that case rather than being a promise, but the sequence is what repeats: export, map, import, schedule, tune.

Do we have to clean our routings first?

No, and trying usually costs a month you do not have. Import what Sage holds today, schedule it, and compare the dates with what your planner believes. The disagreements are your defect list and they arrive specific: a wrong hours-per-unit shows up as a job finishing implausibly early, a missing setup time shows up as a machine that appears to change over for free. Because a routing re-import wipes and recreates that item's steps, each corrected file replaces the last cleanly and version drift never accumulates.

Our setup times are in minutes. Do we convert 300 routings by hand?

No. Set a conversion factor of 0.016667 on the setup column in the routing mask and a 30-minute cell lands as 0.5 hours. Seconds use 0.000278. The factor is stored on the mask, so every future routing import converts identically without anyone remembering to do it, and the per-run log records every row if you want to audit the math. A 300-routing file converts in one run.

Do imported jobs schedule themselves?

No, and the separation is deliberate. An import changes data; the scheduler changes the plan. New jobs appear as unscheduled demand until you run the scheduler, and before the run starts a confirmation states the scope in plain numbers: how many jobs are new and how many existing jobs are being rescheduled. An import can never silently rearrange your shop. The choices are covered in EDGEBIC scheduling modes explained.

Can an import disturb jobs already running?

No, for two independent reasons. Every scheduled job carries a frozen snapshot of the routing it was planned with, so a routing re-import affects future jobs and leaves work in progress alone. And recorded work is never moved by any run: an operation with an actual start and an actual end is historical fact, and no reschedule, mode, or setting will shift it.

What happens when we upgrade Sage?

Nothing, in almost every case. The integration reads files rather than calling an interface, so there is no connector version to track. If an upgrade renames a column heading in an export, you re-map that column in the mask once, which takes minutes. If the export is unchanged, the masks keep running exactly as they did, which is the practical advantage of a file interface that is easy to underrate until the first upgrade weekend.

What if the same file gets imported twice?

Nothing bad happens, on any entity type, and this is designed in rather than tolerated. Master data comes back Reused (matched and deliberately left untouched) unless you enabled updates for that run. Routing imports wipe and recreate an item's steps rather than appending, so steps never accumulate no matter how many times a file is run. Actuals always overwrite the days the file carries, so a double import never double-counts and a corrected timesheet simply fixes the earlier numbers. The system assumes files get re-run, because in real shops they do.

Do we need a second license for the shop floor?

Not to get value from the schedule. Dispatch lists and work center schedules export to Excel and PDF with the column layout you saved, so supervisors can work from a printed or shared sheet that is rebuilt in seconds each morning rather than maintained by hand. When you later want hours captured at the machine rather than typed at the end of a shift, that is a separate decision about actuals collection rather than a prerequisite for scheduling.

What can import never bring across?

The settings that most change what a schedule looks like, because no ERP export has a column for them. Work center groups (machine pools re-shopped on every reschedule, with per-member efficiency factors). The sequence-dependent setup matrix that lets the optimizer sequence work to cut changeover. Operator skills and rosters. Bottleneck anchoring. Lot streaming with transfer batches. Each is configured once inside EDGEBIC and then applies to every imported job afterwards. The EDGEBIC product overview maps them, and the ERP integration architecture explains where the import boundary sits.

Who runs this day to day?

The planner, in about twenty minutes each morning. The routine is export, run the saved masks, run the scheduler, publish the dispatch lists. For the argument that usually precedes the decision, see Sage scheduling gaps and how EDGEBIC fills them; the same questions for other platforms are answered in the SAP and NetSuite FAQs.

Still deciding?

The fastest way to settle any of this is your own export. Pull this week's open jobs and a routing file from Sage, then bring them to a demo: mapping them live takes minutes, and you leave having watched your own shop scheduled against its own capacity.