Loading…
SKIP TO CONTENT
A/L
SYS_010BUILDING

Trading Software

Produce Purchase, Sale & Accounts

Multi-company back office for a produce trader: market and farmer purchases, overnight bill generation, vouchers and reports.

TYPE
TRADING ERP
STATUS
BUILDING
YEAR
2026
ROLE
System design, legacy migration, full-stack implementation
PLATFORM
Flutter (desktop web, mobile web, Windows), Node.js API
STACK
Flutter · Dart · Node.js · Express · MySQL · REST
01

PROBLEM

A produce trader buys from market agents and directly from farmers during the day and sells the same lots on to buyers in other towns. Each lot is already earmarked for a buyer when it is bought, so the sale side is mostly known — but it still has to be billed, freighted, collected and accounted, every day.

The business ran on a legacy desktop application that several operators shared. It worked, its totals were trusted, and it could not be reached from anywhere but the office.

02

SYSTEM

Purchases are entered with their resale already attached. An overnight bill-generation run turns the day’s earmarked lots into sale bills per buyer with that buyer’s charges applied, and running it again replaces only machine-made bills — never anything an operator typed.

Receipts and payments post through voucher types into ledgers, and every company in the group keeps its own books and financial years behind a single login.

The same API serves a desktop web app for the office and a separate phone-sized web app, so the owner can see the position without a desktop.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / PURCHASE TO LEDGER
  1. Accounts, items, cities, vehicles, transporters and per-item rate cards
  2. Market and farmer purchases, each lot earmarked for a buyer
  3. Overnight generation of buyer bills from earmarked lots
  4. Manual sale entry and adjustment, including freight
  5. Cash and bank receipts and payments posted to the ledger
  6. Ledgers, outstanding, registers, cash book and annual statements
SELECT OR HOVER A NODE FOR DETAIL

Flow from masters through purchase, overnight bill generation, sale entry and vouchers into reports.

04

KEY MODULES

M01Masters
One registry-driven screen for all reference data; records deactivate, never delete.
M02Market purchase
Grid entry for lots bought from market agents, with resale columns.
M03Farmer purchase
Direct purchase with a printed settlement slip for the farmer.
M04Bill generation
Bulk creation of buyer bills; re-runs replace only generated bills.
M05Sale entry
Bill lines by origin, item, bags, weight and rate, with freight.
M06Vouchers
Six cash and bank voucher types posting into ledgers.
M07Print designer
Editable layouts with paper sizes, images and amount in words.
M08Reports
Around twenty-five reports from one screen, with print and CSV export.
M09Sharing
Documents sent over WhatsApp with retry for failed sends.
M10Administration
Users, roles, permissions, companies and financial years.
05

ARCHITECTURE

Client
Flutter desktop web app and a separate mobile web app over the same API.
API
Node.js and Express with permissions checked server-side as module.action.
Tenancy
Every table carries a company; sign-in goes login, company, financial year.
Money
Integer fixed-point arithmetic throughout — no floating point in any total.
Data
MySQL with numbered, checksummed migrations and audit fields on every row.
Deployment
Windows Server with IIS; one build produces both web bundles.
06

ENGINEERING

The parts that were not obvious, and what the system does about them.

  1. 01 / 03

    Several operators saving at once

    Document numbers must stay gap-free per series under concurrent saves. Atomic sequences, row versions that reject stale edits, transaction retries and idempotency keys mean a double tap or a retried request never creates a second bill.

  2. 02 / 03

    Matching the old system to the paisa

    Totals had to agree with the legacy application, including how it rounded. Money is integer fixed-point end to end, and the old rounding is reproduced deliberately and covered by tests.

  3. 03 / 03

    A re-runnable bill generation

    Operators sometimes need to regenerate a day. Generated bills are marked as such, so a re-run replaces exactly those and leaves hand-entered bills untouched.

07

SCREENS

  1. SCREEN_01Market purchase grid with resale columns
  2. SCREEN_02Bill generation run
  3. SCREEN_03Report screen with export
08

RESULT

The day’s purchases become the night’s bills without retyping, and the books follow from vouchers rather than a separate write-up.

Several companies and financial years run behind one login, reachable from the office desktop or a phone.