Tradivoo
A management system for trading and production businesses: purchasing, inventory, production planning, sales and books.
- 560
- Products
- 12
- Warehouses
- 1
- System
What they came with
Trading and production businesses tend to run on a stack of spreadsheets and one accounting package that knows nothing about the warehouse. Stock is counted in one file, purchase orders live in another, and at month end someone reconciles the two by typing figures across. Tomorrow's production run gets planned from memory and last week's sales, so the factory makes what it made before rather than what is selling. Tradivoo puts purchasing, inventory, production, sales and the books on one data model, so a goods receipt moves the stock figure and posts to the ledger in the same breath.
What the engagement covered
- Purchasing, inventory, sales and accounting on one data model
- Multi-warehouse stock and point of sale
- Ledgers and books that reconcile to operations
- Forecast per item from history, pre-orders and par levels
- Sub-recipe batches and raw ingredients computed automatically
- Event modifiers and manual overrides with approval
Technical detail
Stock is derived from movements
There is no on-hand column to go stale: quantity is summed from an append-only movement table keyed by item, warehouse and batch. A nightly snapshot row per item and warehouse keeps the read cheap, so a balance is one snapshot plus the movements since it, and a correction is a reversing movement rather than an edit.
Goods receipt and journal in one transaction
A receipt writes the stock movement and its journal lines inside a single Postgres transaction, so the warehouse figure and the ledger cannot drift apart. Postings are immutable once committed; a mistake is fixed with a contra entry, which leaves both trails readable.
Reorder checks run off the write path
Reorder points are evaluated by a scheduled job against derived stock rather than on every movement, so receipts and issues stay cheap to write. Redis holds the job lock and the last-raised marker, so two workers cannot raise the same flag twice for the same item.
The planner proposes, a person commits
The Python planner reads sales history and par levels and writes a draft run, with the figures it used shown on each line. Nothing is reserved and no purchase demand exists until someone commits the draft, at which point the run allocates stock and raises requisitions in one step.
The stack
Interface
Application services
Data and jobs
Planning and deployment
- Sector
- Trading and production
- Audience
- Traders and manufacturers
- Shape
- Built, shipped and run by us
- Stack
- Next.js, NestJS, PostgreSQL
Something like this to build?
Tell us what runs today and where it hurts. An engineer reads it and replies.