Handling Multi-Plant ERP Exports in EDGEBIC

When your ERP holds several plants, decide first whether work moves between them: if it does, import every site into one model with plant-prefixed work center identifiers and transit days on the crossing routing steps, and if it does not, keep the sites in separate models. The import mechanics are identical either way. What changes is scope, naming, and whether a routing has to cross a boundary.

EDGEBIC by User Solutions has scheduled multi-site manufacturers since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, including Cummins across 33 locations, the pattern that holds is simple: model the sites together only where the work is together.

The decision that comes first

Everything else follows from one question: does a part ever start at one site and finish at another?

No shared work. Two plants making different products for different customers, each with its own machines and its own orders. Nothing connects them in a routing. Separate models are simpler: smaller data, faster schedules, and each planner sees only their own site.

Shared work. A part machined at one site and finished at another, or a plant that offloads to a sister site when it is full. The routing crosses the boundary, so both sites must be in the same model or the crossing step has nothing to point at.

Mixed. Most groups. The usual answer is one model per cluster of sites that genuinely exchange work, not one model for the whole company. The wider platform view of multi-site behavior is in scheduling work that moves between plants.

Naming: put the site in the identifier

This is the one convention that prevents a whole class of silent errors.

Matching on import is by identifier, case-insensitively. If Houston and Cleveland both have a work center called MILL-2, a shared model treats them as one machine and merges their capacity. Nothing errors. The schedule simply believes you have twice as many mills as you do, in a place where none of them are.

Prefix the identifier with the site: HOU-MILL-2 and CLE-MILL-2. Then:

• The work center import creates two distinct records.
• The routing import matches the right one, because the same prefix appears in the routing export.
• A planner reading a dispatch list can see where the work is without a lookup.

Do the same for products where a part number genuinely differs by site. Where a part number is the same across sites because it is the same part, leave it alone. Products do not hold capacity, so they do not collide the way centers do.

Filtering the export

Most ERPs export multi-plant data with a plant or site column. Two workable approaches:

Filter in the report. Pass a plant parameter and get one file per site. Each file feeds the same saved mask, so you build the mask once and run it three times. Files stay small and obviously scoped, and a mistake is visible from the filename.

Export everything, rely on identifiers. One large file for all sites, imported once into the shared model. This works cleanly as long as the site is carried inside the identifiers. It is the right approach when work crosses sites anyway, because you want the whole picture in one pass.

What does not work is an unfiltered file imported into a per-site model, because rows from other sites will create work centers and orders that do not belong there. If your models are separate, your exports must be filtered.

Shift calendars stay per site

Each work center carries its own shift assignment, which is what keeps sites honest in a shared model. A plant in Mexico working Monday to Saturday with its own holiday calendar, and a plant in Ohio working Monday to Friday with US holidays, are simply two sets of centers with two sets of shifts.

That means:

• A holiday at one site does not consume capacity at the other.
• A second shift added at one site does not inflate the other's availability.
• Utilization reporting reads per center, so it reads per site by construction.

Set the standard pattern first and override the exceptions, rather than trying to specify every calendar up front. The work center list guide covers the build order.

Transit days: the crossing mechanism

A routing step can carry transit days, applied after the operation finishes and before the next step may start. Transit can be counted in calendar days or in working days, which matters when a four-day move spans a weekend.

A worked example makes the effect concrete:

Machining plans against the Texas center's real shifts and instance count. Heat treat cannot start until the four transit days have elapsed, and inspection waits for the return leg. The resulting lead time is around nine days rather than the eleven hours of run time, which is the honest number and usually the one nobody had written down.

Where the same operation can be done at more than one site with different transit, keep the transit value on the step that describes that route. The routing import carries these columns like any other, and the field-level detail is in mapping routings versus operations from your ERP.

Grouping for readability

Work centers can be grouped by department, which is how a multi-site model stays navigable once it holds sixty centers instead of twelve. Group by site, or by site and area, whichever matches how your planners think.

Where several sites hold genuinely interchangeable machines and a job could legitimately run at either, a work center group models that pool with a per-member factor, so a slower or more expensive site remains a valid choice that the schedule can select when the primary is full. Use it deliberately, and only where offloading is a real option, because a pool that crosses a plant boundary implies a shipment.

Import order does not change

Multi-plant adds scope, not steps. The recurring routine is the same:

1. Items
2. Work centers
3. Routings
4. Work orders
5. Actuals
6. Run the scheduler, then export the plan back

Reconcile after each import. The check that matters most in a multi-site model is the orphan work center check, because a routing that names an unprefixed center will auto-create it as an empty, siteless machine with no shifts. The six checks are in the import reconciliation checklist, and the cadence is in the weekly sync routine.

Then the engine plans across the group

With per-site centers, per-site calendars, and honest transit, the full engine applies across the whole model: finite capacity across shifts and machine instances, sequence-dependent setups, lot streaming with transfer batches, operator skills, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine, the ERP integration architecture shows the import layer that every ERP uses, and the go-live cutover plan sequences the rollout when more than one site is involved, while onboarding a second plant into an existing EDGEBIC database covers the case where the first site is already live.

Model your own sites

Bring exports from two plants, including one routing that crosses between them, to a demo. Watching the transit days push a receiving step out is the quickest way to see whether one model or several is right for your group.