Which ERP Fields EDGEBIC Needs to Build a Finite Capacity Schedule

A finite capacity schedule needs surprisingly little from an ERP: a product identifier, a work center identifier, a routing with an operation flag and hours per unit, and open work orders with a quantity and a date. That minimum set produces a valid schedule. A second tier of fields, led by the number of identical machines in each work center, makes the dates accurate. A third tier of scheduling intelligence has no export column at all and is configured once inside EDGEBIC. This post maps all three tiers so you know what to pull from any ERP.

EDGEBIC by User Solutions reads whatever your ERP already exports through reusable import masks, so this is a mapping question rather than a development one. The ERP integration architecture is identical for every platform, which is why one field list serves them all.

Tier 1: the fields that make a schedule possible

These are mandatory. An unmapped mandatory field aborts the run before a single row is read, which is deliberate: a half-built mask fails loudly rather than importing garbage.

The operation flag is the field first-time users most often set wrong. True means the row is an operation running on a work center. False means the row is a component or subassembly consumed at that point in the routing. Getting it backwards turns components into work centers, and the graphical routing designer shows it immediately.

Two entities on this tier have no ERP origin at all, because no ERP models your plant calendar the way a scheduler needs it: shifts (one row per shift with start and end times per weekday) and plant holidays (closures by date). You write these as a short spreadsheet once. They are ten minutes of work with the widest effect in the whole load, because every scheduled date is computed against them. The general idea is in what production scheduling is.

Tier 2: the fields that make the dates accurate

None of these are required to run, and all of them change the answer. Import what your ERP holds, then add these where the schedule disagrees with reality.

The number of machine instances is the single highest-value field on this tier and the one most ERPs do not export, because they model a work center as one resource with a capacity figure. A four-machine cell imported as one instance produces a plan roughly four times too long, and it fails quietly: nothing errors, the dates are simply wrong. Fill it deliberately for every multi-machine center. The arithmetic is in how EDGEBIC calculates work center capacity, and the finite versus infinite distinction is in finite versus infinite capacity scheduling.

The bottleneck flag connects to production bottleneck identification: mark the constraint and the engine anchors the plan around it rather than treating it as an ordinary center.

Tier 3: the intelligence with no export column

The settings that most differentiate one shop's schedule from another have no column in any ERP export. They are not imported at all; they are configured once inside EDGEBIC and then apply to every imported work order afterwards.

• Sequence-dependent setup matrix. The changeover cost that depends on what ran before, white to black costing four hours where black to white costs one. No ERP carries a from-product-to-product matrix. It is configured in the setup matrix.
• Work center groups. A named pool of interchangeable machines re-shopped on every reschedule, with a per-member efficiency factor. Import the members as ordinary work centers, then build the group. The path is how to create work center groups.
• Operator skills and rosters. Which operators are certified on which centers, and who is on shift. Configured in EDGEBIC, because no routing export models a certification.
• Lot streaming with transfer batches. Moving a partial batch downstream before the whole lot finishes, which no ERP routing expresses.
• Bottleneck anchoring behavior. How the plan is built around the constraint once it is flagged.

The distinction matters for planning a project: do not wait to collect this tier before starting. Import tiers one and two, get a schedule, then layer tier three on top. The EDGEBIC product overview maps the whole engine.

A practical rule for a first export

You do not need a perfect ERP to start, and trying to clean it first usually costs a month you do not have. Export what the ERP holds today, map the tier-one fields plus whatever tier-two fields already exist, and run a schedule. The disagreements between EDGEBIC's dates and your planner's expectations are your defect list, and they arrive specific: a wrong hours-per-unit shows up as a job finishing implausibly early, a missing instance count shows up as a plan four times too long, a missing setup shows up as free changeovers. Each corrected file re-imports cleanly, because master data comes back Reused when it matches and a routing re-import wipes and recreates one product's steps at a time.

That loop, import then compare then correct, is faster than any up-front cleanse, and it is the same loop whether the ERP is SAP, Katana, or a spreadsheet. The mechanics of the recurring version are in keeping your ERP and EDGEBIC in sync.

See it with your own fields

The quickest way to know which of your ERP's columns matter is to map them live. Export a product list, a routing, and this week's open work orders, then bring them to a demo. Mapping takes minutes, and you leave knowing exactly which fields your shop already has and which few are worth adding.