ERP Integration (EDGEBIC)

EDGEBIC + MRPeasy: The Complete Scheduling Integration Guide

User Solutions TeamUser Solutions Team
|
10 min read

Integrating MRPeasy with EDGEBIC means exporting the items, workstations, routings, and open manufacturing orders MRPeasy 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 then go back as Excel. There is no API project, no add-on installed in the account, and 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 ERP and MRP systems 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 MRPeasy case: what to export, how the masks work, what the engine does with the result, and what a realistic first week looks like.

Why a cloud MRP still needs a finite capacity layer

MRPeasy handles what a small-shop MRP should: stock, bills of materials, purchasing, order tracking, and a production plan that books operations onto workstations. What most MRPeasy users report is that the daily sequencing decision against real machine constraints still lives in a spreadsheet, because the questions a planner asks each morning are finite capacity questions:

  • Which of these 40 open manufacturing orders fit on the two machining cells this week?
  • If this rush order jumps the queue, which promise dates move and by how much?
  • Is the assembly bench loaded to 80 percent or 160 percent next Thursday?

Those require modeling shifts, machine instances, changeover sequences, and operator availability against every open order at once. It is a different computational problem from planning material, which is why a dedicated finite capacity layer beside the MRP is the standard pattern. The general case is in finite versus infinite capacity scheduling, and the wider argument is in why ERP needs a scheduling add-on.

The integration in one table

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

DirectionDataHow it moves
MRPeasy to EDGEBICItemsCSV or Excel export to Product import mask
MRPeasy to EDGEBICWorkstations / work centersExport to Workcenter import mask
MRPeasy to EDGEBICRoutings / operationsExport to BOR (bill of routing) import mask, two-pass
MRPeasy to EDGEBICOpen manufacturing ordersExport to SalesOrder import mask
MRPeasy to EDGEBICReported labor (optional)Export to Actuals import mask
EDGEBIC to MRPeasyExecutable start and end dates, dispatch listsExcel export from Job View and reports

An import mask is a saved recipe. It remembers which kind of data you are importing, what 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 of your file maps onto an EDGEBIC field. You build it once by dragging your file's column headings onto EDGEBIC's 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 file records every row individually.

The file is the interface, and that is the advantage

Cloud platforms change on the vendor's schedule, not yours. That is usually fine, and occasionally it breaks an integration built against an API surface. A file-based 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 follow for an MRPeasy account:

  • Nothing is installed in your account. No add-on, no automation, no API key living in someone's password manager. There is nothing to promote or version.
  • No integration credential is created. The scheduler never authenticates against MRPeasy, 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.

Step 1: the four exports

Four exports carry a complete scheduling model. Any list in MRPeasy that saves to CSV or Excel is a valid source.

  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.
  2. Workstations or work centers. Identifier, how many identical machines the workstation really holds, default setup hours, efficiency, and an hourly rate for cost rollups.
  3. Routings. One row per operation: end product, work center, sequence number, hours per unit, setup time, queue time.
  4. Open manufacturing orders. Product, quantity, order reference, and dates.

Describe the export generically and map what you have. Whatever the MRPeasy column headings say, you drag them onto EDGEBIC's fields; the names do not need to match.

Step 2: map the columns once

Build one mask per file and name it after the routine rather than the file: Weekly MRPeasy Manufacturing Orders outlives mo-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 time quoted per lot of 100 pieces becomes per piece with 0.01. MRPeasy routings often carry both cycle time and setup in minutes, so map each with the minutes factor.

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, however, is a value and will be written. 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.

EDGEBIC's 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 then 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. Splitting one product across two runs means the second run's wipe deletes the first run's steps.
  • 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.

Step 4: manufacturing 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 {Ref}-{line}, keeping a multi-line order together.

Imports never schedule anything. Imported manufacturing orders sit as unscheduled demand until you run the scheduler, which states its scope in plain numbers before it plans. Data movement and planning stay separate on purpose, and the choice of run is covered in EDGEBIC scheduling modes explained.

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 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. Revised dates then go back into MRPeasy through the order-maintenance path your process already uses. There is no automated write-back, which keeps your MRP data under your team's control.

A realistic first week

The method has a documented benchmark in the User Solutions lineage: at Plastilite Corporation the ERP vendor itself recommended User Solutions scheduling, and the team went from first export to a complete optimized schedule with ERP integration in 5 days. An MRPeasy shop usually follows the same shape.

DayWork
1Export items and workstations; build and run those two masks; verify counts
2Export routings; build the routing mask with the minutes conversion; review the routing designer
3Export open manufacturing orders; import; run the first full finite capacity schedule
4Compare EDGEBIC dates to current promises; correct instance counts, shifts, and setups where reality disagrees
5Lock the weekly rhythm: saved masks, import order, scheduler run, exports back

The green-field setup walkthrough covers the from-empty sequence, and the MRPeasy to EDGEBIC data mapping reference is the field-level lookup to keep open while building masks.

Test it with your own export

Export this week's open manufacturing 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 comparing tools, the Katana, Fishbowl, and Fulcrum versions of this guide follow the same method, which is the point of a universal import layer.

No. EDGEBIC reads the CSV or Excel exports MRPeasy already produces through reusable import masks. There is no API integration to build, no add-on installed in the account, and no certified connector to version-match. You map an export's columns onto EDGEBIC fields once and save the mask, and every run after that is two clicks with a per-run log recording each row.

Four exports carry a complete scheduling model: items, workstations or work centers with a real machine count, routings with operation sequence and run and setup times, and open manufacturing orders with quantities and dates. A fifth optional export carries reported labor from the floor. Each goes through its own import mask, and every row returns as Created, Updated, Reused, or Failed.

No, and that separation is deliberate. An import changes data, the scheduler changes the plan. Imported manufacturing orders appear as unscheduled demand and stay there until you run the scheduler, which states how many jobs are new and how many are being rescheduled before it plans anything. An import can therefore never silently rearrange the floor.

Expert Q&A: Deep Dive

Q: MRPeasy already has a production planning calendar and a Gantt. Why bolt a second scheduler onto it?

A: Because MRPeasy schedules a workstation as a single resource booked one operation at a time, which is the right model for a small shop but not for one with parallel identical machines, sequence-dependent changeovers, and skilled operators. EDGEBIC loads those constraints and solves the finite capacity question across every open manufacturing order at once: four identical CNC units modeled as one work center with four instances, a heat-treat furnace that runs one job per day, a paint line where going light to dark costs four hours of changeover. MRPeasy stays the system of record for stock, purchasing, and order tracking. EDGEBIC is the compute layer that answers which job fits where and what dates actually hold.

Q: Our routings in MRPeasy carry cycle time per piece in minutes and setup in minutes too. Do we reformat the file before importing?

A: No. You set a conversion factor on each numeric column in the routing mask and the multiplication happens before the value is stored. Minutes to hours is 0.016667, so a 45-minute cycle lands as 0.75 hours and a 20-minute setup lands as 0.333 hours. Different columns in the same file can carry different factors, so a file that mixes minutes and hours is handled by mapping each column with the factor it needs. The factor is saved on the mask, so every weekly import converts identically without anyone doing arithmetic by hand, and the per-run log records each row if you want to audit the result.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together