Data model

What a typical trading ERP needs to know: 67 entities in ten domains, from parties and prices to deliveries, invoices and open items. Every entity is a definition, not a hardcoded table, and almost all of them ship in a replaceable trade package, not in the core.

Ten domains

The orange domains move goods and money. Everything else describes who, what and at which price, or supports all domains alike.

Domain map of the reference data model: business partners, products and pricing feed sales; sales and purchasing move inventory; invoices become open items in finance; foundation, collaboration and platform support every domain.Business partnersparty, customer, suppliercustomer groupProductsfamily, product, categorymanufacturer, offers, attributesPricingsales and purchase pricesdiscounts, channelsSalesinquiry, quote, orderdelivery, invoice, returnInventorywarehouse, bin, movementreservation, count, lotPurchasingproposal, purchase orderreceipt, supplier invoiceFinanceopen items, paymentsdunning, exportFoundationcompany, currencies, countries, tax codes and rules, units, payment terms, shipping methods, packaging, shipping ratesCollaborationactivities, files, messages on any recordPlatformidentity, audit, numbers, outbox, webhooks, processesmaster data and prices used by every documentoutininvoices, credit notes and supplier invoices become open items
Fig. 1 Domain map. Foundation, collaboration and platform serve every domain.

Document flow

Each document line points to the line it came from. That makes partial deliveries, partial invoices, returns and dropshipping traceable line by line.

Document flow: order to cash from inquiry to payment, returns with credit notes, procure to pay from proposal to payment, and dropshipping creating purchase orders from sales order lines. Deliveries, goods receipts and returns post stock movements.Order to cashInquiryQuoteSales orderDeliveryInvoiceOpen itemPaymentReturnsReturn (RMA)Credit noterefers to order linesProcure to payProposalPurchase orderGoods receiptSupplier invoiceOpen itemPaymentdropship line creates a purchase orderstock movements: delivery out, goods receipt in, return in
Fig. 2 Order to cash, returns and procure to pay. Orange marks documents that move stock.

Rules the model follows

Party with roles

A company that is both customer and supplier exists once. Addresses, contacts and tax ids are maintained in one place.

Documents are aggregates

Header and lines are one resource. Lines reference their predecessor line, so the document flow is traceable line by line.

Progress per line

An order line knows how much was delivered, invoiced and returned. Partial deliveries and partial invoices fall out of this naturally.

Snapshots on documents

Addresses, terms, prices and product names are copied into documents. Master data changes never rewrite history.

Posted means immutable

Posted deliveries, invoices and movements cannot be changed or deleted. Corrections are new documents: credit notes, counter movements.

Stock is a ledger

Stock levels are derived from movements and reservations, never edited directly.

Money with currency

Every amount carries its currency. Tax is calculated per line and summarized per tax code.

Core without trade knowledge

The core knows types, traits and strategies, not prices or deliveries. Everything trade specific ships as the trade package and can be replaced.

Everything has an id and many have a number

UUIDv7 ids for every record, gapless business numbers where the law or the user needs them.

Everything with a SKU is a product

Variants are products. A family holds what variants share and which dimensions split product pages. Media live in a PIM, referenced by id.

Tax is determined, not typed

A tax rule finds the tax code per line from ship-from and ship-to country, customer type and product class: domestic, OSS, reverse charge, export.

Lines know their warehouse

An order can ship from several warehouses in several countries. Each warehouse gets its own delivery.

Simple defaults, replaceable by strategies

Decisions such as warehouse allocation, packaging, shipping cost, tax, price, discount approval and return cost ship with a simple default. A strategy replaces it with custom logic, such as allocation by postal code distance.

Partial is normal

Partial deliveries and partial payments are regular cases. Open items track what is still open.

All entities

Filter by domain or search. Each card shows purpose, key fields, embedded lines, traits and the milestone that introduces it. Fields are the essentials, not every column a real system would have.

Deliberately left out

  • General ledger, balance sheet and profit and loss: stays in the accounting system, fed by the export
  • Production, bills of material for manufacturing and MRP
  • Payroll and HR
  • Projects and time tracking
  • Fixed assets
  • Consolidation of several companies
  • Warehouse management beyond bins: picking waves, putaway strategies, scanners

How this model was made

Drafted with AI from common ERP practice and the decisions on this site, then reviewed by me. It is the input for specs and seed data, and a test in itself: how well do models know real ERP practice? Corrections from people who run ERP systems are welcome.