The inventory system data flow diagram, in words

The key facts

• The DFD has one hero data store: the movements history — every external entity writes facts to it, every report reads from it.
• External entities: supplier, customer, staff roles, the store channel, and accounting — each exchanging defined flows, no direct entity-to-entity shortcuts.
• The design lesson the DFD teaches: facts flow one way into the store; reports and handoffs are reads. Editing history is the design failure.
• For buyers: a good DFD predicts good behaviour — the trial tests whether the real system matches its own diagram.
• The wider system: inventory management end to end maps the whole record this page sits in.

The external entities and their flows

Supplier → system: purchase orders out, goods receipts in (with lot and expiry where relevant), supplier invoices in for reconciliation. Customer → system: orders in (via portal, phone, or store), dispatch documents and invoices out, status queries answered from state. Staff → system: receipts, picks, packs, counts, adjustments — every flow carrying an actor. Accounting ↔ system: approved invoices out, payment status back — the reviewed handoff, flowing one way each direction (the boundary design). Store channel ↔ system: orders in by webhook, stock truth back (the Shopify spec).

Note what the diagram forbids: entities never write to each other directly. The supplier's invoice does not update the customer's promise; the store does not edit the ledger. All facts flow through the central processes — which is what makes the system auditable.

The processes and the one hero store

The processes transform flows: intake (validate and check orders against availability), fulfilment (pick, pack, dispatch against the record), counting (cycle counts and stocktakes producing reviewed adjustments), replenishment (reorder points raising purchase orders), and handoff (approved invoices to accounting, status mirrored back).

The data stores behind them are few: products, parties, locations, orders, and the one hero — movements. Every process reads and writes movements; every report (on-hand, trace, KPIs) is a query over it. If your DFD instead shows quantities flowing to a "current stock" store that processes update, you have drawn the tutorial version — the database-design reasoning explains why that version breaks under audit and concurrency. The ER companion shows the same facts as entities.

What the DFD reveals — to designers and buyers

To designers: the diagram exposes the integration points where systems fail — intake idempotency (webhooks retry), handoff atomicity (invoices cross once), and role separation (who may write which flow). It also exposes the classic mistake: a data flow from accounting into quantities, creating two masters. The ER-diagram reasoning covers the fixes structurally.

To buyers: the DFD is a trial script. Trace one order's flows in the trial — does the store channel write to the same store as the phone order? Does the accounting flow carry tax treatment? Is every write attributed? A system whose behaviour matches its diagram is trustworthy; a system whose demo hides flows is telling you something. We build BSimple, so weigh that: its DFD is the one described here — one movements store, reviewed handoff to Xero or MYOB (US integrations rolling out) — and the trial is how you verify the diagram against the product, from $180/$250/$399 per month AUD.