My Imported Hours Came In Wrong: Minutes, Hours, and the Conversion Factor

Imported hours that are 60 times too large or too small almost always come from a units mismatch, not a miscalculation: the source file stores the value in minutes while EDGEBIC stores it in hours, and the import mask did not convert it. The fix is a conversion factor on that field, and confirming it takes one known row.

EDGEBIC by User Solutions stores run time, setup time, queue time, and transit as decimal hours. When a source file keeps any of those in minutes, the mask has to scale the value down before it is saved. This post covers the units traps in a routing or product import; it sits in the EDGEBIC troubleshooting guide and is the companion to how to build an import mask and the mechanics in import masks explained.

First, Confirm the Direction of the Error

A units error has a signature: the number is off by roughly a factor of 60. A 30-minute setup that imports as 30 hours is 60 times too large. A value that was already in hours but got a minutes factor applied comes in 60 times too small. Before changing anything, open one routing you know well and compare a single raw cell against what landed. That tells you which direction to move and which column is at fault. The conversion factor is a per-field property on the mask, applied by the projection layer before the value ever reaches the field that stores it, so the fix is always on the mask row for the guilty column, never in the source file's numbers themselves.

Cause 1: Minutes Left as Hours (No Conversion Factor)

The most common case. The source column holds minutes, the mask maps it straight to an hours field, and no conversion factor is set. A cell reading 30 lands as 30 hours instead of 0.5 hours.

How to tell: the imported value is about 60 times larger than the real time, and the mask row for that field has no conversion factor.

Fix: set the conversion factor to 0.016667 on that field's mask row (one minute is one sixtieth of an hour). The projection layer multiplies the cell by the factor before the value is saved, so 30 minutes becomes 0.5 hours. To convert minutes to hours in general, this factor is the setting to use.

Cause 2: A Factor Applied to a Column Already in Hours

The opposite mistake. A column that already holds hours gets a minutes factor by copy-paste from another field, so a 2-hour step imports as 0.033 hours.

How to tell: the imported value is about 60 times smaller than the real time, and the mask row carries 0.016667 on a field whose source is already in hours.

Fix: clear the conversion factor on that row. A column already in hours needs no factor at all. Set factors only on the columns that genuinely arrive in minutes, and check each numeric field independently, because a single export often mixes units between run time and setup time.

Cause 3: A Truncated Factor

A factor of 0.0167 or 0.017 is a rounded stand-in for one sixtieth, which is 0.0166666 repeating. On small values the drift is invisible; on a large setup it shows.

How to tell: the number is close but consistently a little off, and the discrepancy grows with the size of the value.

Fix: use 0.016667. It is close enough that rounding at the hour level is negligible for scheduling.

Cause 4: A Non-Numeric Cell in a Converted Field

If a text value (a note, a dash, an em-quote) lands in a field that has a conversion factor, the factor is skipped and the cell does not parse as a number. The row may fail rather than import a wrong number.

How to tell: the import log shows a failed row, or the field is empty where you expected a value, and the source cell contains something other than a plain number.

Fix: clean the source cell to a plain decimal. The conversion factor multiplies numeric cells only, including zeros, so a genuine 0 stays 0, but text is not scaled.

The Reconciliation, in Order

1. Compare one known routing raw cell against what imported, to fix the direction and the guilty column.
2. Check each numeric field's conversion factor independently: run hours usually needs none; a minutes column needs 0.016667.
3. Use 0.016667, not a truncated 0.0167, for minute-to-hour conversion.
4. Re-import the corrected file. A routing re-import wipes and recreates each end product's steps from the file, so a corrected re-run replaces the bad values cleanly rather than duplicating steps.
5. Spot-check the result on the same known routing before trusting the run.

Prevention

• Record the source file's units on the mask name (for example "BOR minutes-source") so the next planner knows a factor is required.
• Set the conversion factor once per minutes column and leave hours columns with no factor. Never copy a factor across fields blindly.
• Import one routing first, confirm the numbers, then run the batch. A units error caught on one file is a two-minute fix; caught after a 300-routing import, it means a full corrected re-run.
• Keep the source in a single unit per column. A column that mixes minutes and hours row to row cannot be corrected with one factor.

If the routing came in with the right hours but the wrong sequence instead, that is a different problem covered in my imported routing came in out of order, and a run that reports rejected rows is covered in the import said failed rows.