Exporting the EDGEBIC Schedule Back to Your ERP

Sending the EDGEBIC schedule back to your ERP is an Excel export, not an automated write-back: the Job View grid exports the job schedule as a workbook with colored cells and a legend sheet, the work center schedule and every report export the same way, and revised dates go back into the ERP through the order-maintenance path your team already uses. The write stays manual on purpose, which keeps your ERP records under your team's control rather than under an integration's.

EDGEBIC by User Solutions reads your ERP's exports through import masks, builds a finite capacity schedule, and hands the result back as files. This post covers the return trip: what comes out, in what shapes, and why the boundary sits where it does. The inbound half is in which ERP fields EDGEBIC needs to schedule, and the whole architecture is on the ERP integration page.

The three things worth exporting

A finished schedule answers different questions for different people, so it comes out in more than one shape.

The job schedule is the one that feeds the ERP, because it pairs each job with the dates the finite capacity run produced. The work center schedule and dispatch lists feed the floor. All of them are files, and all of them respect the column layout you saved, so the export looks the way you set it up rather than a fixed default.

The Job View export in detail

The Job View grid is the primary export for anything going back to the ERP. It writes an Excel workbook where the cells are colored by schedule status and a legend sheet explains the colors, so the meaning of the schedule travels into the file rather than being lost in a flat table. You export the whole grid or a filtered slice, which is how you produce a narrow file of just the jobs whose dates changed this run.

That narrow file is the useful one for the ERP. Rather than pushing every date on every run, you export the jobs that actually moved, review them, and update the ERP's promise dates for the ones that matter to a customer. The colored full export stays as the working picture; the filtered slice is the update artifact.

Dispatch lists for the floor

The floor does not need the ERP updated, it needs to know what to run next. A dispatch list is a per-work-center sequence exported to Excel or PDF: this center runs job A, then job B, then job C, in that order, for this shift or this week. It changes as often as the schedule does, because that is what the floor needs, and it posts or shares without touching the ERP at all.

Separating the two audiences is the pattern most shops settle on. The floor works from dispatch lists that update every run. The ERP gets a slower, narrower update of committed promise dates. The dispatch list is a working document; the ERP date is a commitment. The mechanics of a recurring rhythm are in keeping your ERP and EDGEBIC in sync.

Why the write-back is manual

A scheduler that silently rewrites ERP dates on every run takes the planner out of the loop, and the planner's judgment is exactly what running a finite capacity schedule is for. The engine can tell you that a rush order pushes six promise dates, but whether to commit those new dates, renegotiate one with a customer, or expedite to hold the original is a business decision, not an arithmetic one. The scheduling modes let you control the blast radius of a run; the manual write-back lets you control what leaves the building.

Keeping the write manual has three concrete benefits:

• Your ERP data stays under your control. No integration ever writes a date you did not approve.
• Nothing to break on an ERP upgrade. There is no write connector to version-match when the platform updates.
• A reviewable artifact exists. The exported file is the record of what the planner signed off before it loaded, which matters when a customer asks why a date changed.

Feeding the ERP's own bulk-update tool

Manual does not have to mean typing. Because EDGEBIC exports a clean Excel or CSV of job numbers and their new dates, that file can feed whatever bulk update your ERP already supports: a data-import template, a spreadsheet upload, or a saved update routine. EDGEBIC does not drive that step, which is the boundary, but it produces a file shaped for it. Keep the export narrow, job number plus the dates that changed, so the update touches only what moved.

This is where the export side and the import side meet symmetrically: the same file-based discipline that brings ERP data into EDGEBIC carries EDGEBIC's dates back out. One universal file layer in both directions is the whole design, explained in why EDGEBIC connects to every ERP the same way.

What does not need to go back

Most of what EDGEBIC computes stays in EDGEBIC, and that is correct. The ERP does not need the machine-level sequence, the instance assignments, the setup-matrix decisions, or the operator rosters; it needs the promise dates that changed. Sending less back is a feature, not a limitation: the ERP holds stable, agreed commitments while EDGEBIC holds the detailed, frequently-recomputed plan. The two systems answer different questions, and the export boundary is where that division lives. The engine that produces all this detail is on the EDGEBIC product overview, and the finite capacity side is in finite versus infinite capacity scheduling.

See the export with your own data

The fastest way to understand the return trip is to run one. Bring a routing and this week's open work orders to a demo, watch them schedule, and export the result: you will see the colored Job View workbook, a work center schedule, and a dispatch list, and you will know exactly which file your ERP update would use. The same outputs apply whether your ERP is Sage, Odoo, or MRPeasy.