EDGEBIC How-To

How to Check a Routing's Hours and Cost Totals in EDGEBIC

User Solutions TeamUser Solutions Team
|
6 min read

To check a routing's totals in EDGEBIC, open the BOR tab, select the product's routing, and read the three live figures on the strip above the grid: Estimated Hour per unit, Setup Time, and Total Cost. Estimated Hour per unit sums the Hours Required column, Setup Time sums the Setup Time column, and Total Cost is labor plus material for one unit through the recipe. All three update as you type, so in EDGEBIC by User Solutions they are a running check rather than a report.

This is the review pass you run before a routing goes live. For building the routing itself, see how to build a routing step by step; the full task library is on the EDGEBIC how-to hub.

Before You Start

  • The routing exists and has its steps chained to the end item, so nothing is stranded outside the totals you are about to read.
  • You know whether the site-wide primary hours only rollup is on, because it changes what the two hour totals include. It lives on the Settings tab under Schedule.
  • You know your typical order quantity for this product. The header totals are per unit, and the reconciliation that matters is per order.
  • You know that hours and cost are estimates from the recipe, not a record of what ran. Logged actuals are the comparison, not the source.

The Steps

  1. Open the BOR tab and select the product's routing in the selector. Stay in Data Grid mode, because that is where the grid columns you will reconcile against are visible.
  2. Read the three header totals. They sit above the grid and refresh live.
  3. Reconcile Estimated Hour per unit against the Hours Required column. Add the work center rows only. On a three-step routing of 0.20, 0.50, and 0.30 hours per unit, the total should read 1.
  4. Reconcile Setup Time the same way against the Setup Time column. Steps of 0.50, 1.00, and 0.50 should total 2.
  5. Account for any row that did not contribute. Material rows show N/A in the timing cells and add no hours. Parallel child rows are excluded from both hour totals when primary hours only is on.
  6. Multiply out for a real order. Per step, the plan books setup plus hours per unit times the order quantity. Do this for your usual quantity and check the answer against what you expect the operation to take on the floor.
  7. Read Total Cost as one unit's labor plus material through the routing, and note that it is not reduced by the hours rollup.
  8. Fix anything that does not reconcile at the row, then click Update Standard BOR and watch the totals move by the delta you intended.

What Each Total Sums, and What It Leaves Out

Header totalWhat it sumsWhat it leaves out
Estimated Hour per unitHours Required across the work center steps, per unitMaterial rows, and parallel child rows when primary hours only is on
Setup TimeSetup Time across the steps, charged once per runMaterial rows, and the same parallel child rows
Total CostWork center rates applied to time, plus material costs, for one unitNothing on the effort side: it always reflects full effort

Three things are genuinely not in any of these figures, and looking for them there is the most common cause of a total that seems short. Queue time is a shift-aware buffer after a step rather than machine time. Transit days are travel between steps. Lot streaming shifts when a successor may start rather than how long anything takes. All three change the finish date without changing the hours, which is exactly why they are absent.

How to Check It Worked

Make one deliberate edit and watch the arithmetic. Change a step's Hours Required from 0.50 to 0.40 and Estimated Hour per unit should fall by exactly 0.10. If it does not move, the cell did not commit, and saving now would save the old value.

Then schedule a small test order and read the operation bar on the Job View Gantt. The bar should account for setup plus rate times quantity. A bar that is wildly longer or shorter than the header math predicts is nearly always a unit error on one step rather than a capacity problem, and the classic version is a batch total typed into a per-unit field.

For a routing you inherited rather than built, the honest check is against logged hours. Once a few jobs have run the same steps, compare actual hours per unit to the routing's figure. That comparison is what makes recorded actuals worth collecting, and it is the mechanism by which a routing that was always optimistic finally gets corrected.

Common Mistakes

Reading the per-unit total as an order total. Estimated Hour per unit is one unit. Setup Time is one run. Confusing either with an order figure produces quotes and expectations that are wrong by the order quantity.

Expecting material rows to contribute hours. A component row carries a quantity and a lead time, and its timing cells show N/A because they do not apply. If you want material to look like work, you have modeled it as the wrong kind of row: see how to add a material step to a routing.

Chasing a mirror's missing hours. A synchronized parallel copy runs inside its primary's window, so counting it twice would overstate the per-unit content. That exclusion is the whole point of the rollup setting, explained in how to count only primary hours in job totals.

Expecting Total Cost to fall with the hours rollup. It does not. A second machine committed for the same window is still a real cost, so cost reflects full effort while the hour totals avoid double counting. Both behaviors are correct at once.

Comparing the standard routing's totals to a live job's plan. A scheduled job runs on its own frozen copy, so the two legitimately differ after an engineering change. Read the job's copy on its own tab rather than assuming a fault.

Typing a batch total into Hours Required. This is the error the header total catches fastest, because the figure jumps by a factor of the batch size the moment you leave the cell. The safeguards, including the built-in rate converter, are in how to change the hours on a routing step.

Reviewing the numbers without reviewing the chain. A step nobody points at still contributes to the header totals. Totals are the arithmetic check; the chain is the structural one.

Next Steps

If the hours are right but the split between run and setup is wrong, how to add setup time to a routing step explains why the two behave completely differently as quantity grows. For what every field on the step means before you change one, the bill of routing explained is the concept reference.

The takeaway

A routing's three header totals are the cheapest review you can run: Estimated Hour per unit sums per-unit run time, Setup Time sums the once-per-run preparation, and Total Cost gives one unit's labor plus material. Reconcile each against its grid column, remember that material rows contribute nothing and that parallel mirrors are excluded from hours while cost keeps full effort, then multiply out for a real order quantity before anyone quotes from it. Queue, transit, and overlap change dates rather than hours, so their absence here is correct. See where routings sit in the platform on the EDGEBIC overview, read what your existing routings carry forward on the RMDB to EDGEBIC guide, and continue with how to build a routing step by step and how to change the hours on a routing step.

Expert Q&A: Deep Dive

Q: My header total reads less than the sum of the Hours Required column I can see. Is the total wrong?

A: Almost certainly not. Two kinds of row are on screen but deliberately absent from the hours total. Material rows carry a quantity and a lead time rather than machine hours, and their timing cells show N/A, so they contribute nothing. Parallel child rows, marked with the child glyph under their parent, are excluded when the site-wide primary hours only setting is on, because a synchronized mirror runs inside the primary's window and counting it would inflate the per-unit figure. Add up only the primary work center rows and the total should reconcile exactly. True alternative rows stay counted, and Total Cost always reflects full effort whatever the rollup setting says.

Q: A 100-unit order came back at far more hours than the routing header suggested. Where did the extra time come from?

A: The header is per unit and the order is not. Estimated Hour per unit sums the per-unit run time only, so you multiply it by the order quantity to get run hours. Setup Time is charged once per run and does not scale, so it is added rather than multiplied. On a routing with one hour per unit and two hours of setup, a 100-unit order plans about 102 hours of work before any queue, transit, or overlap effects. Beyond that arithmetic, the plan also reflects queue buffers, transit days, and lot streaming, none of which appear in the header totals because they are gaps rather than machine time.

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

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.

Let's Solve Your Challenges Together