Loading…
SKIP TO CONTENT
A/L
SYS_009BUILDING

Adat Software

Commission Agent Trading & Accounts

Produce arrivals, buyer bills, farmer settlements and the full books for agricultural commission agents.

TYPE
MANDI ERP
STATUS
BUILDING
YEAR
2026
ROLE
System design, legacy migration, full-stack implementation
PLATFORM
Flutter (Windows counter, Android, Web), Node.js API
STACK
Flutter · Dart · Node.js · Express · MariaDB · SQLite · REST
01

PROBLEM

A commission agent in a produce market sits between two sets of people who both want to be paid correctly the same day. Farmers bring lots in the morning, buyers take them by afternoon, and by evening every lot has to appear twice — once on the buyer bill and once on the farmer settlement — with market charges and commission applied to each side.

Most agencies were running this on an ageing desktop system that only worked on one counter, stored regional-language text in an old font encoding, and could not be reached from a phone. Replacing it meant reproducing years of trusted numbers exactly, not approximately.

02

SYSTEM

Adat Software treats the daily lot register as the centre of the business. Recording who brought a lot and who took it produces both the farmer settlement line and the buyer bill line at once, so the two sides of a trade cannot drift apart.

Charges are configuration, not arithmetic typed at the counter: item-wise and market expenses are applied automatically on every transaction. Settlements, bills, receipts and vouchers flow into a complete set of books, and market auction data can be pulled in instead of re-keyed.

Counters run a Windows app with an encrypted local copy of the data, so the agency keeps working through a dropped connection; owners get a separate mobile view of ledgers, receipts and reports.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / ARRIVAL TO SETTLEMENT
  1. Farmer lots recorded with item, quantity and lot mark
  2. Daily register of who brought what and which buyer took it
  3. Sale bill per buyer with item-wise charges applied automatically
  4. Farmer settlement net of commission and market expenses
  5. Receipts, payments, cheques and bank entries; settlements marked paid
  6. Ledgers, day book, outstanding and sale registers
SELECT OR HOVER A NODE FOR DETAIL

Flow from farmer arrival through the lot register, buyer bill, farmer settlement and payment into the books of accounts.

04

KEY MODULES

M01Masters
Accounts, items, cities, transport, banks and company settings.
M02Charge settings
Item-wise and market expense rules applied automatically per transaction.
M03Lot register
Live daily register that drives both the buyer and the farmer side.
M04Entries
Inward, sale, market purchase and sale, farmer purchase and vouchers.
M05Bill generation
Buyer bills and farmer settlements produced from the day register.
M06Market integration
Auction and weighbridge data pulled in with item mapping and a live monitor.
M07Print designer
Bills laid out over a photo of the agency’s own printed stationery; batch printing.
M08Reports
Two dozen reports from one shared report screen, all printable to PDF.
M09Sharing
Documents sent over WhatsApp, with push notifications.
M10Mobile
Owner view of ledgers, receipts, entries and reports on a phone.
M11Platform
Subscriptions, device management, remote updates and a superadmin console.
05

ARCHITECTURE

Client
One Flutter codebase: Windows counter app, web, and a separate mobile UI.
API
Node.js and Express over MariaDB with hand-written, checksummed SQL migrations.
Tenancy
Every row carries a tenant; language and script are per-tenant settings.
Offline
Encrypted local store on each counter, synced by a full load and then deltas.
Devices
Each PC registers on first use and can be revoked remotely, wiping its local data.
Integrations
Third-party services are called from the server so keys never reach the client.
06

ENGINEERING

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

  1. 01 / 04

    Replacing a system people already trust

    The legacy desktop schema was mapped table by table into a relational design, including numbering quirks where several lines shared one document number. The new system had to produce the same figures as the old one before anyone would switch.

  2. 02 / 04

    Regional-language text in an old font encoding

    Years of names and captions were stored as 8-bit font glyphs rather than real characters. They were converted to searchable Unicode using a table built from the old system’s own mapping, so data stays readable and findable.

  3. 03 / 04

    Printing Devanagari reliably

    PDF libraries shape complex scripts badly. Documents are rendered as Flutter widgets and captured into the PDF, which prints exactly what the screen shows on any printer.

  4. 04 / 04

    Offline sync that stays correct during a full load

    Data keeps changing while a counter downloads its first copy. Taking the sync cursor before the full load and applying deltas afterwards means nothing written in between is lost.

07

SCREENS

  1. SCREEN_01Lot register — arrivals and buyers for the day
  2. SCREEN_02Farmer settlement with charges and commission
  3. SCREEN_03Print designer over the agency’s stationery
  4. SCREEN_04Mobile — ledger and receipts
08

RESULT

The buyer side and the farmer side of every trade are produced from one record, and the books follow from the day’s entries instead of being written up separately.

Counters keep billing through a dropped connection, and owners can check ledgers from a phone instead of calling the office.