ERPNext work orders and job cards guide

How ERPNext work orders and job cards run production on the shop floor

If you are a production manager or planner, the goal of this section is simple: released orders should reach the floor with material and time that you can trace back to the order. In ERPNext, a work order is created from a BOM for a specific item and quantity, and it carries the planned operations, the warehouses for raw materials and finished goods, and the status that tells the floor what may start. Each operation then becomes one or more *job cards*, which are the floor-level documents that operators open at a workstation. Before you go live, confirm with your own configuration which operations, workstations and BOM versions your team will use, because the work order inherits them. Changing a BOM after orders are released does not reach those orders, so decide how your team handles open orders when a BOM is revised.

Material moves to the floor through a *material transfer for manufacture* stock entry against the work order, which records what left the store for production. Consumption and the finished output are then recorded through manufacture entries, and job card time logs capture the minutes or hours each operator spends on each operation. These entries are what drive progress per operation and the cost that the work order accumulates, so the quality of the data depends on whether operators actually log time and whether store staff transfer the correct quantities. Ask the implementation team to agree on who posts each entry, when, and what happens to partial quantities and rework. Verify the setup with a pilot order that runs through every operation before any production schedule depends on it.

Work orders and job cards earn their setup cost when several operations run in sequence, when workstations are shared between orders, or when you need operator time captured against a specific order. A single-step assembly that is finished in one stock entry usually does not need them, and a simple stock entry is the faster choice. The open-source ERPNext code is licensed under GPL-3.0 and built on the Frappe Framework, so you can review the documented behavior in the repository and the release notes before committing to a process. Plan the process around your shop floor, and confirm each feature against the version you run, since workstation and operation handling changes between major releases.

Which ERPNext deployment and configuration fits your shop floor

A single-company instance with one plant is the simplest case. Work orders, BOMs, workstations and operations are defined once and shared across the whole site. When more than one legal entity or plant uses the same ERPNext site, the company field on each work order, BOM and workstation must be set correctly, and the warehouses used for material transfer must belong to the right company. Stock and accounting boundaries follow the company, so a mistake here moves cost and stock into the wrong ledger.

Company on every record: Confirm that BOMs, work orders and job cards carry the intended company before any production entries are made.
Shared versus separate sites: Multi-company setups share one site, while separate plants may justify separate sites. Decide this with your finance and IT teams before configuration.
Warehouse design: Each company needs its own work-in-progress and finished goods warehouses so material transfer for manufacture posts to the right place.
Access restrictions: Use user permissions to limit which company's work orders a shop floor user can see.
Hosting limits: Frappe Cloud shared hosting is a managed option, but Frappe's warranty coverage depends on a matching support plan and listed version. Confirm with Frappe how multi-company customizations are supported on a shared bench.

Confirm the company structure, warehouse map and permission model in writing before the first work order is created.",

Work order and job card options and when each fits

This table compares the main ways to create work orders, job cards, material transfers and time logs in ERPNext, with the effect each choice has on stock and costing. Read each row as a decision: find the option that matches your shop floor, then check the items in the last column against the ERPNext version you run before you commit.

Decision	Option and when it fits	Effect on stock and costing	Verify in your version
Work order origin	Manual work order suits one-off or small runs, rework and ad hoc builds where no Production Plan exists	Each order carries its own BOM, planned quantities and costing, so variance is traced to that order only	Confirm which BOM and operation fields are copied from the BOM into the order
Work order origin	Production Plan suits repeat demand driven by sales orders or material requests across many items	Plan generates orders in bulk, so raw material shortages surface before release, and costs roll up per order	Check how sub-assembly orders are created and whether plan quantities can be edited after submission
Job card creation	Automatic job cards per operation suit routings with several workstations and supervisors who track progress by step	Each operation carries its own time and cost, so labour and overhead are allocated per step	Confirm the setting that creates job cards on work order submission and whether it applies to all operations
Job card creation	On-demand job cards suit short jobs, single-operation items or shops that release cards only when a station is free	Costs post only when cards are created, so open work in progress is less visible until cards exist	Test how unstarted operations appear in reports and whether planned time is still captured
Material transfer	One Material Transfer for Manufacture entry suits single-stage production with a short bill of materials and a central store	All components move at once, so stock leaves the warehouse before operations start and valuation posts in one step	Check whether partial transfers are allowed and how returns to stock are recorded
Material transfer	Transfers per operation suit multi-step lines where components are consumed at different stations or in different warehouses	Stock moves follow the operation, so work in progress sits at each workstation and cost is tracked by step	Confirm the source warehouse field on each operation and how over-issue is blocked or reported
Time logs	Time logs captured at the workstation suit shops that scan or start and stop jobs at the machine, giving accurate actual times	Actual time feeds job card costing and overhead absorption, which changes variance on the work order	Verify how overlapping logs, paused jobs and logs without a completed quantity are handled
Time logs	Supervisor-entered time suits manual or assembly work with no terminal, accepting lower precision in exchange for lower setup effort	Totals still post to cost, but errors in entry flow directly into labour variance and product cost	Check who can edit or submit time logs and whether an audit trail is kept for changes
Progress tracking	Tracking progress per operation suits multi-step items where partial completion must be visible to planning and sales	Completed quantity by operation drives partial finished goods receipt and scrap entries, so the timing of postings changes	Confirm how the completed quantity field interacts with scrap and with the final operation on the work order

How to set up work orders and job cards in ERPNext

This sequence takes a manufacturer from a confirmed ERPNext installation to a closed work order, with workstations, operations, warehouses and time logs checked against the stock ledger at each stage.

Confirm the ERPNext version and hosting
The implementation lead records the ERPNext major version, the hosting model (Frappe Cloud, Docker Compose or a bench install on your own servers) and whether the site is a production or evaluation instance. Confirm the version is one Frappe still lists as supported on its supported versions page, since warranty coverage depends on running a listed version. Check that Server Scripts and any custom apps are available on the chosen hosting, because some shared hosting does not allow them. The step is complete when the version, hosting and support position are written into the project record.
Define workstations and operations
The manufacturing engineer creates Workstation records with their working hours and costs, then defines Operation masters for each process step such as cutting, welding or assembly. Each operation is linked to its default workstation so job cards can later be routed automatically. Ask the shop floor supervisor to confirm which machines are shared and which operations can run in parallel, because this determines capacity later. The step is complete when every operation in the routing has a named workstation and a costed hourly rate.
Build the BOM with its operations
The engineer creates or verifies the Bill of Materials for the finished item and enables the operations section so each operation, workstation and time per unit is captured on the BOM. Confirm that sub-assemblies have their own active BOMs and that raw materials carry the correct stock units. Run a BOM cost report to check that operation costs and material costs add up to the expected unit cost. The step is complete when the default, active BOM shows every operation with a workstation and time, and the costing total matches the engineering estimate.
Set warehouses for WIP and finished goods
The inventory owner creates or confirms a work-in-progress warehouse, a finished goods warehouse and, where scrap is recorded, a scrap warehouse, then sets them as defaults in the Manufacturing Settings and the Item master. Map each warehouse to its ledger account in the chart of accounts so that stock movements post correctly. Ask the controller to confirm the account mapping before the first transaction, because corrections later require reposting. The step is complete when a test stock entry moves quantity into and out of each warehouse and the stock ledger shows the expected balances.
Create and submit the work order
The planner creates a Work Order from the item, its active BOM, the planned quantity, the planned start date and the source and target warehouses, then submits it. Check that the operations table has been copied from the BOM with the correct workstations, and that the required items list shows the expected raw materials. Submitting the work order reserves nothing by itself, so confirm the stock availability report shows whether materials must be purchased or transferred. The step is complete when the work order is submitted, shows the planned operations, and the material availability is known.
Transfer materials for manufacture
The stores team creates a Stock Entry of type Material Transfer for Manufacture from the work order, which moves the raw materials from the stores warehouse to the WIP warehouse. Verify that the quantities match the required items and that any batch or serial numbers are recorded where the item requires them. Reconcile the stock ledger after posting to confirm the raw material balance dropped in the source warehouse and rose in WIP by the same amount. The step is complete when the transfer is submitted and the WIP balance matches the materials issued to the order.
Run job cards with time logs
Operators open the Job Card generated for each operation, start and stop the time logs at the workstation, and record completed and rejected quantities as work progresses. Supervisors review the open job cards daily and ask operators to close any time log left running. Compare the actual time in each job card against the planned time from the BOM operation to spot bottlenecks early. The step is complete when every job card for the work order is closed, with time logs and quantities recorded for each operation.
Close the work order and reconcile
The production controller creates a Manufacture Stock Entry to move finished goods from WIP into the finished goods warehouse and to record the scrap quantity, then marks the work order as completed. Reconcile planned against actual quantities, planned against actual time per operation, and the WIP balance, which should return to zero once the order is complete. Investigate any residual WIP balance before closing the period, since it means materials or labor were issued but not consumed. The step is complete when the WIP balance is cleared, finished goods are received, and the variance report is signed off by the controller.

Access control, audit trail and operational risks on the floor

Work orders and job cards are where production records get changed, so access, history and recovery need to be designed before the shop floor goes live. The cards below cover who can change production records, how shared terminals are handled, how time edits are traced, how custom logic is hosted, and what to back up first.

Submit, cancel and amend rights

Decide which roles can create, submit, cancel and amend work orders and job cards, since each of these actions changes stock and cost. Separate planners who release work orders from supervisors who close job cards, and test that a cancelled or amended document reverses its stock and time entries as expected. Ask the vendor or your own test environment to confirm how amendments interact with submitted stock entries before you grant amend rights to floor roles.

Operator access on shared terminals

Shop floor terminals are often shared by several operators, so a session left open can record time against the wrong person. Use individual logins or a controlled kiosk method, set session timeouts, and limit operators to starting and completing job cards at their own workstation. Review who can edit employee or operator fields on time logs, because those fields feed labor costing.

Audit history of time edits

Time logs are edited after the fact when a job runs long or a card is missed, and those edits change labor cost and progress reporting. Confirm that version history is enabled on job cards and time logs, and decide who may correct a completed log and what reason must be recorded. Reconcile supervisor edits against the original timestamps in a sample each month during the first quarter after go-live.

Server Scripts on Frappe Cloud shared benches

Custom logic such as validating a job card before completion usually runs as a Server Script. Frappe documents Server Scripts as disabled by default from version 15, and Frappe Cloud public shared benches do not allow them, so a shared-bench plan may not support this logic. Confirm the hosting tier and the server_script_enabled setting before you design any floor automation that depends on them.

Backups before go-live

Take a tested backup and a restore rehearsal before the first work order is released to the floor, and again before every major version change. Confirm the backup covers the database, uploaded files and private files, and check that a restore brings back submitted work orders and their stock entries intact. Agree the recovery point and recovery time you can accept with your operations team before the cutover.

Version support and patch cadence

Floor processes depend on a version that is still supported, so check the supported versions list for the release you plan to run. Plan patch windows around the frequent minor releases that both supported major versions receive, and test each patch against your custom scripts and print formats. Confirm with Frappe whether a support plan is required for warranty coverage on your chosen version.

What changes for planners, supervisors and operators

Once job cards become the unit of execution, the daily rhythm of the shop floor changes in three ways. Operators log time and quantities against the card for each operation rather than against the work order as a whole, supervisors review progress per operation and per workstation, and material moves through stock entries such as Material Transfer for Manufacture rather than through manual adjustments to bin quantities. Planners stop reading the work order as a single number and start reading which operation is open, which card is running and which materials have been issued against it. Confirm with your implementation team which roles will post time logs, who may complete a card, and whether your version lets operators start several cards at once on one workstation.

The costing quality of the whole process depends on two master data sets that are easy to neglect. Workstation records carry the hourly rate and working hours that ERPNext uses to value time on each card, so an out-of-date rate distorts the cost of every job that runs on that machine. BOM operations, their sequence and the items issued at each step decide which cards exist and which materials are expected to be transferred. Before go-live, review every workstation rate, check that each active BOM lists the operations and quantities the floor actually uses, and agree who approves changes. Partial or stale master data is the most common reason for variances that look like shop floor losses but are really configuration errors.

Supervisors will need a short, agreed rule for closing cards and correcting mistakes. Once a time log or transfer is submitted, correcting it means cancelling or amending the document, so the team should decide in advance who may do that and how overtime, rework and interrupted runs are recorded. Ask your partner to demonstrate a complete run on a test site, from transfer to card completion to finished goods receipt, using real workstations and a sample BOM, so that planners, supervisors and operators can see how their daily entries flow into the numbers that finance and management will read.

Questions buyers ask before implementing work orders and job cards

How much does it cost to set up work orders and job cards in ERPNext?

The cost depends on the scope written into the quote, not on a standard price, because DeployOpen does not publish one. ERPNext itself is free to self-host under its open-source license, so the spend is labor and infrastructure. The main cost drivers are the number of BOMs and operations to model, the number of workstations, how many shop floor processes differ from one another, and whether time logging must feed costing or payroll. Ask for a fixed-scope quote that lists each deliverable, the assumptions behind it, and what the client team must provide. Infrastructure costs are separate: Frappe Cloud shared site hosting starts at 5 US dollars per month according to the ERPNext pricing page, while self-hosting carries no license fee.

How long does it take to configure work orders and job cards?

Configuration time follows the number of products, operations and workstations, and how many exceptions the floor uses. A small line with a few routings is a much shorter job than a plant with many multi-level BOMs and shared machines. Testing with real orders usually takes as long as the initial build, so plan for a pilot on one production line before rollout. DeployOpen agrees the timeline in the written scope before work starts, so ask for milestones tied to the pilot, the data load and user training rather than a single end date. No duration figure is given here because none has been researched for this topic.

What data must our team supply before ERPNext can run production?

Your team supplies the production facts that ERPNext cannot infer. The usual inputs are:

Bills of materials for each finished product, with quantities and units of measure
Routings that list each operation, its sequence and standard run times
Workstation data, including hours of availability, hourly cost and capacity
Shop floor process maps showing where material moves, which operations can run in parallel and where quality checks sit
Item, warehouse and stock opening balances

Incomplete BOMs are the most common reason work orders produce wrong material requirements, so validate them with production engineering before the build starts. Ask the implementer to list the exact fields and files they need, and in what format.

Can an in-house team implement work orders and job cards without a partner?

Yes, an in-house team can implement them if it has ERPNext configuration skills, someone who understands manufacturing costing and stock valuation, and time to test with the floor. The Frappe documentation and the frappe/erpnext repository are the primary references for the manufacturing features. Teams often underestimate the process mapping, data cleansing and change management work, which is where partners add the most value. Decide early which parts your team owns and which you buy, such as data migration, custom reports or go-live support. A written scope makes that split visible and lets you compare the cost of internal time against an external quote.

How do custom reports or server scripts change the effort?

Custom reports and scripts add effort because they must be designed, tested, documented and maintained across upgrades. In ERPNext, Server Scripts run Python on document events or as API endpoints. Starting from version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Check that hosting setting before designing any script. Each custom report or script should have a named owner, a test case and a review step at each upgrade. Keep customizations as exported apps rather than edits to core code so they survive upgrades.

What recurs after go-live for work orders and job cards?

After go-live, the recurring work is upgrades, minor-release patching, backups, monitoring, and support for new products, routings and workstations. ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, and version 15 is planned to be supported until the end of 2027, according to Frappe's supported versions page, so the upgrade calendar matters. Both supported major versions receive frequent minor releases, so plan a regular patch window. Frappe's policy also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Ask for the support and upgrade terms in a retainer proposal, separate from the build.

Which version of ERPNext should we build on for shop floor work?

Choose a version that is still in its supported window for the whole planned life of the system, and confirm the feature set you need in that version before committing. The Frappe supported versions page lists version 15 as supported until the end of 2027 and version 16 until the end of 2029. Some shop floor features, such as tracking semi-finished goods by operation, are specific to ERPNext version 16, so check the release notes for the features your floor depends on. Confirm the choice with your implementer in writing, because moving versions after build adds rework.

Who owns the data and the configuration after the project ends?

Your organization should own the data, configuration and custom code, and the written scope should say so explicitly. ERPNext is licensed under GPL-3.0, and the underlying Frappe Framework is licensed under MIT, according to the license metadata of both repositories, so the software can be run and modified inside your own infrastructure. Ask for the BOMs, routings, workstation records, exported customizations and documentation as handover deliverables, and confirm that your team holds the admin credentials. Clarify who can make changes after handover and how those changes are reviewed.

Limits to confirm in your environment before go-live

Work orders and job cards depend on the ERPNext version, the BOM structure, the hosting model and the volume of records your shop floor generates. Each card below is a point to confirm with the vendor or in a test site before you commit to a go-live date.

Version-specific work order capabilities

Work order and job card behaviour changes between ERPNext major versions and between minor releases. Confirm which operation, transfer and time log features exist in the exact version you will run, and test them on that version rather than relying on older documentation or community posts. Ask the vendor which features are only available on the version line you plan to support, and record the version number in your test plan so the result can be repeated during upgrades.

Partial production and rework handling

Shop floors often finish part of a work order, send units back for rework or split a lot across shifts. Confirm how the system records partial completions, how finished quantities roll up to the work order, and whether a rework pass creates a new job card or reuses the original. Test one partial run and one rework loop end to end, then check that stock, time logs and progress percentages agree.

Scrap recording in manufacture entries

Scrap affects valuation and yield, and the way it is entered changes what the finished goods report shows. Confirm whether scrap is taken from the BOM scrap items, entered manually on the manufacture entry or handled through a separate scrap warehouse, and how each option posts to the ledger. Ask your finance lead to sign off the accounting entries produced by a test scrap event before production data is loaded.

Multi-level BOM interaction

A work order created from a top-level item may or may not generate work orders for sub-assemblies, depending on how the BOM tree and planning settings are configured. Confirm how sub-assembly work orders are created, whether job cards exist for each level, and how a change to a lower-level BOM affects open orders. Run a three-level test structure with real operation times before you rely on automatic creation.

Bulk job card creation volumes

Creating job cards for many work orders at once can be slow or fail on large datasets, and the Data Import guidance advises loading only a few thousand records at a time. Ask the vendor what volume your planned shift schedule produces, benchmark bulk creation on a copy of your production data, and plan batched runs outside peak shift hours if the test shows strain.

Hosting and script restrictions

Where ERPNext runs decides which customizations are possible. Server Scripts are disabled by default from version 15 and must be enabled, and public shared benches do not allow them, so custom job card logic may not run on every host. Confirm the hosting model, the server_script_enabled setting and any restrictions on background jobs before you design shop floor automation around them.

When regulated production needs more than ERPNext configuration

Production records kept in ERPNext work orders, job cards and time logs can feed several compliance programs, but none of them is satisfied by the software alone. Where your plant falls under a framework such as ISA/IEC 62443 for industrial automation and control systems, NIS2 for manufacturing entities, or 21 CFR Part 11 for electronic records in regulated products, the question is which records, controls and approvals the framework expects you to show. ERPNext can hold much of that evidence, including who started and completed an operation, which Stock Entry consumed which batch, and when a job card was closed. Whether that evidence is sufficient is a judgment for your auditor or regulator, so confirm applicability with them before you design the records.

DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not decide whether your plant is in scope. In practice, that work means mapping which job card fields, user roles, approval steps and audit trail settings support each requirement, and documenting how they operate. For a regulated product, typical checks include whether job card and time log edits are traceable to a named user, whether Server Scripts or custom fields that alter production records are version-controlled and approved, and whether the network segment between ERPNext and shop floor controllers is separated from the business network. Each of those items is a decision with an owner, and several sit outside ERPNext, in your OT network design and identity setup.

How DeployOpen scopes and delivers ERPNext shop floor work

DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure. The cards below cover how shop floor work in ERPNext is scoped in writing, built and kept running after go-live.

Who DeployOpen is

DeployOpen is a Chainscore Labs company. It plans, implements, customizes, hardens, backs up, documents and supports self-hosted open-source platforms inside your cloud accounts, data centers or air-gapped networks. For shop floor work, that means the ERPNext instance that holds your work orders, job cards and time logs stays on infrastructure you control, and the people who built it can explain each configuration choice to your operations and IT teams.

Fixed-scope agreements

Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines for work orders, job card setup, workstation mapping and go-live are agreed in writing. Ask that the written scope name the operations, workstations and item types in use, which versions of ERPNext are targeted, and which data migrations and integrations are included, so that a quote can be compared against a defined set of outputs.

Build, test and handover

Work order and job card configuration is built in a non-production site first, then tested with real production sequences for a sample of items, including material transfers, time logs and partial completions. Handover should include the configuration record, role and permission settings, operator instructions and a short runbook for supervisors. Confirm the acceptance criteria in the written scope before testing begins.

Hardening and backups

Shop floor data is often the record of what was built, by whom and in which sequence, so the production environment needs access controls, TLS, tested backups and a restore procedure. DeployOpen hardens the deployment and documents backup scope, including the database and uploaded files. Ask how restore is tested and how often, and who approves changes to production scripts that affect stock or job card status.

Ongoing support retainers

After go-live, floor configuration tends to change as routings, workstations and items are added. Ongoing support, upgrades and testing are available as retainers, which suit teams that want a defined response path for production issues. Ask what the retainer covers for ERPNext minor releases, what the response expectations are in writing, and how changes to work order logic are tested before they reach the shop floor.

ERPNext work orders and job cards on the shop floor