Field service management, native to Accredo Saturn.
Field service management is the scheduling, dispatch and on-site capture of work done away from the office. XBA builds it as a module of Accredo Saturn rather than a product beside it: one dispatch board, jobs closed on site, and completed work posted straight to the Saturn ledger — invoice-ready, with nothing re-keyed.
Personal reply from Andrew within one business day.
What was the problem?
A multi-branch services operation was scheduling technicians out of a whiteboard, a shared calendar and three spreadsheets, then re-keying every completed job back into Accredo Saturn by hand.
The re-keying is the expensive part, and it is worth being precise about why. It is not the typing. It is that between the technician finishing the work and someone entering it into Saturn, the record exists only in a person's memory and on a docket in a van. Every hour in that gap is an hour in which a part is forgotten, a labour line is rounded, a job is invoiced for the wrong customer site, or the invoice simply does not go out. By the time the discrepancy surfaces it is a credit note and a phone call, not a correction.
The scheduling problem compounds it. When the dispatch picture lives in three places, the version a technician is working from and the version the office is working from diverge during the day, and neither is the version that ends up in the ledger. Any fix that solved scheduling but left the ledger to be typed up afterwards would have solved the visible half of the problem and none of the expensive half.
What was actually built?
A single web-hosted application with three views — the dispatch board, the technician's own run for the day, and the job detail screen where parts and labour are logged. It reads and writes against the client's Saturn install; it does not keep its own copy of the truth.
Leak repair — Harbour Apartments
// Click the sidebar to switch views. Demonstration data — the real module runs inside the client's Saturn install.
Three design decisions did most of the work here, and none of them are about the interface.
The application holds no master data of its own. Customers, sites, products and price rules are read from Saturn at the point they are needed rather than synchronised into a second database on a schedule. A synchronised copy is a second source of truth with a delay built into it, and the first time the two disagree at month-end, the argument about which one is right costs more than the sync ever saved. The trade-off is real — the module depends on Saturn being reachable, and it is slower than reading a local cache — and it was accepted deliberately.
Validation happens before a technician can close a job, not after. Product codes, customer sites and locations are checked against live Saturn data while the job is still open on the technician's screen. A part number that no longer exists is a five-second correction on site and a twenty-minute reconciliation a week later; the cheapest place to catch a bad record is the place it is created.
Every post is idempotent and carries a reference back. A field application runs on phones, in basements, on rural roads, and it will retry. If a retry can post the same job twice, it eventually will, and the ledger is where that becomes expensive. Each completed job carries its own identifier through to the Saturn transaction, so a repeated submission is recognised rather than duplicated — and the resulting invoice can be traced back to the exact job, technician and timestamp that produced it.
How does a field app get data into Accredo Saturn?
There are two supported routes, and the design decision is which data goes down which one. Reads and standard records travel the OData API. Transactional writes that have to land cleanly use native MaxBasic, posting directly the way Saturn posts to itself. Both treat the ledger as the single source of truth.
parts & labour
OData API or native MaxBasic — which one, and when?
| Path A · OData API | Path B · Native MaxBasic | |
|---|---|---|
| What it is | Saturn's supported web service. An external application talks to the ledger over OData/REST, in the way any modern system expects to. | Accredo's own scripting language, running inside Saturn against its native posting routines. |
| Best for | Reads of any kind, and writes of standard records — a customer, a contact, a job header. | Transactional writes: anything that has to move the ledger and its sub-ledgers together. |
| Why choose it | Supported, documented, versioned, and reachable from anything with an HTTP client. Nothing to deploy inside Saturn. | Posts the way Saturn posts to itself, so the transaction obeys every rule the product enforces on its own users. |
| Where it falls short | Not everything a transaction needs to do is exposed as an endpoint, and a partially-applied write is far worse than a rejected one. | Runs on the client's own install, so it has to be deployed, versioned and documented there — it is not a remote call. |
| Used here for | Customer, site and product lookups; job records; every validation check the technician's screen performs. | Committing a completed job — parts, labour and the resulting invoice — as one native transaction. |
// The wrong path is how integrations corrupt ledgers. Choosing correctly is the specialty.
The short version of that table: use the API wherever it can do the job, and use native posting where the transaction has to be atomic. The failure mode that justifies the split is specific. A financial transaction in an ERP is not one write — it moves stock, it moves a debtor balance, it moves the general ledger, and those movements are only correct together. An integration that assembles that transaction from the outside, endpoint by endpoint, is one timeout away from a stock movement with no invoice behind it. That is not a bug you find in testing. It is a bug you find at month-end when the numbers do not reconcile and nobody can say why.
More on both routes, and the rest of the Saturn toolbox, is on the Accredo Saturn capability page — the integration section covers the same two paths generically, and the capability list covers the scripting, forms and reporting work this build sits on top of.
When is a build like this not worth it?
Often enough that it is worth saying plainly. There are good field service products on the market, and if a business needs standard scheduling with standard job sheets and can live with exporting a file into the ledger once a day, buying one is cheaper and faster than anything described on this page. Custom is not automatically better; it is better when the standard product cannot express the thing that makes the business money.
The case for building it into the ERP rests on two conditions. The first is that the posting has to be native — that the volume, the pricing complexity or the audit requirement makes a nightly export genuinely unacceptable rather than merely untidy. The second is that the process is specific to this business: pricing that depends on contract terms, compliance evidence that has to attach to the job, a scheduling rule no product will ever ship. If neither is true, the honest recommendation is to buy something.
The version of this question worth asking first is smaller than it looks. It is not "should we build a field service system"; it is "what does the gap between the work finishing and the invoice going out actually cost us". Sometimes that number justifies a build. Sometimes it justifies a spreadsheet with better discipline, and the right advice is to leave the process manual and make it bounded.
What changed?
The dispatch board became the single picture of the day, shared by the office and the technicians rather than reconciled between them. Parts and labour are recorded on site, at the moment they are used, by the person who used them. A completed job arrives in Saturn as a native transaction, invoice-ready, with no one re-typing anything and no docket to lose.
The part that matters commercially is the one that is easy to miss: the delay between finishing work and invoicing for it collapsed, because the two stopped being separate steps performed by different people at different times. Chasing invoices stopped being a routine part of the week.
The part that matters technically is that none of it required Saturn to become something else. The ledger is still the ledger, the reporting still reports on the same tables, and the client's Accredo partner can read exactly what was installed and why. The module was documented and handed over; nothing about it is a black box, and nothing about it is load-bearing on XBA continuing to exist.
Got a process like this eating your team's week? The audit is free — and yours to keep.
Book a free process auditQuestions about field service and Accredo.
Does Accredo Saturn have field service management built in?
No. Saturn is an ERP — finance, inventory, sales and purchasing — and scheduling technicians is outside what it ships with. Field service capability is added either by integrating a separate product with it, or by building a module that runs against it. This case study is the second approach.
Can a field service app write invoices into Accredo automatically?
Yes, and the route matters. Reads and standard records go through Saturn's OData web service API. A financial transaction — parts, labour and the invoice behind them — is better committed by native MaxBasic using Saturn's own posting routine, so the stock movement, the debtor balance and the general ledger move together or not at all.
What happens if a technician has no signal on site?
The job is captured locally and submitted when the connection returns. The design requirement that follows from this is idempotency: a retry must not be able to post the same job twice. Each completed job carries an identifier through to the Saturn transaction, so a repeated submission is recognised rather than duplicated.
Do we need to leave our Accredo partner to have this built?
No. Licensing, upgrades and the QSP relationship stay exactly where they are. XBA builds the customisation and integration layer on top and documents it so your partner can see precisely what is installed. The work is complementary, and coordinating with them directly is normal.
Would this work on an ERP other than Accredo?
The pattern transfers; the implementation does not. Every ERP has some equivalent of the two routes — a supported API for records and a native mechanism for transactions — and the design question is always the same one: which data can safely travel the general-purpose route, and which has to be posted the way the product posts to itself. Accredo Saturn is the deep specialty, but the reasoning is not specific to it.