Overview
> Realistic scenario notice: The company described below is a composite of real operational patterns > common to Syrian FMCG distributors. Names, figures, and results are illustrative; they are not > drawn from a named or verified client engagement.
A fast-moving consumer goods (FMCG) wholesaler operating out of Aleppo distributed products from several national suppliers to more than 500 retail outlets — small grocery shops, supermarkets, and corner stores — spread across the city and several surrounding towns.
The business ran eight delivery vans, each staffed by a driver and a salesperson who visited a fixed route of clients on a rotating schedule. At the start of each day, vans were loaded from the central warehouse. At the end of the day, unsold goods were returned, cash was handed over, and invoices were reconciled manually.
This model had worked for years. But by 2025, the cracks were too wide to paper over.
---
The Business Problem
No visibility into van-stock during the day
Once a van left the warehouse, the operations manager had no way to know what had been sold, what remained on the van, or whether a salesperson had offered an unauthorized discount. If a large client needed a rush order and the nearest van was already in the area, there was no way to check whether that van had the right stock. The answer was always the same: "Call the driver."
Cash reconciliation happened days late
Each salesperson collected cash, issued handwritten invoices, and returned with a bundle of paper at day-end. The finance team manually matched invoices against the cash collected, often finding discrepancies that took two or three days to investigate. Some client balances were tracked in notebooks; others in a shared Excel file that multiple people edited simultaneously.
Returns and swaps were untracked
When a client refused a delivery — wrong product, overstock, damaged goods — the salesperson often swapped the item on the spot or simply brought it back. These returns were logged inconsistently, sometimes appearing in the books, often not. This created phantom stock in the warehouse and distorted the picture of which products were actually moving.
Route planning was experience, not data
Routes had been designed years earlier based on driver knowledge. When a new client signed up, they were assigned to the nearest driver's route informally. There was no analysis of which routes were profitable, which clients were buying consistently, or whether the routing made geographic sense.
---
What Dragonfly Soft Built
The engagement centered on a custom ERP tailored specifically to route-based FMCG distribution, with three interconnected components: a warehouse and dispatch module, a driver mobile application, and a back-office management dashboard.
1. Warehouse and Dispatch Module
Before a van is loaded, the dispatcher enters the planned route for that day. The system generates a van manifest — a list of clients in visit order, each with an expected order based on purchase history, and a suggested stock allocation for that van derived from current warehouse inventory.
Each product is assigned to a specific van by scanning barcodes at loading time. The warehouse inventory record is immediately updated: goods move from the warehouse ledger to the van ledger. The warehouse team can see, at any moment, which products are on which van versus what remains on the shelves.
2. Driver Mobile Application
The salesperson carries a mid-range Android device running a lightweight mobile app built with React Native. The app works offline — a critical requirement given patchy mobile connectivity in several delivery areas — and syncs with the server whenever a connection is available.
For each client visit, the salesperson sees the client's outstanding balance, their last orders, and any promotional pricing active for that day. When an order is confirmed, the app generates a digital invoice and prints it via a small Bluetooth thermal printer carried in the van.
Key flows supported by the app:
- Order entry and digital invoice generation — replaces handwritten invoices
- Full or partial delivery confirmation — salesperson marks each line as delivered, short, or refused
- On-the-spot returns — the app creates a linked return document, reducing quantity on the van ledger and flagging it for warehouse receiving
- Cash and credit recording — payment method (cash, credit, partial) is recorded per invoice
- Offline mode — all data is stored locally using SQLite; sync happens automatically when connectivity returns
3. Back-Office Management Dashboard
The web dashboard, built with a Vue.js frontend and a Node.js/PostgreSQL backend, is the operations team's central view:
- Live van tracking panel — shows each van's current stock value, cash collected so far, and number of clients visited vs. planned
- Day-end reconciliation — when the driver submits the day-end report from the app, the system automatically compares cash declared against invoices issued and flags discrepancies for review
- Client ledger — each client has a running balance; credit limits can be set; overdue accounts are highlighted
- Return management — returns received at the warehouse are confirmed by a warehouse user, which closes the return document and restores the product to warehouse stock
- Route analytics — after several weeks of data, the operations team can see revenue per route, revenue per client, and hit rate (what percentage of planned visits resulted in an order)
---
Technical Approach
Offline-first mobile design
The most significant technical challenge was building an app that works reliably in areas with intermittent connectivity. The team chose an offline-first architecture: the app treats the local SQLite database as the source of truth for the current workday. All actions — orders, deliveries, returns, payments — are written locally first. A background sync process uploads completed documents to the server and pulls down updated client balances and product pricing.
Conflict resolution was straightforward in this case because the data model was write-once per entity: each invoice is owned by one salesperson on one device. The only shared data that could conflict was client balances (if the back office updated a credit limit while the driver was offline), and this was handled by giving the server value precedence on next sync, with a notification shown to the salesperson.
Van-level inventory ledger
Rather than tracking inventory only at the warehouse level, the system maintains a location-aware stock ledger with three location types: warehouse, van, and in-transit-return. Every stock movement — loading a van, making a sale, recording a return — creates an immutable ledger entry. The current stock position for any location is derived by summing the ledger. This made reconciliation auditable and eliminated the phantom-stock problem caused by unlogged returns.
Thermal printing via Bluetooth
Clients in Syrian retail contexts expect a physical invoice at the point of delivery. The app pairs with a Bluetooth printer on first use and remembers the pairing. Invoice templates are stored locally on the device (as HTML rendered to a bitmap) so printing does not require a server round-trip. The template matches the company's standard invoice layout, including their logo, client name, itemized list with quantities and prices, VAT line, and total due.
Role-based access
The system supports four roles: warehouse operator (can confirm loads and returns), salesperson/driver (mobile app only), operations supervisor (full dashboard, read-only on financials), and finance manager (full access including client balance adjustments and day-end sign-off). Each role sees only the screens relevant to their function.
---
Operational Changes After Deployment
> Important: The following describes the kinds of operational improvements typically reported after > deploying systems of this type. They are illustrative, not measured results from a verified engagement.
Day-end reconciliation time dropped significantly. Because digital invoices are matched automatically against recorded payments, the finance team's daily close process shifted from manually counting paper to reviewing a pre-generated exceptions report and signing off.
Van returns became traceable. Every return generates a document that follows the product from the salesperson's confirmation back to warehouse receiving. Warehouse staff no longer discovered mystery stock that did not match any record.
Client credit visibility improved. The operations team could see, in real time, which clients had exceeded their credit limit, allowing them to instruct the salesperson during the day rather than discovering problems at month-end.
Route data began to accumulate value. After two months of operation, the route analytics panel showed that two routes had consistently low order-hit rates and that one route was generating a disproportionate share of returns from a cluster of clients — information that informed a commercial conversation with the relevant supplier.
---
Implementation Notes
The project ran across three phases:
Phase 1 — Discovery and data migration (3 weeks): Existing client records, product lists, and opening balances were cleaned and imported from spreadsheets. Route assignments were formalized. The warehouse team was consulted on how loading and returns actually worked day-to-day, which surfaced several edge cases not captured in the initial brief.
Phase 2 — Backend, dashboard, and pilot (6 weeks): The server, database schema, and dashboard were built first. Two routes ran on the mobile app in parallel with the old paper process, allowing discrepancies to be caught before the system went live exclusively.
Phase 3 — Full rollout and training (2 weeks): All eight vans moved to the app. Drivers and salespersons received hands-on training in a half-day session; the most effective training material turned out to be a printed quick-reference card for the most common app flows.
---
When This Pattern Applies
A route-based distribution ERP of this kind is well-suited to any wholesale or distribution business that:
- Operates multiple delivery vehicles with dedicated daily routes
- Has salespeople who collect cash or offer credit at the point of delivery
- Returns goods to the warehouse from the field
- Needs to reconcile van stock with warehouse records at day-end
- Operates in areas where mobile connectivity is unreliable
The core architecture — offline-first mobile client, location-aware stock ledger, server-side reconciliation — applies equally to bottled water distributors, pharmaceutical last-mile delivery, construction materials suppliers, and any other business moving physical inventory through field sales teams.
---
Working With Dragonfly Soft
If your distribution business is managing routes, cash, and returns through spreadsheets and phone calls, the gaps in visibility and the daily reconciliation burden are likely growing as your operation grows.
We work with businesses in Syria and the region to design and build practical software solutions tailored to local operating conditions — including unreliable connectivity, cash-based transactions, and the need for Arabic-language interfaces.
Get in touch with our team to discuss how a custom distribution ERP could work for your operation.
