A Blank Cell in My Import Wiped a Value: Why, and How to Prevent It

A blank cell is supposed to be preserved on an update, so a wiped value almost always means the row was treated as a new record instead of a match, or the entity type does not reconcile that way at all. Once you know which of those happened, the fix is the natural key or the entity's import model, not the blank cell.

EDGEBIC by User Solutions protects planner-set values on an update: when update existing records is on, a blank source cell falls back to the current stored value rather than overwriting it. That guard runs only on the update path for entities that match by natural key, which is where the confusion starts. This post sits in the EDGEBIC troubleshooting guide and pairs with how to build an import mask and import masks explained.

First, Read the Result Counts

The import result dialog reports created, updated, reused, and failed counts. That single line tells you most of the story. A row you expected to update that shows up in the created count did not match an existing record, and a create is exactly where a blank cell takes a default instead of falling back. Read the counts before you read the data.

Cause 1: The Row Was a Create, Not an Update

Blank-cell preservation only runs when a row matches an existing record and takes the update path. On a create, a blank numeric cell takes the create default, which is zero, because a new record has no stored value to fall back to. The value was not wiped from the existing record; a new record was inserted with the blank field at zero, and the original still exists.

How to tell: the result counts show the row as created, and searching for the item reveals both the original record and a new one with the blank field at zero.

Fix: align the natural key so the row matches. Lookups ignore case, but a name typo, an extra space, or a changed code will miss the match and insert a new record. Correct the key column in the source file and re-import. Then remove the accidental zeroed duplicate.

Cause 2: Update Existing Records Was Off

If update existing records is off, a matching row is reused unchanged rather than updated. That is safe, but it also means an import you intended as an update did nothing, and if the item did not match, it was created with the blank default instead.

How to tell: the counts show reused rows where you expected updates, or created rows for items that already existed.

Fix: turn on update existing records in the mask options. It is available on the reconcilable entity types only: product, work center, customer, and sales order. With it on and a matching key, blank cells fall back to the stored value.

Cause 3: The Entity Does Not Reconcile by Natural Key

Routing and actuals imports do not have an update-with-fallback path, so blank-cell preservation does not apply to them at all.

How to tell: the wiped field is on a routing step or an actuals record, not on a product, work center, customer, or sales order.

Fix, routing: put a real value in every field you care about. A routing re-import wipes each end product's steps and recreates them from the file, so the file is the complete definition of the steps afterward, and a blank hours or setup cell becomes zero. Keep all steps for an end product in one file.

Fix, actuals: an actuals import always overwrites the dates the file carries, which makes re-importing a corrected file safe and non-duplicating. The replace-existing option, when on, additionally clears actuals on dates the file does not cover, making the file the complete record. Leave it off if you only mean to add or correct specific days.

Cause 4: A Create-Path Field on a Reconcilable Entity

Even on a reconcilable entity, the create default applies to fields on a genuinely new record. A new product with a blank cost is created with cost zero, which is intentional: a new record with a blank field is not ambiguous the way an existing one is.

How to tell: the record is genuinely new and the blank field defaulted to zero or empty.

Fix: fill the field for new records. Preservation is for protecting existing values, not for inventing them.

The Reconciliation, in Order

1. Read the result counts. Created where you expected updated points straight to a key mismatch.
2. Check the natural key for typos, spacing, or a changed code that missed the match.
3. Confirm update existing records is on for product, work center, customer, and sales order imports.
4. Remember routing and actuals do not preserve blanks; the file is authoritative for those.
5. Re-import the corrected file and clean up any accidental zeroed duplicates.

Prevention

• Match on a stable key. Import the natural-key column exactly as stored so updates land as updates, not creates.
• Leave a column out entirely rather than blank when you do not want to touch it on a reconcilable update, which sidesteps the question altogether.
• Put every field you care about in routing files, because a re-import defines the steps completely.
• Import one row first and read the counts before running a large file, so a key mismatch surfaces on one record instead of hundreds.

A run that reported rejected rows is a separate matter covered in the import said failed rows, and a routing that came in with the wrong step order is covered in my imported routing came in out of order.