What EDGEBIC Cannot Import, and How to Handle It

EDGEBIC imports eight kinds of data through masks, Product, Workcenter, Customer, SalesOrder, BOR, Actuals, PlantHoliday and Shift, and everything else is built in the interface. In EDGEBIC by User Solutions that split falls along a useful line: bulk master data and demand are importable, while the low-volume configuration on top of it is entered by hand. Knowing which is which before you write a migration plan stops you from scheduling a phase around a bulk load that does not exist.

The eight importable entity types

Each has its own mask, and each matches existing records by a natural business key rather than an internal identifier, so a row for WIDGET-A finds the existing Widget-A without case-sensitivity getting in the way.

Files can be xlsx, csv, txt or tsv. Every row ends as exactly one outcome, Created, Updated, Reused or Failed, with the counts shown after the run and a per-run log recording each row. That is the machinery described in EDGEBIC import masks explained, and it covers the parts of a migration that genuinely need volume: the items, machines, customers, routings, jobs, recorded work, holidays and shift patterns.

What is built in the interface instead

Look at the volumes and the split stops feeling like a limitation. A plant has thousands of parts and routing steps, and those all have masks. It has a handful of groups, a few dozen people, and one or two machines where changeover order matters, and those are the hand-built items. Tools and fixtures belong to that set as well, and migrating your tools and fixtures shows why the list is shorter than it looks and which single field is easy to get wrong.

Sequence the work to match

The practical consequence is a two-phase migration rather than one big load.

Phase one, the bulk load. Departments first, since work centers reference them, then everything with a mask in the usual dependency order. At the end of this phase the plant schedules and the plan can be compared against your old system.

Phase two, the configuration. Work center groups, operators and skills, and setup matrices, each verified against a plan that already works. This ordering is better than the alternative even if imports existed for all of it, because you can prove each piece changed the schedule the way you expected. Group members change which machine is chosen. A certification moves a step when the certified person is away. A setup matrix shows up as a Matrix reason on the scheduled row.

Splitting it this way also means phase two is not a go-live blocker. A machine with no setup matrix keeps using its flat setup time. A routing step with no required skill plans exactly as it does today.

Two things not to plan around

Exports do not round-trip. Grid and report exports are a snapshot of what is on screen, built for sharing and analysis, and they are deliberately not in the import file format. If you want a repeatable reload cycle, keep the file you imported from as the master, edit it there, and re-run the mask with updates enabled. The setup matrix CSV is an exception in purpose only: it exists so you can document what you typed, not so you can load it back.

Imports never schedule. An import changes data, not the plan. After loading orders you run the scheduler yourself, which is the single most common surprise for people expecting a load to produce dates.

One import rule that catches migrations

The BOR mask deserves a specific warning, because it behaves differently from the others in a way that matters exactly once, during a migration. All steps for one end product must be in a single file, since a re-import replaces that product's routing entirely per run. Split a product's steps across two files and the second run loses the first run's steps.

That is a data-preparation instruction rather than a mapping one: group your routing export by end product before you start, and confirm each product appears in exactly one file. Pair it with the cleanup discipline in cleaning your data before importing.

What to leave behind entirely

Some things should not cross even though someone will ask. Old quoted dates from a system that planned against infinite capacity are not facts worth re-creating, and migrating quotes and quote history works through which live quotes to re-enter and which to leave as read-only history. Your old system's computed schedule is not migration data either: the new plan comes from scheduling your migrated inputs, which is why validation compares the two plans rather than copying one into the other, as validating a migrated schedule sets out. Deciding this explicitly keeps dead weight out of the new system, and it lines up with what you do not need to migrate.

The takeaway

The import masks do not cover departments, work center groups, operators and skills, or quotes and scenarios (the setup matrix is configured per work center, through an editor with its own Import and Export CSV); it does import Product, Workcenter, Customer, SalesOrder, BOR, Actuals, PlantHoliday and Shift. Plan a bulk-load phase for the eight masked types and a configuration phase for the rest, remember that exports are snapshots rather than reloadable files and that imports never schedule, and keep each end product's routing steps in one file. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with an EDGEBIC migration checklist and how many import masks your shop actually needs.