Auto-Calculate Hours is the actuals import option that derives the missing half of a row: hours from pieces, or pieces from hours, using the rate on the operation the row matched. It is on by default, and it is what allows a shop that counts output in units to produce a schedule measured in time without asking operators to record two numbers.
EDGEBIC by User Solutions offers it as a checkbox in the Import Options dialog for an actuals mask. This article defines what it derives, from what, and what the derived figure does and does not mean. For the underlying rate, see the sibling term run time per unit.
How It Works
An actuals row identifies a day's work on one operation: a job number, a work center, a date, and then hours, pieces, or both. Shops differ in which they capture. A machining cell logs hours because the clock is the natural unit. A packing line counts cartons because output is what the operator sees.
The schedule is built in hours, so a piece count has to become time before it can be compared to a plan. Auto-Calculate Hours performs that conversion at import, in both directions:
- Pieces only. Hours are derived by multiplying the piece count by the operation's hours per unit.
- Hours only. Pieces are derived from the same rate in reverse.
- Both supplied. Nothing is derived; both values are stored exactly as the file gave them.
The rate that does the work belongs to the routing step, not to a global setting. Each step carries its own hours per unit for the product it makes on that work center, so the same hundred pieces correctly derives a different number of hours on a saw than on a paint booth.
Turn the option off and a row supplying only one measure stores only that measure. Nothing is invented, and the other side stays empty.
A Concrete Example
Think of a delivery driver's log. Some drivers write down the miles, others write down the drops. Given a route's known average, either number can be turned into the other for a summary. The conversion is honest as long as the average matches how the route is really run, and it drifts the moment the traffic changes and the average does not.
At Acme Industries the packing line reports cartons only. Pack-1 runs Widget-A at 0.05 hours per unit:
| Job | Work center | Date | Pieces in file | Hours in file | Hours stored |
|---|---|---|---|---|---|
| JOB-2026-0107 | Pack-1 | 22 Jul | 120 | blank | 6.0, derived |
| JOB-2026-0107 | Pack-1 | 23 Jul | 90 | blank | 4.5, derived |
| JOB-2026-0107 | CNC-Mill-1 | 22 Jul | blank | 7.5 | 7.5, as supplied |
The packing rows arrive as counts and land as hours the schedule can use. The mill row arrives as hours and is stored untouched, with its piece count derived instead.
How EDGEBIC Uses It
The option exists because forcing every shop to capture the same measure is unrealistic, and because half a schedule's value disappears if output data cannot be compared to a plan. Deriving at import means the capture habit on the floor does not have to change for the plan to stay meaningful.
The important qualification is what a derived figure represents. It is what the standard rate says the work should have taken, so it inherits the accuracy of that standard exactly. Where standards are maintained it is a good estimate. Where they are stale it is a confident restatement of the plan wearing the label of an actual, and comparing it back to the plan will show almost no variance because the two share a source.
That is worth knowing rather than worrying about. A systematic gap between derived hours and observed reality is useful information: it says the standard on that step is wrong by a consistent margin, which is precisely the kind of finding that improves a routing. Sites that care about variance on their constraint work centers usually capture real hours there, through the kiosk or an hours column in the feed, and let derivation cover the rest of the floor.
The option is independent of the completion flag and of the replacement behavior on the same mask. It only decides how a day's numbers are filled in, not whether the operation is finished or which days the file governs.
For running the load, see how to import actuals from a file, and for converting units on the way in see what is a conversion factor in data import. For comparing the result against the plan, see what is planned vs actual hours. Browse more definitions in the manufacturing glossary.
It is an option on an actuals import mask that fills in the missing half of a row. When a day's row supplies only pieces, the hours are derived from the operation's rate; when it supplies only hours, the pieces are derived the same way. It is on by default, so a file that counts output in units still produces hours you can measure a schedule against.
The rate belongs to the operation the row matched, not to a global setting. Every routing step carries hours per unit for the product it makes on that work center, and that figure is what converts between the two measures. Because the rate is per step, the same piece count on two different operations correctly derives different hours.
Nothing is derived, because nothing is missing. Both values are taken from the file exactly as supplied and stored as given. The option only acts on rows where one of the two is absent, which means turning it on cannot alter a complete row.
Derived hours are planned hours in disguise, and that is the whole explanation. The conversion uses the operation's standard rate, so what you get back is how long that many pieces should have taken, not how long they did take. If the real rate on the floor is slower than the standard, whether because the standard is optimistic, the operation has drifted, or the batch had problems, the derived figure will understate the time every single day and the gap will be systematic rather than random. That makes the numbers useful for tracking output but misleading for measuring capacity or variance, because variance against a figure derived from the plan is close to meaningless. If you need honest hours you have to capture them, either through the kiosk or by adding an hours column to the feed. If you cannot, treat the consistent gap as evidence that the standards need revisiting, since a rate that is wrong by the same margin every day is a rate worth correcting.
Not really, because there is only one set of actual hours and everything reads from it. Once a derived figure is stored it is the operation's actual hours for every purpose: progress percentages, remaining work, variance, and what rescheduling treats as already spent. There is no reporting-only copy. The practical way to get what you want is to make the derived numbers trustworthy rather than to isolate them, which means keeping the standard rates on your routing steps close to reality and revisiting them when derived hours and observed hours diverge. A second and simpler option is to supply both columns for the operations where the difference actually matters, typically your constraint work centers, and let derivation cover the rest. That gives you real hours where decisions are made and reasonable estimates everywhere else.
Expert Q&A: Deep Dive
Q: Our operators count pieces and never record hours. The derived hours look consistently low compared with what the floor actually spent. Why?
A: Derived hours are planned hours in disguise, and that is the whole explanation. The conversion uses the operation's standard rate, so what you get back is how long that many pieces should have taken, not how long they did take. If the real rate on the floor is slower than the standard, whether because the standard is optimistic, the operation has drifted, or the batch had problems, the derived figure will understate the time every single day and the gap will be systematic rather than random. That makes the numbers useful for tracking output but misleading for measuring capacity or variance, because variance against a figure derived from the plan is close to meaningless. If you need honest hours you have to capture them, either through the kiosk or by adding an hours column to the feed. If you cannot, treat the consistent gap as evidence that the standards need revisiting, since a rate that is wrong by the same margin every day is a rate worth correcting.
Q: We want the derived hours for reporting but not for driving the schedule. Is that separable?
A: Not really, because there is only one set of actual hours and everything reads from it. Once a derived figure is stored it is the operation's actual hours for every purpose: progress percentages, remaining work, variance, and what rescheduling treats as already spent. There is no reporting-only copy. The practical way to get what you want is to make the derived numbers trustworthy rather than to isolate them, which means keeping the standard rates on your routing steps close to reality and revisiting them when derived hours and observed hours diverge. A second and simpler option is to supply both columns for the operations where the difference actually matters, typically your constraint work centers, and let derivation cover the rest. That gives you real hours where decisions are made and reasonable estimates everywhere else.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.