Why TradeFlow
Building trust into the handoff.
How TradeFlow models an auditable distribution ERP across commercial approval, inventory custody, delivery evidence, invoicing, and payment.
01 / Business problem
Operational truth was fragmented across handoffs.
Wholesale distribution teams need sales, warehouse, delivery, finance, and purchasing to agree about the same transaction. TradeFlow treats the transitions between those teams as first-class business decisions, preserving who authorized each change and what the system accepted.
02 / Domain boundaries
One flow, explicit contexts.
Commercial owns price, terms, credit exposure, and order approval. Warehouse owns physical custody. Delivery owns evidence and acceptance. Finance owns posting and settlement. Procurement replenishes stock through its own approval chain. Stable identifiers and application commands connect them without collapsing their rules into one model.
03 / Order to cash
State advances only through accepted commands.
A draft is priced and commercially approved before reservation. Tracked identities are assigned when staff pick physical goods. Dispatch transfers custody to delivery; confirmation records acceptance and triggers invoice posting. Payments remain pending until method-specific evidence is verified, then update allocations and the statement timeline.
04 / Inventory custody
Balances are consequences, not editable facts.
Availability is derived from immutable movements at a warehouse and location. Picks bind lots and serials to fulfillment work. Transfers, counted variances, delivery exceptions, and corrections add linked movements instead of rewriting history, making every current balance explainable.
05 / Authorization
Maker/checker is enforced at the server boundary.
Capabilities answer what a person may do, scope answers where, and approval limits answer how much. Distinct internal personas seed approval history for evaluation; visitors operate as a restricted operator and cannot administer the organization.
06 / Reliability
Retries are normal; duplicate business effects are not.
Mutating commands carry idempotency keys and persist command receipts. Aggregate versions provide optimistic concurrency so stale decisions fail explicitly. Correlation identifiers connect interface errors to structured server traces without leaking sensitive context.
07 / Testing strategy
Invariants are tested below and above the API.
Database tests protect immutability and posting constraints. Contract tests exercise authorized commands and failure shapes. Generated-client checks prevent API drift. Browser and mobile tests verify real workflows, and a migrated PostgreSQL acceptance lane validates the complete stack.
08 / Tradeoffs
Deliberate constraints kept the core honest.
Server-authoritative posting can add latency, but it prevents clients from inventing business state.
Immutable corrections create more records than updates, but preserve evidence and simplify audit reasoning.
The public evaluation environment uses one shared company and omits tenant provisioning, billing, and invitations to focus on operational depth.
Production identity federation, provider-managed observability, DNS, and budget alerts remain deployment-specific integrations.
See the decisions as working operational states.
Open operations overview