EDGEBIC + JobBOSS Integration FAQ: 12 Questions Shops Ask First

These are the questions JobBOSS shops ask in the first conversation, answered without hedging: there is no native connector, the interface is your existing exports, the first schedule usually lands in the first working session, and nothing you import can disturb a job already running. Each answer stands on its own, so skip to the 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 JobBOSS integration guide; the field-level detail is in the JobBOSS mapping reference.

Is there a native JobBOSS connector?

No, and that is a design decision rather than a gap. EDGEBIC integrates with JobBOSS 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 it; every run after that is two clicks. The same architecture serves JobBOSS, Epicor, Fourth Shift, and home-grown systems identically, which means there is no per-ERP connector to certify, version-match, or repair when either side upgrades. A connector is a dependency; a file is not.

Does EDGEBIC replace JobBOSS?

No. EDGEBIC adds a scheduling layer beside JobBOSS and changes nothing about how JobBOSS is used. Order entry, quoting, purchasing, job costing, and accounting all stay where they are. EDGEBIC reads exports, builds a schedule against real shift hours and real machine counts, and hands back dates and dispatch lists as Excel files. The ERP remains the system of record for everything financial and commercial. The general case for this split is covered in why ERP needs a scheduling add-on.

What exactly has to come out of JobBOSS?

Four exports carry a complete scheduling model, and a fifth is optional. Parts (a part number is the only mandatory column). Work centers (a work center id, plus capacity detail). Routings (end product, step name, an operation flag, and hours per unit). Open jobs (part, quantity, and a date). Optionally, labor or actuals (job number, work center, date, and hours or pieces). Any JobBOSS report or grid that saves to Excel or CSV is a valid source. You are not writing queries against the ERP and not touching its schema.

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 blanket guarantee, but the method is what repeats: export, map, import, schedule, tune.

Do we have to clean our data before starting?

No, and trying to usually wastes a month. Import what JobBOSS holds today, schedule it, and compare the dates against 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 part's steps, each corrected file replaces the last cleanly.

What happens when JobBOSS is upgraded?

Nothing, in almost every case. The integration reads files rather than calling an API, so there is no connector version to track and nothing to re-certify. If an upgrade renames a column 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. This is the practical advantage of a file interface that is easy to underrate until the first upgrade weekend arrives.

Can an import break jobs that are already running?

No, for two independent reasons. First, every scheduled job carries a frozen snapshot of the routing it was planned with, so re-importing a changed routing affects future jobs and leaves work in progress alone. Second, recorded work is never moved by any run: an operation with an actual start and an actual end is historical fact, and no reschedule, setting, or mode will shift it. On top of both, imports never schedule anything, so nothing on the Gantt moves until you press the button yourself.

Do imported jobs schedule themselves?

No, and the separation is deliberate. An import changes data; the scheduler changes the plan. Newly imported jobs appear as unscheduled demand, and they stay there until you run the scheduler. Before the run starts, a confirmation dialog states the scope in plain numbers: how many jobs are being scheduled for the first time and how many existing jobs are being rescheduled. That means an import can never silently rearrange your floor, and you always know the blast radius before anything happens.

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

No. Set a conversion factor of 0.016667 on the setup column in the routing mask and the multiplication happens during import: 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 400-routing file converts in one run.

What if someone imports the same file twice?

Nothing bad happens, on every entity type. Master data comes back Reused (matched and deliberately left untouched) unless you explicitly enabled updates for that run. Routing imports wipe and recreate a part's steps rather than appending, so steps never accumulate. Actuals always overwrite the days the file carries, so a double import never double-counts and a corrected file simply fixes the earlier numbers. The import system is built on the assumption that files get re-run, because in real shops they do.

How do dates get back into JobBOSS?

Through Excel, and through the date-maintenance path your team already uses. The Job View grid exports the job 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 turns a dispatch list into a saved report rather than a document somebody rebuilds. There is no automated write-back into the ERP, which keeps your ERP data under your team's control.

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 that re-shop on every reschedule, with per-member efficiency factors). The sequence-dependent setup matrix that lets the optimizer sequence work to cut changeover time. Operator skills and certifications. Bottleneck anchoring. Lot streaming with transfer batches. Those are configured once inside EDGEBIC and then apply 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, without IT. IT is worth involving exactly once, to make the JobBOSS exports saved reports that land in a known folder with stable names. After that the routine is export, run the saved masks, run the scheduler, publish the dispatch lists. The daily JobBOSS and EDGEBIC scheduling workflow walks the whole loop, and a JobBOSS shop's first week with EDGEBIC shows how a shop gets from nothing to that routine.

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 JobBOSS and bring them to a demo: mapping them live takes minutes, and you leave having watched your own shop scheduled against its own capacity.