An import mask is a saved recipe for reading a recurring data file: it remembers which kind of record you are loading, what format the file arrives in, whether the first row holds headings, and most importantly how each column in your file maps to a field in the application. In EDGEBIC by User Solutions you build the mask once against a sample file, and every later file of the same shape imports in two clicks, which is what turns a monthly data-loading chore into a routine nobody has to think about.
This entry is part of the EDGEBIC glossary series; for the broader vocabulary of production planning, see the manufacturing glossary.
How an Import Mask Works
The problem a mask solves is that nobody's spreadsheet matches anybody's field names. Your legacy system calls it Part Number; the application calls it product id. Your hours arrive in minutes. Your file has a summary row at the top. None of that is unusual and all of it needs handling every single time a file arrives, unless the handling is saved.
A mask stores that handling. It holds:
- The entity type, meaning what kind of record the rows become. A mask belongs to exactly one.
- The file shape: Excel or CSV, which worksheet, which delimiter, whether the first row is headings, how many rows to skip.
- The field mappings, the heart of it. Each target field gets a source column, either by heading name or by position for files with no header row. Mandatory fields are flagged, and the mask cannot run until they are mapped.
- Conversion factors where the units differ, so a minutes column multiplied by 0.016667 lands as hours.
- The row-error policy, deciding whether a bad row stops the run or is recorded and skipped.
At run time the mask is applied row by row. Each row is matched against existing records by its natural business key, a product by its id, a work center by its id, a holiday by its name and date, and matching is not case sensitive, so a file row reading WIDGET-A finds the existing product Widget-A. Every row then produces exactly one of four outcomes: created, updated, reused, or failed. Nothing is ever half-imported silently. The result dialog shows the counts, and a per-run log file records what happened to every row including the ones the dialog does not display.
A Worked Example
From the documentation's walkthrough: a product spreadsheet exported from a legacy system, arriving weekly.
The planner selects Product as the entity type, clicks Define New, names the mask Weekly Product Sync, and picks the sample .xlsx file, choosing the worksheet. The application reads the column headings and lists them.
Mapping is drag and drop. The heading Part Number from the file is dragged onto the product id row in the field mappings grid. That row is flagged as required, so the mask will not run until it is filled. The remaining fields are mapped the same way, and a conversion factor is set on any column whose units need adjusting.
The mask is saved. The following week, the new file is the same shape with different rows. The planner picks the saved mask, points it at the new file, and runs it. Rows for products that already exist come back as updated or reused; genuinely new part numbers come back as created; a row with a blank part number comes back as failed with the reason recorded.
That second run took two clicks. The first took fifteen minutes. That ratio is the entire argument for masks.
How EDGEBIC Uses Import Masks
A few product specifics are worth holding onto:
- Eight entity types are importable: Product, Workcenter, Customer, SalesOrder, BOR, Actuals, PlantHoliday, and Shift. Shifts and plant holidays being on that list matters more than it sounds, because it means a plant can load a whole year's calendar from a spreadsheet rather than typing it.
- Masks are per file shape, not per file. If two of your suppliers send order files with different layouts, that is two masks, and both can live side by side under the same entity type.
- A blank cell is a value. Depending on how the mask is configured, an empty cell can overwrite a populated field with nothing, which is one of the most common surprises on a first live run and a good reason to test against a copy first.
- Exports do not round-trip. Grid and report exports produce a snapshot of what you see for sharing and analysis. They are deliberately not the import file format, so an exported grid is not a backup you can re-import.
- The log file is the record of truth. The result dialog summarizes; the log has every row. When an import produces a number nobody expects, the log is where the answer is.
Masks are also the honest boundary of the integration story. This is file-based and database-source loading rather than a live native connector to another system, which means your data is exactly as current as your last run and the import cadence is a decision you make deliberately. The upside is that it works with any system capable of producing a spreadsheet. The import masks explainer covers the screens, how to build an import mask walks the first one step by step, and for the vocabulary inside a mask see an import entity type and an upsert in data import.
An import mask is a saved recipe for reading a recurring data file. It remembers which kind of record you are loading, the file format, whether the first row is headings, and above all how each column in your file maps to a field in the application. You build the mask once against a sample file, and every later file of that same shape imports in two clicks with no remapping.
There are eight entity types: Product, Workcenter, Customer, SalesOrder, BOR, Actuals, PlantHoliday, and Shift. A mask belongs to one entity type, so a plant that receives a weekly product file and a nightly order file keeps two masks rather than one. Work center groups, operators, skills, the setup matrix, departments, quotes, and scenarios are maintained in the application rather than imported.
That is a setting on the mask. Imports match existing records by their natural business key, a product by its id, a work center by its id, a holiday by its name and date, and the match is not case sensitive. Every row then resolves to exactly one outcome: created, updated, reused, or failed. The counts appear in the result dialog and every row's outcome is written to a per-run log file.
It depends on how the mask reads the file. A mask mapped against header names survives a reordering, because it looks up the heading text rather than the position. A mask using positional mapping, which is what you need when a file arrives with no header row, reads column three as column three regardless of what now sits there, and a reordering silently loads the wrong data into the wrong field. The way you find out is the result dialog and the log file: a positional mask that has drifted usually produces a burst of failed rows because a text value landed in a numeric field, but the dangerous case is when the swapped columns are the same type and the import succeeds with wrong values. The habit worth forming is to test a mask change against a copy of the file before the live run, and to prefer header mapping whenever the file has headers at all.
No, and the distinction matters when you are setting expectations internally. An import mask reads files: Excel workbooks and CSV files you or your ERP produce, and it can also read from a database source you point it at. It is not a live native connector that watches your ERP and syncs changes as they happen. What that means practically is that your data is as current as your last import run, so the cadence is a decision you make: some plants import products monthly and orders nightly, others do everything on a Monday morning. The upside of the file approach is that it works with any system that can produce a spreadsheet, which in practice is all of them, and it never depends on a vendor keeping an integration alive.
Expert Q&A: Deep Dive
Q: Our ERP export changes column order every few months. Does that break the mask, and how would we find out?
A: It depends on how the mask reads the file. A mask mapped against header names survives a reordering, because it looks up the heading text rather than the position. A mask using positional mapping, which is what you need when a file arrives with no header row, reads column three as column three regardless of what now sits there, and a reordering silently loads the wrong data into the wrong field. The way you find out is the result dialog and the log file: a positional mask that has drifted usually produces a burst of failed rows because a text value landed in a numeric field, but the dangerous case is when the swapped columns are the same type and the import succeeds with wrong values. The habit worth forming is to test a mask change against a copy of the file before the live run, and to prefer header mapping whenever the file has headers at all.
Q: Is an import mask the same thing as a connection to our ERP?
A: No, and the distinction matters when you are setting expectations internally. An import mask reads files: Excel workbooks and CSV files you or your ERP produce, and it can also read from a database source you point it at. It is not a live native connector that watches your ERP and syncs changes as they happen. What that means practically is that your data is as current as your last import run, so the cadence is a decision you make: some plants import products monthly and orders nightly, others do everything on a Monday morning. The upside of the file approach is that it works with any system that can produce a spreadsheet, which in practice is all of them, and it never depends on a vendor keeping an integration alive.
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.