ERPNext as the Core System, with a Custom Web App — Is This the Right Direction?

ERPNext Customize ERPNext
1

Hello,

I was assigned the task of implementing ERPNext in our company as the central system for production and warehouse processes. The complete workflow is quite extensive and covers everything from quotation and order intake, through production planning, material requirements and warehouse operations, to the final finished product.

One of the main requirements is to provide dedicated screens or kiosks for employees, production workstations and warehouse areas. Each kiosk should display only the information and functions required by the employee or location where it is installed.

Instead of giving every user access to the full ERPNext Desk interface, I decided to build a separate, simplified web application where ERPNext remains the core system and the single source of truth, while the custom application acts as a dedicated operational interface.

Current architecture concept

ERPNext is responsible for:

  • users, roles and permissions,

  • item and material master data,

  • warehouses and stock balances,

  • stock receipts, issues and transfers,

  • production and warehouse documents,

  • transaction history and audit trails,

  • eventually also BOMs, Work Orders, Job Cards and Quality Inspections.

The kiosk application retrieves data from ERPNext through the API and provides a simplified interface adapted to a specific employee, workstation or warehouse.

The goal is not to create a separate application for every kiosk. Instead, there is one shared application core, and additional modules can be enabled depending on the requirements of a particular user or location.

The current implementation includes:

  • user authentication based on ERPNext accounts,

  • feature visibility based on ERPNext roles and permissions,

  • item search by item code, name or barcode,

  • stock balance preview for one or multiple warehouses,

  • stock receipt and stock issue operations,

  • item master data preview,

  • warehouse location management,

  • visual indication of where an item is stored,

  • label printing,

  • operation history,

  • a touch-friendly interface designed for kiosk screens.

The idea is that adding a new workstation should not require building another application from scratch. It should only require creating or enabling a new module and configuring which warehouses, operations and sections are available on that kiosk.

Local workstation assistant

At the centre of the application there is an interactive assistant currently called Beemo.

The plan is to connect it to a locally hosted language model and speech recognition system. The assistant should listen to employee requests and control the application interface.

For example, an employee could say:

  • find a specific item,

  • show its warehouse location,

  • open the stock issue module,

  • check current stock availability,

  • display the current production task,

  • navigate to a specific section.

The assistant is intended mainly for intent recognition and interface navigation.

Operations that modify ERPNext data, such as issuing materials, completing a production operation or submitting a stock transaction, would still require explicit user confirmation.

A local LLM was selected because of data privacy requirements and the need to avoid sending internal production or warehouse information to external AI services.

AI tools such as GPT, Gemini and Claude Sonnet are being used during prototyping and development. However, the application architecture, permissions, business processes and ERPNext integration are designed around the company’s actual operational requirements.

Questions for experienced ERPNext users

How would you evaluate this approach?

Is an architecture where:

  • ERPNext remains the central transactional system,

  • a custom web application acts as the kiosk and operator interface,

  • all business transactions are submitted through ERPNext APIs,

  • users, roles and permissions remain managed in ERPNext,

  • each workstation receives only the modules it requires,

a reasonable solution for a larger number of production and warehouse kiosks?

I am also considering whether the application should remain a completely separate frontend communicating with ERPNext through REST APIs, or whether it would be better to gradually move it into a custom Frappe application and use the framework more directly.

I would particularly appreciate feedback regarding:

  • compatibility after ERPNext upgrades,

  • authentication and authorization in an external frontend,

  • REST API versus custom whitelisted methods,

  • using Socket.IO for real-time updates,

  • stock synchronization between multiple kiosks,

  • preventing duplicate or concurrent stock transactions,

  • maintaining a complete ERPNext audit trail,

  • managing permissions securely on both the frontend and backend,

  • deciding which functions should remain standard ERPNext features and which should be implemented in the custom interface.

I would appreciate a technical review of this architecture and any advice on potential problems that should be addressed before developing the system further.

erpnext_kiosk_redacted_2
erpnext_kiosk_redacted_21889×1019 139 KB

erpnext_kiosk_redacted_1
erpnext_kiosk_redacted_11851×941 245 KB

2

The direction is right. erpnext as the single source of truth, thin kiosk frontends over the api. thats the correct shape. dont turn back.

the answer to “separate frontend vs custom frappe app” is BOTH: keep the kiosk app separate, and put a small custom frappe app on the bench that holds your server-side methods. the frontend stays free,
the transactional brain lives next to the data.

  1. UPGRADE COMPATIBILITY
  • zero core customization. everything custom lives in your own app. custom fields as fixtures in that app, never hand-edits.
  • your api surface will outlive upgrades better than doctype internals. pin your frontend to explicit field lists, never “give me everything.”
  • keep a staging bench. run your kiosk integration tests against it before any upgrade touches production. thats the whole insurance policy.
  1. AUTH / AUTHORIZATION IN AN EXTERNAL FRONTEND
  1. REST API VS CUSTOM WHITELISTED METHODS
  • split by read/write. reads and search: standard rest, its fine.
  • writes that span more than one document (issue material + update job card + touch stock) must NOT be the frontend making 3 rest calls. one of them fails, your books are mid-stride and the kiosk doesnt know.
  • one whitelisted method per business operation. one call, one atomic
    transaction, server-side. thats what your custom frappe app is for.
  1. SOCKET IO / REAL-TIME
  • fine for freshness display. treat every pushed number as advisory.
  • the truth about stock exists at exactly one moment: commit time, server-side. never let a kiosk act on a number it got pushed 4 seconds ago without the server re-checking at submit.
  1. STOCK SYNC BETWEEN KIOSKS
  • dont sync stock between kiosks. there is nothing to sync. erpnext is the only holder of stock truth, kiosks are windows onto it.
  • the moment a kiosk caches stock and another kiosk trusts that cache,
    you have two sources of truth and one of them is lying.
  1. DUPLICATE / CONCURRENT TRANSACTIONS
  • idempotency key on every write operation, minted by the kiosk, checked server-side. double-tap on a touchscreen is not a rare event, its tuesday.
  • pattern that holds: record the INTENT first, verify preconditions server-side at commit, refuse replays of the same intent.
  • With Pacioli i run this shape in production as plan → prove → record: the plan is written before the entry, the entry proves against the plan, the record is immutable after. even if you dont use my tool,
    build that shape. it turns “did the kiosk do that twice” into a question the ledger itself can answer.
  1. AUDIT TRAIL
  • if kiosks share a service account, your audit trail says “kiosk 3 did everything” and the WHO is gone forever. erpnext’s trail is only as good as the identity you hand it.
  • carry the operator identity through to the transaction, every time, even though the station credential is doing the transport. attribution is a day-one decision, you cannot retrofit it onto old entries.
  1. PERMISSIONS FRONTEND + BACKEND
  • frontend permission checks are UX, nothing more. they decide what buttons to draw. enforcement lives server-side at the credential and method layer, or it doesnt exist.
  • assume the kiosk browser is hostile. if a curl with that stations credential can do something the screen never offered, thats your real permission surface.
  1. WHAT STAYS STANDARD ERPNEXT
  • anything that touches the stock ledger or the accounting ledger stays a standard erpnext document. your app CREATES stock entries, it never invents its own parallel bookkeeping.
  • desk stays the office interface: reporting, masters, corrections. the kiosk is for the 6 operations that station does all day, nothing else.
  1. BEEMO

  • local llm for intent + navigation with human confirm on writes: right instinct, right layering. keep it.

  • the trap is downstream. the day the assistant works well, someone will want “beemo, issue the material” to just DO it. a confirm dialog is not governance, its a habit-click after week one.

  • when you cross that line, put a machine-checkable layer between the assistant and the books, same scoped credentials + intent-first shape as above. the assistant gets a scope, not trust.

    Happy to go deeper on any of these.