A distributor’s field and ordering system
Reps, dealers, suppliers and head office work from one set of numbers across 93 branches. Orders are still priced and billed in the ERP the branches already had.
How it was builtEach order is typed once, on a phone in a dealer’s shop or in a browser, and nobody types it again at the branch. The software that keeps your books today goes on keeping them.
Each order is entered once, in the field or in a browser, and stock from a branch whose feed has stopped is marked with the date it was last read.
The read side is a snapshot of the ERP, rebuilt every two hours through the working day, with each branch read from the live stock feed or from a fallback copy. Writes go to a Postgres store beside the ERP and travel back to the branches as files and email.
A field and ordering system built by 64ARCS has been in daily use across a parts distributor’s 93 branches since July 2026. Its production Android app went on the Play Store on 14 July 2026. Two products of 64ARCS’s own, PathWay AI and 64Griddle, have been open in a browser as pilots since 15 September 2026.
Choose the level of detail.
Plain words, no jargon.
If you write software, start at Engineering detail.
Stock, prices, dues and credit limits are each kept in one place. In the distributor’s system, stock for two in three branches comes from the live feed. The rest comes from a copy that runs about a day behind, and a branch whose copy has stopped updating shows its date next to its stock.
Customer, stock, price and credit limit each come from one place. Two in three branches are on the live stock feed. The others fall back to a copy about a day behind, and rows from a branch whose feed has stopped carry their as-of date.
The ERP sits on-premises behind a slow WAN link, so the read side is baked into the container image as read-only SQLite and rebuilt every two hours from 07:00 to 19:00 IST. A branch is read from the live stock master when its newest reading is under three days old, and otherwise from a fallback copy that lags about a day. Of the 93 branches, 62 read live. The supplier screen shows each branch’s as-of date, transfer suggestions state the source branch’s date, and stock rows from a dormant branch carry a dated warning. A fallback branch with no purchase in over 45 days is flagged dormant and is never offered as a source for a transfer.
It is written for your business. It reads from the software your books already run on, sends orders back into it, and keeps what that software was never built to hold, such as field visits, attendance and credit decisions.
Nothing has to be migrated. It reads from the ERP and writes back through it, and keeps field activity, attendance and credit decisions, which the ERP has nowhere to put, in a separate store beside it.
In the one built so far, the ERP is 1,087,117 lines of hand-written VB.NET and keeps the books. A write store on Cloud SQL Postgres holds what it cannot: field activity, orders, attendance and credit decisions, with photographs in object storage. The captured order lives there, and the priced sales order lives in the branch ERP, as it always has.
Reps on the road, dealers ordering at night, suppliers and head-office staff each see the screens their job needs, on a phone or in a browser, in any of thirteen languages. An order taken where there is no signal waits on the phone and goes in when the signal returns. It cannot go in twice.
Reps, dealers, suppliers and head office each see what their role needs of the same orders, stock and dues, on Android and the web, in thirteen languages. Orders taken without signal queue on the phone and post when it returns, and a retried order is booked once.
Reps, dealers, suppliers and head office share one web front-end in thirteen locales, with each role fenced on the server. The Play Store app is a Trusted Web Activity around that front-end, so a feature ships with a web deploy. The phone keeps an outbox of orders taken offline. Each cart carries a client-generated transaction ID that is reused on every retry, so a post that timed out is booked once. The file sent to the branch is named after the order ID, and the ERP refuses a filename it has already saved.
Before an order is saved, the server checks the dealer’s dues and credit limit again against head office’s own record, whatever the phone showed. If the dealer is over the limit, had a cheque bounce in the last 120 days, or has a bill 90 days or more overdue, the server sends the order back with the reasons, and nothing is saved yet. The rep can confirm and book it anyway, and the reasons stay on the order for good. A dealer ordering from their own login cannot confirm past it. A payment and the photograph of its receipt are saved together, or neither is.
Credit is re-checked on the server against head office’s own dealer record before an order is written, a soft block, not a refusal. Where a rep confirms past it, the reasons stay on the order and show on its card. A dealer’s own login cannot confirm past it. A payment and its proof photograph commit together, or neither is recorded.
The order endpoint re-derives the credit level and answers 409 with needs_ack and the reasons unless the request carries an acknowledgement, so a client running old code cannot skip it. For a customer login the acknowledgement is forced false. Acknowledged reasons are persisted on the order row. A payment and its proof photograph arrive in one multipart request and commit on one connection, and the old proof-less path answers 426. The file sent to the branch carries no rates, and the branch ERP prices the order from its own masters at save.
Where a standard package already fits the way you work, it stays, and 64ARCS builds only the part it cannot do.
One is the distributor’s system. The other two are early products of our own, both browser pilots, and each has a panel on the Products page that says where it stops.
Reps, dealers, suppliers and head office work from one set of numbers across 93 branches. Orders are still priced and billed in the ERP the branches already had.
How it was builtA student works on an assignment inside the terms their teacher set, and the session is kept as a record both of them see. It shows how the work happened and does not judge who wrote it. Replies are prepared examples, and no generative model is connected.
What it does, and where it stopsIt reads an AI prompt before you send it, marks where an assistant would have to guess, and offers wording that you accept or reject. Version 0.5.3 runs on local rules in the browser and makes no network requests.
What it does, and where it stopsWe sit in your branches and watch how the work is done today.
Together with you, we settle where each number lives and who may change it.
It is written in small pieces, and you see each one working before the next begins.
Orders reach your system with no rates on them. It prices them, and nobody retypes anything.
We stay on afterwards. A piece is replaced only after you have watched the new one run beside it.
We sit in your branches and write down the exceptions and workarounds that never reach the org chart.
We agree which system owns each fact, what gets connected and what gets built.
Each slice goes in front of a branch as soon as it works.
Orders write back through your ERP and are priced there, so nobody retypes them.
We stay on, and any replacement runs beside the original before it takes over.
Sit in the branches, trace every place a fact is contradicted, and find out which copy people trust.
Agree the owner of each fact, where each rule is enforced, and the one write path.
The server comes first, with its rules, transactions and migrations, and the apps follow in slices that ship.
Read from snapshots of the ERP, and write back through one deduplicated path that the ERP prices at save.
Replace a module only after it has run beside the original, read-only, on real data.
Sometimes you don’t need us. Some problems are a process fix, not a platform. If a spreadsheet is already doing the job, it stays, and you will hear that early.
GST, TDS, dealer schemes and WhatsApp, for businesses in India
If your branches each hold a different figure for the same stock or the same dues, write to hello@64arcs.com or use the form. A person reads it and replies within two working days. The first call is sixty minutes on how your operation runs, no deck.