Field orders are won or lost in places the network does not reach — basements, rural beats, market lanes at noon. An order pad that needs a signal fails exactly where coverage matters most, and every failure teaches the rep to write orders on paper and "enter them later". Offline-first order capture means the opposite design: the app assumes there is no network, works completely without it, and treats connectivity as an optimisation.
What has to be on the device
Capturing an order offline is easy; capturing a correct order offline is the hard part. The xMatix mobile app carries the working set down to the device: the catalogue with pack sizes and current stock signals, customer-specific pricing, active schemes and slabs, and the outlet's credit position and outstanding. The order the rep builds at the counter is priced and validated the way the server would price it — not a wish list to be corrected at the depot.
The write path: durable, not hopeful
Orders are written to a local database first and queued in a durable outbox — every edit survives the app being killed, the battery dying, or three days without signal. When connectivity returns, delta sync reconciles changes in dependency order. The engineering is described plainly in the offline sync architecture and designing a durable outbox for the last mile; the vocabulary in what is an offline sync engine.
Fast entry is a feature, not a nicety
A rep keys dozens of orders a day, many with long tails of lines. The order screen is built for high-frequency entry — search-as-you-type, recent and suggested items, quantity entry that respects pack hierarchies — and suggested order quantities give the conversation a starting point grounded in the outlet's own offtake rather than in memory. Voice-first entry is part of the same story: speak the order, don't tap it.
From captured to fulfilled
A synced order is not a spreadsheet row — it lands in the order-to-cash flow with credit checks, fulfilment staging and GST-compliant invoicing, and shows up in secondary sales visibility the same day. The rep sees the order's status on the next visit, which is what makes the outlet trust the process enough to keep ordering through it.
Common questions
Does the app really work with no connectivity at all?
Yes — offline is the designed-for case, not a degraded mode. The catalogue, pricing, schemes, credit position and the day's visit plan are synced to the device in advance; orders, visits and activities are captured locally and reconciled later. A rep can run a full day — capture to invoice in van-sales mode — without signal.
How are prices and schemes correct when the device is offline?
Customer-specific pricing and active scheme definitions travel to the device with the sync, so the order is priced at the counter the way the server would price it. When the order syncs back, the server recomputes and remains the authority — silent drift between device and server pricing is exactly what the design prevents.
What happens if the app is killed or the phone dies mid-order?
Order lines are written to the local database as they are entered and queued in a durable outbox. Restarting the app resumes from the last write; nothing rides on the process staying alive or the network coming back at a convenient moment.
How do offline orders avoid duplicates when they sync?
Each captured order carries a stable client-side identity, so a retry after an interrupted sync completes the same order rather than creating a second one. Sync conflicts surface for resolution instead of silently overwriting either side.
What does the back office see, and when?
As soon as an order syncs it enters the normal order-to-cash flow — credit check, fulfilment, invoicing — and appears in coverage and productivity dashboards. There is no separate "field orders file" to import; the field and the office share one system of record.