Guide / for designers
The ER diagram behind a business management system
Six entities and one refusal — no stored quantities — produce a model where every number has a history. The diagram drawn in words, for designers and for buyers who want to know what they are buying.
The key facts
- The core entities: Party, Product, Location, Movement, Order (with Lines), Stocktake — plus the accounting handoff as a reference, never a second ledger.
- The one refusal: quantities are derived from movements, not stored — the decision that makes audit, concurrency and traceability possible.
- Extensions once the core holds: batches, reservations, multi-level units, projects grouping on-site assets.
- For buyers: this model is testable without code — the trial asks it questions ("why does it say 3?") directly.
- 01The key facts
- 02The entities and their relationships
- 03The one refusal the diagram must encode
- 04Extensions — and the buyer's version of this page
The entities and their relationships
Party — one abstraction for customers and suppliers, with roles; every Order references exactly one. Splitting them early forks every later report.
Product — SKU, description, unit, par level; optionally self-referencing for multi-level units (a box-of contains units-of). Holds nothing about quantity.
Location — warehouse, shop, van, customer site; self-referencing for hierarchies. Stock exists only at a location.
Movement — the heart: direction, quantity, product, location, actor, timestamp, reason; optionally referencing a Batch or an OrderLine. Append-only. Every report is a query over this entity.
Order / OrderLine — header (party, dates, state) plus lines (product, quantity, price, per-line state); specialised as CustomerOrder, PurchaseOrder, Invoice. States form the life-cycle machine.
Stocktake — a group of counted variances with review before adjustment; adjustments enter as Movements, so even corrections have history.
LedgerLink — not a ledger: a reference from an approved invoice to its accounting counterpart, so the operational record knows what the books already hold without holding books itself. The accounting boundary is a modelling decision, not an integration afterthought.
The one refusal the diagram must encode
No QuantityOnHand attribute on Product. Two models compete: stored totals (simple, and broken — no history, no concurrency safety, no answer to "why 3?") versus derived truth (on-hand = query over movements). Every serious system lands on the latter; every tutorial starts with the former. The ER diagram should show QuantityOnHand as a view or query dependency, never as a column — that one arrow is the model's moral centre, and it is what makes the audit trail, the traceability and the concurrent safety fall out for free. The class-diagram companion and the system diagram extend the model upward.
Extensions — and the buyer's version of this page
Once the core holds, extensions slot in without surgery: Batch (movements reference it; expiry and origin ride along; recall traceability becomes a graph query), Reservation (promises without consumption, so availability is honest), Project (on-site assets grouped under a customer with lifetime history), UnitLevel (boxes and singles as one truth).
We build BSimple, so weigh that: it is commercial software — the model above is not its published schema, but its behaviour is the model's behaviour, and that is testable without code. Ask the trial the questions the diagram promises: trace a batch, explain a quantity, void an invoice, watch two users at once. Plans run $180/$250/$399 per month AUD; the ER-thinking for stock systems continues in the inventory-specific companion.
Frequently Asked Questions
What entities does a business management system ER diagram include?
At its operational core: Party, Product, Location, Movement, Order/OrderLine, Stocktake — with the accounting connection as a reference, not a second ledger. Extensions add Batch, Reservation, Project and unit levels.
Why should quantities not be stored attributes?
Because stored totals cannot explain themselves. Derived quantities — from an append-only movement table — give you audit history, concurrency safety and traceability as free consequences of the schema.
How does the accounting system appear in the model?
As a reference from approved invoices to their ledger counterparts — the operational system produces documents and tracks their state, while the books remain the single compliance record. Two ledgers is how reconciliation archaeology starts.
Is BSimple built exactly on this diagram?
Its schema is not published, and we will not pretend to show code we do not. Its behaviour matches the model — movements, derived truth, traceability — and the trial is how you interrogate it on your own products.
Where does an ER diagram differ from a class diagram for this domain?
Detail, not substance: classes add behaviour (state machines on orders, rules on transitions); entities define the data those behaviours guard. The class-diagram page covers the behavioural half.
BSimple