PRODEAZY
Configuration-Driven Enterprise Resource Planning
Monthly Report
Form Customization
Stockout Incidents
Dashboard KPIs
The client ran operations across spreadsheets and manual processes. Sales teams tracked enquiries in Excel with no conversion visibility. Purchase indents were emailed between departments with no approval tracking. Production planners couldn't see real-time inventory, causing over-ordering and stockouts. Quality control results were in notebooks, never feeding back into procurement decisions. Monthly reports required manually compiling data from five sources over two days.
We built a metadata-driven ERP from scratch where the system adapts to the business at runtime. Field layouts, workflow routing, document templates, and validation rules are all stored in the database and editable by administrators through the UI — not by engineers through code. The FieldConfigManager, workflow routing engine, and database-stored print templates all express the same principle: defer decisions to runtime configuration so the software serves the business as it actually is.
Under the Hood
Dynamic Field Configuration Engine
Every transaction form has fields described as metadata in the database. Administrators toggle visibility, required state, read-only mode, defaults, and validation rules via a UI panel. No code touched, no server restarted.
Multi-Step Workflow Engine
Post-QC routing is data-driven, not hardcoded. After a QC pass, the engine reads the source document, checks the post_qc_flow flag, and resolves the next destination. Adding a new routing rule means a database record, not a deployment.
Template-Driven Print Generation
Three-tier template resolution: database-stored custom template (checked first), file-based default template, then built-in fallback. Admins can paste new Handlebars HTML templates and preview immediately.
Generic Transaction Component
A single TransactionPage component handles any transaction type — fetching field config, rendering header and line-item grids dynamically, managing parent/child document relationships. Adding a new transaction type requires zero new form implementations.
In Action
- +Sales pipeline: Enquiry → Quotation → Order → Packing → Dispatch → Return → Payment
- +Purchase pipeline: Indent → Enquiry → Order → Receipt → QC → Return → Vendor Payment
- +Production pipeline: Target → Planning → Requisition → Entry → QC
- +Role-based access control with 7 personas (admin to quality inspector)
- +Real-time reporting with MySQL JSON_OBJECT and JSON_ARRAYAGG aggregation
- +LMTD comparisons and Top-N analysis computed in SQL
- +Configurable validation rules with stored regex patterns and live test capability
- +LookupSelect dropdowns showing pending quantities alongside item names
Why We Did
What We Did
Every architectural decision has a reason. Here are the ones worth explaining.
Why MySQL over a document database?
The data is inherently relational — a Sales Order references a Quotation, which references an Enquiry, which references a Party. MySQL 8's JSON functions give document-style flexibility for the config layer without abandoning relational integrity for transactions.
Why configuration in the database rather than code?
The primary deployment target is a business where engineers are not on-call. When a process changes, the admin panel is the escape valve. Storing configuration in the database means the system evolves without a software release cycle.
Why Handlebars for print templates?
Server-side rendering for print documents is intentional. Handlebars templates are legible HTML that a technically literate admin can read and edit, stored as text in the database. React-PDF would require a build step and developer involvement for every template change.
Something Like This
In Mind?
Tell us what you're building. We'll tell you how we'd do it.