Keeping a Change Log of Import Mask Edits

An import mask edit replaces the previous mapping with no version history, so a one-line-per-change log kept beside the masks is what explains a shifted hour total six months later. The application records what each run did through its per-run import log. What it cannot record is why someone changed the mapping, and that is the piece investigations always need.

EDGEBIC by User Solutions reads ERP data through saved import masks, and a mask is deliberately a live configuration rather than a versioned document. That is the right design for something a planner edits by dragging a column heading onto a field. It just leaves one small responsibility on your side, and this post is that responsibility in full.

What is already recorded, and what is not

Worth separating, because teams assume more or less coverage than exists.

The bottom two rows are the whole argument. Everything above them is covered, and covered well: every row of every run comes back as exactly one of Created, Updated, Reused, or Failed, and the log keeps the full audit record. What no automatic record can hold is intent. The schedule change log is a different artifact answering a different question about the plan, not the data interface.

The five fields

Keep it to one line. A change log that takes two minutes to write does not get written.

• Date. So you can correlate it with when the schedule changed shape.
• Mask. Which routine, by its saved name.
• What changed. One clause. "Setup column remapped to the new heading."
• Why. The field that earns its keep.
• How it was proved. The check you ran, in three words.

A worked page looks like this.

Four lines is a realistic year for a stable shop. The March line is the one that pays for the whole exercise.

The edits worth logging

Not every change deserves a line. These do, because each of them changes numbers without changing anything visible.

A conversion factor added or removed. A factor multiplies a numeric column before the value is stored, so adding one silently rescales every affected operation. Minutes to hours is 0.016667, seconds to hours 0.000278, and a standard quoted per lot of 100 becomes per piece with 0.01. The mechanism is in what a conversion factor is. An edit here is the single highest-value log line you will ever write.

A column deliberately left unmapped. An unmapped column is ignored, which makes deliberate omission indistinguishable from an oversight. If the ERP now exports a machine count or an efficiency that your team maintains in the scheduler instead, the reason belongs in writing or someone will helpfully map it.

A key column remapped. The natural key decides whether rows update existing records or create new ones. Get it wrong and a catalog duplicates. This edit should always carry its proof: a ten row test returning Reused rather than Created.

An option toggled. Whether updates overwrite existing records, whether a bad row stops the run or is marked failed and skipped, whether missing products and work centers are auto-created. These change behavior across every future run and leave no trace in the mapping grid. Options are covered in how to set import options for a mask.

An exclusion applied in the export. Filtering a retired code or a status out of the export is invisible from inside the mask, which is exactly why it needs the note.

Where to keep it

Wherever your team already keeps operational notes. The format matters far less than the habit. What does matter is that it sits with the other one-page artifact worth having: the map of which mask reads which export file.

Those two together are what turn an ERP upgrade into an hour of checking rather than a day of discovery, because the first question after an upgrade is always which masks touch the files that changed. Both are covered in what to check after an ERP version upgrade, and the wider set of conventions worth writing down is in documenting your plant's conventions.

What it looks like after two years

Short, which is the point. A stable shop writes three to six lines a year, so two years of history fits on one screen and reads in ninety seconds.

Do not prune it. The temptation is to remove lines describing mappings that have since changed again, but those are exactly the entries that explain a number nobody can otherwise account for. A line from eighteen months ago recording that setup switched to minutes is what tells you the current factor is correct rather than a mistake someone left behind.

One habit is worth adding at the two year mark: read the log before any ERP upgrade. It takes two minutes and it usually surfaces one mapping whose reason no longer applies, such as a conversion factor for a units problem the ERP fixed at the source. Removing a factor that is no longer needed is a five second edit if you know it is there, and an afternoon of arithmetic if you do not.

The habit that makes it stick

Write the line when you save the mask, not at the end of the day. The reason is not discipline, it is accuracy: the why is clear in the moment and vague four hours later, and the why is the only field a log cannot reconstruct.

One more practice pairs with it. Before any mask edit reaches a full file, run it against a small slice and read the counts, which is both the proof column of your log entry and the thing that catches a mistake before it reaches the schedule. That routine is testing an import mask change before the live run.

Bring your current masks and whatever notes exist to a working session. Reconstructing the reasoning behind an existing mapping is a useful exercise in itself, and it usually produces the first four lines of the log. The architecture behind the masks is on the EDGEBIC ERP integration page, and the engine they feed is on the EDGEBIC product overview.