What Is Positional Column Mapping in a Data Import?

Positional column mapping tells an import to read each field from a numbered column position rather than by matching a heading name. It exists because plenty of real source files arrive with no heading row at all, particularly fixed-format extracts from older systems that were designed to be read by a program rather than a person. In EDGEBIC by User Solutions the choice is a single setting on the import mask, and getting it right is the difference between a clean load and a file full of values in the wrong fields.

How it works

An import mask is a saved recipe that remembers which kind of data you are loading, what format the file arrives in, whether the first row holds headings, and how each column in your file maps onto a target field. The mapping grid shows the target field, whether it is mandatory, the source heading it is mapped from, a column number, and an optional numeric conversion factor.

The heading setting flips which of those two mapping columns is in play:

With headings present, the import looks for a named column wherever it happens to sit, so a source system that reorders its output causes no trouble. With headings absent, the import reads position three as position three, whatever now occupies it. That is a real and quiet risk: insert one column upstream and every mapped field after it shifts by one, the run reports success, and the data is wrong. Nothing about that failure announces itself, which is why the setting deserves a moment's thought rather than a reflex.

Two neighboring options usually travel with a headerless file. The delimiter choice tells the import how the columns are separated, and it covers comma, semicolon, tab and space alongside the spreadsheet option for workbook files. See what is a delimiter in data import for that side of the decision. And a quoted-text option handles files whose values are wrapped in quotation marks, which matters when a description legitimately contains the delimiter character.

The per-row conversion factor is independent of both and worth knowing about while you are in the mapping grid: a source column expressed in minutes can be multiplied on the way in so the stored value is in hours, as described in what is a conversion factor in data import.

A concrete example

A planner inherits a nightly text extract from a legacy system. It is comma delimited, it has no heading row, and the first line is already a real record. Its columns, counted in a plain text editor, are:

1. part number
2. description
3. unit of measure
4. lead time in days
5. unit cost

Building the mask means selecting the product entity type, choosing the comma delimiter, setting the mask to treat the first row as data, and then typing column numbers on the mapped fields rather than dragging anything: 1 onto the product identifier, 2 onto the description, 3 onto the unit of measure, 4 onto the lead time, 5 onto the cost. The planner dry-runs ten rows, confirms that the first record is a real part and not the word "part number," and then runs the full file.

Three months later the extract gains a plant code as a new second column. Nothing errors. Descriptions land in the unit of measure field, units of measure land in lead time, and costs land nowhere useful. The run reports created and updated counts that look normal. The only signals are the values themselves looking wrong in the product grid, which is why the recovery habit matters: recount the columns in a text editor, correct the mask, and re-run. Because rows are matched by business key rather than blindly appended, the corrected run updates the same records instead of duplicating them, as described in what is an upsert in data import.

The same file with headings would have shrugged off the new column entirely. That is the whole argument for asking whoever produces the extract to add a heading row.

How EDGEBIC uses it

The setting lives on the mask, so a recurring routine behaves identically every week without anyone remembering a preference. The mask also remembers the last file path and, for workbook files, the worksheet, which is why re-running a saved recipe is two clicks.

Three habits keep positional mapping safe:

• Count columns in a plain text editor, not in a spreadsheet view. Two consecutive delimiters mean an empty column that still occupies a position, and a spreadsheet renders that as a blank cell you can easily skip over when counting.
• Dry-run ten rows on any new or changed mask. Ten rows prove the mapping, and the run results show immediately whether the first row was consumed as labels or read as data.
• Prefer headings whenever you can get them. Positional mapping is a compatibility mode for files you do not control, not a default.

Keep one boundary in mind: mapping choices never affect the plan. An import writes data, and the schedule is recalculated only when the scheduler runs. A mis-mapped file is a data cleanup, not a scheduling emergency, and the row-by-row evidence of what happened sits in the run's log, described in what is an import run log.

The takeaway

Positional column mapping is the right tool for a file with no headings and the wrong tool for a file that has them. Choose it deliberately, count the columns from the raw text, dry-run before you commit, and push for a heading row in any feed you can influence. To see the mapping grid and its options in a working system, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring import terms, read what is an import entity type and what is row-error tolerance in a data import.