An import entity type is the kind of business record a given import mask loads, and it is the first choice you make when setting up an import. Every mask is bound to exactly one entity type, and that binding decides which fields you can map, which are mandatory, and how each row is matched and saved. The planner-facing types are products, work centers, customers, sales orders, routings, and actuals, each with its own field catalog and its own processing logic.
EDGEBIC by User Solutions uses the entity type to route every row to the right handling. This article defines the term and the available types. To see the fields for each, read how EDGEBIC handles import masks.
How It Works
When you create an import mask, you pick the entity type before anything else. That choice loads a field catalog: the canonical list of target fields for that record, with the mandatory ones marked so the import refuses to run if any is left unmapped. A product mask shows product fields; a routing mask shows routing fields; the two do not overlap.
The entity type also selects how rows are processed. Each type has its own logic for finding an existing record, deciding whether to create, update, or reuse it, and saving it. Master-data types like products and work centers match on a business name and reconcile against what already exists. Routings run a two-pass process, because a step's link to the next step is only known after all steps are saved. Actuals resolve to a job and work center and write hours or pieces against the right day.
Because a mask is bound to one type, its behavior stays predictable and its mandatory checks stay specific. To load several types, you build several masks and run them in an order that respects their dependencies.
A Concrete Example
Think of entity types as different intake forms at a clinic. The new-patient form asks for name and date of birth; the insurance form asks for a policy number; the appointment form asks for a date and a provider. You would not mix them, because each form gathers a different kind of record and has different required boxes.
In EDGEBIC, the same idea applies:
| Entity type | What it loads | A mandatory field |
|---|---|---|
| Product | Finished goods, raw materials, WIP | product name |
| Work center | Machines, cells, labor stations | work center name |
| Customer | Customer master records | customer name |
| Sales order | Jobs and demand | product, quantity, reference |
| Routing | The step sequence for a product | end product, step, hours |
| Actuals | Logged hours and pieces | job, work center, date |
Pick "routing" and EDGEBIC shows you the routing fields and applies the two-pass step-wiring logic. Pick "product" and you get product fields and the master-data match-and-reconcile logic instead. The form matches the record.
How EDGEBIC Uses It
The entity type sits at the top of every import mask and is the switch that shapes the rest. It decides the mask's field list, its mandatory-field gate, and the row-by-row logic that turns each line of your file into a saved record. Master data, demand, routings, and actuals each get treatment suited to them.
In practice you build one mask per type and run them in dependency order: products and work centers first, then routings and sales orders that reference them, then actuals. For the field details behind each type see how to build an import mask, and for the outcome of each row once it is processed see the sibling term import row status. Browse more definitions in the manufacturing glossary.
Expert Q&A: Deep Dive
Q: We are standing up a new plant and have spreadsheets for products, machines, customers, routings, and open orders. What order do we import them?
A: Load master data first, then the things that reference it. A safe order is products, then work centers, then customers, then routings, then sales orders, and finally actuals if you are carrying history. Each is its own entity type with its own mask, so you build and run them one at a time. Routings depend on both products and work centers already existing, and sales orders depend on products and customers, so importing in that sequence means the references resolve cleanly. Some masks can auto-create a missing referenced record as a convenience, but a deliberate order gives you cleaner data and clearer error messages if something is off.
Q: Our routing file has both operation steps and material steps mixed together. Is that the wrong entity type?
A: No, that is correct for the routing entity type. A routing import expects both kinds of step in the same file and uses a flag column on each row to tell them apart: rows marked as operations point at a work center, and rows not marked point at a product or component. So a single routing file legitimately mixes machine steps and material steps for the same finished good, and EDGEBIC reads the flag to decide how to treat each row. What you should not do is try to load routings through the product or work center entity type; those are for master records, not for the step sequence that ties them together.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.