Skip to content
EN FR

Building modern ERP systems: structural patterns

Documentation status: architecture. The ERP manuscript is an evolving companion draft; patterns here are design guidance, not a claim that the entire ERP solution is shipped.

Separate kinds of business state

  • Master data: stable identity and reference meaning, not a container for every module-specific field.
  • Documents: explicit intention or commitment with identity, lifecycle, participants and lines.
  • Movements: an appendable record of a business change.
  • Positions: state derived from or reconciled against movements.
  • Policies: credit, approvals, pricing and posting rules modeled as domain knowledge.
  • Posting and reversal: draft → validate → post → business effects → possible reversal; deleting posted history usually loses traceability.

Order-to-Cash is a process, not one transaction

Sales confirms an order; Inventory reserves; Logistics confirms shipment; Accounting posts an invoice; Payments records settlement. Each context asserts only facts under its authority. A process instance carries correlation, current state, pending action and references to those source objects. Retries require idempotence; missing stock and human approval are business states, not necessarily technical exceptions.

Order confirmed -> Stock reserved -> Shipment confirmed
                -> Invoice posted -> Payment received

Architecture checks

Make Sales/Inventory availability and reservations explicit. Keep accounting Posting its own boundary. Give compensation, audit, cross-context mapping and semantic CI/CD named owners. Do not rely on a single long-running SQL transaction to span days of process execution.

Continue

Domain-driven design · Declarative modeling · Events and processes · Data consistency

LaTeX sources: Building Modern ERP Systems with logiCells/erp-structural-patterns.tex, sales-and-inventory-boundary.tex, accounting-boundary-and-posting.tex, order-to-cash.tex.