How a supervisor gets a live plant floor view in ERPNext
A supervisor who needs to know which machines are running, idle or stopped, what material sits at each station and which job cards are open should not have to assemble that picture from several reports. In ERPNext, the plant floor view is meant to present that state visually, with plant floors laid out as areas, machines represented as workstations with status indicators, floor stock shown against each station and processing job cards visible from the same screen. The view is only as current as the transactions behind it: a workstation shows a status change only when someone records it, a job card reflects time logs only after operators submit them, and floor stock is accurate only when material transfers and manufacture entries are posted on time.
That dependency shapes the project. Before any scoping, the team should confirm which plant floor features exist in the ERPNext version they will run, because the visual elements, status labels and how floors and machines are grouped change between releases. Check the current ERPNext documentation and build a test site on the same version and branch as production, then load a realistic set of workstations, operations and open work orders. Ask the implementation partner to demonstrate the screens with that data rather than with a demo site. Feature availability should be written into the statement of work as a verified item, not assumed from marketing material or from this page.
Which floor view option fits your shop floor
This table compares the three realistic ways to show machine status and processing job cards: the standard ERPNext workspace and list views, a plant floor view on the visual interface if your version provides it, and a separate dashboard fed from ERPNext data. Read each row against your own supervisors' needs, and confirm the items in the final row before you commit to a design.
| Option | What it reads and who it suits | Maintenance effort and main trade-off |
|---|---|---|
| Standard workspace and list views | Workstation, Job Card and Stock Entry records through built-in list and report views. Suits small floors where supervisors already work in the ERPNext desk. | Lowest build effort because it uses core screens. Trade-off: status is shown as records and filters, not as a visual picture of each machine. |
| Plant floor view on the visual interface | Plant floors, workstations and their status illustrations, with floor stock and open job cards shown in the visual layout. Suits floors where supervisors need a glance-level view at a shared screen. | Layout, status rules and icons must be configured and kept in step with workstation changes. Trade-off: depends on the features your ERPNext version provides, so confirm them before design. |
| Separate dashboard fed from ERPNext | Data pulled through reports or the REST API into a tool such as a BI or monitoring dashboard, combined with machine signals where they exist. Suits multi-site groups or teams that already run a dashboard platform. | Highest effort: an integration, access control and refresh schedule to build and operate. Trade-off: flexible visuals, but a second system to secure, monitor and keep in sync. |
| Data freshness | Confirm whether each option refreshes on page load, through realtime updates or on a schedule, and how often job card and stock changes appear. | Ask the vendor or check the release notes for your version. Freshness determines whether supervisors trust the view during a shift. |
| Machine status source | Confirm whether status comes from manual entries, Downtime Entries or machine connectivity, since ERPNext records what is entered into it. | If status is typed in by operators, plan who updates it and when. Automatic signals need a separate integration with the machines. |
| Access and visibility | Confirm which roles can see floor views, job card costs and stock quantities, and whether a shared shop floor screen can be restricted to status only. | Shared screens need a restricted role or a read-only dashboard account. Review these roles when workstations or users change. |
| Version support | Confirm the ERPNext version in use, since the plant floor view and its features depend on it. Check the frappe/erpnext releases page for minor changes that affect your option. | Upgrades can change layouts and fields. Test the view on a staging site before each major version move. |
| Ownership of changes | Decide who maintains layouts, status rules and dashboard queries: the internal ERP team, a partner or both. | Each change to a workstation or routing can affect the view. Agree on a change owner and a test step before go-live. |
What each role needs from the floor view
Supervisors ask which jobs are running, which are waiting for material, and which machines are idle or behind plan. They mostly read work orders, job cards, and workstation status, and they reassign or sequence work rather than rewrite production records. Their picture of the floor depends on job cards being opened and closed on time by operators, so the view is only as current as the time logs behind it.
- Records they touch: Work Orders, Job Cards per operation, and Workstations, mainly to read progress and status.
- What they should see: Open and overdue job cards by workstation, material availability for each operation, and quantities completed against planned.
- What they should edit: Sequencing and assignment decisions, with changes to planned dates kept to roles your process allows.
- Access rule to confirm: Whether supervisors can change job card quantities or only comment, and whether they hold the Manufacturing User or Manufacturing Manager role.
- Check before rollout: Confirm with your ERPNext version which floor view screens exist, since visual machine status is not a confirmed standard feature.
Operators ask what they should run next, which material to pull, and how to record start, stop, and output. They touch job cards at the point of work, so the screen they use must be narrow and quick. Their entries drive time, quantity, and downtime data for everyone else, which makes their permissions the most sensitive to scope.
- Records they touch: Job Cards for their workstation, Time Logs, and material transfer requests tied to the operation.
- What they should see: Only the jobs assigned to their workstation, with the drawing, operation steps, and quantities.
- What they should edit: Start and stop times, completed quantity, and operation status on job cards they are assigned to.
- Access rule: Operators should not hold roles that alter BOMs, routings, costs, or workstation rates. Confirm that a restricted operator role can be scoped to their own job cards.
- Check before rollout: Test how a single operator logs a stoppage and whether that entry reaches the downtime records used by maintenance.
Maintenance planners ask which machines stop most, how long they stay down, and when preventive work can fit between jobs. Their work depends on downtime and workstation records, which they should read in full and edit only for maintenance-specific fields. They need to see the effect of a stopped machine on the schedule without changing production quantities.
- Records they touch: Downtime Entries, Workstations (status and availability), and job cards affected by a stoppage.
- What they should see: Downtime by workstation and reason, the open jobs that depend on a machine, and planned maintenance windows.
- What they should edit: Downtime reasons, maintenance notes, and workstation availability, but not finished quantities on job cards.
- Access rule: Use a dedicated maintenance role that can write downtime entries without gaining rights over stock or costing documents.
- Check before rollout: Confirm which maintenance fields are native to your ERPNext version and which need a custom field or report built during implementation.
Finance and costing staff ask what each job costs in labour and machine time, whether scrap or downtime is distorting unit cost, and whether the floor records match stock and accounting entries. They read more than they write, and they need the floor view to reconcile to the ledger rather than replace it. Their questions are about the period and the cost basis, not the minute-by-minute floor state.
- Records they touch: Workstation rates and costs, Job Cards with time and quantity, and stock entries that consume and produce material.
- What they should see: Time and material booked per job card, scrap and downtime totals by workstation, and variance against the costing assumption.
- What they should edit: Workstation hourly rates and costing parameters, under controlled change, not on the floor screen.
- Access rule: Restrict rate changes and cost fields to finance roles, and log changes to them. Confirm which rate fields are editable by which role in your setup.
- Check before rollout: Reconcile a sample of closed job cards against stock and cost reports before relying on the view for costing decisions.
How to set up workstations and job cards for the floor view
This sequence takes a test ERPNext site from a confirmed version and clean master data to working workstations, job cards and stock movements that a supervisor can read on the floor view. Each step ends with a check so the team knows the data is fit for the next step.
Confirm the ERPNext version and manufacturing features
The implementation lead and an ERPNext administrator install the version your team intends to run on a separate test site, following the install method chosen for the project. They confirm that the Manufacturing module, Workstation, Operation, Work Order and Job Card doctypes and the visual plant floor view are present in that exact version, and they check the version against the supported versions page before go-live planning. Do not rely on a feature list from a blog or older guide. The step is done when a test user can open each of these doctypes from the desk and the team has written down the version number.
Clean the item and workstation master data
The manufacturing lead and the data owner export current item, BOM and machine lists and remove duplicate items, retired machines, and unit-of-measure variants that will confuse stock and job card entries. Each machine receives one workstation record with a unique, stable name that the floor will recognize. Agree the naming convention for items, warehouses and workstations in writing before any import. The check is a short reconciliation: the count of active machines on the shop floor matches the count of enabled workstations on the test site, and every item used in an open work order has exactly one valid stock unit.
Load workstations and working hours through templates
An ERPNext administrator loads workstations using the Data Import tool with the downloadable template, starting with a small batch so errors are easy to trace. The import of working hours uses the Workstation Type and working hour templates where the shift pattern is shared by several machines, so that a change to a shift is made once. Costs per hour are entered only after finance confirms the rates. The check is a filtered list of workstations showing the expected working hours and hourly rates for each machine, sampled against the shop floor schedule by a supervisor.
Configure operations, routings and job card rules
The manufacturing lead defines each Operation once, links it to the workstation that performs it, and builds routings from those operations for the products on the test list. Work orders are then created from a BOM and a routing, which generates job cards per operation and workstation. The administrator decides who may start and complete a job card and which fields operators must fill in. The check is a test work order whose job cards appear under the correct workstation with the expected sequence of operations and planned quantities.
Set up time logging and job card execution
A trained operator, working on the test site, starts and stops a job card using the time log entries, records completed quantity, and submits the card. The administrator confirms that the actual time, quantity and workstation are recorded against the correct job card and that the work order progress updates. Test a split shift and an interrupted run, because these cases are where time logs most often produce overlapping or open entries. The check is a report of the test job cards showing actual time and completed quantity that match what the operator recorded on paper or the test script.
Connect downtime and stock entry practices
The production supervisor and the stores lead agree how stoppages are recorded through Downtime Entries against the workstation, and how material is issued to the floor through stock entries for manufacture and material transfer for manufacture. Confirm which warehouse holds floor stock, whether it is a dedicated warehouse per line, and how returns and scrap are posted. Document these rules as a one-page floor procedure. The check is a test sequence: one stoppage, one material transfer and one scrap entry, each traced from the floor view to the stock ledger and the downtime report without duplicate or missing entries.
Test the floor view with real shop floor scenarios
The project team runs the floor view through scenarios taken from the actual shop floor, such as a machine breakdown mid-job, a rush order that reorders the queue, a material shortage at one workstation and a shift change. Supervisors compare what the view shows for each machine status, floor stock quantity and open job card against what they see on the floor at the same time. Record each mismatch, fix the source data or configuration, and repeat the scenario. The step is complete when the supervisors sign off in writing that the view matches the floor for every scenario on the test list, and the open issues are logged for the go-live decision.
Securing shop floor data in ERPNext
A plant floor view puts live job card, time and stock data in front of supervisors and operators, so it inherits every access and integrity question the rest of ERPNext raises. The six controls below cover who can change what, how people sign in, where the site sits on the network, and how the job card history is protected and proven.
Role-based access for operators
Operators should record time, start and finish job cards, and report scrap, but they should not change item costing, workstation rates, BOM structure or other master data. Map each floor role to the minimum DocTypes and permission levels it needs, then test the plant floor view with an operator account before go-live. Confirm the role and permission setup in the ERPNext roles and permissions documentation, and check field-level restrictions for cost fields.
Login through existing identity
Where the organization already runs Active Directory or OpenLDAP, ERPNext can authenticate floor users against it and map directory groups to ERPNext roles at each login. This removes separate shop floor passwords that tend to be shared on terminals. Confirm the SSL/TLS options, group mapping behavior and what happens to accounts when a person leaves the directory. Social login is an alternative only where an approved provider is already in use.
No unsupported custom logic on shared benches
Custom server logic that enforces floor rules, such as blocking a job card from closing without a quality check, depends on server scripts. Since version 15 these are disabled by default, and Frappe Cloud public shared benches do not allow them. Decide early whether floor rules need a custom app on infrastructure you control, and confirm the server script setting in the Frappe documentation before promising any rule to supervisors.
Backups and restore tests for job history
Job card history, time logs and stock entries live in the site database, and a restore that has never been tested is not a recovery plan. Define the recovery point the plant accepts, schedule backups for the database and the files, and restore into a separate environment to check that job cards, workstation records and stock balances reconcile. Ask the implementer to document who runs the restore and how long it takes on your hardware.
Audit trail for time and stock changes
Supervisors need to know who edited a time log or moved stock after a job card was submitted, and why. Confirm which DocTypes keep version history in your ERPNext release, how cancelled and amended documents appear, and whether the audit view is enough for your quality or regulatory reviews. Where records must be signed or immutable, confirm the requirement with your quality team before relying on ERPNext alone.
Network placement relative to plant systems
The ERPNext site should sit in the business network or a DMZ, not on the control network next to PLCs and SCADA servers. Floor terminals reach it over a restricted path, and any integration with machine data flows through a controlled gateway with defined ports and accounts. Review this placement against the ISA/IEC 62443 zone and conduit approach with your OT security team, and confirm the architecture with them before the design is fixed.
Where OT security standards apply to a floor view
A plant floor view in ERPNext should be treated as a records and reporting layer, not a control system. ERPNext holds production data such as work orders, job card status, time logs and workstation records. It does not run machines, and a floor view built on it should never send commands to a PLC, SCADA system or machine controller, nor sit inside the control network. Keep the view on the business network, feed it data through a one-way or tightly scoped interface, and have the OT team confirm where that boundary sits before any build starts.
The ISA/IEC 62443 series is the main reference for securing industrial automation and control systems. Its four groups cover general concepts, policies and procedures for asset owners, system requirements, and component requirements. For an ERPNext floor view, the asset owner's security program (described in ANSI/ISA-62443-2-1-2024) and the security risk assessment for system design (ANSI/ISA-62443-3-2-2020) decide what data crosses the boundary, which roles can see it, and how the integration is monitored. NIST SP 800-82 Rev. 3, the guide to operational technology security published in September 2023, offers a complementary view that also weighs OT performance, reliability and safety. Ask your OT security lead which of these documents your organization already follows before writing integration requirements.
Regulation may also apply. NIS2 Annex II lists manufacturing as a critical sector, so organizations in scope should confirm their reporting and risk management obligations with counsel rather than assume a floor dashboard falls outside them. If the view is tied to machine connectivity, the Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and includes an essential requirement that machinery be protected so that connecting another or remote device does not lead to a hazardous situation. That requirement belongs in the design review with the machine builder and the integrator, not after go-live.
What to confirm in your ERPNext version before committing
The plant floor view depends on features that vary by release, deployment model and site layout. Confirm each item below in the current documentation and a proof of concept on your own data before you commit budget or scope.
Standard visuals in your version
Confirm which plant floor and machine status visuals ship in your target ERPNext release and which are add-ons or custom work. Check whether the workstation illustrations, floor layouts and job card panels you need are part of the standard release or need a custom app. Record the exact version you will run, since the supported lines receive frequent minor releases and visual behavior can change between them.
How machine status is set
Decide whether status comes from a supervisor action, from time logs recorded against job cards, or from an external machine feed. Each source has different ownership and error rates. Ask which status values the standard release supports, whether a stoppage can be recorded without a job card, and who is accountable for keeping the status current on each shift.
Real-time updates or scheduled refresh
Confirm whether the view updates live or refreshes on a timer, and how long a change takes to appear for a supervisor on another screen. A scheduled refresh may be acceptable for a planning board but not for stoppage response. Test the refresh behavior under the background job and scheduler configuration you plan to run in production.
Sizing for workstations and users
Ask the vendor or community which numbers of workstations, concurrent users and open job cards the site was sized for, then verify with a load test on your own data volumes. Floor screens often poll the same records from many devices, so count them as concurrent users. Plan the database, Redis and worker capacity from those figures rather than from the default demo setup.
Server script limits on shared hosting
Custom visuals or status logic that run as server scripts need the server_script_enabled setting, which is disabled by default from version 15. Frappe Cloud public shared benches do not allow server scripts, so a custom view built that way cannot run there. Confirm the hosting model first, then decide whether the logic belongs in a custom app on infrastructure you control.
Multi-company and multi-site behavior
Check how the plant floor view filters workstations, floor stock and job cards when one installation holds several companies or when you run several sites. Confirm that a supervisor sees only the plants they are permitted to see, and that the same workstation names do not collide across companies. Test role and user permission restrictions with real supervisor accounts before rollout.
What does a plant floor view cost and how long does it take?
Does ERPNext itself cost money for a plant floor view?
The software is free to use, but the work to configure the plant floor view is not. ERPNext is open source, and the ERPNext pricing page states that self-hosting ERPNext is free. If you host on Frappe Cloud instead, the pricing page lists shared site hosting from 5 US dollars per month, shared servers from 20 US dollars per month and dedicated servers from 125 US dollars per month. Those hosting figures are the only recurring platform amounts we can point to here. Whatever you host, your main costs are people: the time to design workstations, job card flows and floor stock views, plus testing. Ask any provider to split the quote into build effort and hosting so you can compare the options cleanly.
What drives the cost of a plant floor view up or down?
Scope drives most of the effort. The main factors are:
- The number of workstations and plant floors, since each machine needs its status, capacity and job card behavior checked.
- How deeply job cards and downtime are used, for example whether operators log time per operation or only completion.
- Custom visuals, such as machine status illustrations beyond the standard views.
- Data cleanup, because workstation names, item codes and open work orders often need correction before the screens are useful.
- Integration with machine or MES data, which adds interface design, error handling and monitoring.
- Testing with floor staff, which takes time on the shop floor and cannot be skipped if the screens are meant for daily use.
A smaller site using standard views will cost far less than a multi-floor plant with live machine feeds.
How long does a plant floor view take to build?
Duration depends on the same drivers as cost, so no single timeline applies to every plant. A realistic plan separates discovery, build, data cleanup, floor testing and go-live. Discovery covers floor walks and a review of how supervisors read the floor today. Build covers workstations, floor stock and job card views. Data cleanup often runs in parallel and can become the longest step. Ask for a named schedule with milestones in the written scope, and ask which steps depend on client input such as data owners or test access. Treat any timeline given before a floor walk as provisional.
What is one-time work and what recurs after go-live?
The initial build is one-time, but the view needs care after it goes live. Recurring work includes:
- ERPNext upgrades and their minor releases, which can change screens and job card behavior, so each release should be tested on the plant floor views.
- Data maintenance, such as adding workstations when machines are installed and retiring old ones.
- Changes to job card steps, downtime reasons and floor layouts as the plant evolves.
- Support, which can be handled by your own team or through a support retainer agreed in writing.
Ask any provider to state which items are included in the fixed-scope price and which would be quoted separately.
Can our internal team build a plant floor view without a partner?
Often yes, if your team already runs ERPNext manufacturing and has someone who knows workstations, work orders and job cards well. The harder parts are usually the people and data side: getting supervisors to agree on what the screens should show, cleaning master data, and testing with operators during a shift. Internal teams should also plan for upgrades, since the Frappe support versions page lists when each version reaches end of life and your release plan must follow it. Partners are most useful when the scope spans several plants, machine integrations or a tight go-live date. Certified partners are available for ERPNext implementation according to the ERPNext pricing page.
What does the client need to provide for this work?
The project depends on client time and access. Plan for:
- Floor walks with the supervisor and operators, so the build reflects real stations and handoffs.
- Named master data owners for workstations, items, operations and downtime reasons who can answer questions quickly.
- A test site or test company in ERPNext where new screens can be checked without touching live orders.
- A named supervisor who signs off acceptance against agreed test cases.
- Access to any machine or MES data source, including credentials and network paths, if integration is in scope.
Ask the provider to list these inputs in the written scope so delays are visible early.
What should we ask for in a fixed-scope quote for a plant floor view?
A fixed-scope quote should be specific enough that you could check the deliverables after go-live. Ask for:
- A list of plant floors, workstations and machines in scope, with the status information each screen shows.
- The job card and downtime features covered, and which are excluded.
- Whether custom visuals are included and how many screens they cover.
- Data cleanup responsibilities, split between client and provider.
- Any machine or MES integration, with the data fields and error handling described.
- The testing approach, the acceptance criteria and the named supervisor who signs off.
- The timeline with milestones, and the assumptions behind it.
- Post-go-live support terms, upgrade handling and any retainer options.
DeployOpen agrees scope, deliverables and timelines in writing before work starts and gives a quote from that written scope.
Which checks should happen before we approve the build?
Before approval, check that the design matches how supervisors actually run the floor. Confirm that each workstation shows the status states your operators use, that floor stock views match physical locations, and that job cards reflect the operations on your routings. Ask how downtime is recorded and whether the screens reflect those entries. Confirm the test plan covers normal shifts, a stopped machine and a changed job card. Finally, confirm which ERPNext version the screens target, because the Frappe support versions page lists versions with set end-of-life dates and the release process will follow the version you choose.
How DeployOpen scopes and delivers a plant floor view
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For the ERPNext plant floor view for machines and job cards, we start from the workstations, job cards and stock movements your supervisors already work with, then build the visual layer on top of them.
How we scope
- Map which plant floors, workstations and job card operations the supervisor view must show.
- Agree which machine status signals come from ERPNext records and which need manual entry.
- Confirm the written scope, deliverables and timeline with you before any build work starts.
How we build
- Configure workstations, floor warehouses and job card statuses in your ERPNext instance first.
- Build the visual layout and status illustrations with custom configuration rather than a forked codebase.
- Test job card transitions and floor stock views with your supervisors using a staging copy of your data.
How we hand over
- Document the workstation setup, status meanings, roles and permissions behind the plant floor view.
- Walk your administrators and supervisors through daily use, updates and what to check after an upgrade.
- Provide the configuration exports and build notes your own team needs to maintain the view.
How we support
- Offer ongoing support, upgrades and maintenance as a retainer after handover, if you want it.
- Review the plant floor view when you move between ERPNext major versions and plan the upgrade path.
- Confirm with us during scoping which support level fits your shop floor hours and change process.
