Guide / for designers
The company management system ER diagram, drawn honestly
A company-wide system spans several records — stock, orders, people, money. The entities, relationships and integrity constraints, and the seams where one model ends and another begins.
The key facts
- One model per record, seams between them — the company-wide ER diagram is really several strong models joined by references, not one mega-table web.
- The operations core: Party, Product, Location, Movement, Order/OrderLine, Stocktake — quantities derived, never stored.
- The boundaries that keep the diagram honest: accounting as a reference (LedgerLink), HR as a separate domain, storefronts as channels.
- For buyers: the model is testable through behaviour — the trial asks the questions the diagram answers.
- Where it fits: this page is one branch of the inventory management guide.
- 01The key facts
- 02The operations core entities
- 03The seams — where the company model splits deliberately
- 04Integrity constraints — the quiet half of the diagram
The operations core entities
Party — customers and suppliers as one entity with role flags; every order and every movement-actor references it. Splitting people and companies into separate webs early is the classic modelling regret.
Product — SKU, description, unit, par level; self-referencing for pack levels (box-of contains units-of). Carries no quantity.
Location — store, warehouse, van, customer site; self-referencing for hierarchies. Every quantity exists at a location.
Movement — the append-only fact table: direction, quantity, product, location, actor, timestamp, reason; optionally referencing OrderLine or Batch. On-hand quantity is a query over this entity — drawn as a dependency, never as a stored attribute. The schema decisions justify it fully.
Order / OrderLine — header and lines with per-line state; specialised as CustomerOrder, PurchaseOrder, Invoice. The state machine on the header is the life cycle made structural.
Stocktake — count events with variance rows; approved variances emit Movements. Corrections have authors, like everything else.
The seams — where the company model splits deliberately
Money. The accounting model (ledgers, journals, tax) is a different discipline with different integrity rules; the operations model references it — an approved invoice carries a ledger counterpart reference — without holding it. One model trying to be both produces two half-ledgers. The boundary reasoning applies at the diagram level.
People. HR entities (employment, leave, certifications) belong to the people domain; the operations model needs only who did what — Party and actor references cover it. Fusing HR into operations is how suites become unmaintainable.
Channels. A storefront is an integration, not an entity — orders from channels arrive through an intake relation referencing the source, keeping the core model channel-agnostic. The layer guide shows the seam in practice.
The honest architecture lesson: a company management system is several excellent models with designed seams, not one heroic diagram. The system diagram shows the whole at a coarser grain.
Integrity constraints — the quiet half of the diagram
Entities and relationships are half the diagram; the constraints are what make it trustworthy: uniqueness on SKUs and party identifiers; non-negativity rules expressed as guardrails at the movement level; immutability on movements (no updates, no deletes — corrections are new rows); state-machine checks on order transitions (no skipping states, no two simultaneous winners of the last unit); and attribution — every mutable fact carries its actor and timestamp. We build BSimple, so weigh that: it is commercial software (the schema is not published), but its behaviour — derived truth, audit on every change, deliberate accounting seam — is this diagram working, and the trial is how a buyer interrogates it on real products.
Frequently Asked Questions
What entities does a company management ER diagram include?
Per domain: the operations core (Party, Product, Location, Movement, Order/OrderLine, Stocktake), plus accounting, HR and channel models as separate diagrams joined by references. One mega-diagram is a design smell.
Why should quantities not appear as a stored entity attribute?
Because stored totals cannot explain themselves or survive concurrency — derivation from movements buys audit, traceability and correctness as consequences of the schema.
How does the accounting system appear in the diagram?
As a reference from approved documents to their ledger counterparts — never as a second ledger inside the operational model. Two masters is how reconciliation archaeology starts.
Is BSimple's schema exactly this diagram?
Its schema is not published, and we will not pretend otherwise. Its behaviour matches the model's promises — movements, derivation, attribution — and the trial is how you verify behaviour on your own data.
What constraints matter most in practice?
Movement immutability, state-machine checks on orders, and attribution on every change. Constraints are the difference between a diagram and a trustworthy system — the ERD is the promise, the constraints are the enforcement.
BSimple