Shop Floor Production & Labour Tracking

The problem this solves

NetSuite holds the work order, the assembly bill of materials, the routing and the standard costs. The shop floor holds the reality — who ran which operation, how long it actually took, how many pieces were scrapped at station three, and why the line stood idle for forty minutes on Tuesday. Between the two sits a clipboard.

Paper travellers get filled in at the end of a shift from memory, keyed into NetSuite by an administrator a day or two later, and by the time a work order completion posts, the information is too old to act on. Nobody knows the true state of the floor without walking it. Actual labour hours never make it into the work order at all, so standard versus actual cost variance is a fiction. Scrap gets recorded as a rounding difference at completion rather than attributed to an operation, a reason and an operator, which means the same defect recurs because nothing in the data points at its cause.

Operators are not the obstacle. Asking someone in gloves to navigate a standard NetSuite work order record on a desktop screen is.

What ECOSIRE builds

We build a shop floor terminal that runs in a browser on a tablet or a fixed kiosk on the line, backed by SuiteScript 2.1 server logic that writes to your work orders in real time. It is a NetSuite customisation, not a separate system with a sync — there is no middleware, no external database and no reconciliation job.

The operator terminal

A Suitelet renders a large-target, glove-friendly interface with minimal typing. Operators identify themselves by badge scan, barcode or PIN. The terminal shows the work orders released to their work centre, filtered by location and subsidiary, ordered by scheduled start or priority. Selecting a job shows the operation sequence from the work order routing, the quantity required, the quantity already completed and the assembly item with any attached drawing or instruction file stored on the item record.

From that screen an operator can clock on to an operation, clock off, record good quantity completed, record scrap with a reason code, log downtime against a reason, and add a note. Client SuiteScript handles the scanning and the immediate validation; a RESTlet or Suitelet POST handles the server write, so the transaction is committed to NetSuite as it happens rather than queued for later. Where the floor has patchy wireless coverage, the terminal buffers entries locally and posts them when connectivity returns, with a visible indicator so an operator always knows whether their entry has landed.

What it posts to NetSuite

Operation clock-on and clock-off create labour records against the work order operation, capturing employee, work centre, machine, start time, end time and run versus setup classification. Quantity completion posts work order completion transactions with the correct assembly item, quantity, location and lot or serial numbers where the item is inventory-detail tracked — the terminal prompts for lot or serial capture rather than leaving it to be fixed later. Backflushed components consume against the work order's bill of materials as configured.

Scrap is posted as a discrete quantity against the operation, with a reason code from a custom list you define, attributed to the operator and the machine. Downtime is captured the same way, so a work centre's available time, run time and downtime are all present in the data. A User Event script keeps the work order's derived status, completed quantity and remaining quantity consistent as these postings arrive.

Supervisor view

A separate Suitelet dashboard gives supervisors the floor at a glance: jobs in progress by work centre, who is clocked on to what, quantity completed against schedule, open scrap and downtime events, and jobs that have not started against their scheduled window. Saved searches behind it are yours to modify. Supervisors can reassign a job to a different work centre, correct an operator's entry within a permitted window, and close out an operation.

Corrections are not silent. Any edit to a posted labour, scrap or completion entry writes an audit record showing the original value, the new value, who changed it and when — which is what makes the actual-cost figures defensible when finance asks.

Costing and reporting

Because actual labour hours land against the operation, standard-versus-actual variance becomes real. The solution ships saved searches for labour efficiency by operator and work centre, scrap rate by item, operation and reason, downtime by reason and work centre, and completion attainment against schedule. In OneWorld accounts everything is subsidiary- and location-scoped, so a supervisor at one plant sees their plant.

Roles and permissions are explicit: an operator role restricted to the terminal, a supervisor role with correction rights, and an administrator role. Operators never need — and never get — access to the wider NetSuite record set.

Who this is for

Discrete and batch manufacturers already running work orders and assembly items in NetSuite, with a floor of operators who need to record work as it happens rather than at the end of a shift. It suits shops with a routing of several operations per work order, meaningful scrap that needs attribution, and a real need for actual labour cost rather than standard. Multi-plant OneWorld manufacturers benefit most, because the alternative is a different clipboard convention at every site.

It is not a fit if you complete work orders in a single step with no routing and no labour capture — the native work order completion screen already covers that.

How delivery works

This is built to order. There is no ready-made download.

1. Scoping call. We map your work centres, routings, operation structure, how you want operators identified, which reason codes matter, your lot and serial requirements, and what device the floor will actually use. We look at your sandbox where you can give us access.

2. Fixed quote and specification. You receive a written functional specification covering every script, custom record, field, list, saved search and role we will deliver, with a fixed price and a delivery date. We do not start until you approve it.

3. Build. We develop as an SDF project against your sandbox, using your real assembly items, routings and work centres so the terminal reflects how your floor is actually structured.

4. Install in your sandbox. We deploy to your sandbox as an unmanaged bundle or SDF deployment, run a pilot on one work centre with real operators and the real device, and adjust the interface based on what happens when someone wearing gloves uses it.

5. Production deployment. After sandbox sign-off we deploy to production, configure roles and script deployments, set up the terminals, and hand over the source. You own the SDF project.

6. Support window. A defect-fix support window follows go-live, with the length agreed in the quote. Ongoing support and enhancement are available separately.

Typical lead time from approved quote to production is one working week, depending on the number of work centres, the routing complexity and whether offline buffering is in scope.