Commerce Ops
Order and inventory back-office dashboard
The operations dashboard Codesloci ERP grew out of — purchase orders, supplier records, returns and discounting for a single-store operation. Deliberately small: exactly the modules one location touches daily, over the same API contract that later scaled into the full ERP, with charted reporting instead of a separate BI layer.
The problem
A single-location business needs the purchase-to-return loop closed and reported on, but not the weight, cost or configuration surface of a full ERP. The failure mode is not missing features — it is a system so general that nobody can tell whether this month’s numbers actually add up.
Our approach
A focused MUI dashboard covering exactly the operational modules a single store touches daily, over the same Express + MongoDB API contract that later scaled into the ERP. Reporting is handled with MUI X DataGrid and Charts rather than a separate BI layer. The reconciliation view was built first and everything else was built to feed it, which is why the numbers agree.
The outcome
A deliberately small system that closed the loop for a single store, and became the proving ground for the module architecture Codesloci ERP now uses.
What is inside
Purchase and return workflows with supplier and customer registries
Discount rules applied across orders
DataGrid-driven order, product and inventory management
Charted reporting on sales and purchasing
JWT-authenticated Express API shared with the ERP line
Direct predecessor to Codesloci ERP — the same module architecture, before the Vite rebuild
Engineering notes · 3 min read
Built backwards, from the reconciliation screen
One
Locations
scope held deliberatelyReconciliation
Built first
everything feeds itCodesloci ERP
Became
same module architectureMost operational tools are built feature by feature and reconciled at the end, which is why the numbers never quite agree. This one was built the other way round: the three-way reconciliation between purchases, stock on hand and returns was the first screen, and every other module was built to feed it.
The effect is that a variance is a first-class thing with a reason attached, rather than a discrepancy someone notices in a spreadsheet. The demo ships with one purchase order that deliberately does not reconcile, because a reconciliation screen where everything always agrees proves nothing.
Restraint as a feature
A single-location business does not need multi-store stock, cost centres, or an approval matrix. Adding them would have been easy and would have made the system worse — every configuration surface is something an operator has to understand before they can trust the output.
The scope was held to exactly what one counter touches daily. When a second location did arrive, that was the trigger to start Codesloci ERP rather than to inflate this.
- Purchase and return workflows with supplier and customer registries
- Discount rules applied across orders, resolved the same way every time
- Charted reporting from the operational data — no export, no separate BI layer
- The same JWT-authenticated API contract the ERP line later inherited
A small system whose numbers agree is worth more than a general one whose numbers need explaining.
Front end
Back end
Data
Platforms
Web
Need a platform like Commerce Ops?
We can walk you through how this was built, what it cost to run, and what the equivalent looks like for your business.
Or email us directly at [email protected]