ERPNext Africa · engineering patterns

Shop floor & beyond: extending ERPNext for the factory

Four patterns we run in production at a South African designer-furniture manufacturer — from CAD design to CNC telemetry to management dashboards — all built on ERPNext rather than beside it. Presented generically; system walkthroughs available on request.

Every pattern below is live in production today — not a concept sketch. Companion to Why ERPNext and the furniture briefing.

01 · The principle: extend inside the system of record

Factories accumulate side-systems — the nesting spreadsheet, the whiteboard schedule, the machine-monitoring app with its own database. Each one splits the truth. The pattern that works: build the extension inside ERPNext — custom DocTypes for the data, Server Scripts for the logic, Web Pages for the floor-facing screens — so every new capability inherits the same permissions, audit trail, API and backups as the ledger.

No parallel database — machine data, nest data and floor status live as ERPNext documents, joined to work orders and items like everything else.
No parallel users — floor screens and dashboards authenticate against ERPNext's own accounts and roles.
Version-controlled anyway — the scripts and pages live in a git repo as a reviewable mirror, deployed to the instance over the REST API. Custom work stays inspectable and portable without forking the product (see the customisation dial).

02 · CAD → BOM → factory: no re-keying from design to floor

The design desk and the factory should share one structure. Two production patterns:

Design BOMs straight out of CAD

A Fusion 360 plugin walks the assembly, exports the bill of materials — part names, numbers, volumes, materials — and captures a rendered thumbnail of every part automatically. The output loads into ERPNext as the manufacturing BOM, image links included: the floor sees a picture of the part it's building, and a design revision becomes a BOM revision instead of an afternoon of retyping.

Nesting output → live cutting board

CNC nesting software (Fusion/TruNest-class) already decides how parts lay out on sheets. Its export is machine-readable — so instead of a person transcribing it into a cutting spreadsheet, a parser ingests it and creates the records directly:

Nest export (JSON) ──▶ parser ──▶ Nest · Sheet · Part · Offcut records ──▶ live board workflow: Awaiting CNC → Confirm Cut → Breakup → per-part checklist → Released

The board shows every sheet and part against its work order, with offcuts tracked as stock. Mill-order and breakup-report print formats come off the same records — the paperwork is a view of the data, not a separate artefact.

Why it matters commerciallyThis is the difference between "ERP for the office" and "ERP the factory actually uses". The nesting spreadsheet is usually the last spreadsheet to die — this pattern kills it.

03 · Machine telemetry: the shop floor reports itself

Modern CNC controllers publish live state — running, idle, alarm, active file, operator, part counts. A small always-on bridge subscribes to the controller's feed (MQTT over WebSocket in our production case) and writes it into ERPNext as two document types:

DocType	Behaviour	What it gives you
Machine (live status)	Upserted continuously	A real-time floor view: which machines are cutting, what they're cutting, who's operating
Machine Run (history)	One row per completed job, append-only	Utilisation, run times and job history — joined to work orders for actual-vs-planned

Floor and production teams get live pages — current machine activity, the production schedule, a week view — all reading the same records. No side database, no separate monitoring product, no per-machine licence.

The general ruleAny machine or device that can publish data — CNC, edgebander, compressor, scale — can land in ERPNext through the same bridge pattern: a service subscribes, ERPNext stores, permissions and reporting come free.

04 · Floor boards & apps: screens the factory actually uses

ERPNext's Web Pages turn the instance itself into the floor's app platform: purpose-built screens (a cutting board, an intake page, a checklist) served by the ERP, styled for the workshop, driving the same documents the office sees.

Workflow with teeth — stage transitions are buttons on the board (Confirm Cut, Confirm Breakup) that update the underlying documents; a part can't be "released" until its checklist is ticked.
Server Scripts as the logic layer — validations and automations live as configuration in the instance (see the dial), not as a forked codebase.
Print formats as views — mill orders, breakup reports, labels: generated from the records, never maintained separately.

05 · The insights layer: dashboards without a second system

When leadership wants friendlier dashboards than the ERP's own screens, the trap is a BI tool with its own copied data and its own user list. The production pattern instead:

A read-only web app over the ERPNext API — modern UI (personas: finance view, factory view, mobile approvals), deployed on edge hosting, issuing only read requests.
ERPNext is the identity provider — login via OAuth against the ERP's own users and roles; what you may see in the dashboard is exactly what you may see in the ERP. No parallel accounts to manage or forget to revoke.
Reports that answer management's actual questions — on-time delivery, margin variance per order — built on the live ledger and stock data, not last month's extract.

And the AI layer rides the same railsThe same role-scoped API that feeds dashboards feeds AI agents — reporting assistants and data-quality checks with exactly the access a user would have. See Ready for AI.

Sources

Production implementations in our client network (South Africa) — walkthroughs under NDA on request · Frappe Framework docs — Server Scripts, Web Pages, REST API · Why ERPNext (platform) · Furniture manufacturing briefing