Testing an Import Mask Change Before the Live Run

Test an import mask change by running it against a ten-row slice with updates turned off, confirming that existing records come back Reused rather than Created, and checking the hour arithmetic on one job you know: only then run the full file. The whole routine takes about four minutes, and it catches the failures that produce a clean run and a wrong schedule.

EDGEBIC by User Solutions imports through saved masks, and mask edits are quick by design: you drag a column heading onto a field and save. Quick edits deserve a quick proof, because the dangerous import failures do not throw errors. They complete successfully with the wrong numbers.

Why a successful run proves nothing on its own

Every row of an import comes back as exactly one of four outcomes: Created, Updated, Reused, or Failed. A result of 500 rows and 0 Failed feels like verification. It is not, because three of the most damaging mistakes produce exactly that result.

• The key column moved. Every row is genuinely new to the system now, so every row is created. Zero failures, and a duplicated catalog.
• A unit changed inside an unchanged heading. Standard time still parses, still lands in the right field, and is now sixty times too large. Zero failures.
• A value landed in the wrong field. Quantity in a date field fails loudly, but hours in a setup field or the reverse imports cleanly. Zero failures.

The counts and the arithmetic together catch all three, which is why the test is two checks rather than one.

The five steps

1. Cut the file to about ten rows. Draw them from records you know already exist, not from new ones, because the point of the test is to see matching behavior. Keep the heading row.

2. Turn updates off. With updates off, a row that matches an existing record comes back Reused and the record is left untouched. That is what makes this safe to run against live data: nothing is overwritten while you are checking the mapping.

3. Run it and read the counts. For a slice of known-existing records you want Reused across the board. Anything else is the signal.

4. Do the arithmetic on one job. Take a part whose operations you know. Three operations at 0.25, 0.40, and 0.10 hours per piece with 1.5 hours of setup on the first, on an order of 200 pieces, totals (0.25 + 0.40 + 0.10) x 200 = 150 run hours plus 1.5 setup, so 151.5. If the import produces that, units and field mapping are both right. If it produces 9,090 you are in minutes. If it produces roughly 2.5 a per-lot standard is being read as per-piece.

5. Turn updates on and run the full file. Then read the counts once more, because the split between Created and Reused on the full file is its own useful signal.

The pre-flight gate you get for free

Before any of this, one class of mistake is caught automatically. The mandatory field check runs against the mask configuration rather than the data, so if a required field is not mapped to any column, the run aborts before it opens the file. Nothing is imported, and the failure names the missing field.

That covers the loud half of mask breakage: a required heading that got renamed cannot silently do damage. It does not cover a required field mapped to the wrong column, which is what step three exists for. The mandatory fields per entity type are listed in which ERP fields EDGEBIC needs to schedule.

Routings need a different test

Routings are the one import that cannot be tested against live data with updates off, because they do not reconcile row by row at all. Operations reference each other, so the import runs in two passes: pass one reads, validates, and buffers every row, and pass two groups by end product, sorts by sequence number, writes the steps, and wires the chain. To make that repeatable, each end product's steps are wiped and recreated once per run.

So test a routing mask change one of two ways:

• Against a scratch product name that appears nowhere else in your data. You get to confirm the two-pass wiring produced a connected chain, then delete it.
• Against one real product you are willing to re-import from a known-good file immediately afterward.

Two things make this less alarming than it sounds. Scheduled jobs are unaffected, because each carries a frozen snapshot of the routing it was planned with, so work in progress does not move. And re-importing the correct file restores the routing exactly, since the wipe-and-recreate is what makes routing imports consistent rather than cumulative. The one caveat is that a wipe regenerates the step identities, so a job you later switch to use the current routing picks up the recreated steps.

The rule that catches most people here: keep all of one product's steps in one file. Split across two runs, the second run's wipe deletes the first run's steps.

Actuals need a chosen job

Actuals overwrite the dates the file carries, which is what makes re-importing a corrected timesheet safe. For a test, that means picking your slice deliberately: use a job and dates you can verify afterward, or a job that is already complete so nothing in the live plan depends on the result. The related option that clears actuals on dates the file does not cover is the one to leave alone during a test. Details are in importing ERP labor transactions as actuals.

Stop on error, or continue

One option shapes what a test tells you. By default a bad row is marked Failed with its reason recorded, and the run continues through the remaining rows, so one bad date never blocks 500 good ones. The alternative aborts the run on the first error.

For a ten-row test, either is fine and continuing is more informative, because you see every problem in one pass rather than one at a time. For the full production run, continuing is almost always right: you want the 498 good rows in and a short list of the two to fix. The setting lives with the other per-mask options in how to set import options for a mask.

Record what the test proved

The proof from step three or four is the last field of a good change log line: "10 rows Reused" or "Job 4412 totals 151.5 hours". It takes five seconds to write and it is the sentence that answers the question in six months. The format is in keeping a change log of import mask edits, and the fuller post-import pass is the import reconciliation checklist.

Bring a mask you are nervous about editing to a working session. Running the ten-row test live is usually the moment the routine stops feeling like process and starts feeling like the obvious thing to do. The architecture is on the EDGEBIC ERP integration page, and the engine the data feeds is on the EDGEBIC product overview.