Loading…
SKIP TO CONTENT
A/L
SYS_011LIVE

Arkam Foods Online Portals

Field Replacements & Salesman Expenses

Two field portals and a back office for a food distributor: product replacements at outlets and salesman expenses, each with approvals.

TYPE
FIELD SALES
STATUS
LIVE
YEAR
2026
ROLE
System design, full-stack implementation
PLATFORM
Flutter (Android, Web PWA), two Node.js APIs
STACK
Flutter · Riverpod · Node.js · Fastify · MySQL · Neo4j · REST
01

PROBLEM

A food distributor’s salesmen cover fixed routes of shops. Two things happen on every route that the office needs to know about: goods that a shop wants replaced, and money the salesman spends to run the route.

Both were handled on paper slips and phone calls. Replacement quantities were disputed after the fact, expenses were settled from memory, and nobody could see by route or by item where replacements were piling up.

02

SYSTEM

The system is two focused field portals on top of one back office. The Replacement app records replacement slips at each outlet; the Expense app is the salesman’s expense book. Each does one job on a phone in a shop, rather than one app trying to do everything.

Every slip and voucher goes to the back office for approval, and approval is per line and per quantity: a single slip can be partly approved, partly held and partly declined, from whichever angle the manager prefers — by slip, by item or by route.

Who approves what is resolved from the company’s reporting hierarchy, held as a graph, so approval routing follows the org chart instead of being hardcoded.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / ROUTE TO APPROVAL
  1. Salesman fixes the day’s route; the app remembers it
  2. Party searched and selected at the shop
  3. Item lines with quantities, location-tagged, printed or shared
  4. Expense types and amounts recorded against a vehicle
  5. Per-line, per-quantity decisions by slip, item, route or salesman
  6. Route orders, replacement lines and the expense ledger, exported
SELECT OR HOVER A NODE FOR DETAIL

Flow from the salesman’s route through outlet selection, replacement slip and expense entry to approval and reports.

ARCH_02 / ONE BACK OFFICE, TWO FIELD PORTALS
ADMIN PORTAL
  • Replacement slips at outlets, corrections, thermal receipts
  • Expense vouchers, cash handover and the salesman’s expense book
SELECT OR HOVER A NODE FOR DETAIL

An admin portal with two field portals beneath it: the replacement app and the expense app.

04

KEY MODULES

M01Admin portal
Companies, users, org chart, masters, approvals, reports and dashboards.
M02Replacement wizard
Party, item lines with quantity steppers, review and slide-to-confirm.
M03Corrections
Quantity changes formally amend a saved slip instead of editing it.
M04Thermal receipts
Bluetooth 80 mm printing with a PDF fallback; reprints marked duplicate.
M05Replacement approval
Approve, hold or decline quantities by slip, by item or by route.
M06Expense wizard
Expense types and amounts, vehicle, review, saved as a voucher.
M07Cash handover
Money given to and received back from salesmen, as vouchers.
M08Expense approval
Decisions per line by expense type or by salesman.
M09Expense ledger
By day, salesman and voucher, exported as CSV, Excel or PDF.
M10Integration API
Keyed per company: master sync both ways and a read-only replacement feed.
05

ARCHITECTURE

Clients
Three Flutter apps — admin portal as an installable PWA, two Android-first field portals.
APIs
Two Fastify services over one schema: a back-office API and a field API for the phones.
Data
MySQL for records; Neo4j for the reporting hierarchy, visibility and approval routing.
Tenancy
Every row carries a company; six roles gate navigation and data.
Auth
Short-lived tokens with single-flight refresh and a uniform response envelope.
Deployment
APIs on Windows Server with IIS; web apps built as static sites.
06

ENGINEERING

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

  1. 01 / 04

    Documents that can be corrected but not rewritten

    A printed slip has been seen by the shop. Corrections are numbered amendments made in one transaction, copy numbers never collide, and every reprint is logged as a duplicate — enforced on the server, not trusted to the app.

  2. 02 / 04

    Approval at the level of a quantity

    Managers rarely approve a whole slip. Splitting each line into approved, held and declined quantities — reachable from three different drill-downs — needed a decision model with history rather than a status flag.

  3. 03 / 04

    Field capture that never blocks a save

    Location is best-effort with a timeout and records why it failed, and Bluetooth printing falls back to a shareable PDF. A salesman standing in a shop is never stuck waiting on a sensor.

  4. 04 / 04

    Routing approvals through an org graph

    Who can see a voucher and who decides next depends on the reporting hierarchy. Holding that hierarchy as a graph alongside the relational data makes approval routing a query rather than a set of hardcoded rules.

07

SCREENS

  1. SCREEN_01Replacement app — item lines and review
  2. SCREEN_02Thermal receipt for a replacement slip
  3. SCREEN_03Expense app — add expense
  4. SCREEN_04Admin portal — approval by route
08

RESULT

Replacements and expenses are recorded where they happen, and every quantity and amount carries a decision and a history instead of a dispute.

The office can see by route, item and salesman where replacements and spend are going, and outside systems can pull the same data through the integration API.