EDGEBIC + Microsoft Dynamics: The Complete Scheduling Integration Guide

Integrating Microsoft Dynamics with EDGEBIC means exporting the items, work centers, routings, and open production orders your ERP already holds to Excel or CSV, 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 export back for the ERP and your customers. There is no middleware server, no extension deployed inside the ERP, and no certified connector to maintain through a platform update.

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 approach has fed schedules for the US Navy, GE, BAE Systems, and Cummins, including Cummins scheduling across 33 locations from AS400-era data. This guide covers the Dynamics case: what to export, how the masks work, what the engine does with the result, and what a realistic first two weeks looks like.

Why the edition does not matter

Dynamics is a family rather than one product, and manufacturers run several generations of it side by side, sometimes in the same group of companies. A file interface makes that irrelevant. The masks read what an export produces, not what a platform version exposes, so the same method serves Business Central, Finance and Operations, and the older generations a plant may still be running after an acquisition.

That matters more here than in most ERP families, because Dynamics estates change shape. Platforms move forward on a vendor cadence, partners add extensions, and companies migrate between editions. A connector would have to be re-qualified at each of those moments. A file has nothing to re-qualify. The general category view is in the older Microsoft Dynamics scheduling integration overview, which covers integration approaches other than this one.

Where Dynamics stops and detailed scheduling starts

An ERP is built to be right about material, cost, and commitments, and that work belongs there. The gap most Dynamics plants report is further downstream, in the questions a planner answers every morning:

• Which of these 90 open orders actually fits on the constraint work center this week?
• If the expedite jumps the queue, which promised dates slip and by how much?
• Is the paint line loaded to 85 percent or 145 percent next Tuesday?

Those are finite capacity questions. Answering them means modeling shifts, machine instances, changeover sequences, and operator skills against every open order at once, which is a different computational problem from planning material. The discipline split between planning material and scheduling capacity is standard in the operations management body of knowledge maintained by ASCM. The general argument is in finite versus infinite capacity scheduling, and the gap-by-gap version for this ERP is the companion post on Dynamics scheduling gaps and how EDGEBIC fills them.

The integration in one table

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

An import mask is a saved recipe. It remembers which kind of data you are importing, what format it arrives in (an Excel workbook, or comma, semicolon, tab, or space delimited text), whether the first row carries headings, 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: pick the mask, press Do It.

Every row in your file produces exactly one outcome: Created, Updated, Reused (found 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. Nothing half-imports silently, which matters when someone asks what a run actually changed.

Step 1: the four exports

You do not need everything Dynamics knows. Four exports carry a complete scheduling model.

1. Items. The item identifier, description, unit of measure, and any cost or lead-time columns you want visible. The identifier is the natural key and matching is case-insensitive, so PUMP-A in the file finds Pump-A in the database.
2. Work centers. The work center identifier, how many identical machines it holds, default setup hours, efficiency, and an hourly rate if you want cost rollups. Bottleneck and shift assignment flags can ride along in the same file.
3. Routings. One row per operation: end product, work center, sequence number, hours per unit, setup time, queue time.
4. Open production orders. Product, quantity, order reference, and dates.

Any list, report, or query in your Dynamics environment that saves to Excel or CSV is a valid source. You are not writing an extension, not calling an API, and not standing up a middleware service. The file is the interface, which is exactly why nothing here enters your ERP's update path.

Step 2: map the columns once

Build one mask per file. Name it after the routine rather than the file: Weekly Dynamics Work Orders outlives orders-week29.xlsx. Mandatory fields are flagged in the mask editor, and the run refuses to start until they are mapped, so a half-built mask fails before it reads a single row rather than half-way through.

Two mask features carry most of the weight in a Dynamics integration:

Unit conversion. ERPs and schedulers disagree about units constantly. 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 is 0.000278. A standard time quoted per lot of 100 pieces becomes per piece with 0.01. Different columns in one file can carry different factors, so a routing export mixing per-lot run times with per-changeover setup minutes lands correctly in one run.

Blank-cell preservation. On an update run, a blank cell keeps the existing value instead of wiping it. A file carrying only item number and price refreshes prices and touches nothing else. Note the matching rule: a zero is a value, not a blank, so leave a column out 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 naive row-by-row import cannot wire those links, because step 20 does not exist yet when step 10 is written.

EDGEBIC's routing import therefore 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.

Three conventions save time later:

• Number sequences in gaps of 10. When engineering inserts a deburr step next quarter it 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 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: 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}, which keeps a multi-line order together instead of scattering it.

One rule matters more than any other: imports never schedule anything. After the run, imported orders sit as unscheduled demand. You then run the scheduler, which states its scope before it plans (how many jobs are new and how many existing jobs are being rescheduled), and the new work slots around everything already committed on the floor. Data movement and planning stay separate on purpose, so an import can never silently rearrange a plant.

Once the data is in, the whole engine applies to your Dynamics work: 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 executable 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, which turns a dispatch list into a saved report rather than a document someone rebuilds each morning.

From there, revised dates go back into Dynamics through the date-maintenance path your order process already uses. There is no automated write-back, which is deliberate: your ERP data stays under your team's control and inside your existing approval process. The category framing for this split is on the ERP scheduling add-on page.

A realistic first two weeks

The method behind this guide 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. A single-site Dynamics plant with clean routings can move at close to that pace.

If you are starting from an empty database, the green-field setup walkthrough covers the sequence in detail, and the Dynamics to EDGEBIC data mapping reference is the field-level lookup you keep open while building masks.

Prove it with your own export

The fastest evaluation is not a feature list, it is your own file. Export this week's open production orders and a routing file, then bring them to a demo. Mapping them live takes minutes, and you leave having watched your own plant scheduled against its own capacity. Shops comparing several ERPs at once can also read the Infor and Global Shop Solutions versions of this guide: the method is identical, which is the point. The questions that usually come up first are answered in the Dynamics integration FAQ.