EDGEBIC + Rootstock: The Scheduling Integration Guide

Integrating Rootstock with EDGEBIC means exporting the items, work centers, routings, and open work orders the platform already holds to CSV or Excel, mapping those columns once with a reusable import mask, and letting EDGEBIC schedule the work against finite capacity: real shift hours, real machine counts, and sequence-dependent setups. Executable dates go back as Excel. Nothing is installed in your org, no integration user is created, and there is no certified connector to version-match when either side updates.

EDGEBIC by User Solutions is the newest generation of a scheduling line that has integrated with ERPs this way since 1991. Across 35+ years the same file-based approach has fed schedules for the US Navy, GE, BAE Systems, and Cummins. This guide covers the Rootstock case: what to export, how the masks work, and what the first week looks like.

Why a cloud-native ERP still needs a floor scheduler

Rootstock runs the business: orders, inventory, purchasing, financials, and the manufacturing records around them. What most manufacturers report is that the daily sequencing decision happens somewhere else, usually a spreadsheet, because a planner's morning questions are finite capacity questions:

• Which of these 60 open work orders fits on the two constrained cells this week?
• If this rush order jumps the queue, which promise dates move and by how much?
• Is the paint line loaded to 80 percent or 160 percent next Thursday?

Answering those means modeling shifts, machine instances, changeover sequences, and operator availability against every open order at once. That is a different computational problem from recording transactions, which is why a dedicated finite capacity layer beside the ERP is the standard pattern. The general case is in finite versus infinite capacity scheduling, and the job-shop version is in job shop scheduling challenges.

The integration in one table

The EDGEBIC ERP integration architecture is identical for every ERP, Rootstock included:

An import mask is a saved recipe. It remembers which kind of data you are importing, the format it arrives in (Excel workbook, or comma, semicolon, tab, or space delimited text), whether the first row is headings, whether text values are quoted, and how each column maps onto an EDGEBIC field. You build it once by dragging your file's column headings onto the target fields. Every run after that is two clicks.

Every row produces exactly one outcome: Created, Updated, Reused (matched and deliberately left alone), or Failed (rejected, with the reason recorded). A result dialog shows the counts and a per-run log records every row individually.

Why a file is the right interface for a cloud platform

Cloud platforms release on the vendor's schedule, not yours. That is usually fine, and occasionally it breaks an integration built against an API surface or a managed package. A file interface has a much smaller failure mode: the only thing that can break is a column heading, and the fix is re-mapping one row in a mask.

Three practical consequences for a Rootstock org:

• Nothing is deployed. No package, no custom object, no code. Your sandbox-to-production process is unaffected because there is nothing to promote.
• No integration user or credential is created. The scheduler never authenticates against the ERP, so there is no permission surface to review or rotate.
• Scheduling keeps working offline. The plan is computed locally, so a connectivity problem stops the export, not the shop's dispatch list.

If your IT team prefers a query surface to a downloaded file, the trade-offs are compared in CSV versus database view export tradeoffs.

Step 1: the four exports

1. Items. The item identifier, description, unit of measure, and any cost or lead-time columns worth having visible. The identifier is the natural key, matched case-insensitively, so BRK-200 in a file finds brk-200 in the database.
2. Work centers. Identifier, how many identical machines the center really holds, default setup hours, efficiency, and an hourly rate for cost rollups. Where the ERP does not hold instance counts, build the list yourself using the work center list guide.
3. Routings. One row per operation: end product, work center, sequence number, run time per unit, setup time, queue time.
4. Open work orders. Product, quantity, order reference, and dates.

Any report that saves to CSV is a valid source. You are not writing code and not requesting database access, which a cloud platform would not offer anyway.

Step 2: map the columns once

Build one mask per file and name it after the routine rather than the file: Weekly Work Orders outlives wo-week29.csv. Mandatory fields are flagged, and the run refuses to start until they are mapped, so a half-built mask fails before it reads a single row.

Two mask features carry most of the weight:

Unit conversion. Set a conversion factor on any numeric column and the multiplication happens before the value is stored. Minutes to hours is 0.016667, seconds to hours 0.000278, and a standard quoted per lot of 100 becomes per piece with 0.01. Different columns in the same file can carry different factors. The wider treatment is in mapping your ERP's units of measure.

Blank-cell preservation. On an update run, a blank cell keeps the existing value rather than wiping it, so a partial refresh file is safe. A zero is a value, not a blank, so leave a column out of the export rather than filling it with zeros you do not mean.

Step 3: the routing import, and why it takes two passes

Routings are the hardest data to move between systems, because operations reference each other: step 10 feeds step 20 feeds step 30. A row-by-row import cannot wire those links, because step 20 does not exist yet when step 10 is written.

The routing import runs in two passes. Pass one reads and validates every row, auto-creates any work center or product the file names that does not exist yet, and buffers the steps. Pass two groups the buffered rows by end product, sorts them by sequence number, writes them, and wires the chain: 10 to 20, 20 to 30, and the terminal step to the finished product, so the routing renders as one connected flow in the graphical routing designer.

Conventions that pay off immediately:

• Number sequences in gaps of 10 so a later insert becomes 25 and nothing renumbers.
• Keep all of one product's steps in one file. A routing import wipes and recreates that product's steps once per run, which is what makes re-imports idempotent.
• Re-importing is safe for running work orders. Every scheduled job carries a frozen snapshot of the routing it was planned with, so a routing change applies to future jobs and leaves work in progress untouched. That behavior is what makes engineering changes routine, as covered in handling engineering changes with a routing re-import.

Step 4: work orders in, then run the scheduler

The order import maps product, quantity, reference, and dates. When your export carries an order reference, rows sharing that reference group under one sales order and their jobs auto-number as the reference followed by a line number, keeping a multi-line order together. The identifier conventions are in keeping job numbers aligned.

Imports never schedule anything. Imported work orders sit as unscheduled demand until you run the scheduler, which states its scope in plain numbers before it plans. Reconcile first, using the import reconciliation checklist.

Once the data is in, the full engine applies: finite capacity across multiple shifts and machine instances, work center groups that re-shop the machine pool on every reschedule, a sequence-dependent setup matrix, lot streaming with transfer batches, operator skills, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine.

Step 5: sending dates back

The return trip is Excel. The job schedule grid exports 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. Revised dates go back into Rootstock through the date-maintenance path your order process already uses. There is no automated write-back, which keeps your ERP data under your team's control.

A realistic first week

The documented benchmark in the User Solutions lineage is 5 days at Plastilite Corporation, where the ERP vendor itself recommended User Solutions scheduling. The day-by-day version is in the first week ERP integration checklist, and the staged rollout including a parallel run is in the go-live cutover plan.

Test it with your own export

Export this week's open work orders and a routing file, then bring them to a demo. Mapping them live takes minutes, and you leave having watched your own shop scheduled against its own capacity. If you are evaluating more than one ERP, the NetSuite and Acumatica versions of this guide follow the same method, which is the point of a universal import layer.