A production-grade PHP & MySQL ERP built in-house at Nexus Code Labs, covering Accounts, Inventory, and HR/Payroll with role-based approvals and audit-ready reporting throughout.
What is DOS ERP?
DOS ERP (Digital Office Suite) is Nexus Code Labs' own enterprise resource planning system, developed with PHP, MySQLi, jQuery, and Bootstrap, and hosted at nexuscodelab.com/erp. It's actively used to run day-to-day accounting, inventory, and manufacturing operations for a real business — every screen in this page is a genuine screenshot from the live system, not a mockup.
The platform follows a strict internal standard for every module: consistent voucher workflows, a locked TCPDF report format for every printed document, role-based access on every screen, and a full audit trail on every transaction. That discipline is what lets the system scale from a single ledger entry to a full statutory financial statement without the data model ever needing to be re-worked.
Every module shares the same conventions, so the system behaves predictably no matter which screen you're on.
Built on PHP, MySQLi, jQuery, and Bootstrap — no framework overhead, full control over every query and screen.
Every voucher type carries its own configurable approval chain, with sort order and signature-on-file per role.
Every printed report and voucher shares one TCPDF layout — logo, criteria line, page numbering, and signature blocks.
A single User_ID on every table plus DB Audit Trail Management means every change is traceable to a person.
A closer look at the modules that make up the day-to-day operation of DOS ERP.
The moment anyone logs in, DOS ERP surfaces what actually matters — total orders, quotations, customers, and vendors as live KPI cards, refreshed against the current database rather than a cached summary.
Below the KPIs, a set of charts break down the transaction mix (GRNs, orders, invoices, vouchers), inventory by type, and — critically — a Low Balance Items chart that flags stock about to run out before it becomes a production problem.
The financial backbone of the system: a full 5-level account hierarchy (Assets → Current Assets → Cash & Bank → Cash in Hand → individual GL codes) used consistently across every voucher, report, and reconciliation screen.
Each account carries a control type — Bank_Cash, for instance — so the system knows automatically which accounts feed bank reconciliation and which stay purely internal, without a single hardcoded rule elsewhere in the code.
All 17 financial reports in the Accounts module — General Ledger, Trial Balance, Balance Sheet, Profit & Loss, and more — share one criteria screen pattern: pick a GL code, a date range, and any extra filters, then generate straight to PDF or Excel.
The General Ledger below shows exactly what a partner or auditor receives: opening balance, every posted voucher affecting the account, a running balance, and a closing total — generated on demand, not pre-built.
Reconciling book balances against the bank statement is a dedicated report of its own, filtered by bank account and statement date — part of a wider Cash & Bank suite that also includes the Cash Book, Bank Book, and Cheque Register.
Keeping this as a first-class report — rather than a manual spreadsheet exercise — is what makes month-end close fast and defensible.
Every voucher type — Bank/Cash Receipt, Bank Payment, Journal, Payment, and more — has its own maker-checker-approver chain, defined once per document type with an explicit sort order for who prepares, who checks, and who signs off.
That workflow isn't just configuration: it prints. The Journal Voucher shown here carries three named signature lines — Prepared By, Checked By, Approved By — pulled straight from the approval authority set for that document.
Alongside User Setup, DOS ERP includes Admin Assign Privileges and Assign User Privileges screens that scope exactly which menus, forms, and actions each account can reach — right down to individual Setup screens.
Combined with DB Audit Trail Management and Daily Database Backup, this gives the system the same access-control and recovery posture you'd expect from a commercial ERP, without depending on a third-party vendor.
For manufactured items, DOS ERP stores a full recipe — the Batch Card Recipe — defining exactly which raw materials and quantities go into one production batch of a finished product, versioned by batch quantity.
The printed recipe becomes the shop-floor reference: for a batch of 10 Electrical DB - 8 Way units, it lists precisely 80 MCBs, 150 metres of copper wire, 10 enclosures, and so on, each with a plain-language remark explaining the ratio.
Once a batch is issued for production, the Batch Receipt Note closes the loop: it records the finished quantity actually received back into stock against the original Batch Issue, with the product and expected quantity auto-resolved from that issue's recipe.
Posted BRNs become read-only — visible for reference and audit, but no longer editable — which is exactly the behavior you want once a production run has been confirmed.
The sales cycle runs Quotation → Customer Order → Invoice, with GST and per-line discounts calculated automatically and the invoice report filterable by customer, order number, and posted or cancelled status.
The printed invoice carries the same professional layout as every other DOS ERP document — clean line items, tax and discount breakdown, grand total, and dedicated signature lines for Prepared, Checked, Approved, and Received By.
The newest module taking shape in DOS ERP. Employee Master brings every personal, contact, and employment record together in one tabbed profile — Personal Info, Documents, Dependents, Qualifications, Experience, and History — instead of scattering employee data across disconnected forms.
Personal Info opens by default with the employee's photo front and center, alongside CNIC, marital status, blood group, and nationality. Contact Details, Employment Details, and Attendance Setup collapse below it, and one Save Employee button commits every tab together in a single transaction.
Every insert, update, and delete across the database — MySQL/MariaDB today, with SQL Server, Oracle, and PostgreSQL support built in — is captured at the column level: which table, which record, which attribute changed, its old value, its new value, the user, the timestamp, and the originating IP address.
The Audit Trail Search screen turns that log into an actual investigation tool, searchable by any combination of user, table, control number, attribute, date range, or action — so "who changed this and when" is always a filter away, not a database query someone has to write by hand.