Enterprise B2B ERP
ProdBusiness
Designed & built full-stack by Farivar Zarvandeh
Explainable enterprise B2B ERP with database-enforced correctness.
- Database tables
- 480
- Domain schemas
- 32
- Foreign keys
- 2,638
- RLS policies
- 474
- UI routes
- 90
- Passing DB validation checks
- 30
Figures counted from the repository; maturity note: Navigable mock-data frontend and executable, validated PostgreSQL reference schema. The FastAPI backend, integrations and live AI are planned across a 60-sprint roadmap.
01
Product introduction
ProdBusiness is an enterprise B2B ERP for wholesalers, distributors and industrial suppliers. One explainable engine covers pricing, procurement, stock and finance. A navigable workspace prototype and a 480-table PostgreSQL model that enforces correctness and tenant isolation in the database are built; the FastAPI backend is planned.
02
The problem
Many ERPs keep price, invoice and stock truth separately for each channel. Staff orders, portals, EDI and field agents can then disagree. Multi-company books, warehouse-scoped stock and B2B exceptions (credit holds, price mismatches, missing receipts) end up spread across modules and spreadsheets. AI features are often bolted on without evidence, approvals or an audit trail. ProdBusiness's own predecessor showed these limits: one legal company, globally keyed stock and a scheduler tied to the web process.
03
The solution
ProdBusiness is designed around one authoritative calculation and execution core shared by every channel. PostgreSQL itself enforces balanced journals, immutable posted ledgers, sealed price decisions, single-reservation stock and tenant/company row-level security. The UI is role-first and explainable: work queues, entity workspaces, a price waterfall showing applied and skipped rules, plain-language invoice-match explanations and decision previews before any commit. AI is limited to proposals: it shows evidence and a before/after diff, and a human approves before any action, which is recorded as an action receipt.
04
Core features
Role-first workspaces
ImplementedTwelve module workspaces (Sell, Buy, Stock & Ship, Finance and more) across 90 routes. They include a command palette, persona switcher, record timeline drawer and English/French UI.
Procurement suite
PartialRequisitions, RFQs with a bid comparison matrix, purchase orders, proforma invoices and landed cost, all built as working mock screens.
Explainable invoice matching
PartialPrice, quantity, tax, duplicate and missing-receipt mismatches are explained in plain language, with status and next step.
Price waterfall
PartialEach pricing step shows whether it was applied or skipped, why, and which rule version produced it.
Warehouse and shipping
PartialReceiving and two-stage receipt, bin positions, scan-based picks, blind counts, shipments, carriers and load planning.
Finance workspace
PartialChart of accounts, journals, open items, a bank reconciliation split view, period close and e-invoicing queues.
Database-enforced invariants
ImplementedBalanced journals, immutable ledgers, sealed pricing, idempotent commands and no double stock reservation, verified by 30 passing checks on embedded PostgreSQL.
Tenant and company isolation
ImplementedForced row-level security with restricted runtime roles. A missing tenant context fails closed.
AI proposal drawer
PartialAI suggestions appear as uncommitted proposals with purpose, evidence, a before/after diff, uncertainty and an approval boundary.
FastAPI domain services and workers
PlannedA versioned /api/v1 command API, a durable outbox, integration workers and Redis-assisted caching.
EDI, carrier and e-invoice integrations
PlannedEDI partner onboarding, DHL/freight booking, structured e-invoices and bank feeds through certified adapters.
05
System architecture
Two layers are built today: a Next.js App Router workspace prototype running on an in-memory mock store, and an executable PostgreSQL reference model validated in embedded Postgres. The target runtime is a domain-modular FastAPI monolith. It writes canonical state to PostgreSQL, publishes through a durable outbox to separate domain and integration workers, and uses Redis only for reconstructable caches and rate limits. AI tools may only call allowlisted domain commands through approval-gated proposals.
Hover or focus a component to trace its real connections.
10 components · 10 connections, as found in the repository.
06
Technology stack
- frontend
- Next.js (App Router, Turbopack)ReactTypeScriptlucide-reactIBM Plex
- backend
- FastAPI (planned)Python (planned)SQLAlchemy / Alembic (planned)
- data
- PostgreSQLRow-level securityRedis (planned)
- ai
- Policy-bound proposal and receipt modelProvider-agnostic (planned)
- infra
- PGlite validation harnessNode.js toolingS3-compatible storage (planned)
- integrations
- EDI / Peppol (planned)DHL and freight (planned)ZUGFeRD / XRechnung (planned)DATEV and FEC exports (planned)
07
Product experience

Procure-to-pay
- 1Raise requisition
- 2Run RFQ and compare bids
- 3Issue purchase order
- 4Receive goods
- 5Capture supplier invoice
- 6Resolve explained match exception
- 7Approve and pay
Quote-to-order
- 1Qualify lead
- 2Track opportunity
- 3Build quote with price waterfall
- 4Apply contract or price book
- 5Release sales order
Warehouse cycle
- 1Receive and inspect
- 2Put away to bin
- 3Pick with scan task
- 4Blind count
- 5Plan load and ship
AI-assisted change
- 1Open AI proposal
- 2Review evidence and diff
- 3Check uncertainty and boundary
- 4Prepare draft for approval
07b
AI capabilities
Reviewable AI proposals
A dedicated drawer shows an AI suggestion's purpose, supporting evidence, before/after diff and uncertainty. It is clearly marked as not committed until a human approves.
Governed AI data model
Thirteen schema tables cover model policies with spend limits, allowlisted tools and grants, budgeted runs, proposals, evidence citations, action receipts and safety evaluations.
Planned grounded assistance
Roadmap items: document extraction with citations, quote and price explanation, bid summaries, forecasting and exception triage. Autonomy is tiered from read-only up to approval-required financial actions.
08
Engineering challenges
- 01
Ledger correctness inside the database
Deferred constraint triggers reject unbalanced journals at commit and block mutation of posted lines. Accounting truth does not depend on application code.
- 02
Concurrency-safe stock reservation
Scoped writers and guards ensure the last unit cannot be reserved twice and a retried posting batch cannot deduct stock twice.
- 03
Multi-tenant, multi-company isolation
474 row-level security policies with restricted roles, composite scoped foreign keys and fail-closed empty context, all checked by automated tests.
- 04
Keeping 480 tables coherent
A machine-readable schema model, a feature-to-entity map and Node validators keep table, column and FK counts consistent with the docs and 32 ER diagrams.
09
Technical differentiators
Explainability first
Price waterfalls, plain-language match explanations and decision previews show users why something happens before they commit.
Correctness by construction
Money, stock, idempotency and isolation rules live in PostgreSQL guards rather than only in services.
AI that proposes, never silently acts
Every AI suggestion carries evidence and a diff and requires approval. Executed actions leave a permanent receipt.
Falsifiable product goals
Each candidate differentiator has a measurable pass/fail evidence gate instead of a marketing claim.
10
Explore further
The source repository is private. A live walkthrough is available on request.