ERP Integration (EDGEBIC)

EDGEBIC + Microsoft Dynamics Integration FAQ: 12 Questions Plants Ask First

User Solutions TeamUser Solutions Team
|
8 min read

These are the questions Microsoft Dynamics plants ask in the first conversation, answered without hedging: there is no certified connector, the interface is your existing exports, nothing is installed inside the ERP, and nothing you import can disturb an order 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 Dynamics integration guide, and the field-level detail lives in the Dynamics to EDGEBIC mapping reference.

Is there a certified Dynamics connector?

No, and it is a design decision rather than a gap. 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 run after that is two clicks. The same architecture serves Dynamics, SAP, NetSuite, Sage, Epicor, and home-grown systems identically, so there is no per-ERP connector to certify, version-match, or repair when either side updates. A connector is a dependency. A file is not.

Does this work for Business Central and Finance and Operations?

Both, and for the older Dynamics generations as well, because the interface is a file rather than an API. The masks read what an export produces, not what a platform version exposes. That matters in groups where sites landed on different editions over the years: one method covers all of them instead of one integration per edition. The wider category discussion, including approaches other than this one, is in the Microsoft Dynamics scheduling integration overview.

Does EDGEBIC replace any part of Dynamics?

No. Dynamics stays the system of record for materials, procurement, costing, inventory valuation, and financials. 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. Order entry, material planning, and purchasing keep running exactly as they do today. The general case for that split is in why ERP needs a scheduling add-on.

Does anything get installed inside Dynamics?

No. No extension is published, no schema is extended, no integration user is created, and nothing joins your update path. The only artifacts on the ERP side are the exports your team builds, which are ordinary reports run by people who already have the permission to run them.

What exactly has to come out of Dynamics?

Four exports carry a complete scheduling model, and a fifth is optional. Items (an identifier 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 production orders (item, quantity, and a date). Optionally, reported hours (job number, work center, date, and hours or pieces). Any list, report, or query in your environment that saves to Excel or CSV is a valid source.

How long until the first real schedule?

Most plants see a first finite capacity schedule from their own data in the first working session, and a tuned one inside two weeks. 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.

We run several sites in one company database. One EDGEBIC database or several?

Split by scheduling decision rather than by ERP structure. If sites share machines, share operators, or transfer work between plants, keep them in one database and use departments to group each site's work centers, because the engine can only balance load across resources it can see. If each site plans independently, a database per site keeps files small and each planner's view focused. Whichever you choose, check for repeated work center codes across sites first: the identifier is the natural key, so two centers both called WELD-1 merge into one record with combined load unless you prefix them on the export side.

Do we have to clean our routing data first?

No, and trying usually costs a month. Import what the ERP 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 an order 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 rather than layering on top of it.

What happens when the platform takes an update?

Nothing, in almost every case. The integration reads files rather than calling an interface, so there is no connector version to track and nothing to re-qualify. If an update renames a column heading in an export, you re-map that column in the mask once, which takes minutes. Adding a five-minute export check to your post-update routine is the whole exposure.

Our routing times are in minutes. Do we convert them first?

No. Put a conversion factor of 0.016667 on that column in the routing mask and a cell of 30 minutes lands as 0.5 hours. Seconds use 0.000278 and a time quoted per 100 pieces uses 0.01. Different columns in the same file can carry different factors, so one export can mix units and land correctly in all of them. The factors are saved with the mask, which makes the conversion permanent and auditable through the per-run log.

Do imported orders schedule themselves?

No, and the separation is deliberate. An import changes data; the scheduler changes the plan. Newly imported orders appear as unscheduled demand and stay there until you run the scheduler. Before the run starts, a confirmation states the scope in plain numbers: how many jobs are being scheduled for the first time and how many existing jobs are being rescheduled. An import can therefore never silently rearrange a plant, and you always know the blast radius before anything happens. The modes are covered in EDGEBIC scheduling modes explained.

Can an import disturb orders 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. On top of both, imports never schedule anything.

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 order 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. Involve IT or your partner exactly once, to turn the four exports into 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. For the gap-by-gap argument that usually precedes this decision, see Dynamics scheduling gaps and how EDGEBIC fills them, and for the same questions answered for other platforms, the Infor and Global Shop Solutions FAQs follow the same shape.

Still deciding?

The fastest way to settle any of this is your own export. Pull this week's open 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.

No, and that is a design decision rather than a gap. EDGEBIC integrates through reusable import masks that read Excel, CSV, delimited text, or a database source. You map an export's columns onto EDGEBIC fields once and save it; every run after that is two clicks. Because there is no connector, there is nothing to certify, nothing to version-match, and nothing to repair when either side updates.

No. No extension is published, no schema is extended, no integration user is created, and nothing enters your update path. The only artifacts on the ERP side are the exports your team builds, which are ordinary reports run by people who already have the permission to run them. That is the practical reason a file interface clears review faster than an integration project.

Through Excel and the date-maintenance path your order process already uses. The Job View grid exports the job schedule as a workbook with colored cells and a legend sheet, and every report dialog exports to Excel or PDF with the column layout you saved. There is no automated write-back, which is deliberate: changes to ERP records stay inside your existing approval process.

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, because an operation with an actual start and end is historical fact. On top of both, imports never schedule anything at all.

Expert Q&A: Deep Dive

Q: We already have a partner who customizes our Dynamics environment. Where do they fit in this, and do we need them?

A: For roughly one afternoon, and then not at all. The only ERP-side work is turning four exports into saved reports that land in a known folder with stable file names and stable column headings, which your partner can do quickly and which nothing about this integration makes harder for them later. After that the routine belongs to the planner: export, run the saved masks, run the scheduler, publish the dispatch lists. Nothing is deployed into the environment your partner maintains, so their release process, their extensions, and their update testing are all untouched. If your partner has previously written scheduling logic into a customization, that is the piece worth revisiting, since configuration a planner can change tends to outlive code nobody remembers writing.

Q: Business Central takes updates on a vendor cadence. What is our exposure each time one lands?

A: One thing to check and nothing to redeploy: do the four exports still produce the same column headings? If yes, the masks run unchanged, because the interface is a file and there is no connector version bound to the platform. If a heading changed, you open the affected mask and re-map that row, which takes minutes and needs no testing cycle on the ERP side. Building this check into your post-update routine costs about five minutes a cycle, and it is worth doing deliberately rather than discovering the mismatch on a Monday morning when the import reports a mandatory field unmapped and refuses to start.

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