How many orders can run on one timer?

No fixed limit. Most plants land on 2–4 orders on the same timer in practice; the screen handles more if your work genuinely groups that way.

Does each order get its own consumption?

Yes — materials are attributed to their own order. Only the operator's time is shared across the run. Consumption follows the order it belongs to.

Can the split be adjusted manually?

No. The split is calculated from the planned-runtime ratio and posted as such. If the ratio is wrong for a particular run, fix it at the source — the routing — so every future shared run is correct too.

Shop Floor Execution

uShopFloor

From paper and confusion to clarity on the floor.

Many shop floor environments still rely on paper, disconnected tools, or unclear instructions. uShopFloor translates planning into clear, executable tasks designed for gloves, noise and real environments. The interface is intentionally simple — no training should be required. Inline quality checks, materials consumption, machine status and issue capture all happen on the same screen the operator is using anyway — so the loop between planning and execution stays closed.

uShopFloor order dashboard with shift KPIs and queued and running order cards

Functionalities · 9

uShopFloor · Concurrent Orders

One run, several orders.

Plenty of work serves more than one order at once — an oven cycle baking parts for three production orders, a CNC nest cutting two, a single mix feeding four. uShopFloor lets an operator open the orders together on one timer. When the run stops, the time is divided across the orders in proportion to their planned runtimes — so each order carries the cost it actually consumed, not whichever was tapped first.

Stack orders on one timer

Open two or more production orders together. One start, one stop. The screen shows them all running under the same shared timer.

Time split by plan ratio

When the timer stops, runtime is allocated to each order in proportion to its planned runtime. A 20-minute order gets twice the share of a 10-minute order. The operator does no maths.

Honest cost on each order

Per-order time posts to Business Central against its own production order. Shared runs stop hiding behind one order; costing stays attributable.

What you see

Shared runs, attributed honestly.

A lot of plant work is shared by design: one oven cycle for three products, one nesting plate for two orders, one mix that serves four. The old options are both bad — pick one order and log everything to it, or stop and restart the timer for every swap. uShopFloor lets the operator run the orders together. At the end, the system splits the time across the orders by the ratio of their planned runtimes and posts each share to its own production order. Cost stays where it belongs; the operator does nothing extra.

Open multiple production orders on a single shared timer
Total runtime split across orders by planned-runtime ratio
Per-order time and cost posted to Business Central separately
Useful for batch processes, oven cycles, nested cuts, shared setups
Operator never logs a manual split
Audit trail records the ratio applied to every shared run

uShopFloor order detail with operation list, live run timer and output actions

When this matters

Signals you'd reach for this.

Shared runs land on one order

A two-hour oven cycle that served three orders gets logged to one. The other two look free; the costing is fiction.

Operators stop and restart to swap orders

When the system insists on one order per timer, operators stop a perfectly fine run just to log the swap. Time gets lost in the gaps.

"Whichever order I tapped first"

When the system has no way to share time, attribution depends on tap order. The numbers tell you who was first, not who used the capacity.

Batch costing is averaged in a spreadsheet

A monthly spreadsheet that retroactively splits batch time is creative writing. The split should happen at the source.

FAQ

The questions everyone asks first.

Still wondering? Ask us directly →

Each order on the shared timer has a planned runtime from its routing. The actual runtime is divided across the orders in proportion to that planned ratio. An order planned at 20 minutes and one planned at 10 share an actual 30 minutes as 20 and 10.

See uShopFloor in a 30-minute demo.

A real screen-share with someone who built it. No slides.

The uTools suite