Mapping Your ERP's Units of Measure for Scheduling

Getting units of measure right in an ERP import is a numeric problem, not a labeling one: the schedule multiplies run time by order quantity, so both sides must describe the same physical thing, and any mismatch is corrected with a conversion factor on the column in the import mask rather than by editing the file. A unit error never fails an import. It just moves every date by a clean multiple, which is why it is the most expensive quiet mistake in ERP integration.

EDGEBIC by User Solutions has been reconciling ERP unit conventions since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the same four mismatches account for nearly all of them: minutes against hours, per-lot against per-piece, stocking unit against production unit, and a time value hiding in the wrong field.

Two kinds of unit, and only one of them drives dates

It helps to separate them before you map a single column.

Quantity units describe how much you are making: pieces, cases, pounds, feet. They appear on the order and on the product record.

Time units describe how long an operation takes: hours, minutes, seconds, or a standard quoted per lot of some size. They appear on the routing.

The schedule computes operation hours as setup plus run time multiplied by quantity. Only the numbers matter to that arithmetic. The unit label on the product record is for humans, and it is still worth carrying through, because a planner reading a dispatch list should see the same word the ERP shows. The general concept is covered in what is a unit of measure in manufacturing, and adding one in the application is in how to add a unit of measure.

The conversion factor is the whole mechanism

Every numeric column in an import mask can carry a conversion factor, and the multiplication runs before the value is stored. That single feature handles nearly every unit problem without touching the export file:

Different columns in the same file carry different factors. A routing export with setup in minutes and run quoted per hundred converts both correctly in one pass: 0.016667 on the setup column, 0.01 on the run column.

Because the conversion lives in the saved mask, it applies to every future run automatically. You solve the unit problem once, not weekly. The full option list is in import masks explained.

Mismatch 1: minutes imported as hours

The most common one, and the easiest to spot. A 90-minute operation imported without a factor becomes 90 hours, which is a factor-of-sixty error in the wrong direction. The reverse happens when hours are imported into a system expecting minutes.

The tell is a job that schedules across weeks when the shop knows it is a two-day job, or the opposite. Reconcile one job by hand and the sixty jumps out.

Mismatch 2: a per-lot standard treated as per-piece

Many ERPs quote a standard time against a standard lot: 2.5 hours per 100. Imported as-is into a per-piece field, a 500-piece order costs 1,250 hours.

The fix is a 0.01 factor, but only after you decide whether the lot standard includes setup. If it does, split it before applying the factor, because setup does not scale with quantity and run time does. The combined setup and run time guide walks the split with worked numbers.

Mismatch 3: stocking unit against production unit

This is the one that requires a decision rather than a factor.

Suppose orders arrive in cases of 24 and routings are timed per piece. Two options exist:

• Convert the order quantity to pieces with a factor of 24 on the quantity column. The routing stays per piece.
• Convert the run time to per case by multiplying by 24. The order stays in cases.

Prefer the first. Making the piece the scheduling unit everywhere means the routing needs no adjustment when case sizes change, and the shop floor counts pieces anyway. Purchasing units, stocking units, and pricing units stay in the ERP where they belong, and never need to reach the scheduling import.

Where an operation genuinely runs per sheet or per batch rather than per piece, express it as run time per piece: a 4-up nest at 0.4 hours per sheet is 0.1 hours per piece. One unit through the whole routing keeps the arithmetic auditable.

Mismatch 4: the value landed in the wrong field

Not strictly a unit error, but it looks like one. Run time mapped into the setup field produces a job whose hours do not change with quantity, because setup is charged once. The tell is that a 10-piece job and a 1,000-piece job take the same time.

Check the field mapping before you reach for a factor. The minimum ERP fields EDGEBIC needs lists what each field means.

A short conversion audit

Run this once per new mask, then whenever the export changes shape.

1. Name the unit of every numeric column you are about to map, from the ERP's own documentation or a report header. Do not assume.
2. Pick the scheduling unit, usually the piece, and write it down.
3. Set factors so every mapped column expresses itself in hours and in the scheduling unit.
4. Import, then reconcile one job by hand. Setup plus run time times quantity, compared against the schedule.
5. Spot the multiple. A gap near 60, 100, 1,000, or the case size names the culprit immediately.

Step 5 is why the audit works. Unit errors produce clean multiples, unlike genuine data problems, which produce noise.

Once it is right, it stays right

The factor lives in the saved mask, so it applies on every future import without anyone remembering it. That is what makes the recurring routine short: export, pick the mask, run, read the counts. The rhythm is in the weekly ERP sync routine, and the post-import verification is in the import reconciliation checklist.

With consistent units, the engine can do its job: finite capacity across shifts and machine instances, sequence-dependent setups, lot streaming with transfer batches, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps the engine, and the ERP integration architecture shows the import layer that every ERP uses.

Check your own units

Export one routing file and one order file and bring them to a demo. Naming the unit on every column takes a few minutes and usually surfaces at least one assumption nobody had written down.