Reading the Import Log After a Nightly ERP Run

An unattended import writes one log file per run recording every row's outcome, and reading it takes about ninety seconds: check the row count, check for failures, then check the mix of Created against Updated. In EDGEBIC by User Solutions each row ends as exactly one of four outcomes, and the run's result dialog reports the counts while the log file records each row with the reason for any failure. That review is the only thing standing between a broken export and a plant working to a confident wrong plan.

What gets written

Two artifacts come out of every run.

The result dialog, shown while you are there, with counts per outcome. Useful for an interactive import, absent by the time you read about a nightly one.

One log file per run, in the import log folder under your local application data. It records every row's outcome and the reason for any failure, and files are kept until you delete them. That makes the folder a usable history of your integration in date order, and also something worth pruning occasionally.

The four outcomes

Reused is the outcome that fools people. Leaving matches untouched is the default behavior, so a run that reports every row as Reused and nothing as Updated has found all your records and deliberately changed none of them. Nothing failed. Nothing happened either. If your cycle is meant to refresh data, the update option needs to be on, which is the fix in keeping product masters in sync.

The ninety-second morning review

Three numbers, then a decision.

1. Row count against a normal night. A file that halved usually means the export ran before the source system finished, not that your order book collapsed. This is the check most likely to catch a genuinely broken night, and it needs no interpretation, just a sense of what normal looks like.

2. Any Failed rows, and their reasons. Failures are specific and fixable. The common ones:

3. The mix of Created against Updated. A routine night is mostly updates with a few creates. A night that created everything means a key column moved or an identifier format changed, and you are now building duplicates rather than refreshing records. That one is worth stopping for.

The decision. Whether to let the day's scheduling run proceed on this data. People skip this step, and it is the one that matters. An import that quietly loaded a bad file does not announce itself later: it produces a plan that looks entirely normal and is wrong all day.

Two things the log will not tell you

That the plan is up to date. Imports change data and never schedule. A perfect log with zero failures still leaves yesterday's plan in place until someone runs the scheduler. If your routine is unattended, make the scheduling run part of it explicitly, per scheduling a nightly ERP export import routine.

That the numbers are right. A row that loads cleanly can still be wrong. Setup times that arrived sixty times too large because a minutes conversion factor was missing are a successful import by every measure in the log. This is why the load check matters as much as the log check: a work center showing impossible hours is the visible symptom of a clean import of bad data, and my imported hours came in wrong walks through it.

Reading a routine week

Over a few weeks the logs become a baseline, and the baseline is what makes anomalies obvious.

Because logs are retained until deleted, this history is available without any extra tooling. It is also the reason to prune: a folder holding years of runs makes the recent ones harder to find.

Who reads it

The failure mode that actually bites is not a missing feature, it is an unattended job with no named reader. The logs faithfully record a broken week that nobody opened.

So name the owner, give them the log folder path so the check does not require hunting, and agree what they do when a number looks wrong. If the routine touches masks as well as data, keep a note of mask edits alongside it, since a changed mask explains a changed pattern, which is the argument in keeping a change log of import mask edits. Ownership itself is covered in who owns the ERP import routine on your team.

When you change a mask

Test before the live run rather than discovering the result in tomorrow's log. Run the changed mask against a small file, read the outcomes, confirm they match what you intended, then let the nightly job use it. Testing an import mask change before the live run sets out the procedure, and it is worth following even for a change that looks trivial, because a conversion factor or an update toggle changes every row.

The takeaway

Every import writes one log file per run recording each row as Created, Updated, Reused or Failed, kept until you delete it. Review a nightly run in ninety seconds: compare the row count against normal, read any failure reasons, and check that the Created against Updated mix looks routine, then decide whether today's scheduling should proceed. Remember that a clean log proves the file parsed, not that the numbers are right and not that the plan is current, since imports never schedule. Name the person who reads it. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with an ERP import reconciliation checklist and a monthly ERP to EDGEBIC data audit.