Migrating Your Item and Customer Master to EDGEBIC

Migrate your item and customer master to EDGEBIC first, through saved import masks, because routings and orders link to them by name and need them to exist. In EDGEBIC by User Solutions, products carry their codes, descriptions, units of measure, and costs across as mapped columns, and customers come in as the light reference list your orders and quotes point at. Get this foundation right at the front of the migration and every later import resolves cleanly instead of failing on a missing reference.

Master data is the foundation the rest stands on

A scheduling model is a set of linked records. Routings reference products and work centers. Orders reference products and customers. Those links are made by name, which means the thing being pointed at has to exist before the pointer lands. Import a routing that names a product EDGEBIC has never heard of, and the step has nothing to attach to.

That dependency is why item and customer data goes first. It is the foundation, and everything structural sits on top of it. Migrate it carefully and the routings and orders that follow snap into place; migrate it sloppily and every later import surfaces the gaps. The full sequencing is laid out in the order to import your data into EDGEBIC, and this post is about getting the first layer right. It fits inside the broader path on the RMDB to EDGEBIC guide.

Migrating the item master

Export your items from RMDB and build a product import mask. The fields worth mapping deliberately are the ones scheduling and quoting actually use:

• Item code. The identifier routings and orders link to. This is the name that must match everywhere, so keep it identical across every file.
• Description. What the part is, for the planner reading the Gantt.
• Unit of measure. How the item is counted.
• Unit cost and unit price. What it costs to make and what it sells for.

Map these once, save the mask, and import. The detailed mechanics of a product import are in how to import products from Excel in EDGEBIC, and the general mask workflow is in EDGEBIC import masks explained.

Costs are worth care because they do more than sit on a record. EDGEBIC uses unit cost and price in quote simulation to estimate material and labor cost, so accurate costs on the item master mean your what-if promise dates and cost estimates are grounded from the first quote.

Migrate the scheduled tree, not the whole catalog

A large item master often holds thousands of parts, most of them dormant. You do not need all of them in EDGEBIC. What scheduling touches is a tree: the finished goods you build, the sub-assemblies their routings reference, and the components those consume.

The sub-assembly point matters. When a product's routing references a sub-assembly, EDGEBIC treats that step as a sub-assembly and rolls its hours, labor, and material up when it schedules and quotes the parent. For that rollup to work, the sub-assembly has to exist as a product with its own routing. So the rule is: bring the finished goods, their sub-assembly trees, and the components those consume, and leave the dormant remainder in your system of record.

A practical filter is to export the items referenced by any routing or open order you are migrating, plus their sub-assembly tree. Because the mask is saved, you can always import more later in a click, so start with the scheduled tree and widen only if a gap appears.

Migrating customers

Customers are light. EDGEBIC uses them to attach orders and quotes to who they are for, so you want them present, but you do not need a full ERP customer record with billing terms and addresses. You need the customer names your open orders and quotes reference, so those links resolve.

Export a simple list of the customers tied to the orders you are migrating and import it through a customer mask before you import the orders. If your demand comes out of an ERP export that already carries a customer name column, you can build the customer list from the distinct names in that file. Keep it minimal: the goal is that every order finds its customer, not that EDGEBIC becomes a second customer database.

A worked example

A shop migrates the master data for its make-to-order product line.

1. Filter the items. Rather than export all 6,000 parts, the planner exports the 240 finished goods on the line, their sub-assemblies, and the components those consume: about 900 items.
2. Map and import products. They map item code, description, unit of measure, cost, and price in one mask, save it, and import the 900 items.
3. Build the customer list. From the open orders export, they pull the 60 distinct customer names and import them through a customer mask.
4. Then routings and orders. With products and customers in place, the routing and order imports that follow resolve every reference on the first pass.
5. Fix and re-run. A handful of items had a stale unit of measure. The planner corrects them in RMDB, re-exports, and re-imports in one click.

The foundation went in first and clean, so nothing built on top of it had a missing reference to chase.

Common pitfalls

• Name drift. The item code links products to routings and orders. One spelling in the item file and another in the routing file breaks the link. Keep codes identical everywhere.
• Missing sub-assemblies. A referenced sub-assembly with no product record contributes nothing to the parent's rollup. Bring the whole tree.
• Blank cells overwriting values. A blank in a mapped column can clear a field. Check how the mask handles empty cells before a large import.
• Over-migrating. Importing a dormant 6,000-part catalog adds noise, not capability. Bring the scheduled tree and widen only if needed.

The takeaway

Migrating your item and customer master to EDGEBIC is the first structural step of the move, because routings and orders link to it by name. Bring the scheduled tree of finished goods, sub-assemblies, and components rather than the whole catalog, map item code, description, unit of measure, and cost once in a saved mask, and keep customers light: just the names your orders reference. Get this foundation right and every later import resolves cleanly. See the platform in full on the EDGEBIC overview, read the whole path on the RMDB to EDGEBIC guide, and then follow the order to import your data into EDGEBIC.